NNSquad - Network Neutrality Squad
[ NNSquad ] Re: [IP] Re: Cox to Trial New Congestion Management System
Just because it's complicated doesn't mean that ISPs shouldn't try to help consumers. We're in an era where P2P capability will become common in set top boxes and even TV sets. This will generate a lot of jitter problems for the home and consumers will most likely blame the ISP for intra-subscriber congestion problems. Also, some VPN solutions will replicate the priority labels on the VPN headers as well so there is a way to make QoS work with VPN. Furthermore, there is a possibility that some people will try to masquerade P2P traffic as VoIP traffic, but this should be handled with priority budgets. The ISP should always respect the user's priority labels first up to their allowable budgets and the budget for high priority should naturally be lower than bulk background traffic. George -----Original Message----- From: nnsquad-bounces+george_ou=lanarchitect.net@nnsquad.org [mailto:nnsquad-bounces+george_ou=lanarchitect.net@nnsquad.org] On Behalf Of Peter Eckersley Sent: Wednesday, January 28, 2009 3:37 PM To: Lauren Weinstein Cc: nnsquad@nnsquad.org Subject: [ NNSquad ] Re: [IP] Re: Cox to Trial New Congestion Management System Just two scenarios to go a little further along David's lines: How is Cox planning to treat ssh? According to their FAQ, VPN software will be marked as time-sensitive, while backups and bulk data transfers will be marked as low priority. Here are two common use cases for the encrypted ssh protocol: 1. Log into a remote computer, issue text based commands and run interactive terminal applications (time-sensitive, low bandwidth). 2. Log into a remote computer and copy/backup/synchronise files to or from that machine, using applications such as scp, sftp or rsync over ssh (not time sensitive, very bandwidth-intensive). Is Cox planning to distinguish between these two uses of an encrypted protocol? If the answer is yes, how will that distinction affect a third use case for ssh: 3. Log into a remote computer and run graphical remote desktop applications using VNC or the X Windowing System over ssh (time sensitive and bandwidth intensive). The ssh example is just one illustration of how traffic prioritization by the network is difficult. Another good example would be the use of the encrypted BitTorrent protocol in a streaming video service. How does Cox plan to determine if that is a P2P protocol, to be deprioritized, or streaming video, to be prioritized? On Wed, Jan 28, 2009 at 02:55:21PM -0800, Lauren Weinstein wrote: > > ----- Forwarded message from David Farber <dave@farber.net> ----- > > Date: Wed, 28 Jan 2009 17:44:20 -0500 > From: David Farber <dave@farber.net> > Subject: [IP] Re: Cox to Trial New Congestion Management System > Reply-To: dave@farber.net > To: ip <ip@v2.listbox.com> > > > > Begin forwarded message: > > From: "David P. Reed" <dpreed@reed.com> > Date: January 28, 2009 4:27:59 PM EST > To: dave@farber.net > Cc: ip <ip@v2.listbox.com> > Subject: Re: [IP] Cox to Trial New Congestion Management System > > No need to be anonymous on my part. I have testified on this matter, and > will again. Here there are two MAJOR problems. > > Under the current architecture of the Internet, Cox would indeed have to > inspect the contents of user traffic to make an accurate determination of > the type of Internet traffic at the level of detail described in their > document. > > If Cox would provide clear technical documentation of how they determine > what type of traffic is being emitted this could be clarified. I cannot > think how they would do what they claim to do without deep inspection of > user data. Perhaps a Cox engineer would provide this to your list, Dave. > > For example, if one has an IP voice client sending RTP/UDP/IP packets to a > peer node, following the VoIP standards, it is quite difficult without > looking inside the IP datagram to determine that is such a thing. (there > are special cases that can be determined for certain IP voice gateways onto > the PSTN, but IP telephone to IP telephone connections that have been > introduced by SIP session initiators cannot even be identified by having > reserved port numbers on either end). > > The standard way to do this is to use the IP header TOS field, which was > designed to indicate "time sensitivity". However, that field does not tell > you what type of traffic is carried in the way that Cox explains it. > > The other problem worth considering here is that Cox doesn't contemplate > new, yet-to-be-invented protocols for new applications, which can be in > either category. > If Cox truly provides "Internet" service, it must understand that those > yet-to-be-invented applications are a core part of the Internet's value - > the Internet grew by being inventive, not by negotiating with Cox for > permission to run new types of traffic over the connections subscribers > have paid for as *Internet* service, not Cox-brand service. > > > > David Farber wrote: > > > > > > Begin forwarded message: > > > > *From: * > > *Date: *January 28, 2009 8:45:29 AM EST > > *To: *Dave Farber <dave@farber.net <mailto:dave@farber.net>> > > *Subject: **!!Anonymize!!: Cox to Trial New Congestion Management > > System* > > > > *_PLEASE ANONYMIZE!!!! > > _* > > See http://www.cox.com/policy/congestionmanagement/ > > > > The concerns I see with this are that this would have to use DPI, very > > likely installed in-line, in order to function. Former FCC Chairman > > Martin referred to this as opening customer's mail to look at what sort > > of letter is inside. In addition to that, it is hard to imagine that > > ISPs would want to be in the middle of making decisions for users about > > relative priorities of different applications. One user may really want > > VoIP treated best, while for another it is P2P or gaming. These choices > > may be better left to users themselves to sort out. > > > > ------------------------------------------------------------------------ > > Archives <https://www.listbox.com/member/archive/247/=now> > > <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 > > ----- End forwarded message ----- -- Peter Eckersley pde@eff.org Staff Technologist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993