[IP] Re: Cox to Trial New Congestion Management System

[David Farber <dave@farber.net>]

Begin forwarded message:

From: Lauren Weinstein <lauren@vortex.com>
Date: January 28, 2009 9:00:40 PM EST
To: David Farber <dave@farber.net>
Subject: Re: [IP] Re:   Cox to Trial New Congestion Management System


Dave,

The march of encryption into all phases of the Internet is continuing
at a rapid pace -- though not as fast as I'd like to see.  Any ISP
management technologies that depend on DPI, or even "known ports"
(given port-agile applications) cannot help but be ephemeral in
nature.  Viewed in their best possible light, they can only be
considered to be very short-term stopgaps, with the potential for a
range of unfortunate collateral damage.

--Lauren--
Lauren Weinstein
lauren@vortex.com or lauren@pfir.org
Tel: +1 (818) 225-2800
http://www.pfir.org/lauren
Co-Founder, PFIR
  - People For Internet Responsibility - http://www.pfir.org
Co-Founder, NNSquad
  - Network Neutrality Squad - http://www.nnsquad.org
Founder, PRIVACY Forum - http://www.vortex.com
Member, ACM Committee on Computers and Public Policy
Lauren's Blog: http://lauren.vortex.com

- - -

On 01/28 19:59, David Farber wrote:
> Begin forwarded message:
>
> From: Bill Stewart <bill.stewart@pobox.com>
> Date: January 28, 2009 7:28:47 PM EST
> To: dave@farber.net, ip@v2.listbox.com
> Subject: Cox to Trial New Congestion Management System
>
> "Deep Packet Inspection" usually refers to looking
> beyond the IP and TCP/UDP headers and into the data itself,
> typically to see what's inside http or other Port 80 packets.
> That's not needed for the protocols Cox is handling as
> low-priority here - well-known TCP ports do the job.
>
> Depending on how they implement it,
> they're actually doing what you would want as a user -
> you don't want Bittorrent hogging your downlink bandwidth
> when you're trying to browse the web,
> much less when you're trying to talk on VOIP.
>
> Doing the right thing is easier on DSL than on cable,
> because in DSL the bottleneck is almost always
> your downlink, as opposed to a cable you're sharing
> with your neighborhood, but even for cable it's not bad -
> queuing low-priority traffic on a congested link is good,
> and the protocols they're affecting handle it just fine.
> You don't mind if your ftp's a few milliseconds late,
> but it's annoying if VOIP has to wait for it.
>
> IP TOS or DSCP bits are a more precise method,
> and they're typically what business customers use,
> but they're not consistently supported across the
> public internet across multiple ISPs, though some
> ISPs support them across their own networks.
> Also, the TOS bits are designed to let
> applications ask for _better_ treatment,
> and what's needed here is marking traffic for
> slower than best effort but still reliable treatment;
> even DSCP's AF11 is rather a hack.
>
> The controversial choice is not delaying streaming video -
> unlike videoconferences or broadcast video,
> Youtube and its friends buffer just fine,
> but it's harder to identify that without either
> deep packet inspection or targeting video sites,
> which has obvious network neutrality issues.
>
>
>
>
>
> -------------------------------------------




-------------------------------------------