NNSquad - Network Neutrality Squad
[ NNSquad ] Re net neutrality vs. diff-serv?
----- Forwarded message from Dave Farber <dave@farber.net> ----- Date: Tue, 7 Sep 2010 13:06:16 -0400 From: Dave Farber <dave@farber.net> Subject: [IP] Re net neutrality vs. diff-serv? Reply-To: dave@farber.net To: ip <ip@listbox.com> 1B4779CC-BAB6-11DF-A217-C3169D0C7E3D: Begin forwarded message: > From: "David P. Reed" <dpreed@reed.com> > Date: September 7, 2010 8:48:53 AM EDT > To: dave@farber.net > Cc: ip <ip@listbox.com> > Subject: Re: [IP] Re net neutrality vs. diff-serv? > > > In response to Geoff Kuenning, It is precisely *this choice* (at each packet source to be able to request standard Internet packet transport services) that the Internet Access Providers want to *deny* in their battle against network neutrality. Their equipment is not set up to honor "expedited forwarding" on IP data grams, and apparently will never be; they aren't interested. Instead they are fighting for the right to block and interfere with your packets based on equipment that tries to decode their content, and fighting for the right to make pre-negotiated "deals" with specific targets who have no choice but to agree or be put out of business. They apparently want to block downloads of movies, because they deem them less valuable than other content (especially since they sell movies on their triple play); sometimes claiming that all downloads, even those from Hulu and iTunes' AppleTV service are somehow "pirated" by sly conflation of TV downloads with "pira cy". In other words they want the right to discriminate by target address, target port, and deep packet inspection of content methods - and they want that "right" to be written into the FCC's regulations, as if it is their speech, and not the Internet users', that deserves 1st amendment protection. (The Supreme Court did *not* say that money and profits per se is protected speech, though some seem to think it did). > > Every technical person involved, including myself, has said that if the Internet access providers and backbones would agree to support "expedited forwarding" with an agreement across the network *not to change that label* and *to interpret that flag by placing such packets at the head of EVERY queue*, that that would not in itself be a problem - and it would be extremely neutral, since anyone could set that flag, and all Internet carriers would interpret it the same. That is not at all the same as a broad endorsement of any random idea labeled "quality of service", which is often just screwing with packets in a plausible way to jack up prices to force you to use overpriced, monopoly triple play phone and TV offers. > > However, when you say - sure, enable expedited forwarding - in a meeting with access providers, some respond immediately by saying something of the order of "but wait, we turn the expedited forwarding flag OFF because it is a security hole". > > I think this is pretty good evidence that the arguments for prioritization are just FUD covering up a different agenda - one of desiring to find ways to extract rents in complex ways, without earning those rents by providing a service (i.e. just like the guy in the airline seat next to you is paying a lot less than you are because of "who he works for", but gets the same or better service, like being able to book at the last minute and get his tickets refunded). > > And on the matter of your VOIP problems - I suspect that the clogs in your network that you observe are due to "big buffer" syndrome - in particular, if you observe a delay larger than 150 msec., but are not losing packets, you are noticing a device in your path that has more than 1xRTT of buffering in it - which essentially defeats any hope of getting low latency service. This is not a bug with TCP. Any low level device that allows its backlog to grow that big without signalling congestion is *the cause* in and of itself of congestion. 3G network protocols in particular are thus misprovisioned, but most DOCSIS CMTS's and modems have this problem as well. I repeat that this is NOT a problem with TCP - *any* adaptive protocol attempting to avoid congesting the network must receive congestion signals from the underlying network to do its job. Instead of doing so, hardware vendors have, *perversely*, been throwing buffer memory into congestable devices - thinking that "ne ver dropping a packet" is a *feature*. Well, it's a real feature that causes really POOR QoS. > > It would make the Internet engineers' jobs a lot easier if the folks who build radio networks and CMTS's would learn a little about control theory - so they could propose a mechanism for adaptive control of sources that responds as quickly and stably as the TCP congestion control mechanism, rather than inserting buffers that only add to end-to-end latency, destroy the control loops required to get sources to slow down, and increase jitter. > > And to answer Geoff's specific post: > >> In clogged situations, I'd much rather lose a bunch of TCP >> packets than a bunch of UDP ones. > Please don't confuse protocol choice with drop rates or "value" in your preferences. You might not value all TCP and UDP packets equally, but the value you place on them should have nothing to do with their protocol number. I'd suggest actually understanding the math of congestion control theory, rather than just waving hands in a way that seems to show that you think that the network treats such packets differently, or should. >> The former produces an annoying drop >> in effective bandwidth, which I can live with; > In fact, router dropping of packets in properly managed (i.e. on any modern OS's stack) TCP connections gives you a roughly fair share *exactly the bandwidth* of the bottleneck link. Dropping a packet because of congestion on an outbound link in a router does NOT reduce its *capacity*, per se. What would reduce its effective capacity is *not* dropping packets, allowing the queue to build up to the point where packets are delivered long after they are irrelevant! Again, learn the math of congestion theory and queueing theory. Modern TCPs with SACK deal with drops well - and if congestion is managed, the congested link will be used very efficiently. There are any number of papers that demonstrate this. Perhaps it is disappointing that the link is underprovisioned compared to the traffic demand. Here you have a possible action: Ask your provider why that is... probably it's because the CEO is nearing retirement, and is goosing the stock price by underinvesting. Or perha ps it is because demand growth exceeds the buildout rate - very profitable for an operator in the short term, but not good business strategy when there is competition (of course there is essentially NO competition in the access provider market for high-speed Internet, because the processes that would allow facilities competition are captured by local governments who favor a tiny number of providers). >> the latter produces huge >> stuttering and dropouts that make it impossible for me to understand >> what the person on the other end is saying. > If you are getting stuttering, then you are observing excessively long delays, probably due to the "big buffer" problem. If the buffers were reduced to 1xRTT (remember that is RTT *with no traffic*, not RTT with huge queueing delays due to traffic) at the bottleneck router, then you would see all the TCP's stop killing your VOIP and gaming traffic. >> -- >> Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/ > > > > On 09/05/2010 11:10 PM, Dave Farber wrote: >> >> >> >> >> >> Begin forwarded message: >> >>> From: Geoff Kuenning <geoff@cs.hmc.edu> >>> Date: September 4, 2010 2:45:58 AM EDT >>> To: dave@farber.net >>> Subject: Re: [IP] Re net neutrality vs. diff-serv? >>> >> >>> >>>> >>>>> After reading a lot of online and offline expert comments to my >>>> >>> >>>> original post, I am coming around to the the view that David Reed >>> >>>> suggested, that only two fundamental tiers of service are really >>> >>>> necessary, one is best effort, for most internet traffic and the other >>> >>>> is a guaranteed low latency service >>> >>> As someone who has recently been using VOIP a lot under clogged >>> conditions, I'd argue that there's a need for a third category: low drop >>> probability. In clogged situations, I'd much rather lose a bunch of TCP >>> packets than a bunch of UDP ones. The former produces an annoying drop >>> in effective bandwidth, which I can live with; the latter produces huge >>> stuttering and dropouts that make it impossible for me to understand >>> what the person on the other end is saying. >>> -- >>> Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/ >>> >>> Orchestra retrospectively extremely satisfied with symphony [No. 1] as >>> result of barrel of free beer. >>> >>> -- Gustav Mahler, post-premiere letter to Arnold Berliner >>> >> Archives | Modify Your Subscription | Unsubscribe Now > ------------------------------------------- ----- End forwarded message -----