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

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