Interesting People mailing list archives

Re: Cox to Trial New Congestion Management System


From: David Farber <dave () farber net>
Date: Wed, 28 Jan 2009 21:21:38 -0500



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.





-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com




-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com


Current thread: