[ NNSquad ] Re: Fear mongering and trolls (Re: Keith Dawson: uTorrent Responds Regarding UDP Usage)

[Richard Bennett <richard@bennett.com>]

One of the interesting facts that's emerged from the rather wide 
discussion of my recent article is BitTorrent, Inc.'s motivation to 
develop their own congestion avoidance scheme over UDP: classical TCP 
congestion avoidance doesn't work well for applications that use TCP 
streams the way BitTorrent does. It takes too long to respond to 
congestion, and it doesn't prevent BitTorrent from dominating the 
out-bound channel from a user's home network. So they've been tinkering 
with their own scheme for some time in hopes of doing for themselves and 
their users what TCP doesn't do for them.

Of course, a number of people, myself included, have been pointing out 
the deficiencies of TCP for this kind of application for a long time, 
only to be criticized as "clueless" or worse by people who believe that 
TCP is a sacred cow Since TCP doesn't effectively rate-limit P2P, it's 
necessary to resort to other means to bring about fair allocation of 
network resources. One means of doing that is DPI-based classification 
and traffic policing, and another is to revise the end-to-end congestion 
avoidance algorithm. Both approaches have their place.

UDP by itself is neither evil nor dangerous, it's a tool that can be 
used to increase or decrease the efficiency and stability of the 
Internet. In the BitTorrent case, they're clearly aiming for an 
improvement. But we can't say that for all possible systems of this sort 
implemented by people more concerned about grabbing a larger chunk of 
Internet bandwidth at the expense of their neighbors. Fortunately, this 
latter case is largely speculative at this point. While we can hope it 
remains that way, there is every reason to expect that it won't.

RB

David P. Reed wrote:
> There has been huge confusion appearing on this list regarding UDP.  
> The view that UDP = danger has been expressed.
> This is incorrect, and seriously counter productive, especially if 
> these arguments are presented to policy makers.
>
> I will keep this brief, but am willing to expand on these points if 
> necessary.
>
> 1) UDP is not "dangerous".  It is a well-understood standard, and 
> requires only a little care in use to do things that *are not 
> possible* using TCP.  As an example, the dominant VoIP standard, SIP, 
> uses UDP (as the transport for RTP), so if we were to ban UDP, it 
> would break VoIP as well!   Similarly, streaming video standards use UDP.
>
> 2) If there is an issue at all, it is that BitTorrent might not "back 
> off" when congestion occurs in some downstream router.  That's not a 
> good way to design BitTorrent, because it will make BitTorrent work 
> *worse*, by forcing the routers that get congested to discard the 
> BitTorrent packets themselves.
>
> I have some confidence that BitTorrent and uTorrent guys actually know 
> how to implement protocols that work - I know the inventor of 
> BitTorrent, and he is quite savvy, and has shown a great deal of 
> interest in making protocols that "behave".   If they do not work (and 
> there is a technical measure of this, well known in the congestion 
> control community) then they can be fixed.
>
> 3) The Internet has shown itself to be pretty robust, all things 
> considered.  Many fear-mongers (starting with Bob Metcalfe) have 
> claimed that it will all come crashing down.  It has not.  It hasn't 
> even come close, though some people like to tell just-so stories about 
> one or another large-scale problem.   The proper response to a problem 
> is to measure it, understand it, and fix it.
>
> Here's my advice: Don't listen to fear-mongers.  Ask for data that 
> shows evidence for their claims.  Take a deep breath. Evaluate the 
> risk, and take a measured response.  Don't buy gear from 
> fear-mongering salespeople with kludges like "RST injection" or Deep 
> Packet Inspection.
>
>   [ For readers who are unfamiliar with David, he *created* UDP, so
>     he knows of what he speaks.  David also makes another important
>     point -- when there are problems, the proper course is to fix
>     them.  Brett suggested that years ago I postulated an "Internet
>     Meltdown."  What he's actually referring to is a PFIR
>     conference I held aimed at finding specific solutions to
>     *prevent* the meltdown of the Internet.  And so far we have
>     collectively succeeded.  But many of the same risks do remain,
>     if changed in form -- and new risks have since appeared,
>     especially commercial and policy-related, rather than strictly
>     technical.  There's continuing work to do -- that's part of
>     what this list is about.
>
>     It's similar in a way to the situation we had around Y2K.  If
>     steps hadn't been taken proactively to fix what needed to be
>     changed, there could have been some serious problems (though
>     civilization wasn't going to collapse from Y2K failures in any
>     case).  But we did what needed to be done, and actual Y2K
>     problem events were comparatively limited in number and
>     severity.
>
>     In the case of Y2K though, we were mainly dealing with technical
>     changes.  With the Internet, the intersection of technology and
>     policy with commercial interests makes for a considerably     more 
> complex situation.  But we can succeed, if we have
>     (as Dr. Strangelove would say) the will to do so!
>
>     -- Lauren Weinstein
>        NNSquad Moderator ]
>