Subject: RE: [bmwg] Congestion?

From: "Perser, Jerry" <[email-masked]>
Date: Wed, 20 Mar 2002 10:20:28 -0800

Kevin,

The coupling between LOSS and CONGESTION is very close and the draft needs
to be changed to reflect this.  My definition of Congestion has a unique
properties of 1.) externally observable and 2.)dose not guess the intent of
the DUT/SUT.

Starting with Jim McQuiad point, if you increase the test duration such that
"time dependent on #2" is removed (or minimized), then Loss > 0 is
congestion.  The problem is that people will reduce the test duration in
order to hide congestion.

The argument that "higher delay" also indicate congestion is just a symptom
that loss will occur in the future.  The fact that the test duration was too
short for loss does not negate congestion.  In fact, I can shorten the test
duration even more to remove "higher delay".  Congestion means that the
DUT/SUT can not handle the OLOAD.  Whether the packets are buffered on the
wire or in a queue should not change that.

The other problem with "higher delay" is how much is "higher"?  This makes
the definition ambiguous and leads to interpretation.  The reason I stick to
the definition "Loss > 0" is because of its unabiguity.

When you use the terms "device congestion" or "port congestion", it implies
that you locate the point where the packet was dropped.  I would like to use
the words device, port, blade, fabric, etc. as adjectives.  When you say the
DUT/SUT congestion (or just congestion), it is in the general sense that you
have not narrowed down exactly where the packets were dropped.

Let me confer with the other authors and rewrite (then post) a better
definition for congestion.  If any of this doesn't make sense, blame it on
the Hilton's excellent service.  I am sitting here at the bar doing email
through the wireless.

Jerry.

-----Original Message-----
From: Kevin Dubray [mailto:[email-masked]]
Sent: Tuesday, March 19, 2002 10:58 AM
To: [email-masked]
Subject: [bmwg] Congestion?

From the BMWG minutes of the 52nd IETF related to 
<draft-ietf-bmwg-dsmterm-02.txt>:

"Follow-up commentary regarding the use of the term
'congestion' in the draft ensued. Jerry indicated by congestion
he meant 'the condition by which the device is unable to
forward packets.' It was offered that another look at what the
draft states and what Jerry means might be advantageous. It
was suggested to take follow-up discussions to the list."

The discussion offers various notions of "congestion" (Network
(multiple DUTs), device and/or port.  Perhaps a narrowing the
term to "device congestion" or "port congestion" or
some such would be beneficial...

In dsmterm-02, the definition "congestion" states: "A condition when
one or more egress interfaces are offered more packets than
are forwarded at any given instant."

I interpret this to mean packet loss is not necessarily a condition 
for congestion.  If I recall in the SLC discussion, there was that 
statement that "unable to forward" implied "loss." (due to the
monitoring at egress?)  How tight is the couplage of loss to 
congestion as refered to in the draft?

-Kevin

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

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