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

From: "Perser, Jerry" <[email-masked]>
Date: Thu, 6 Mar 2003 09:44:30 -0800

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

---

From: "Mark E. Robinson" <[email-masked]>
Date: Thu, 6 Mar 2003 12:07:50 -0800

This is starting look like a mensa discussion group at 2 in the morning after way to 
much coffee:-) There are a couple of questions here. 

1) How does the test equipment know that IT has sent a bad packet and then 
removes that packet from the test calculation (ref paragraph 2 ) ? This would most 
likely come to light if the tester does not believe the numbers and then drills down to 
find out what went south. 

2) In relation to the test equipment, why would the test equipment care why a packet 
was dropped and how would it know if there is a simple algorithm problem or if the 
device is truly congested. It really should not care. The DUT/SUT is a black box. 
Once the packet enters the device/system the only thing the test/test equipment 
should care about is what comes out ( ref paragragh 3).

3)Hummmm, "If 'Good in' > 'Good Out', the DUT/SUT filtered the packet
   based on congestion, not on errors." What?

Congestion is the state of the DUT/SUT and is of no concern to the test/test 
equipment. 

It seems to me that this discussion is getting loaded down with what basicly 
constitutes red herring discussions. The last time I checked, thoughput, forwarding 
rate, latency, have already been defined several times over. The time has long past 
for RFCs to be manipulated to cover or smooth over tester/DUT limitations.   All 
definitions and methodology should treat the test equipment and DUT/SUT as black 
boxes. 

Mark Robinson

On 6 Mar 2003 at 9:44, Perser, Jerry wrote:

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

---

From: "Mark E. Robinson" <[email-masked]>
Date: Thu, 6 Mar 2003 12:07:50 -0800

Mark Robinson