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: "Perser, Jerry" <[email-masked]>
Date: Thu, 17 Oct 2002 13:13:30 -0700

Kevin,

Thanks for the RFC 1254 pointer.  I will be adding it to dsmterm references.

After reading RFC 1254, it agrees with David Newman's comments.  I found
five different references to congestion and loss.  I would like to quote you
section 3.5 Fair Queueing, "On congestion, packets are dropped from the
longest queue."  In section 1.1, they talk about a "quantitative definition"
based on "resource power"  The problem is "resource power" is ambiguous as
long as the value of alpha is not standard (section 2.2).

Weather we congest the device, gateway, outbound, or egress-port-overuse
will be in the methodology document.  The terminology is defining what a
congested [device, gateway, outbound, egress-port-overuse] is.  In the
methodology document, we will be using [device, gateway, outbound,
egress-port-overuse] to show where the loss should be happening.

Do you have examples where congestion occurs and fails RFC 1254, Mr.
Polit's, dsmterm ID's definition based on loss?

Jerry.

___________________________________________________________ 
Jerry Perser                       Phone: 818.676.2320 
Director of Test Methodology       Lab:   818.676.2337 
Netcom Systems Inc.                Cell:  818.292.6457
26750 Agoura Road                  Fax:   818.880.9165 
Calabasas, CA, 91302               Corp:  818.676.2300

---

From: "Perser, Jerry" <[email-masked]>
Date: Thu, 17 Oct 2002 13:13:30 -0700

Kevin,

Jerry.