Subject: RE: [bmwg] Congestion Definition in dsmterm03

From: "Perser, Jerry" <[email-masked]>
Date: Tue, 15 Oct 2002 11:20:08 -0700

Kevin,

Sorry for the delay in the reply.  I wanted to take time in reading your
comments, reading Steve Polit's presentation, reading our definition.

The extremely fine point is "congestion" IS NOT "overloading" (RFC 2285).
Both terms will have "more packets offered than forwarded".  Congestion
happens between the ingress and egress ports, where overloading is at the
ingress of the medium.

Congestion assumes that there is no "overloading" (RFC 2285).  All packets
can and were accepted by the DUT/SUT.  The DUT/SUT did not forward all the
packets to the egress port for some reason.  We want to call that reason
"congestion".

We explicitly say "egress interfaces" to mean packets that SHOULD be
forwarded.  Packets offered not to an egress interfaces are destined to the
DUT/SUT.  An example would be control plane packets (i.e. BGP, OSPF, IGMP).
These packets do not belong any of the vector definitions and are not
typically included in measurements (RFC 1242, 2285, 2432).

We talk about Throughput (RFC 1242) to show the relationship between
throughput and congestion.  Most of the testing has been to find the
throughput of a DUT/SUT.  Differentiated Services (RFC 2475) talks about
offered loads beyond throughput.

Congestion does not have "Measurement units".  Congestion does not refer to
rates or a quantity.  It defines a condition, a state of the DUT/SUT.
During congestion, the DUT/SUT is losing packets.  There are other
definitions on measurements during congestion.

Instead of "arrival rates", can you use the terms offered load or forwarding
rate (RFC 2285)?  I am not sure if arrival rate is an ingress or egress
term.  The notion of arrival rates is in the definition.  The congestion
definition states both offered and forwarded.

One of our authors English language skills far exceeds mine.  I'll ask him
to look at you comments, then mine to see if there are gooder words we can
use to convey the message.

Jerry.

> -----Original Message-----
> From: Kevin Dubray [mailto:[email-masked]]
> Sent: Tuesday, September 24, 2002 1:34 PM
> To: Perser, Jerry
> Cc: BMWG (E-mail)
> Subject: Re: [bmwg] Congestion Definition in dsmterm03
> 
> 
> 
> On 9/3/2002, Jerry Perser wrote:
> 
>  > Kevin,
>  >
>  > 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
> 
> 
_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: Kevin Dubray <[email-masked]>
Date: Wed, 16 Oct 2002 10:59:00 -0400

Perser, Jerry wrote:

 >
 > Congestion does not have "Measurement units".  Congestion does
 > not refer to rates or a quantity.  It defines a condition, a
 > state of the DUT/SUT.

No issues here..

 > During congestion, the DUT/SUT is losing packets.

Ah. Here's where I don't agree.  Loss is _a_ possible indicator of
congestion.  As may be unexpected delay, delay variance, unfairness,
or (dare I say it) reordering.

And I understand the need to differentiate between packets dropped
at device ingress versus those dropped internal to the
system. (i.e.,  one can't apply a packet treatment to a packet
that doesn't make it into the box).

What I'm against is taking a reasonably well cited, general term like
"Congestion" (note the capital C ;-), and recasting its definition to
a more paroachial term that restricts it's indication solely to
lossful events on the forwarding plane.

Once again, I'd advocate taking a more general definition
of "congestion" (say, the gateway congestion definition cited in
RFC 1254) for the terminology draft, and leave the details of
how you plan to use loss as an indication of [device?, gateway?,
outbound?, egress-port-overuse?] congestion in the methodology document...

-Kevin

---

From: Kevin Dubray <[email-masked]>
Date: Wed, 16 Oct 2002 10:59:00 -0400

No issues here..

-Kevin

---

From: "David Newman" <[email-masked]>
Date: Wed, 16 Oct 2002 18:37:43 -0700

> lossful events on the forwarding plane.

The ID's coauthors discussed this at length a couple of versions ago. Some
of us wanted to use delay or other metrics as additional indicators of
congestion.

We ultimately decided not to do so. Here's why: Of all the metrics cited
here, loss on egress is the only one that always indicates a congested
state. The other metrics might indicate congestion -- but they might not.

For example: Let's offer a box loads of 10 percent and 50 percent of its
aggregate capacity. We observe zero loss in both cases but much higher delay
in the 50 percent iteration. Is the box congested, even though it forwards
everything without loss?

An even more troublesome issue is that the congestion threshold for all
metrics other than loss will vary according to test setup. Just because one
box exhibits 100 usec delay with 40-byte packets at 56 percent load doesn't
mean we should declare 56 percent as the universal congestion threshold for
any device.

Loss is loss -- a nice, neat, binary indication that congestion exists.

dn

---

From: "David Newman" <[email-masked]>
Date: Wed, 16 Oct 2002 18:37:43 -0700

dn

---

From: Scott Poretsky <[email-masked]>
Date: Thu, 17 Oct 2002 10:37:47 -0400

I have to admit that I am in complete agreement with Kevin.  But that 
should come as no surprise since I have been making these same points since 
we started work on the draft two years ago. Congestion is a condition in 
which a queue is filling due to packet arrival rate exceeding packet 
service rate.  This comes straight from fundamental queueing theory and I 
see no reason to change a definition that has been used throughout the 
telecommunications industry since the 1960s.

The definition applies to our hopefully soon to exist test methodology as 
well.   A Test Engineer can observe congestion occurring within a DUT at 
its egress port by observing increased delay or loss or both from the 
packets forwarded from the egress.   A Baseline is first established by 
making a few measurements of loss and delay at decreased offered loads.  As 
the offered load is increased, a point will eventually be reached in which 
there is delay because the queue is building and eventually loss because no 
queue is infinite.  Delay will occur before Loss occurs.  Delay is an 
indicator of congestion because the DUT is no longer able to service 
packets at the rate of arrival, which forces a queue to build.  Because 
packets sit in a queue, they take longer to get serviced and the Test 
Engineer observes Delay.  Loss may never occur under the condition in which 
delay is observed.  Both delay and loss may occur simultaneously.  The best 
router implementations for QoS allow the user to manually configure for 
each ToS value its queue size in units of microseconds to indicate the 
longest period a packet can sit in a queue (delay) before drops will start 
to occur (loss).  To your example below "We observe zero loss in both cases 
but much higher delay in the 50 percent iteration. Is the box congested, 
even though it forwards everything without loss?"  The answer is YES.  The 
queue is building because the device is becoming congested.  It may be "a 
nice, neat, binary indication" to have Loss as the only indicator for 
congestion, but that would be technically inaccurate.

It is also important to note that the location within the DUT at which the 
congestion (queueing) occurs does not matter to the Test Engineer 
performing black-box benchmarking.  Delay and Loss could be occurring at 
the ingress, on the backplane, or at the egress.  What matters is that the 
DUT is experiencing congestion and there is loss or delay to traffic (and 
likely TCP traffic).  The beneficial by-product of this is that congestion 
can be artificially induced in a DUT by offering traffic to multiple 
ingress ports bound for the same egress port.  This is a useful approach to 
perform QoS benchmarking.  The example that you provided and then I 
repeated above indicates you have a device in which it is not necessary to 
offer traffic on multiple ports to perform QoS benchmarking.

Above I mentioned "implementations for QoS allow the user to manually 
configure for each ToS value its queue size in units of microseconds to 
indicate the longest period a packet can sit in a queue (delay) before 
drops will start to occur (loss)".  This is known throughout the 
telecommunications industry as a "packet treatment".  I noticed Kevin used 
the word "packet treatment" below.  When  I wrote the very first draft of 
this terminology I included the term packet treatment.  It would be great 
to have it added back it in since it is a commonly used, but 
non-standardized term used for QoS.

Scott

---

From: Scott Poretsky <[email-masked]>
Date: Thu, 17 Oct 2002 10:37:47 -0400

Scott