NNSquad - Network Neutrality Squad
NNSquad Home Page
NNSquad Mailing List Information
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ NNSquad ] Re: As predicted: The BitTorrent vs. "traffic shaping" arms race
- To: firstname.lastname@example.org
- Subject: [ NNSquad ] Re: As predicted: The BitTorrent vs. "traffic shaping" arms race
- From: Kee Hinckley <email@example.com>
- Date: Wed, 20 Feb 2008 14:05:42 -0500
On Feb 19, 2008, at 6:25 AM, Richard Bennett wrote:
From Comcast's perspective, the issue is allocating bandwidth fairly
among users and rationally among applications. VoIP needs better
service than BitTorrent from the standpoint of latency and jitter,
so the desire to demote the priority of BT uploads or to ration BT's
upload sessions is sound network management on a link with low
intrinsic throughput in the upstream direction. The Comcast network
was tuned for HTTP and now has to deal with a different mix of
traffic, so naturally it manages the applications (or flows, if you
will) that are farthest from their provisioning assumptions.
And while BT is popular these days with a small group of people, the
majority of Comcast's users are still more concerned about good HTTP
performance than about seeding lots of new torrents.
These are good points, and I think they do a good job of pointing out
that there isn't going to be one "right" answer here. (Which doesn't
bode well for *anyone* when Congress gets its hands on things.
Trademark law is about the only area I've seen that allows judgement
as part of the legal process.)
It wasn't that long ago when we were all blithely assuming that VoIP
and such things would simply be solved with QoS bits. You'd think
we'd learn that data may not have desires and motives, but the people
sending and receiving it do.
Part of the problem with the dialog we are having is that we all got
off to a very bad start. Comcast didn't *tune* BT traffic, it
interfered with it. I'm sure that by the time the decision made it to
the P.R. folks who might have realized it was a problem, the
difference between tuning and interfering had long since evaporated,
and the knowledge that there were legitimate uses for the technology
probably wasn't there either. But no matter. Step one is to forget
how the conversation started and think sensibly about what the
"rightest" solution is. Let's assume that Comcast was simply trying to
*slow down* heavy traffic, BT was low-hanging fruit, and we'll leave
it at that.
What follows is an egotistic attempt to provide some focus to the
debate about Network Neutrality. So FWIW...
Some basic assumptions, in no particular order.
1. Unlimited bandwidth isn't.
People seem shocked by this, but it's been true from day one. ISPs
cannot afford to allocate enough bandwidth to manage simultaneous
maximum usage from all users anymore than they allocated enough modems
for every dial-in customer to dial in at the same time. Unlimited
bandwidth means you aren't going to get *charged* for high usage. It
doesn't mean you'll always get full bandwidth. You can ask ISPs to
change the name of the service if you want, but don't expect them to
change the practice. That's not to say we can't draw lines in the
sand. Terminating high-usage customers is an accounting solution to a
technical problem, and a stop-gap measure at best. I think it steps
over the line.
2. ISPs need to manage bandwidth.
That's pretty basic. But what I'm trying to say is that it's not
acceptable to say, "Well, if people are using more, then just charge
them more." In the first place, we really don't want the legal system
telling a company how to manage the bottom line--particularly when it
involves choices that may be the difference between being competitive
or going out of business. In the second place, it's not always that
simple. Bandwidth isn't a dial you can simply turn up at the main
office. It's impacted by everything from the deployment of equipment,
to the running of new lines, to basic architectural issues. If the
issues faced by Cable-based ISPs aren't obvious enough, consider
satellite-based systems. Download/upload speeds are massively
asymmetrical, latency is mind-boggling, and total download bandwidth
can only be increased by launching new satellites. Like it or not,
ISPs do have to manage bandwidth, and allocate it on a per-user basis.
3. ISPs need to manage user experience.
As Richard says, most ISP customers are concerned about HTTP
performance. When an ISP installs a caching proxy, they are solving
two problems at once. They are reducing their external bandwidth
requirements, and they are improving their customer experience. They
are also mucking with the underlying protocol, intercepting traffic
and adding potential monitoring capabilities--but we all seem to have
recognized that they have a legitimate need to do so, even though it
gives HTTP traffic a competitive advantage over, say, Gopher traffic.
So when we start talking about HTTP vs. P2P vs. VoIP traffic, keep in
mind that this is simply an extension of what we've already come to
expect, if not actually requested.
4. Some services require different QoS than others.
Note that I didn't say "protocols", I said "services". The confusion
between the two is one reason we are having this discussion. I think
everyone would agree that Voice services need to be able to provide
the ability to have an unbroken conversation if they are to be
competitive. (If you aren't sure, go find a 9600 baud modem and try
running Cu-SeeMe over it.) And I think we'd also consider it
reasonable if our Voice services were prioritized (forgetting for a
moment who does the prioritization) over our Web services which were
prioritized over our File Transfer services--at least until we're
sitting in the living room waiting for TiVo to download a movie from
Amazon. The point is, we *want* prioritization. The debate is over
*who* gets to decide what is prioritized; and *how* it is done.
Based on those assumptions, I see three main issues to address.
a) *Which* services should get priority.
The only person who really knows the answer to this is the end-user.
Just to complicate things, their priorities are likely to change based
on what they are currently doing, as well as on whether they are using
a service they paid for, or one that is free.
b) *How* services should get priority.
This is an investment and infrastructure problem. The only entity that
can make a business decision as to where to invest money is the ISP
c) When services *can* get priority.
You may want to download that movie to your TiVo right now, but if
your neighbors are using VoIP, you're just going to have to wait.
Only the ISP can see the overall picture.
Given that, I'd put forth the following goals.
The goal of Network Neutrality is to allow the ISP to do (b) while
preventing them from doing (a) insofar as possible given (c).
In order to enforce Network Neutrality, we want to make sure that the
ISP doesn't abuse (b), or do (a) while calling it (c).
So that sounds simple. What's the issue? :-)
1. There is currently no way for the user to communicate their
I'm not talking about checking off a list here, but you might, for
instance, imagine a system in which the OS requested higher priority
for packets from the front-most application. With or without that
support, the ISP will always have to make some priority assumptions
based on protocol and/or packet destination. That low-level
information is being used as a stand-in for "type of service".
Obviously this isn't ideal, and if we are to accomplish the above
goals, the mapping and prioritization decisions clearly need to be
made openly. Additionally, the question of what is to be done about
paid services is going to be critical. It's not just a matter of
companies paying the ISP for faster access. That treads the line of
conflating (a) and (c) and it seems as though it should be avoided
(although what if a company wants to co-locate a caching server at an
ISP; is that okay?). But there's also the issue of services the *user*
has paid for. They are going to have higher performance expectations
for those services. Should the ISP attempt to address them?
2. *How* to prioritize is a business decision, even though it can be
used to deliberately restrict what is possible.
To give a specific example; a box which disrupts P2P is likely to be a
lot cheaper than one which throttles the bandwidth on users who are
hogging the network (whether using P2P or not). It isn't reasonable to
mandate what technology an ISP installs (unless, apparently, you're
the NSA). However, it is reasonable to put restrictions on how
prioritization impacts a service; e.g. slowing vs. breaking. Drawing
that line is likely to be more difficult than it sounds; past a
certain level, slowing VoIP is pretty indistinguishable from breaking
3. The determination of when services *can* get priority is
subjective, and not likely to be public.
Even assuming that ISPs have this capability now, they aren't likely
to want to make that kind of traffic and performance data public. No
ISP is going to want to let their competitors know that they've hit
capacity in a particular city. And the trade-off of which users to
impact, and how much, is going to be based on input ranging from
engineering to marketing to whomever is in charge of today's weather.
Finally, this isn't something that can easily be monitored by a third
party; spot monitoring doesn't provide enough of the big picture. As
with most situations, we can request penalties for wrong-doers when
caught, but we can't guarantee that nothing will be done wrong in the
first place. That's life.
I don't know if this casts or re-casts the discussion in a useful
light, and I almost certainly have missed some issues. But I did try
to walk through a number of the concepts without hitting any hot
phrases like "porn", "illegal content" or "competing services". I'd
be very interested in any comments. Assuming I don't get totally
lambasted, I'll probably turn it into a blog post at http://www.marrowbones.com/commons/technosocial/
A few footnotes.
 Unless of course, you had a dedicated phone line to call. My first
(non-uucp) ISP offered discounts if you provided your own modem. I
actually drove over and watched them plug it in and pile it on a shelf
of other user-provided modems. Now-a-days of course, the ISP drives
over to *my* house and watches *me* pile the modem on a shelf. It's a
Charging Extra for Bandwidth
 There's an interesting alternative that ISPs might explore over
charging more for additional bandwidth. They might take a page from
the power companies' books and give customers *discounts* for *not*
using extra bandwidth during peak times. That requires some client/
server software to let the customer know when the time is good, and a
protocol so that some apps can check it as well. But it certainly
ought to be easier for ISPs to deploy such a system than it was for
the power companies. If bandwidth is a limited resource, and expanding
bandwidth requires significant investment, then the economics of
conservation ought to work just fine in this situation. If I'm
planning on watching that movie on TiVo *tomorrow*, I certainly don't
care whether the software downloads it now, or at two in the morning.
In fact, I'd probably prefer two in the morning. By moving the ISPs
big-picture knowledge down to the edge, where the user knows what
takes priority, you end up providing long-term benefits to the ISP and
immediate benefits to all users.
Users Care About HTTP, Not BT
 More accurately, they are concerned with *web browser*
performance, which in fact involves a number of protocols, not just
HTTP. I raise this because I actually think Richard's comment, while
well-intentioned, runs straight into the network neutrality issue.
Some browsers know how to use BitTorrent to download files. That's a
performance enhancement to the browser. By slowing BitTorrent
specifically, the ISP actually *is* hurting the user's "HTTP"
performance. And by choosing that protocol specifically, the ISP is
definitely benefiting some companies over others, and having an impact
on the technological direction of the internet; which is precisely
what we don't want to happen.