[ NNSquad ] Re: As predicted: The BitTorrent vs. "traffic shaping" arms race

[Kee Hinckley <nazgul@somewhere.com>]

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[1]. 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].

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[3]. 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  
itself.

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  
priorities.
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  
it.

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.

Guaranteed Phoneline
[1] 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  
weird world.

Charging Extra for Bandwidth
[2] 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
[3] 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.