NNSquad - Network Neutrality Squad
[ NNSquad ] Re: A fatal case of Innovator's Dilemma
It's a dilemma, but I don't think it's fatal. Networks are upgraded
every few years or so anyway, because the appetite for bandwidth always
increases as does the diversity of applications. When Comcast deployed
this network nobody cared much about VoIP or P2P, and there weren't any
HDTV movies. HTTP was a novelty, but its traffic needs fit nicely with
the existing topology of CATV networks, the inverted tree. In the next upgrade, they'll make it more p2p-friendly by increasing upstream BW by a factor of 10. This won't happen as fast as we'd all like, but it's been announced and all that. The one thing I like about Comcast is that they offer "broadband" to 99% of the homes they pass, which is a heck of a lot more than AT&T does with DSL. I believe they can do that because they have a cheap, semi-crappy, asymmetrical network. It's not FiOS, but it's better than dial-up. RB Bob Frankston wrote: "The Comcast network was tuned for HTTP". Isn't this crux of the problem? -- tuning the network for a given presumed activity and then punishing those who discover new value? This misses the whole point of the Internet's value in providing opportunity rather than more and more and more of the same old. But then if you hire a cable TV company or a phone company to provide connectivity how can you expect anything else? It is an admission that Comcast isn't the appropriate steward for our infrastructure. In http://www.frankston.com/?name=SATNVZCustomers I explain why serving the majoring gives our society a fatal case of "Innovator's Dilemma" by isolating us at a local maxima. It is indeed the Minitel failure mode. Why are we managing the network through the rear-view mirror? -----Original Message----- From: nnsquad-bounces+nnsquad=bobf.frankston.com@nnsquad.org [mailto:nnsquad-bounces+nnsquad=bobf.frankston.com@nnsquad.org] On Behalf Of Richard Bennett Sent: Tuesday, February 19, 2008 06:25 To: Vint Cerf Cc: Lauren Weinstein; nnsquad@nnsquad.org Subject: [ NNSquad ] Re: As predicted: The BitTorrent vs. "traffic shaping" arms race 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. RB Vint Cerf wrote:Richard, I don't think this is a circular argument. The attempt to identify particular protocols by traffic analysis is not the same as simply detecting and moderating a high capacity flow. this is where your interpretation of my remark differs from my intent. I would much rather see a clear statement that rate limiting is in effect regardless of either protocol or destination (or source) than to have the kind of bludgeon used by Comcast applied only to a specific protocol which may, in fact, NOT be consuming excessive resources. I also hope that ISPs don't arbitrarily suppress flows as long as the aggregate among all users of the common access pipe doesn't overload the system. vint On Feb 17, 2008, at 7:56 PM, Richard Bennett wrote:You're making a circular argument, Vint. If an ISP searching for BitTorrent streams by traffic analysis comes up with a "false positive" and throttles another high-volume stream instead, he would in effect be managing traffic more fairly. One goal of residential network traffic management is to prevent high-volume users from degrading the experience of low-volume users, so the de-prioritization of any high-volume flow will do. A second goal is to prioritize flows that need low jitter, and that part depends on the ability to identify applications. If BitTorrent users obfuscate, they will simply find all their traffic being de-prioritized. They may not want that, but they have the power to change it by not obfuscating. And our ISPs are adding more bandwidth all the time (Verizon, Comcast, and AT&T in particular) but networks of millions of users aren't as easy to upgrade as your home Ethernet. RB Vint Cerf wrote:some people claim they can recognize bit torrent by traffic analysis - of course this could lead to false positives that seriously interfere with Internet applications. what a mess. The ISPs would be better advised either to build more capacity or, at least, try to do traffic engineering in a more fair fashion. v On Feb 16, 2008, at 5:02 PM, Lauren Weinstein wrote:As predicted, P2P extensions to thwart ISP "traffic shaping" and "RST injections" are in development. We can assume that ISPs will attempt to deploy countermeasures, then the P2P folks will ratchet up another level, and ... well, we may well end up with the Internet version of the Cold War's wasteful and dangerous Mutally Assured Destruction (MAD). There's gotta be a better way, folks. "The goal of this new type of encryption (or obfuscation) is to prevent ISPs from blocking or disrupting BitTorrent traffic connections that span between the receiver of a tracker response and any peer IP-port appearing in that tracker response, according to the proposal. This extension directly addresses a known attack on the BitTorrent protocol performed by some deployed network hardware."http://torrentfreak.com/bittorrent-devs-introduce-comcast-busting-encryption -080215/--Lauren-- NNSquad Moderator |