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: 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