BufferBloat: What's Wrong with the Internet? [telecom]

formatting link
BufferBloat: What's Wrong with the Internet?

"A discussion with Vint Cerf, Van Jacobson, Nick Weaver, and Jim Gettys"

Here's my take on the BufferBLoat issue: 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 cents. YMMV.

Reply to
Bill Horne
Loading thread data ...

The URL in the original post wasn't valid.

Please use

formatting link
instead. TIA.

Bill

Reply to
Bill Horne

On Mon, 12 Dec 2011, Bill Horne wrote,

Very good summation -- sometimes things get to the point where fixes create more things that need fixes than what they fix.

There's not even QoS in the Internet or the TCP/IP protocol suite. Overprovisioning (brute force) is used in many cases. But it doesn't always work. And what the bufferbloat article demonstrates is that there's no fix that works across all speeds. There's no reliable way to tell the network if your application is one that needs big or little buffers.

I do.

The problem goes away if you accept the simple and obvious (as in "the emperor really is naked") fact that TCP/IP has outlived its usefulness. It worked over a fairly wide range for a rather long time. But it predates MS-DOS and should be relegated to the same museum.

The magic bullet I'm supporting is called RINA, the Recursive InterNetwork Architecture. It's an all-new protocol suite based on radical simplicity. Rather than a fixed number of layers in a stack, it uses a single layer mechanism (the distrubted interprocess facility, or DIF) as many times as needed, no more no less. Thus a common protocol is recursed, but with differing parameters and options at each layer to account for the different scope. Protocol options include QoS, encryption, authentication, multicast, and more... and it's extensible.

See the Pouzin Society web site

formatting link
for more details. The theoretic underpinnings are described in John Day's book, Patterns in Network Architecture: A Return to Fundamentals. John likes to say that he didn't invent RINA; he discovered it.

-- Fred Goldstein k1io fgoldstein "at" ionary.com ionary Consulting

formatting link
+1 617 795 2701

***** Moderator's Note *****

Q. What happened to the little boy who told everyone that the Emperor was naked?

A. Nothing. For the rest of his life, absolutely /nothing/ happened to him.

Bill Horne Moderator

Moderator's Note Copyright (C) 2011 E. William Horne. All Rights Reserved.

Reply to
Fred Goldstein

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.