NNSquad - Network Neutrality Squad
[ NNSquad ] Re: [IP] BitTorrent uTorrent 2.0 uTP will self-throttle to protect networks
|
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. 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.” 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. 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. 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. George From: David P. Reed [mailto:dpreed@reed.com]
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 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] 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] 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. 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 I find the word games/rhetorical tricks that Ou and Bennett
use fascinating. We'll see whether Farber posts my response below. Subject: RE: [ NNSquad ]
BitTorrent uTorrent 2.0 uTP will self-throttle to protect
networks 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. |