[ NNSquad ] Re: Keith Dawson: uTorrent Responds Regarding UDP Usage

[Brett Glass <nnsquad@brettglass.com>]

At 12:21 AM 12/2/2008, Wes Felter wrote:

> > If the TCP congestion avoidance algorithm doesn't work well - which
> > is true - why not fix it instead of bypassing it?
>
> Because P2P app developers can't modify the OS kernel.

This is not correct. There are actually patches for Linux which cause
it to ignore RST packets, in an attempt to thwart their (IMHO legitimate)
use for the purpose of network management.

> People use the
> tools available to them (even if they're the wrong tools) to solve
> problems in a way that they understand (even if it's the wrong
> solution), so we have BitTorrent Inc. designing new transport
> protocols because they can't modify TCP.

Could it be that in fact they are doing so because they do not consider
their current exploitation of flaws in TCP (to wit, the protocol's ability
to do congestion management only on a per-session basis and only in
response to dropped packets) to afford them them sufficient control of
the ISP's network?

The fact is that, as George Ou notes, the effect on Internet infrastructure
could be devastating. Remember, NAT routers handle UDP by creating an entry
in an internal table when they pass an outgoing packet with a unique source
port, source address, destination port, and destination address. Because UDP
is a connectionless protocol, the router cannot watch for a FIN or RST packet
and use this as a signal that it's OK to delete the table entry. Nor can they
rely on heuristics based on the assignments of well known ports (e.g., a DNS
query to Port 53 on a server will receives a single packet as a response,
after which the entry can be deleted). Instead, they have to rely on a crude
timeout mechanism, deleting the entry after a few minutes of non-use.
Unfortunately, given the extreme aggressiveness of the BitTorrent software
(each node contacts, and is contacted by, hundreds or thousands of nodes
per minute) will likely overflow most routers' NAT tables. This will cause
the table entries for other users' activity to be dropped, resulting in
unreliable DNS and VoIP.

Another danger of the use of UDP is that the BitTorrent developers have
specifically stated that they will implement "firewall hole punching" to their
software. This is a technique in which a third host sends packets with
spoofed source addresses so as to "poke a hole" in the firewalls protecting
two others. One might, naturally, think that those who condemned the use of
RST packets for administrative termination of TCP sessions as "forgery" (even
though this is a well established technique and is mentioned in at least one
RFC) would likewise condemn the breaching of firewalls in this manner, but
we've seen no such reaction. This suggests that these parties may have a
different motive than the ones they claim.

The ironic thing is that all of this effort is being expended to move the
distribution of content from the center of the Net, where bandwidth is
plentiful and inexpensive, to the extreme edges, where it is scarce and
expensive. If those companies and organizations that did P2P simply were
willing to pay their own freight for bandwidth instead of trying to get
it for free from ISPs (and multiplying the expense many times over in the
process), the entire Net would be the better for it.

--Brett Glass

   [ Leaving aside Brett's usual posturing about what he considers
     to be "paying their own freight" and "getting it for free"
     (last time I looked, virtually all of us, from ordinary
     consumers to giant corporations are paying good money for our
     Internet connections) he does have a point about NAT tables.

     Commodity routers in particular often have very small (and
     often undocumented in size -- you don't know how small until
     you fill them up) NAT tables.  When you reach capacity, bad
     things start to happen.  And it's also true that the standard
     method for dealing with UDP in these tables is timeouts, which
     is indeed a crude technique that can be rather easily
     overwhelmed.

     This isn't to say that methods can't be designed to handle UDP
     in ways to minimize these issues, but there are certainly major
     differences between the TCP and UDP methodologies.

     --Lauren Weinstein
       NNSquad Moderator ]