Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On 12/12/2011 4:13 PM, Stephen Ronan wrote: > Perhaps of interest -s.r. > > ---------- Forwarded message ---------- > Date: Fri, 9 Dec 2011 09:52:45 -0500 > From: Dave Farber <dave at farber.net> > To: ip <ip at listbox.com> > Subject: [IP] BufferBloat: What's Wrong with the Internet? > > <http://queue.acm.org/detail.cfm?id=2076798> > > BufferBloat: What's Wrong with the Internet? > A discussion with Vint Cerf, Van Jacobson, Nick Weaver, and Jim Gettys [snip] I think this is a great discussion of how difficult it can be to change a widely-implemented protocol like TCP: engineers keep doing work-around solutions until the solutions create new problems. At the heart of the TCP/IP protocol suite is a design philosophy of trading time for reliability: the whole idea was to make a reliable path using unreliable links (remember that in the 1960's, link reliability was horrific by today's standards), and because of that, there is no "minimum transit time" specification in the IP protocol. We have added on QOS and other hacks to improve traffic flow for near-real-time applications such as IPTV, but the bottom level protocols don't know about them and don't deal with them. At some point, the Internet will need a major overhaul. For what I do, which is mostly email, it worked as originally designed. For what many ISP's and content providers are attempting to do, which is near-real-time content delivery, it can be "bent to fit" by adding ever-fatter pipes and ever-larger buffers, at the expense (as the OP pointed out) of degrading key performance metrics like latency. For what common carriers are trying to do, which is to substitute common-channel bandwidth for the virtual-circuit design of the Public Switched Telephone Network (PSTN), TCP/IP can't be made to fit. There isn't enough elasticity in the available bandwidth structure to accommodate the (sometimes incredible) variability of telephone calling patterns, where by-hand intervention is still done, on a daily basis, to prevent outages due to mass-calling-events such as hurricane-or-other-severe-weather-related traffic, media outlet call-in promotions, and excess-demand holidays like Mother's Day. Unfortunately, the cost-per-transferred-bit of the Internet is so low compared to using virtual-circuit protocols such as ATM, that most executives put blinders on and opt for the cheap solution, usually with the assumption that we diode-heads will find a way around any problems like we always do. I don't have any magic bullets to solve this issue. I think that voice-traffic will migrate to the Internet until there are service problem too obvious to ignore, such as those Comcast Voice customers are experiencing on a daily basis, and then the powers-that-be will push for a new protocol suite that preserves low cost-per-moved-bit price advantages at the expense of higher (I think MUCH higher) rates for anyone doing "anything but" traffic. The battle of the titans is coming, but it won't be a fight about who sells which movie or who gets to download which song. This fight will be about which mega-corporations carve out virtual slices of Internet bandwidth so that they can avoid paying for their own. My 2?. YMMV. -- Bill Horne 339-364-8487
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |