Subject: Re: [Ieprep] RE: PSTN collapse

From: Fred Baker <[email-masked]>
Date: Mon, 09 Dec 2002 15:34:30 -0800

At 04:57 PM 12/9/2002 -0600, Ayyasamy, Senthilkumar  (UMKC-Student) wrote:
>I am aware of only RFC 896, which talks about congestive collapse
>and how it leads to "Internet meltdown".

You should also take a look at RFC 970, which describes the mechanism for 
congestive collapse. This did in fact occur in late 1987 and most of 1988. 
The issue was that most links in the 56 KBPS NSFNET were running at 
capacity. Your queuing theory courses should have told you that 100% 
utilization implies infinite delay, something experimentally shown to apply 
in that network. The Fuzzball Routers used in much of it had a grand total 
of eight buffers in their grand total of 64 KBPS of data memory and 64 KBPS 
of program memory, which meant that anything resembling a burst was an 
instant overload. You might notice that a lot of Van Jacobsen's work on 
making TCP robust in the presence of loss is dated 1988; there is a reason. 
He was already working on making it robust in the presence of reordering; 
that related to CSNET's X.25 network, which opened up an arbitrary number 
of X.25 circuits between any two routers and distributed load across them, 
resulting in random traffic reordering on a truly large scale.

At the time, Father Time and his minions deployed a mechanism similar to 
that described in RFC 970 to help overcome the issues. That helped, but in 
the end could not create bandwidth. The problem was solved with the 
deployment of the NSFNET DS3 backbone - which had it's own problems, like 
"gray links" that passed perhaps half the messages sent over them without 
link layer errors...

Woody, your turn to chime in :^) 
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Dave Crocker <[email-masked]>
Date: Sat, 14 Dec 2002 08:08:18 -0800

Fred,

Monday, December 9, 2002, 3:34:30 PM, you wrote:
>>and how it leads to "Internet meltdown".

Fred> You should also take a look at RFC 970, which describes the mechanism for 
Fred> congestive collapse. This did in fact occur in late 1987 and most of 1988. 
Fred> The issue was that most links in the 56 KBPS NSFNET were running at 
Fred> capacity. Your queuing theory courses should have told you that 100% 
Fred> utilization implies infinite delay,

After a number of years of doing Arpanet measurements, Leonard Kleinrock
includes a slide in presentations about the net, showing an interesting
curve.  Y was delay and X was throughput.  The curve was almost horizontal
for quite awhile, then had a rather sharp knee as then was highly vertical.

Kleinrock noted that this summarized the performance of Arpanet packet
switching. He's an excellent teacher, able to make queuing theory actually
sound interesting. But he also knows when to keep things simple

He summarized the curve as: throughput is very very good, until it gets very
very bad.

In effect, he said, all of the queuing mechanisms in a switch are useful
only in the very short range of the knee. When the system is under sustained
load that is at capacity, queuing does not help.

Why bother with all that mechanisms, he then asked?

Transients.  Queuing mechanisms are for *transient* high loads.

d/
-- 
 Dave <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.408.850.1850