North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: ISPs slowing P2P traffic...

  • From: Matt Landers
  • Date: Wed Jan 09 15:54:19 2008

Semi-related article:


On 1/9/08 3:04 PM, "Deepak Jain" <deepak@xxxxxx> wrote:

> c-89260
> tus-Notes-88673
> If I am mistakenly being duped by some crazy fascists, please let me know.
> However, my question is simply.. for ISPs promising broadband service.
> Isn't it simpler to just announce a bandwidth quota/cap that your "good"
> users won't hit and your bad ones will? This chasing of the lump
> under-the-rug (slowing encrypted traffic, then VPN traffic and so on...)
> seems like the exact opposite of progress to me (by progressively
> nastier filters, impeding the traffic your network was built to move, etc).
> Especially when there is no real reason this P2P traffic can't
> masquerade as something really interesting... like Email or Web (https,
> hello!) or SSH or gamer traffic. I personally expect a day when there is
> a torrent "encryption" module that converts everything to look like a
> plain-text email conversation or IRC or whatever.
> When you start slowing encrypted or VPN traffic, you start setting
> yourself up to interfere with all of the bread&butter applications
> (business, telecommuters, what have you).
> I remember Bill Norton's peering forum regarding P2P traffic and how the
> majority of it is between cable and other broadband providers...
> Operationally, why not just lash a few additional 10GE cross-connects
> and let these *paying customers* communicate as they will?
> All of these "traffic shaping" and "traffic prioritization" techniques
> seem a bit like the providers that pushed for ubiquitous broadband
> because they liked the margins don't want to deal with a world where
> those users have figured out ways to use these amazing networks to do
> things... whatever they are. If they want to develop incremental
> revenue, they should do it by making clear what their caps/usage
> profiles are and moving ahead... or at least transparently share what
> shaping they are doing and when.
> I don't see how Operators could possibly debug connection/throughput
> problems when increasingly draconian methods are used to manage traffic
> flows with seemingly random behaviors. This seems a lot like the
> evil-transparent caching we were concerned about years ago.
> So, to keep this from turning into a holy war, or a non-operational
> policy debate, and assuming you agree that providers of consumer
> connectivity shouldn't employee transparent traffic shaping because it
> screws the savvy customers and business customers. ;)
> What can be done operationally?
> For legitimate applications:
> Encouraging "encryption" of more protocols is an interesting way to
> discourage this kind of shaping.
> Using IPv6 based IPs instead of ports would also help by obfuscating
> protocol and behavior. Even IP rotation through /64s (cough 1 IP per
> half-connection anyone).
> For illegitimate applications:
> Port knocking and pre-determined stream hopping (send 50Kbytes on this
> port/ip pairing then jump to the next, etc, etc)
> My caffeine hasn't hit, so I can't think of anything else. Is this
> something the market will address by itself?
> DJ