Re: [ledbat] list of reasons for needing multiple TCP connections

[Eric Spaeth <[e-mail]>]

Robb Topolski wrote:
> 2.  (Until I'm blue in the face, I swear), P2P developers generally 
> are fans of the Internet and are unlikely to intentionally develop in 
> ways harmful to the network.  I don't know how else to day it.  They 
> don't ##### where they live.  They surf websites and take VOIP calls, 
> too. 
The problem with this statement is that P2P troubles are an n-user 
problem; it is often difficult for people to discern impact without 
seeing a direct and immediate negative effect from their actions.  Even 
so, I tend to think that most users don't care about the impact they 
cause on the network as long as they get theirs.  You'll notice that 
every time the topic of ISP throttling comes up on a public forum the 
first question is almost always "How do I get around it?"  with very 
little focus on "Why would the ISP spend the time and money to implement 
a throttle for P2P?"

I think BitTorrent's creator Bram Cohen said it best:  .... it's 
something he [Bram Cohen] predicted when he first thought up BitTorrent. 
"My whole idea was, 'Let's use up a lot of bandwidth,'" he laughs. "I 
had a friend who said, 'Well, ISPs won't like that.' And I said, 'Why 
should I care?'"
Source: 
http://www.sfweekly.com/2008-01-23/news/bittorrent-comcast-eff-antipathetic-to-fcc-regulation-of-p2p-traffic/3

>     It's clear that the users of BitTorrent see this as simply another
>     means of grabbing more network resources.
>
>
> 3.  I'm not agreeing with that conclusion, as it's just as plausible 
> that they want to reduce their own support load; a lot of effort is 
> dedicated to teaching users how to avoid overrunning the buffers in 
> their modem.  However, if "more network resources" are they're there 
> to "grab" and doing so doesn't interfere with anybody, then so what?  
> The design of TCP is to keep trying to grab more network resources, 
> and most applications do nothing to change that behavior.
TCP is a tamable beast; we've had decades to work out issues of 
congestion-avoidance synchronization, figure out different algorithms 
for window scaling, and implement solutions like RED to eliminate or 
reduce tail-drop issues.  Instead we're talking about replacing TCP 
transport with a hastily crafted replacement using UDP underpinnings 
primarily to get around ISP interference.  I spend quite a bit of my 
time digging through packet captures, troubleshooting application issues 
caused by developers who suffer from chronic clue deficiency when it 
comes to network awareness; (ie, it worked great from my desk to the dev 
server in the same building, but when we deployed it to users in India 
the application is slow.  Can you fix the network?)  I have very little 
faith that this will get anywhere close to right on the first attempt. 

I'm really wondering what impact this is going to have on routing at the 
backbone layer.   Many large network operators are using intelligent 
route reflectors like the Internap FCP platform or the 
Avaya/RouteScience appliances to attempt to route around congested 
links.  One of the ways they make path selection decisions is to analyze 
TCP flow performance (look for retransmits) or read router NetFlow data 
to evaluate performance of various paths.   How will the use of uTP 
affect route selection by these appliances once they start to get a 
significant amount of traffic for which they are unable to ascertain 
flow statistics?

-Eric
_______________________________________________
ledbat mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ledbat