Subject: RE: [Ieprep] RE: PSTN collapse

From: "Gunn, Janet" <[email-masked]>
Date: Mon, 16 Dec 2002 09:39:48 -0500

That is a standard queueing theory curve- nothing specific to the Internet.

And the interesting thing is that, by changing the scale, you can make the
"knee of the curve" appear (to the human eye) to be in different places.
Therefore you should always be suspicious of quantitative arguments based on
the "location" the knee of the curve.

But the qualitative point is the same.

Queueing with infinite buffers, or where "arrivals" are dropped
indiscriminately when the buffer is full, is only useful for handling
transients.

However, "discriminatory" queueing, where only "preferred" arrivals are
allowed to queue, or  where "preferred" arrivals can "bump" "non-preferred"
arrivals when the buffer is full, make a difference for the preferred
arrivals (as long as they are only a small percentage of the total) even in
sustained congestion.

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]]
Sent: Saturday, December 14, 2002 11:08 AM
To: Fred Baker
Cc: [email-masked]
Subject: Re: [Ieprep] RE: PSTN collapse

Fred,

Monday, December 9, 2002, 3:34:30 PM, you wrote:
Fred> 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".

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

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Dave Crocker <[email-masked]>
Date: Mon, 16 Dec 2002 09:23:44 -0800

Folks,

Monday, December 16, 2002, 6:39:48 AM, you wrote:
Janet> However, "discriminatory" queueing, where only "preferred" arrivals are
Janet> allowed to queue, or  where "preferred" arrivals can "bump" "non-preferred"
Janet> arrivals when the buffer is full, make a difference for the preferred
Janet> arrivals (as long as they are only a small percentage of the total) even in
Janet> sustained congestion.

Unfortunately, this category of mechanism is at key line of attack for QOS,
which is notably lacking from the Internet. So discriminatory queuing might
sound great, but has nothing to do with the current, global Internet.

And the reason I am responding, after Kimberly's nudge to drop this thread,
is to encourage people to note that the IEPREP effort is not going to be
useful unless and until discussion pays attention to technology realities
and operations realities. The latter are the more challenging.

After two years, it is clear that a focus on making infrastructure changes,
to support IEPREP, is not going to be productive.

Discussion needs to look for discrete, mechanisms that can "contribute" to
IEPREP utility through incremental adoption, rather than looking for major
changes that solve large parts of the problem space.

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

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 16 Dec 2002 12:22:15 -0800

> changes that solve large parts of the problem space.

I absolutely agree.

thanks,
-rohan