Why don’t we have peak and off-peak pricing for broadband?

Packets are not people, and the concept of “peak hour” doesn’t really work for a medium whose properties vary extremely fast.

I saw this poster on the London Underground yesterday, and as is often the case it got me thinking about the parallels with telecoms.

The poster explains the peak and off-peak fare structure for tube travel. The purpose of this pricing system is to manage the relationship between supply and demand in a system that is capacity constrained. Over short and medium timescales the supply is essentially fixed, and demand can oversaturate that supply.

This overload causes people to have to queue on the streets to get into stations, wait for multiple trains to pass in order to board, and experience delays due to people and objects getting trapped in closing doors. So it is seen as an undesirable thing!

This peak pricing scheme has several subsidiary objectives:

  • To suppress demand at peak times to avoid having to engage with exceptionally costly capacity upgrades.
  • To time-shift some demand so as to lower the peak and hence the uncomfortable and unsafe overcrowding at peak periods that deters “premium” commuter travel.
  • To price discriminate between the business and leisure passenger.
  • To meet a social need for lower fares for some groups of passengers.
  • To encourage travel when the resources are under-used, and hence customers for shops and businesses that generate wealth for the city as a whole.

What is important to observe about this is how the tube tariff is structured: the peak period is limited to before 9.30am, and between 4pm and 7pm. In other words, the periods of “high” or “excess” demand are measured in hours.

Trains are discrete objects, the services arrive spaced a few minutes apart, and the nature of the “statistical smoothing” of the arrival of humans (buffered and serialised by lifts and escalators) makes their arrival relatively predictable. So the relationship between supply and demand is a fairly simple one.

In terms of demand, humans all have similar needs for transport: you don’t have to deliver some bodies in milliseconds and others in months. In contrast, computer data is not at all homogenous in its need for timely delivery.

When we look at telecoms, whilst peak tariffs have been common for telephony, they are a notable rarity in the packet data world. We typically have a unitary charging model, billed to some percentage of maximum sustained throughput. Why so?

The key difference is that broadband is fundamentally all about instantaneouseffects of processes that happen at very high rates of change, as well as the speed of light. The result is that traffic patterns are very “bursty” and irregular.  The periods of overload are extremely short in duration, and are spread out throughout the day. Some “datagram trains” at midnight are packed, whereas others in rush hour are empty.

Whilst a broadband network may on average be busy in the evening when the surge of cat video fandom happens, applying peak pricing over that period doesn’t do much to help. It can suppress overall demand, but it cannot sift and shift the time-insensitive file store backups away from the urgent and important video conference.

Computer networks also have a mix of elastic and inelastic demand, which is unlike human traffic. A packet network has buffers that change state very quickly, so the supply is highly variable in quality. The tube network supply has a very stable and predictable quality in terms of how long you have to wait for train.

With packets we care about flows, not the experience of individual packets. For Transport for London, “every journey matters”. That isn’t true for packets. Some flows are OK with loss, others are not. The nature of the system is very different to tube travel. Packets are neither people nor pizzas.

There have been many attempts to introduce some kind of “peak pricing” for broadband, with varying degrees of technical merit and commercial success. The challenge is that for people, it is the quantity that is the central issue, whereas for packets it is the quality (i.e. timeliness of arrival). That means you have to take a fundamentally different approach.

One such approach (but not the only one) is a polyservice network. This time-shifts demand according to its quality need and cost-sensitivity by using a mix of “quality ceilings” and “quality floors”. If anyone ever successfully builds and markets one, it could be quite a thing to behold!

I would say “watch this space”, except that’s a quantity metaphor. So to be quality-centric, all I can do is suggest you “wait this time”…

For the latest fresh thinking on telecommunications, please sign up for the free Geddes newsletter.