Boston Linux & Unix (BLU) 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

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Off-Topic [IP] BufferBloat: What's Wrong with the Internet? (fwd)



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org