BMWG session at Atlanta IETF

Hi,

So far, I've only one request regarding a 15 minutes discussion slot
for the BMWG session at the Atlanta IETF.

Unless I hear from anyone else requesting a slot, I'm signing the WG
up for a 1 hr session.

Let me know,
Kevin

RE: Congestion Definition in dsmterm03

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.

Re: Congestion Definition in dsmterm03

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?,

RE: Congestion Definition in dsmterm03

> 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.

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

RE: Congestion Definition in dsmterm03

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.

RE: Congestion Definition in dsmterm03

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 

RE: draft-ietf-bmwg-mcastm-08.txt

Jerry -

I have been closely reviewing your comments from the archives:
http://www1.ietf.org/mail-archive/working-groups/bmwg/current/msg00139.html)
, specifically:

"A.) Input frame rate for each class of traffic [Br91] or as a percentage of
media_maximum-octets [Ma98].  There MUST be two rates; one for each traffic
class.

I believe this statement could lead to confusion.  I have searched Br91 <rfc
1242> for any mention regarding "input frame rate for each class of traffic"
but I haven't found any specific details regarding this reference.  I could
be wrong, just respond with why.

Thanks.

Debby Stopp 
Principal Software Engineer
(818) 444-2365

IXIA
26601 W. Agoura Rd. 
Calabasas 
CA 91302 
Tel: 818 871 1800 (US) +1 818 871 1800 (international) 

debby <at> ixiacom.com
http://www.ixiacom.com  

RE: RE: draft-ietf-bmwg-mcastm-08.txt

Debby,

You are correct that RFC 1242 does not mention "each class of traffic".  The
reason is that RFC 1242 only deals with a single class of traffic.  RFC 2432
section 3.2.1 was written to extend RFC 1242 definition.  Quote from RFC
2432: "Based on the RFC 1242 definition for throughput, the Mixed Class
Throughput benchmark attempts to characterize the DUT's ability to process
both unicast and multicast frames in the same aggregated traffic stream."

If you look at RFC 1242 section 3.17, measurement units are in "N-octet
frames per second" or frame rate.  RFC 2285 section 3.5.2 measurement units
include percentage.  RFC 2432 section 3.2.1 measurement units are "Frames
per second".

Many people quote throughput as a percentage.  This is not the valid units
per RFC 1242 or 2432.  I was attempting to write the draft to match the de
facto standard.  This reference can be removed if enough people object to
it.

A better wording would be:

A.) Input frame rate for each class of traffic [Br91] or as 
    a percentage of media_maximum-octets [Ma98]. There MUST
    be two rates; for both unicast and multicast frames.

Jerry.

> -----Original Message-----
> From: Debby Stopp [mailto:dstopp <at> ixiacom.com]
> Sent: Tuesday, October 22, 2002 4:54 PM

RE: RE: draft-ietf-bmwg-mcastm-08.txt

Throughput certainly is not measured as a percentage, just as you report.
But 1242 does include an appendix (which needs updating) which states the
maximum frame rate for different sized packets.  Of course, this creates a
natural desire and the context for thinking of throughput as a percentage of
the maximum possible rate.  It's not invalid to talk about it that way, but
it's not the UNIT for reporting throughput.

cheers,

Jim McQuaid
NetIQ

-----Original Message-----
From: Perser, Jerry [mailto:jerry.perser <at> spirentcom.com]
Sent: Wednesday, October 23, 2002 12:27 PM
To: bmwg <at> ietf.org
Subject: RE: [bmwg] RE: draft-ietf-bmwg-mcastm-08.txt

Debby,

You are correct that RFC 1242 does not mention "each class of traffic".  The
reason is that RFC 1242 only deals with a single class of traffic.  RFC 2432
section 3.2.1 was written to extend RFC 1242 definition.  Quote from RFC
2432: "Based on the RFC 1242 definition for throughput, the Mixed Class
Throughput benchmark attempts to characterize the DUT's ability to process
both unicast and multicast frames in the same aggregated traffic stream."

If you look at RFC 1242 section 3.17, measurement units are in "N-octet
frames per second" or frame rate.  RFC 2285 section 3.5.2 measurement units
include percentage.  RFC 2432 section 3.2.1 measurement units are "Frames

RE: RE: draft-ietf-bmwg-mcastm-08.txt