Money for jams

To see why, imagine you are approaching a ticket barrier with two school parties in front of you. If the teachers in charge tell the kids to step aside for you, you would get straight through yet the children have hardly been slowed down at all. So what is to stop programmers giving all their traffic high weight? This is where the congestion charging comes in, and so does some tricky reasoning.

Service providers would still offer flat-rate access, but instead of download caps they would have a congestion allowance. If your congestion volume exceeds your limit you could still transfer all you wish along uncongested routes ­ or you can pay for a greater allowance.

Your software would give light, bursty traffic high weight because it will have little effect on your congestion volume; but big downloads would be set low to minimise your congestion hit. Big users, including businesses, could buy higher congestion limits. But if you played your weightings right you could download as much as you liked with little or no congestion charge.

Similarly, network operators could be charged more for sending traffic through congested routes of other networks. They compete to sell capacity, so it would still pay them to keep their own infrastructure clear, but they would have an incentive to seek out clear routes. Oddly, because traffic is controlled from the edge, operators cannot see congestion outside their own network.

Briscoe’s answer is a second protocol tweak, this time to the Internet Protocol standard, to enable a mechanism called re-feedback, which flags how much congestion your packets will be allowed to cause.
“There’s one spare bit in IP and that’s all we need,” he said. A bonus is that the system could scupper Denial of Service attacks.

It would require no hardware changes at the user level, and no infrastructure changes except at the access gateways. But getting changes approved is perhaps the biggest problem of all. Jacobson’s algorithm and TCP equality, however illusory, have achieved the status of Holy Writ.

Briscoe, by his own admission, blew his top in frustration at a 2006 meeting of the Internet Engineering Task Force (IETF) after trying for a year to explain his ideas. There are signs that people are taking his ideas more seriously, but don’t expect changes to come in very soon. “From past experience at the IETF I reckon it could take me five years to get it through,” Briscoe said.