Packets are not pizzas: Why ISPs are content, not carriage

You can see Justice Scalia make this argument in the famous Brand X case, where he mocks people who argue that ISPs aren’t carriage:If, for example, I call up a pizzeria and ask whether they offer delivery, both common sense and common “usage” … would prevent them from answering: “No, we do not offer delivery–but if you order a pizza from us, we’ll bake it for you and then bring it to your house.”

To make his point clear for the hard-of-thinking, he continues:

The logical response to this would be something on the order of, “so, you do offer delivery.” But our pizza-man may continue to deny the obvious and explain, paraphrasing the FCC and the Court: “No, even though we bring the pizza to your house, we are not actually ‘offering’ you delivery, because the delivery that we provide to our end users is ‘part and parcel’ of our pizzeria-pizza-at-home service and is ‘integral to its other capabilities.’”

He snarkily ends:

Any reasonable customer would conclude at that point that his interlocutor was either crazy or following some too-clever-by-half legal advice.

There’s only one problem: this analogy is a load of pepperoni.  It fails to capture the essence of what an ISP is about.  His legal advice is too-simple-by-half. Why so?

The pizza analogy can be a useful pedagogical tool. I’ve used it to illustrate packet scheduling. However, such reasoning by analogy is not a basis for reality-based regulation. The moment you begin to reason about packets as if they were pizzas, you are assuming a congruent mapping between these. Yet the junk and infidelity between the model and reality are so large as to make the parallel useless.

To see why, let’s imagine that pizzas could be treated like packets.

Packets are not physical things

If pizzas were packets, the delivery person could perfectly legitimately turn up at the door asking for payment, whilst apologising that she has dropped the pizza down the road. There is no recompense for loss. She could break your pizza into bits, and deliver slices of different pizzas in an arbitrary order, some stone cold, and still be working perfectly to specification. She could even hand you duplicate pizzas!

Packets only have utility as parts of flows, not individually, unlike carriage.  Since packets are merely arbitrary divisions of a data flow, we are only interested in the population statistics of loss and delay, not any individual item. After all, what kind of pizza delivery service offers a managed level of hunger and starvation over long periods?

With packets, computing processes can conjure unbounded elastic demand at effectively zero cost. There is no historical precedent in carriage of an infinite pizza-duplication machine throwing multiple copies of pizzas out of the oven into the delivery truck, all to be delivered piping hot for the same fixed price.

The nature of the packet delivery service contract is completely different to ordering one pizza. Carriage sees value in the item, whereas it is a basic error to reify packets; the value is in the timely computation.

Packets use a shared contended medium

With a pizza parlour, there is a close relationship between the rate at which they can bake pizzas and deliver them. The amount of contention for delivery resource is relatively low, meaning pizzas can be delivered quickly whilst still hot. The delivery time is dominated by physical distance, not the waiting time on a shelf as they come out of the oven.

Compare this to packets, where individual users of packet networks can saturate the entire resource (e.g. a single handset on an LTE cell, gigabit fibre into gigabit backhaul). Pizza orders from one user don’t soak up the entire local pizza chain’s delivery capability. Yet the very core job of a packet network is to enable such resource contention. Dynamic effects readily dominate the static structural delivery delay.

The way we deliver packets is different to pizzas. Pizzas move down the street. With packets, there is no motion involved whatsoever. (Hint: it’s not carriage.) There is only repeated copying of bits (at the speed of light!), plus the erasure of packets.

It’s a little bit like the pizza chain having hot storage cases dotted around town, and hiring Ferrari taxis to shuttle back and forth between those locations, each taxi having its own small patch. There is only so much storage space in each box, so extra pizzas get thrown away. Those that are there slowly go cold until the next taxi picks them up.

ISPs came into existence because they were able to take telecoms “carriage” services (the “taxis”), and extract a statistical multiplexing gain from them. Rather than one taxi per pizza delivered end-to-end, you can aggregate demand as you shuffle them between boxes to avoid unused transport resources.

From the very beginning, ISPs have performed a non-telecoms service. The raison d’être of an ISP, and what distinguishes it from a telecoms circuit, is to contend a resource and thus create and manage the resulting trading space.

The pizza trading space isn’t like the packet one

When you order a pizza, you expect it to be delivered within the estimated timeframe, or you complain and get your money back. You can only place a limited size of order before they tell you “sorry, we can’t bake ‘em any faster!”. You don’t ask for some parts of your order to be delivered extra-quick, or tell them it’s OK to hold off a while if anyone really hungry calls in with an order.

With packets we have intra-user and inter-user contention. These resource trades may be priced differently. This has no parallel in carriage. With packets there is also a “technical contract” constraint on demand at ISP boundaries (so the service level depends on not over-saturating the resource). This is not a feature of carriage: it is not a breach of contract to offer too much to carry.

For computing applications we each have an (implicit) “intentional semantics” for the order in which applications should fail when the system is saturated. For example, it’s OK for the nightly backup to miss its deadline if I’m watching Netflix all night. (Whether we have the ability to express these intentions and have the network execute them is another matter.) That means there are couplings between flows of packets, e.g. inbound/outbound, within the same application, and between different applications and users.

Such couplings have no parallel in pizza delivery. The trading spaces are fundamentally different. Since control of the resource trades is the defining aspect of regulation, failure to grasp the nature of the trading space is fatal to Scalia’s reasoning.

Packets are really, truly, not like pizzas

When you consider these issues together you get a qualitatively and categorically different thing from carriage. The key mistake is to reason about distributed computing as if it is like moving physical objects along defined pathways within minimal interaction with each other. We have become beguiled by the idea of carriage well beyond its bounds of utility! Why so?

We can get away with the “carriage” idea for pizzas, or packages in the post. That is because the system is (supposed to be) lossless, has a very narrow range of variability of supply, and (compared to computing) relatively homogeneous demand. It thus appears predictable to the point of being deterministic.

Telecoms circuits (using TDM) are likewise lossless, uncontended and deterministic. Hence the carriage metaphor could be stretched to this corner case of distributed computing. Once the circuit was established, the trades were externalised from the network, and placed entirely in the hands of the circuit user.

With broadband and packets, we’ve left that universe. The carriage metaphor doesn’t stretch, it breaks. The reality of ISPs is very different to the naïve model we are being presented with.

ISPs are distributed computing services

What ISPs do is to share resources among many users and uses by the operation of a resource trading space. This is conceptually the same as how Windows or OSX share resources in their operating systems, or a cluster in a data centre rack. We just widen the scope over which the resource scheduling is being done. There is no scope at which this distributed computing resource scheduling suddenly becomes “carriage”, just because you bought a telecoms circuit to do the interconnect.

The essence of an ISP is the existence of the trading space, and the computationalfunctions that control this resource sharing. The ability to copy at a distance is a side-effect of the computations that the ISP performs. This is paradoxical, but that’s just the way the world is. Get used to it!

There are short-term resource trades, e.g. queues and QoS mechanisms. There are long-term resource trading options (e.g. SDN orchestration) and (sometimes) a need for route determinism (e.g. voice calls). These trades have no carriage equivalent, principally because bit and atoms have different properties.

Treating ISPs like carriage tramples on basic freedoms

There is a freedom of association of the users and ISPs that does not exist with a common carrier. I can legitimately choose not to carry porn sites, or domains that end in the evil letter ‘z’. I can aggregate any (or no) applications into the service. There are no “special services” vs “public Internet”: these are false conceptual divisions.

The choice over performance allocation is code, no different to the code that forms the rest of the (distributed) application in a PC or data centre. This is a basic freedom of speech right being exercised by the ISP on behalf of its users (and especially for intra-user contention). Ordering of performance is an editorial choice like the ordering of articles in a publication.

Platforms that dynamically match supply to demand

Since we alluded to pizza delivery being like lots of taxis running around, we have an example from the world of physical transport to draw upon to illustrate the point: Uber. (For a moment, put to one side Uber’s dodgy business ethics, as they aren’t relevant to this discussion, even if they may parallel some ISPs!)

What Uber does is to offer a trading platform to match supply to demand. Users express where they would like to go, and the type of service they would like. A dynamic price is then given for that. They don’t own or operate the taxis. They can decide what destinations they want to offer. They can choose to optimise journey times to some destinations, or for some users. It’s all their choice. They can even refuse to service you, as long as it is not on unacceptable discriminatory grounds like race.

It is the same matching function that aligns supply to demand that is the essence of an ISP: you can outsource every other element, except this one. It is, indeed, “integral to its other capabilities.”

Because a service like Uber uses carriage as an input, it does not become carriage. That is like your newspaper being regulated as a trucking company because it can transport your classified ad. Similarly, just because your ISP owns some of the network elements doing carriage doesn’t make the ISP carriage. That is a fallacy of composition.

ISPs are content, not carriage

Uber is content, not carriage.  It’s a software application, running in the cloud, on a centralised computing platform. An ISP is content, not carriage. It’s a software application, running on a highly distributed computing platform, made mostly from specialised computers called routers.

Got it? You don’t have to be crazy interlocutor (or even a Supreme Court judge) in order to believe it.