Re: BitTorrent uTorrent 2.0 uTP will self-throttle to protect networks

[David Farber <dave () farber net>]

Begin forwarded message:

From: "David P. Reed" <dpreed () reed com>
Date: November 2, 2009 9:34:21 PM EST
To: George Ou <george_ou () lanarchitect net>
Cc: "'Vint Cerf'" <vint () google com>, "'NNSquad'"  
<nnsquad () nnsquad org>, "'Lauren Weinstein'" <lauren () vortex com>,  
"'Richard Bennett'" <richard () bennett com>, "'Dave Farber'" <dave () farber net 
>
Subject: Re: [ NNSquad ] Re: [IP] BitTorrent uTorrent 2.0 uTP will	 
self-throttle to protect	networks



On 11/02/2009 08:40 PM, George Ou wrote:
> It’s not just Richard Bennett that disagrees with Vint Cerf on Net  
> Neutrality.  Dr. Robert Kahn and Dr. David Farber are on that list  
> as well and they do not have an aversion to intelligence on the  
> Internet and they don’t believe that intelligence needs to be  
> regulated out of existence.
I don't understand what point you are trying to make here.   Is this  
some kind of allusion to a weird kind of democratic voting  
institution?   Are all the "Dr." mentions supposed to be some kind of  
credentialism?
I haven't spoken to Bob Kahn recently, but I have spoken to Dave  
Farber.  His view as explained to me about Net Neutrality is that he  
doesn't trust the government to implement any kind of rule without  
screwing it up royally (I'm happy for Dave to correct me).   I could  
ask Bob - we're good friends  and have been since he recruited me into  
the Internet project.   However, knowing Bob, I suspect his concerns  
about Net Neutrality are similar: he doesn't think regulators should  
design outcomes.   I personally tend to agree with that sentiment -  
but I believe regulators are needed, not for design, but to insure  
against misbehavior by entities that have too much market power.  And  
we see lots of claims being made by companies' lobbyists that are  
similar to the old Hush-a-phone and Carterfone claims: if users and  
entrepreneurs were to run their own applications and define their own  
priorities, the whole telecommunications system would fall apart, so  
the operators should be screw around with user-paid-for applications  
like BitTorrent, calling them "stealing".

No one has ever suggested that "intelligence should be *regulated* out  
of existence".  Those are your words, a "straw man" of sorts - how you  
would characterize someone else's views.   I don't use the word  
"intelligence" because I think (with Weizenbaum and others) that it  
cheapens the term to apply it to powerful technical methods of  
whatever sort.   However, I would argue that having the network  
elements involved in transport try to "optimize" functions other than  
efficiency of bit transport and flexibility of switching (routing  
included) is not a good choice.   Blurring the terms together to argue  
bizarre constructions about "intelligence" and "regulation" makes for  
great political speeches.  It's a lousy approach to technical design  
and architecture.
> You are mischaracterizing the problem by suggesting that a network  
> has to inspect the contents of the packets (not that there is  
> anything wrong with content inspection and DPI) to classify  
> priority.  There are very accurate ways to classify traffic and it  
> has nothing to do with inspecting the content of packets and Richard  
> Bennett described one of them on a comment to my site where he stated:
> “There’s actually a simpler way to do this that doesn’t require the  
> ISP to examine the traffic to determine what’s what at all: divide  
> the time into small sampling intervals (sub-second) and give the  
> first few packets in each interval highest priority; then lower the  
> priority of each following packet linearly. During periods of  
> inactivity, allow credits to accumulate that increase the number of  
> high-priority packets.
>
> That’s not the whole story, of course, but it’s a good start.”
 Perhaps I miss the point, but how does this algorithm work at all to  
give what the user wants priority to be?  It sounds like a scheduling  
queue discipline in a time sharing system where it is assumed that  
light users are supposed to get more performance than users who are  
using complex algorithms but need real time response.   It doesn't  
tell you "what's what" - all it does is define a sharing discipline  
where all of the packets are treated them same, except for their rate  
of arrival.   When an engineer says: no one should ever want to do  
that, I hear "I know what's good for every user".  That's arrogance.
> There are very accurate ways to simply analyze the traffic pattern  
> to correctly identify the needs of applications and to fairly  
> allocate bandwidth and queue management.  Just alternating the queue  
> between different applications and different users would be  
> infinitely more fair than a dumb FIFO system.
Who proposed a "dumb FIFO system"?  Again, just a strawman argument -  
is this anything other than mischaracterizing what others are saying  
so that you can be right?  The Internet is full of pretty damn  
sophisticated technology that works smoothly under the IP  
abstraction.  IP is not "FIFO" - the "in-order delivery" requirement  
of *some* applications is provided by TCP or by (timestamp ordering  
in) RTP.  "At most once" delivery is achieved by packet labeling and  
discarding at the receiver.  "At least once" delivery is achieved by  
source retransmission until acknowledgement.   The underlying  
transport networks can work by ESP if someone figures out how ESP  
works.  No rule against using intelligence in the underlying  
networks.  The issue is just that the end-to-end protocols are not  
*dependent* on the underlying network.

> Lastly, you keep ignoring my statement that user or application  
> preference SHOULD TAKE PRECENDENCE over the ISP’s default settings  
> so long as it is within quota.  Sorry to yell, but you seem to be  
> ignoring this very important point and you’re misrepresenting my  
> position by doing so.
There are no quotas today.   I cannot respond to your point in the  
absence of the quotas you imagine to be real.   What is the language  
of "default setting" expressed in?

I take it you are proposing a network architecture other than the  
Internet because you refer to a very differnet approach.   Feel free  
to construct a worldwide network other than the Internet, get lots of  
applications to use it, finance its deployment.  Fine.  Don't call it  
the Internet, and you've got a potential winner.  Perhaps it should be  
called "The Bell System".   It didn't deliver web pages that are  
sourced in pieces from lots of different servers within milliseconds,  
but it was damned good at delivering isochronous single fixed rate  
streams from one point on the globe to another.    Maybe it would have  
been a better direction.  The ITU thought so.  We could write an  
"alternate history" science fiction story, just like the idea of  
digital steam-powered computers created "steampunk".

But the Internet has done pretty well.   Why break it?  To prove that  
Metcalfe was right that the Internet couldn't work at scale?
> I believe that it is fair to say that the belief that low bandwidth  
> applications (especially real-time) don’t deserve to be prioritized  
> over high bandwidth applications is fringe and I think many good  
> engineers would share that position.
Many people are more flexible in their thinking - they are capable of  
thinking that priority has no inherent connection to bitrate.  But if  
you cannot imagine that, I guess you think that more flexible thinkers  
are fringe thinkers.   I don't know what makes a "good engineer".   
However, since my father was an engineer, and I was trained by  
engineers, I suspect that the tradition of engineering focuses on what  
*users* want and not what *engineers* want them to want.

> George
>
> From: David P. Reed [mailto:dpreed () reed com]
> Sent: Monday, November 02, 2009 5:19 PM
> To: George Ou
> Cc: 'Vint Cerf'; 'George Ou'; 'NNSquad'; 'Lauren Weinstein';  
> 'Richard Bennett'; 'Dave Farber'
> Subject: Re: [ NNSquad ] Re: [IP] BitTorrent uTorrent 2.0 uTP will  
> self-throttle to protect networks
>
> I don't think the proper argument is about credentials.  The proper  
> argument is about design and architecture.   Bennett keeps trying  
> (on this and other lists) to impute motivations to people, to make  
> claims about their deviousness, etc.
>
> Vint's original point is about putting the user in control of  
> priority, since the users (and the services the user uses on the  
> other side of the network) know what's important and what's not.    
> Reading tea leaves by inspecting the contents of packets for clues  
> is a piss-poor way to judge what the user wants.  Let the user say  
> "this stream of packets is life and death" even if it looks like a  
> music download, and this is "not terribly important" even if it  
> looks like a telephone call.
>
> It's not up to the ISP to decide for the user what services are  
> important and what protocols are important.
>
> Trying to claim that Vint's view on this is a "fringe" idea is just  
> nonsensical.
>
> On 11/02/2009 06:34 PM, George Ou wrote:
> Vint Cerf says: “I don't understand why a low bandwidth application  
> is necessarily higher priority than a high bandwidth one for example.”
>
> With all due respect to your credentials, it seems like you’re  
> taking end-to-end too literally and even more so than most of the  
> authors of that paper.
>  I think you have a fringe position that a lot of great engineers  
> and academics would vehemently disagree with.  In fact it violates  
> the most fundamental concepts of fairness that a low bandwidth and  
> non jitter-inducing applications such as VoIP or online gaming (sub  
> 100 Kbps) shouldn’t have their packets forwarded first.  Despite the  
> lower priority state, the high bandwidth applications WILL STILL  
> receive the highest average bandwidth application and the overall  
> file transfer speed of a P2P application would be unchanged.  So the  
> P2P application will experience zero degradation (I’d argue it would  
> improve in performance because fewer people would shut P2P off if it  
> is less toxic) and VoIP or online gaming would experience close to  
> zero jitter.  The fact that we’re doing round robin on the transmit  
> queue is fundamentally more fair than a First In First Out (FIFO)  
> system.
>
> The system if implemented very accurately if it measures protocols  
> based on data patterns and not just simple port number  
> identification, it would prevent protocol masquerading abuse and it  
> would avoid misclassifying some “P2P” protocols such as Skype as a  
> “background” application.
>
>
> Vint Cerf says: “Nor do I see that low duration should necessarily  
> have precedence over high duration (regardless of bandwidth).”
>
> I have made it clear in figure 4 of my article on why this makes  
> sense (concept thanks to Bob Briscoe).  Assuming that both  
> applications are bursty e.g., they take whatever bandwidth the  
> network can feed them, the lower duration application with much  
> smaller transfers should always get higher priority.  Again, this  
> would result in no performance declination for a large bulk transfer  
> since the low duration application would simply get out of the way  
> sooner.  The difference is that the low duration application (web  
> surfing) would run MUCH better than before which would allow users  
> to leave their P2P or any other file transfer application running  
> 24x7 without fear of degrading their network.  The result is that  
> web browsing and other low duration applications run much better and  
> P2P would run faster due to the increase in available seeders.
>
>
> Vint Cerf says: “I can readily understand, for example, the shaping  
> of the overall traffic envelope for a given user, based on the  
> service class to which that user belongs (here I am thinking of  
> maximum burst capacity as a measure of "class").”
>
> As I’ve mentioned before, you are severely limiting the tools  
> available to engineers and services by suggesting that the only  
> permissible differentiator between classes should be maximum  
> bandwidth.  Moreover, there’s no reason that users shouldn’t be  
> allowed to purchase different levels of fractional ownership (in the  
> form of usage caps) and be permitted to purchase multiple usage caps  
> e.g., one for low/medium/high priority where the lower priorities  
> will have the most generous usage caps (possibly no caps).
>
>
> George Ou
>
> From: Vint Cerf [mailto:vint () google com]
> Sent: Monday, November 02, 2009 3:06 PM
> To: George Ou
> Cc: 'David P. Reed'; 'NNSquad'; 'Lauren Weinstein'; 'Richard Bennett'
> Subject: Re: [ NNSquad ] Re: [IP] BitTorrent uTorrent 2.0 uTP will  
> self-throttle to protect networks
>
> george,
>
> Yes I do have problems with the default choices as I am not sure it  
> is clear that these defaults make sense. I don't understand why a  
> low bandwidth application is necessarily higher priority than a high  
> bandwidth one for example. Nor do I see that low duration should  
> necessarily have precedence over high duration (regardless of  
> bandwidth). These choices seem bereft of clear rationale.  I think  
> one area that may drive our differences is whether there is an  
> overall workable way to allocate capacity among users, independent  
> of priority within that capacity. I can readily understand, for  
> example, the shaping of the overall traffic envelope for a given  
> user, based on the service class to which that user belongs (here I  
> am thinking of maximum burst capacity as a measure of "class"). In  
> times of congestion, I think I would be inclined to argue for user  
> prioritization within a "fair share" of the available capacity for  
> that user.
>
> vint
>
>
> On Nov 2, 2009, at 5:58 PM, George Ou wrote:
>
>
>
> Dr. Cerf,
>
> I understand that Google and others like to tout “user preference  
> prioritization”, but you haven’t addressed some of the key  
> limitations to that system.  I am fine with user-labeled priority so  
> long as it operates with reasonable priority quotas and budgets, but  
> what do you do about the vast majority of users and applications  
> that fail to label accurately or fail to label at all?  So my  
> question to you is this:
>
> ·         Do you have a problem with a default priority mechanism -  
> one that would cede control to user or application preference so  
> long as it is within quota – that is implemented by the ISP which  
> always gives higher priority to low bandwidth applications over high  
> bandwidth applications, and gives priority to low duration  
> applications over high duration applications?  Do you have a problem  
> with this type of good discrimination?
> ·         If you do have a problem with a default ISP priority,  
> please explain your reasoning.  Is the objection based on a concern  
> that a default prioritization scheme would inaccurately classify  
> information (even though we can classify based on packet patterns  
> rather than simple port identification), or do you have a  
> philosophical problem with it?  And if so, how would this be any  
> different Comcast’s “Fair Share” system which prioritizes low  
> bandwidth users (average measured over 15 minutes) over high  
> bandwidth users which the FCC reviewed and considers fair?
>
>
>
> George Ou
>
> From: Vint Cerf [mailto:vint () google com]
> Sent: Monday, November 02, 2009 2:33 PM
> To: George Ou
> Cc: 'David P. Reed'; 'NNSquad'; 'Lauren Weinstein'
> Subject: Re: [ NNSquad ] Re: [IP] BitTorrent uTorrent 2.0 uTP will  
> self-throttle to protect networks
>
> George,
>
> This discussion suggests that users should have something to say  
> about the priority of packet flows WITHIN the capacity they are  
> paying for (capital letters just in lieu of italics; I am not  
> shouting). If the access ISP can do traffic shaping to keep users  
> within their pro-rata envelopes and also respond to user-specified  
> priority, I would think we would be moving toward a balance that  
> seems useful.
>
> vint
>
>
> On Nov 2, 2009, at 1:54 PM, George Ou wrote:
>
>
>
>
> I’ve published my results here.
> http://www.digitalsociety.org/2009/11/analysis-of-bittorrent-utp-congestion-avoidance/
>
> Dr. Reed.  Your use of the words “rhetoric” and “tricks” aren’t very  
> useful to this discussion, and I would take issue with your comments.
>
> 1.       BitTorrent still hogs over 90% of my broadband connection  
> over HTTP.  This has significant ramifications beyond just real-time  
> applications like VoIP and online gaming.
> 2.      You shouldn’t be so quick to discount VoIP and online  
> gamers.  A very large number of BitTorrent (or any P2P app) users  
> also do online gaming and VoIP, and they’re forced to shut down  
> their P2P application when the use VoIP or game and that actually  
> hurts the P2P upload and download throughput for the entire P2P  
> community since there are fewer seeders.
> 3.      Don’t conflate wireless with wired broadband.  Just because  
> 150 ms ping for wireless is best case doesn’t make 70 ms additional  
> on a wired network bearable for online gaming.  Maybe you’re  
> different, but I don’t know any gamer that will put up with an  
> additional 70 ms if they can help it.  I thought it would be  
> tolerable for VoIP, but my Lingo VoIP phone service drops a  
> significant amount of audio even when I merely upload with BitTorrent.
>
>
>
> George Ou
>
> From: nnsquad-bounces+george_ou=lanarchitect.net () nnsquad org  
> [mailto:nnsquad-bounces+george_ou=lanarchitect.net () nnsquad org] On  
> Behalf OfDavid P. Reed
> Sent: Monday, November 02, 2009 8:43 AM
> To: 'NNSquad'
> Cc: Lauren Weinstein
> Subject: [ NNSquad ] Re: [IP] BitTorrent uTorrent 2.0 uTP will self- 
> throttle to protect networks
>
> I find the word games/rhetorical tricks that Ou and Bennett use  
> fascinating.  We'll see whether Farber posts my response below.
>
> George Ou wrote:
> Subject: RE: [ NNSquad ] BitTorrent uTorrent 2.0 uTP will self- 
> throttle to protect    networks
>
> Too bad nobody ever bothered to test if these claims actually hold  
> water
> before repeating them endlessly.  I just tested uTorrent version 2  
> build
> 16850 today and it still grabs all the bandwidth and jacks up the  
> ping to
> unbearable levels for online gaming and VoIP.  It certainly does NOT  
> protect
> my network.
>
> I will do some testing myself, because I am curious about the  
> mechanism in uTorrent 2.0.   I do note that "unbearable levels for  
> online gaming and VoIP" is an interesting statement.
>
> If true that means that ping times might be 100 msec or more.   Now,  
> since I have been recently measuring ping times on networks where  
> there are no "uTorrent" or other P2P services running, I can tell  
> you that on a variety of commercial providers, 150 msec. ping times  
> are common - and on ATT 3G in several cities, there are stable ping  
> times that can be measured that are on the order of 2000-5000 msec.
>
> So the "data" presented by Mr. Ou represents a very, very  
> interesting choice of phrase.   Say that it is "unbearable" for two  
> of the most sensitive-to-latency applications (only).
>
> I would, myself, stick to scientific measurements: how many  
> milliseconds?   Clearly he has measured that data.   But I presume  
> the hope of a talented columnist is to get the word "unbearable" to  
> stick in the mind, and leave the "bumper sticker" impression without  
> the qualifying information.
>
> Rhetorical trickery?  You be the judge.   I'm gonna report numbers.




-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com