Network Neutrality

[Ryan Malayter]

On 3/22/06, Eric <erpo41 at hotpop.com> wrote:
> there are two ways "around" this, that I can think of, both
> of which suck for Cox:
>
> 1. Content-based whitelisting, meaning you can't make any kind of
> connection in or out unless Cox can identify the type of traffic by its
> content.
>
...
> 2. A man in the middle attack, meaning Cox decides to break the
> encryption, which is a mostly straightforward process in this case. This
> creates several interesting problems.
>

I think you're ignoring the fact that Cox can throttle your connection
simply based on analysis of traffic volumes. They don't have to do any
crypto at all, or inspect any packets deeply. Throttling rules would
be set up that say "hey, here's one client getting data at high speed
from a bunch of other folks simultaneously, and sending data quickly
upstream to a bunch of people at the same time."

Such a rule would be fairly straightforward to implement by tracking a
few simple counters per client. I imagine Packeteer and the other
traffic-shaping vendors already have something along those lines
available.

Such traffic-pattern throttling wouldn't step on VPN or SSL
connections, as they're typically from a single host to single host.

Basically, BitTorrent has a very unique traffic pattern that makes the
encryption at best a temporary roadblock to traffic shapers. The vast
majority of BT traffic is from copyright violators, so it's not like
the imapcted users will complain about the throttling in any official
capacity. As for the impact on "legitimate" BT traffic like Linux
distros... well, I'm sure Cox doesn't care one bit. It's not like the
Ubuntu project is going to sue Cox over BT traffic shaping.
--
   RPM