Subject: RE: [bmwg] dsmterm-05 - Forwarding Congestion

From: "Perser, Jerry" <[email-masked]>
Date: Thu, 6 Mar 2003 11:20:48 -0800

John,

I'll start with a quote from RFC2285, section 3.5.2 Offered load:

      Frames which are not successfully transmitted by an external
      source of traffic to a DUT/SUT MUST NOT be counted as transmitted
      frames when measuring forwarding rates.

How do you define "successfully transmitted"?

My opinion is frames that has a CRC errors, Dribble Bit Errors, Alignment
Errors, or are either Oversize or Undersize lengths (RFC2889 section 5.9.3),
"are not successfully transmitted ... to a DUT/SUT".  The Data link layer
SHOULD filter these frames such that they never appear at the egress of the
DUT/SUT.

Jerry.

-----Original Message-----
From: John Dawson [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 10:42 AM
To: [email-masked]
Subject: RE: [bmwg] dsmterm-05 - Forwarding Congestion

> If the packet is corrupted going into the ingress of the DUT/SUT, 
> it is observed and not counted as a valid offered packet. 

Are you saying that offered load is now dependent upon whether the DUT
detects an error with the packet?  That seems like a substantial change in
methodology -- I use the word "seems" as I don't think the RFCs have
agreement on how offered load is actually to be measured.  Previously the
entire measurement process was independent upon the DUT's view of the world
-- we could measure everything from an external perspective.  The above
statement would be a substantial departure from that philosophy.

I would say that the group has avoided problems with bit error rate for far
too long.  I argue that some measure of protection is already warranted.
For instance, including an automatic retry for a failing test case if the
measured loss is less than the expected BER for the transmission media.

Although current tests (with an occasional retry) do work for 30 to 60
seconds without significant CRC disruptions, is that going to hold up as we
move to systems with many copper gigabit ports?  Is throughput going to
become a meaningless measure if the number of offered bits exceeds practical
BER limits?

John 
-----Original Message----- 
From: Perser, Jerry [mailto:[email-masked]] 
Sent: Thursday, March 06, 2003 9:45 AM 
To: Newman, David; Barbara Denny 
Cc: [email-masked] 
Subject: RE: [bmwg] dsmterm-05 - Forwarding Congestion 

Barbara, 
This I-D as well as its predecessors (RFC1242, RFC2285, RFC2432, RFC2647) 
have ignored physical layer errors.  The focus has been to benchmark the 
device.  Physical errors can affect the metrics, but in practice don't.  In 
RFC2554 or RFC2889 test where physical layer errors were present, I have 
corrected the error and rerun the tests. 
Another point is that we (the test operator) externally observe the metrics 
at the ingress and egress of the DUT/SUT.  If the packet is corrupted going 
into the ingress of the DUT/SUT, it is observed and not counted as a valid 
offered packet. 
If "a packet gets dropped due to buffer or queue limits being exhausted", 
weather it the IP layer or lower layers, then is falls under Forwarding 
Congestion.  If 'Good in' > 'Good Out', the DUT/SUT filtered the packet 
based on congestion, not on errors. 
Jerry. 
> -----Original Message----- 
> From: David Newman [mailto:[email-masked]] 
> Sent: Thursday, March 06, 2003 9:01 AM 
> To: Barbara Denny 
> Cc: [email-masked] 
> Subject: RE: [bmwg] dsmterm-05 - Forwarding Congestion 
> 
> 
> 
> On Thu, 6 Mar 2003, Barbara Denny wrote: 
> 
> > I sent David some more info but maybe I should 
> > at least mention to the group that this kind of 
> > loss will look the same to IP.  You lost a packet. 
> > At IP, how will you know if it was due to congestion 
> > or a problem at the link layer due to interference, 
> > etc? Are you requiring that lower layers notify 
> > IP a packet gets dropped due to buffer or queue 
> > limits being exhausted? 
> 
> Not at all. One of OSI's few redeeming features was layer 
> separation -- 
> one variable at a time is a very good thing indeed. 
> 
> Let's begin by agreeing that loss induced by events at other 
> layers occurs 
> all the time, and some of these events could affect the sole variable 
> under observation here -- the DS field in the IP header. 
> Examples include 
> LOF in Sonet, backoff algorithm timeouts in half-duplex 
> Ethernet, and RF 
> issues in wireless. 
> 
> If I understand your question correctly, it is essentially 
> "aren't these 
> cases where loss exists without congestion?" and of course 
> the answer is 
> yes. 
> 
> Still, this issue is orthogonal to the definition at hand. 
> Let's look at 
> the definition of forwarding congestion again: 
> 
> "A condition in which one or more egress interfaces are offered more 
> packets than are forwarded." 
> 
> In the cases above, the egress interfaces are offered too FEW packets, 
> not too many. Given this underfeeding, we would expect the egress 
> interfaces to be able to forward all packets without loss. 
> 
> My statement was that loss on the egress interfaces ALWAYS indicates 
> forwarding congestion. I don't believe anything we've discussed here 
> contradicts that statement. I could be wrong. If I've missed something 
> please let me know -- especially if there is a case we've 
> missed where 
> loss on egress != forwarding congestion. Thanks. 
> 
> dn 
> 
> ps. By the way, the issue of extraneous variables isn't 
> addressed in other 
> bmwg documents either. I could test a switch or router and 
> get throughput 
> of 0 bit/s by unplugging a cable, yet still conform to 2889 
> or 2544.  On 
> the general question of whether we should make all efforts to 
> factor out 
> extraneous variables like this, I think we're in complete agreement. 
> 
> 
> 
> _______________________________________________ 
> bmwg mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/bmwg 
> 
_______________________________________________ 
bmwg mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/bmwg 
_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: "David Newman" <[email-masked]>
Date: Thu, 6 Mar 2003 12:06:32 -0800

My $0.02: The issue is not whether L1/L2 events occur, but rather where they
are observed to occur.

From the perspective of what is externally observable, we can only know what
traffic we offer a DUT/SUT and what traffic the DUT/SUT forwards to us. In
practical terms, this means we collect stats from the test instrument's tx
and rx interfaces.

We do not and cannot know what happens in flight.

I take John's point that runts, bad CRCs, and the like can affect
measurements. Then again, I don't think John is suggesting that traffic from
a generator that itself introduces these errors should be considered valid.

John, if I've misunderstood your position please correct me. I would NOT
agree if you are saying traffic from a busted traffic generator, for some
definition of busted, should be considered valid.

dn

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Perser, Jerry
> Sent: Thursday, March 06, 2003 11:21 AM
> To: 'John Dawson'; [email-masked]

---

From: "David Newman" <[email-masked]>
Date: Thu, 6 Mar 2003 12:06:32 -0800

dn