Subject: [bmwg] Congestion Definition in dsmterm03

From: "Perser, Jerry" <[email-masked]>
Date: Tue, 3 Sep 2002 14:46:55 -0700

Kevin,

Below is new definition (and discussion) for congestion.

The plan is to put it in the 04 version along with a change to "delay
variation."  I am current changing "delay variation" to "jitter" because way
we are using the term complies with the use of "jitter" in RFC1889 and
RFC2598 more that "delay variation" in draft-ietf-ippm-ipdv-10.txt (which
IESG has approved as a Proposed Standard).

3.1.3 Congestion

   Definition:
A condition in which one or more egress interfaces are offered more packets
than are forwarded.

   Discussion:
This condition is a superset of the overload definition [2]. The overload
definition assumes the congestion is introduced strictly by the tester on
ingress of a DUT/SUT. That may or may not be the case here.

Another difference between congestion and overload occurs when the SUT
comprises multiple elements, in that congestion may occur at multiple
points. Consider an SUT comprising multiple edge devices exchanging traffic
with a single core device. Depending on traffic patterns, the edge devices
may induce congestion on multiple egress interfaces on the core device. In
contrast, overload [1] deals only with overload on ingress.

Throughput [1] defines the lower boundary of congestion.  Throughput is the
maximum offered rate with no congestion.  At offered rates above throughput,
the DUT/SUT is considered congested.

Ingress observations alone are not sufficient to cover all cases in which
congestion may occur. A device with an infinite amount of memory could
buffer an infinite amount of packets, and eventually forward all of them.
However, these packets may or may not be forwarded during the test duration.
Even though ingress interfaces accept all packets without loss, this
hypothetical device may still be congested.

The definition presented here explicitly defines congestion as an event
observable on egress interfaces. Regardless of internal architecture, any
device that cannot forward packets on one or more egress interfaces is
congested.

___________________________________________________________ 
Jerry Perser                         Spirent Communications
Director of Test Methodology         SmartBits Division 
Phone: 818.676.2320                  26750 Agoura Road 
Lab:   818.676.2337                  Calabasas, CA, 91302 
Cell:  818.292.6457                  Corp:  818.676.2300

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

---

From: Kevin Dubray <[email-masked]>
Date: Tue, 24 Sep 2002 16:34:20 -0400

> Below is new definition (and discussion) for congestion.

It would appear the delta from the previous version of the
definition is that you remove the temporal component - "at any
given instant."

Also, from the new version of the discussion, you introduce a
relationship between throughput and congestion.

Here's my issue with the current tack this is taking:

     1. Congestion is a _widely_ used term, especially in networking.
        You seem to be putting an extremely fine point on it -
        cite a specialized (egress port) context but choose to utilize
        a generalized handle for the term being defined.

     2. Your discussion alludes to throughput and rates, yet the
        definition refers more to a quantity than rate.  In a
        1997 Nanog presentation, Steve Polit suggested network device
        congestion is: "...when packets arrive faster than can be
        forwarded".  While you allude to throughput in the
        discussion, the notion of arrival rates is missing in
        the definition.

If you want to keep the definition general, why not something
like: 'the condition when demand exceeds system capacity and
system response is subsequently impaired.'  This shouldn't
fly in the face of those who speak generally of congestion and
who may wish to speak of response time versus, or in addition
to, throughput.

If you really want to add terminology about a specialized type
of congestion, I'd consider using Mr. Polit's view with a more
pointed handle to avoid confusion with the general notion of
"congestion."

In either case, though, I suspect the reason you're introducting
the term is that you hope to use congestion as a factor
in the collection of a response.  Perhaps it should be left
at that - we can argue whether congesting an egress port makes
sense to a particular metric when you describe that metric's
methodology. :-)

Do others think this is hair splitting, or that Jerry's changes
are just fine?

-Kevin

---

From: Kevin Dubray <[email-masked]>
Date: Tue, 24 Sep 2002 16:34:20 -0400

-Kevin

---

From: Scott Poretsky <[email-masked]>
Date: Tue, 24 Sep 2002 17:12:51 -0400

Kevin,

I think you are 100% correct.

Scott

---

From: Scott Poretsky <[email-masked]>
Date: Tue, 24 Sep 2002 17:12:51 -0400

Kevin,

Scott