Kevin Dubray | 8 Oct 19:36 2002
Picon

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
Perser, Jerry | 15 Oct 20:20 2002

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.
(Continue reading)

Kevin Dubray | 16 Oct 16:59 2002
Picon

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?,
(Continue reading)

David Newman | 17 Oct 03:37 2002

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
(Continue reading)

Scott Poretsky | 17 Oct 16:37 2002

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.
(Continue reading)

Perser, Jerry | 17 Oct 22:13 2002

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 
Debby Stopp | 23 Oct 01:54 2002

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  
(Continue reading)

Perser, Jerry | 23 Oct 18:27 2002

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
(Continue reading)

Jim McQuaid | 23 Oct 18:56 2002

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
(Continue reading)

Debby Stopp | 23 Oct 20:22 2002

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

Jim -

Your point is well taken, however, the original question was regarding the validity of the reference sited in Jerry's suggested text for section 4.1.  That text specifies how the transmitted streams should be configured, not how the metrics are to be reported.

Jerry -

Thank you for your reminders from RFC 1242 and quote of RFC 2432.  That was extremely helpful, however, I believe the reference that you sited should be removed.  A better wording for that section of text is:

The relationship between the intended load [Ma91] of multicast class frames vs. unicast class frames MUST be specified:

    a) As an independent rate for unicast class and multicast class of traffic OR
    b) As an aggregate rate comprised of a ratio of multicast class to unicast class of traffic.

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



> -----Original Message-----
> From: Jim McQuaid [mailto:jim.mcquaid <at> netiq.com]
> Sent: Wednesday, October 23, 2002 9:57 AM
> To: 'Perser, Jerry'; bmwg <at> ietf.org
> Subject: RE: [bmwg] 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
> 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
> > To: bmwg <at> ietf.org
> > Subject: [bmwg] 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 
> >
> > _______________________________________________
> > bmwg mailing list
> > bmwg <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/bmwg
> >
> _______________________________________________
> bmwg mailing list
> bmwg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/bmwg
> _______________________________________________
> bmwg mailing list
> bmwg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/bmwg
>


Gmane