Money for jams

Bob Briscoe talks about the internet with the world-weary air of a man who has spent years banging his head against a brick wall.

The web is clogging up with the increasing use of bandwidth-hungry applications and there are calls for content providers such as the BBC to contribute to the cost of boosting capacity. Internet service providers (ISPs) try to answer the problem by imposing download caps and throttling heavy users. Briscoe believes that much of this is unnecessary and barely effective.

A couple of tweaks to internet protocols would make access ‘blisteringly fast’ for light users while heavy users downloading as much as they do now would be hardly affected. But it would also involve a congestion charge reminiscent of that imposed on motorists who enter central London at peak times, though Briscoe objects strongly to the use of the term.

In mid-1987 Van Jacobson, of Lawrence Berkeley Laboratory, introduced a solution that has served the internet ever since. It conformed to the internet’s founding principle that traffic control is done by the ‘edge’ computers (your PC and a web server, say) using the Transport Control Protocol (TCP), while equipment on the intervening network does the routing using the Internet Protocol (IP).

If data arrives too fast for a router to handle, it starts to drop packets, causing the destination machine to request retransmission. Jacobson’s idea was that a source machine should halve its data rate when this happens, and then build up speed until packets start dropping off again.

This algorithm, applied as a TCP patch to the mere 30,000 machines then on the Net, was phenomenally successful, speeding everything up as well as relieving congestion, and its effect initially was to give each user of a channel a roughly equal share of capacity.

That it is still functioning at all, 20 years later, is testament to its strength ­ a billion machines share internet resources by making between 10 and 100 rate adjustments a second. It was fair enough for the kind of bursty traffic generated by older web activity, such as email and browsing. But recent applications, such as peer-to-peer (P2P) file-sharing, transfer data more or less continuously, perhaps 24 hours a day.

Yet each P2P stream, under the ‘equality’ principle, has exactly the same right to a channel at any instant as a light user who is using a channel in very short snatches at a time (see image here). Applications such as P2P make things far worse by sending data in multiple TCP streams, each with the same claim on capacity as one person using a single stream.

Throwing bandwidth at the problem is similar to throwing water uphill because TCP allocates the same measly share of the new capacity, says Briscoe. A costly quadrupling of the capacity of the 10Mbits/sec link would boost the transfer rate of light users from 20Kbits/sec to just 80Kbits/sec.

Data rates are not so bad in practice because some service providers themselves prioritise some traffic and throttle heavy users.

But this is patching over the cracks of a flawed architecture, in Briscoe’s view, and throttling only marginally improves speeds for light users while punishing heavy users. Briscoe has nothing against these. “We want them to use the internet. That is what it is there for,” he says. Briscoe’s proposals shift the focus from data volume to congestion volume, measured by the number of dropped packets you cause.

They involve two protocol tweaks. One is ‘weighted TCP’, a refinement of the protocol to allow application programmers to give internet traffic different priority weights. Typical bursty traffic would be heavily weighted to get a greater share of capacity if it hits a bottleneck, yet heavy, near-continuous traffic would be barely affected.