NNSquad - Network Neutrality Squad
[ NNSquad ] Re: As predicted: The BitTorrent vs. "traffic shaping" arms race
I wrote a longer and more nuanced response address question of bandwidth management but it's a bit far-afield for NNS. The important point is that it's not for the ISP [sic -- transport provider] to dole out scarcity -- they must not make promises they cannot keep. The key is that the Internet is a dynamic in which you discover what is possible and you have to accept that there are no guarantees. Once you make the network decide what applications are more important than the other you break the dynamic. If you believe in NN than you have to accept that not everything will work. The solution is to make sure the transport provider is in the business of providing capacity and is only in the business of providing capacity and has no incentive to create value through scarcity and then selling off bits and pieces of the scarcity packaged as services to those who can pay a high price. As I keep pointing out -- the current system is structurally corrupt and the FCC is the biggest stakeholder in preventing change. -----Original Message----- From: nnsquad-bounces+nnsquad=bobf.frankston.com@nnsquad.org [mailto:nnsquad-bounces+nnsquad=bobf.frankston.com@nnsquad.org] On Behalf Of Kee Hinckley Sent: Wednesday, February 20, 2008 14:06 To: nnsquad@nnsquad.org Subject: [ NNSquad ] Re: As predicted: The BitTorrent vs. "traffic shaping" arms race 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.