Data caps are controversial. Many people think they are a scandalous price-gouging tool for greedy ISPs. Others think they are a reasonable response to the gluttony of users. The (statistical) reality is more complex. This article checks out how the dough is really connected to the data.
We all want a pizza action
Let us first remind ourselves of the basic facts about how statistically multiplexed pizza delivery networks work. I hope we can all agree that their purpose is to create value to users, and that they do this by moving pizzas around. This value comes from delivering flows of individual “slices” to the right places fast enough, and that the topping is still warm on arrival.
You don’t want cold pizza delivered for dinner. Having a stack of congealed meat feast arrive hours after bedtime does not make for a great home dining experience. So a good user experience depends on getting quality as well as quantity.
The problem is that the delivery system – the underpaid Indigestion Service Provider guy on his moped brining your toasty packets, sorry, pizzas – is in a lot of demand. Many very hungry and impatient people, some living miles from the restaurant, all want to be fed. This peak demand is particularly evident at the very moment when everyone is most ravenous: on a Saturday night as a big game is on the TV, as demand is highly coupled and correlated.
So we have a finite delivery resource (supply), and a potentially unbounded claim on that resource (demand).
Rolling in the deep pan
Now imagine we have three types of customer: the President, pot-heads and plebs.
The President is insistent on getting her pizza NOW and HOT. The penalty of non-delivery of the right quality and quantity of presidential pizza is a threat to pass a law that regulates the pizza market to ensure that presidential pizza is always available at pizza outlets all the time, even if this makes the whole industry uneconomic and closes down.
That means on nights when she is in residence, the pizza parlour has to refuse all other orders, just in case a presidential one comes in. The order entry system is “full” at zero orders!
At the other extreme, we have the pot-heads. They are typically stoned out of their minds, have the munchies, and can’t keep track of time. They barely know which way up to put the pizza in their mouths, and don’t care if it is hot or cold – assuming they can even notice the difference.
On most nights, the customers are plebs. They are OK as long as they don’t go to bed hungry, and their pizza is not stone cold.
As you can see, the pizza business has different kinds of demand that require different types of supply, and you have to get the right quality and quantity to the right customer.
Two tasty toppings
What happens is that pizzas pile up at the kitchen’s delivery counter, slowly going cold. Each driver walks up to the counter, takes the pizza that’s been waiting longest, and drives off with it. The selection of which pizza to take is without regard to either the length of journey, or how long the customer has been waiting. (One driver’s college-educated brother could do better at scheduling the orders, but he instead became a lawyer and drafted a pizza neutrality law to prevent such manifestly unfair practises, since all slices are created equal.)
When demand exceeds supply, it can be for two reasons: either there is too much volume to bake and carry (a capacity constraint) or the food cannot all be delivered quickly enough to arrive at an acceptable temperature (a schedulability constraint). These TWO (note again for the hard-of-thinking: TWO) constraints on supply mean you sometimes can’t always satisfy demand.
For Presidential demand, everything is limited by the scheduling constraint. You make no money if you just pump out cold pizzas. All non-Presidential orders experience 100% loss. For pot-heads, their deliveries are entirely capacity-constrained. You don’t get any benefit from keeping slack in the system, or expediting orders. For the plebs, they have both capacity and scheduling demands, and there are trade-offs in getting satisfactory outcomes for both.
Hence the pizza network (by necessity) always makes choices over how much pizza to make, and which deliveries get hit with the disappointment of cold and hunger. There’s no way of avoiding the choice: the business is a trading space between supply and demand. The only decision to be made is who gets hit with the disappointment, and do they get cold pizza (delay), or goes without entirely (loss)? Thus it’s a system also with two degrees of freedom, and they can be traded.
In the worst case, your customers all go away because they consistently either don’t get the quality or quantity they need. Alternatively, they may like the pizzas, but are priced out of the market by being made to pay for a quality they don’t value, or idle overhead resources. If the customers leave, then you are left paying the delivery drivers to do nothing. In the best case, you make the right trades, pricing reflects the value received, and the drivers are all busy all the time. You make loads of profit and have happy customers.
The difference between these two outcomes is how we allocate pizzas to delivery drivers, and how our prices reflect our constraints and the nature of demand (quantity and quality).
The paradoxical packet predator
OK, we’re done with pizzas. Let’s talk packets.
When packets sit in queues, waiting for other packets ahead of them to be transmitted, we have contention for the transmission resource. Protocols like TCP attempt to limit contention by backing off demand when “orders” get lost. Paradoxically, TCP first fills queues to cause overload and packet loss, and then backs off. This is why TCP is apredatory protocol – a TCP flow is quite likely to cause loss to rival flows, before encountering loss to itself! Any attempt to be more civilised, like backing off as you observe increasing delay, results in being eaten alive or starving to death: you are out-competed by the other connectivity carnivores.
(As an amusing aside, TCP has a nasty habit of dialling up additional orders for more packets when the first order isn’t delivered quickly enough, and on mobile networks operators insist on the moped guy driving until the point of death to deliver, no matter how long it takes, because the billing system has already clocked every packet on the way out. Hence the “three truckloads of cold pizza” problem as you go from 3G to 2G and your phone turns into a brick for two minutes as useless timed-out data continues to slowly arrive, in triplicate, for which you are being billed, in triplicate.)
So in any TCP/IP network we have a great deal of contention going on. As the applied load to the network is increased, this contention grows. Eventually it causes applications to fail: web pages don’t load, Skype turns you into a stuttering mess, and YouTube displays the circle of death. If you keep adding load, the network becomes unstable and collapses. So you have to keep it within its predictable region of operation.
Your demand for packet delivery arms a quality of experience hazard to everyone else,even if the hazard does not fully mature into application failure. Every usage – or evenpotential for usage – of such a shared resource detracts from the value to other users. (The President only has to be at home, and doesn’t need to even place an order, for the whole capacity to be allocated.)
Thus broadband is a fundamentally rivalrous resource at all times and applied loads.
The President says she “didn’t swallow”
As such, all your packets always appear as pollution to other users. Yet with volume data caps the polluter never pays for degrading the schedulability resource, only the capacityone. We all have the attitude of presidents, the appetite of pot-heads, and the actions of plebs. We want the highest possible quality, but place enormous orders without regard to whether they can actually be delivered ‘hot’, and then complain about the failures of the ISP when they don’t deliver everything we order as fast as we want it.
Now you can see why data caps are crap, sorry, not aligned with the fundamental reality of statistical multiplexing. Since we have TWO constraints, metering and measuring on just one of them on its own is never going to work. Data caps set a hard volume limit, not only ignoring the schedulability constraint, but also ignoring the trading space below that limit (i.e. the guy at the counter handing the pizzas to the delivery folk).
You then dump all orders over that limit, even if the delivery network is idle and you are paying the delivery drivers to do nothing. This is hardly the most intelligent way of operating a communications network. Bandwidth is too a weak a proxy for the actual resource used.
Packet pollution pays
The reason we’re in this pickle is that users feel entitled to communicate as if the network was empty, and ISPs collude with this fantasy by selling “bandwidth”. Users imagine they are still accessing “presidential” TDM networks that don’t have contention. Common carriage regulations ignore issues of contention, and implicitly assume complete isolation from other users and services. So the regulatory lawyers are equally out to dinner (if only because their experience of home delivery is no good).
When contention becomes too noticeable we talk about a false concept of “congestion”, and have gone on a mathematical wild anchovy chase for a “congestion pricing” algorithm. The whole business is baloney.
But we don’t live in that TDM world any more. Contention actually matters, and the schedulability constraint is every bit as important as the capacity one, and often more important as we demand faster delivery of ever more quality-demanding flows.
A side-order of statistics, sir?
There are two ways of resolving this problem.
The first is to create some very complex scheduling pricing systems that use advanced algebra to confuse the hell out of the public. This isn’t such a great idea, even if obfuscatory pricing is a telco speciality and it would make Amdocs richer than Apple.
The other is to have a word with the guy handing out the pizzas at the counter, and get the underlying scheduling issue sorted. By raising the scheduling capacity constraint, you can deliver a lot more pizza on time to more people. Orders from Presidents, plebs and pot-heads can all be supported at once.
Then you can begin to rationally price by temperature – i.e. quality – to reflect your constraints! Any user can be given an “uncapped” plan, as long as they are willing to accept that quality can (and must) vary. By separating the network into multiple qualities (note: not “tiers”), a simple and rational pricing scheme can be achieved.
Anyone for an extra hot polyservice pepperoni pizza network?
Please get in touch to discuss your broadband network. We can help you identify and manage the performance hazards.
To keep up to date with the latest fresh thinking on telecommunication, please sign up for the Geddes newsletter
Read It Now
