Uncategorized —

IETF: find more peer-to-peer bandwidth, but use it sparingly

The IETF is considering new P2P work: a mechanism to find more bandwidth for …

During its 72nd meeting this week in Dublin, the Internet Engineering Task Force (IETF) held two birds-of-a-feather (BoF) sessions about bandwidth for peer-to-peer applications. The first was about finding more bandwidth for P2P apps, the second one about how such apps can use less of it.

Finding more

The topic for the ALTO (Application-Layer Traffic Optimization) BoF was to come up with a way for ISPs to signal which network paths peer-to-peer applications such as BitTorrent should use as their first choice. BitTorrent typically sets up several dozen connections to BitTorrent users elsewhere. It then tries to download over each connection, but it only uploads data over about four connections at a time. If BitTorrent manages to set up connections to destinations reachable over high-bandwidth paths when starting a download, it can reach much higher download speeds more quickly.

On the surface, an "oracle" server that knows which paths have the best bandwidth might seem to be a bad thing for ISPs like Comcast that have been trying to control P2P bandwidth. But that's not necessarily the case: the all-knowing oracle could also be equipped to guide peer-to-peer traffic to avoid congested parts of the network and use cheap or under-utilized network paths instead.

The idea still has to face a host of open questions, so it's not a given that the "oracle" service will ever see the light of day (or the inside of the tubes).

Using less

A couple of days later, the TANA (Techniques for Advanced Networking Applications) BoF discussed implementing a scavenger service for peer-to-peer traffic. Under normal circumstances, packets flowing over the Internet receive a best effort service: the routers do what they can to deliver the packets.

There has been plenty of work in the IETF to allow for better than best effort service, but the idea behind the "scavenger service" is different. If you can give certain packets a worse than best effort service, they won't get in the way of packets sent by other applications. So it's no problem to fill up network links with packets that are marked with a code requesting the scavenger service—if there's not enough bandwidth, the scavenger packets are the first to be thrown away.

Unfortunately, most routers aren't set up to support this scavenger service, and even if they were, using the service requires complex settings in the few applications that support it, like Azureus. Solution: rather than let the routers throw out scavenger packets as needed to keep the tubes from getting clogged, implement a scavenger service in TCP's congestion control.

Normal TCP behavior is to increase its transmission speed relatively slowly, and then back off quickly when packets are lost, presumably because the network couldn't handle the rate at which TCP was sending. The scavenger service is implemented by simply ramping up more slowly and backing off even more quickly than with regular congestion control. There seemed to be the prerequisite "rough consensus" in the BoF that this idea has some merit.

Unfortunately, there is a slight complication. TCP congestion control is implemented in the kernel of an operating system. Changing this code is always tricky, but not a huge deal if you have the kernel source, as with Linux, BSD, and even Mac OS, but it gets much harder in the case of Windows. Microsoft has implemented a number of changes to TCP in Vista, but it seems unlikely it would push out an additional TCP congestion control algorithm in an update—this would probably be a feature in Windows 7, if that. And it's unlikely many Mac users will be compiling their own kernel just so their BitTorrent downloads are friendlier on the network.

The alternative would be to use the only other protocol that gets through firewalls and NAT devices reliably: UDP. In the BoF, some argued that this is the only workable choice, while others expressed disgust at re-implementing TCP over UDP just because it's inconvenient to wait for the OS vendors.

Getting a BoF group approved is the first hurdle to jump in having a new working group chartered in the IETF. Now that the BoFs have taken place, it's up to the IETF's leadership to determine whether this work should find a permanent home.

You must to comment.