Subject: RE: [bmwg] Congestion?

From: "Perser, Jerry" <[email-masked]>
Date: Thu, 21 Mar 2002 10:44:07 -0800

Fred,

I am real curious on how you determine "added delay"?  Every DUT I have
tested has some delay variance.  When I run a 30 seconds test, my tester
gives me minimum, maximum, and average delay.  I get these three numbers at
any packet rate (including 1/10 of the available rate and full available
rate).

So if I test at 1/10 of the available rate and full available rate, I will
get six different delay numbers.  Do you have an equation that can take
these delay number and determine if the DUT is congested?

I understand your point about existence of device congestion.  I use it to
describe a condition where "the DUT/SUT is externally observed NOT to
forward all the packets that is was offered".  From an external view, I can
not tell you why or where the Cisco 7500 dropped packets, only how many
packet were not forwarded.

I try to keep a black box approach to testing.  I am never sure what the
internal architecture is.  I've had Support Engineers state that the loss
was caused by one thing, yet we've proved that is was cause at a different
point in the DUT.

Jerry.

-----Original Message-----
From: Fred Baker [mailto:[email-masked]]
Sent: Wednesday, March 20, 2002 11:59 AM
To: Perser, Jerry
Cc: [email-masked]'
Subject: RE: [bmwg] Congestion?

to put a finer point on this, from one perspective loss and delay are 
different signals to a sending transport, but from another perspective loss 
is nothing more than infinite delay. Personally, I measure congestion in 
terms of the added delay: if I send evenly spaced packets at 1/10 of the 
available rate, I can measure a base delay (consisting of propagation delay 
plus switching latency), and as I drive traffic harder congestion adds 
queuing delay, which should be roughly proportional to 1/(1-p), where 
p=arrival rate over capacity.

personally, I don't believe in the existence of device congestion. The 
device doesn't get congested. Its buffers get depleted, its buss gets 
congested, its CPU processing power on the forwarder related to the ingress 
interface (which may be different than the processing power related to 
another interface) may get depleted, or the queues can get backed up, but 
they don't all happen at the same time. I would prefer to talk about 
interface congestion and leave it at that, or if the bottlenecks are 
sufficiently important (eg, on a Cisco 7500, you can run a bunch of gigabit 
Ethernets, but if you attach them to separate cards the intervening 560 
MBPS buss can get in the way) they should be measured separately.

At 12:20 PM 3/20/2002, Perser, Jerry wrote:
>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

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