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

From: "Perser, Jerry" <[email-masked]>
Date: Mon, 7 Apr 2003 15:57:49 -0700

Mark,

Please do not post emails in HTML format.  It messes up the archives.
Answers are in-line:

>Yes it is the case. The tester determines the offered load and the shape of
the offered
>load. Thus it is the tester that determines if a DUT/SUT will become
congested. If the
>tester sends a Offered Load of 0 percent then what would cause the
congestion? 

This is a philosophical case.  An Offered Load of 0 percent constitutes zero
packets over the total test duration.  If no packets are offered (zero), no
packets are lost, hence no forwarding congestion.  There is a requirement to
offer one or more packets in order to externally observe traffic control
mechanisms.  In fact, RFC1242, RFC2285, and RFC2432 also have this
requirement of offering one or more packets.

>If the tester offers traffic to system under test and the test encompasses
the complete 
>system then the offered load is the cause for the congestion (see comments
for 
>paragraph 1 ) The fact remains that the test person needs to understand
what he/she is 
>doing ( what a concept ). If for any reason, any port becomes congested it
is still 
>caused by the traffic offered and it makes absolutely zero difference as to
who did 
>what to whom. If you are defining a chain of devices as a SUT then any
failure at any 
>point becomes a failure of the SUT. If you tried to run a test without the
basic 
>understanding of SUT and the traffic shape required, I would like to have a
talk with 
>your manager. 

You lost me in this statement.  Can you restate what the technical issue is?
I do not want to get into a debate about the yours, mine, or the test
operators competence.

Actual there is a different point to be made with this paragraph.  The last
sentence is incorrect.  RFC1242 does not limit "Overload" to the ingress
interface.  RFC2285 limits Overloading to the medium of the interface.  I
will send a note to the author of that paragraph to see if we can fix it.

>This paragraph has some serious problems. The fact that packet loss can be
caused by 
>any number of things pretty much nulifies this entire paragrah. The
inference of this 
>paragrah is that if packet loss occurs it is because of congestion. I will
give you 
>that most cases of packet loss will fall into this catagory but to say all
is simply 
>not right. The HUGE assumption here is that the devices forwarding process
is 100 
>percent bug free and that is never the case ( much as everyone thinks there
stuff is 
>bullet proof ). The fact remains that a packet can be dropped for a
googolplex of 
>reasons.

Packet loss can be created by many things.  I disagree that "The fact that
packet loss can be caused by any number of things pretty much nullifies this
..." I-D along with RFC1242, RFC2285, and RFC2432.  All four documents use
loss and an indicator for a metric.  The authors before me (RFC quoted) have
removed physical line errors, DUT bugs, and stupidity from loss.  Do other
BMWGers believe that these RFCs "has some serious problems"?

>So what this means is that throughput is the minimum rate at which you drop
a packet, 
>right?

Close. Forwarding Congestion is a condition that happens between throughput
[RFC1242] and Overloading [RFC2285].  This is the region where traffic
control mechanisms can be externally observed.  At rate below throughput,
all packet are observed to get the same treatment. At the Overloading rate,
loss is caused by 2 different forces: 1.) limit of the physical medium, or
2.) traffic control mechanisms.  Since you can not externally tell the
difference, we want to avoid this load.

> Ok with that accepted what does it mean when packets go out of order and
the 
>latency increases 10 fold ?

Packet go out of order and the latency increases 10 fold.  Do not try to say
more than really happened.  These two externally observable events do not
mean that the DUT/SUT is congested.

>A device becomes congested when it can no longer handle the 
>traffic it is offered. 1 packet held in a overflow buffer is a congested
device.  

Held or lost?  The I-D specifically talks about lost.

>So in this paragrah you disagree with paragraph 3. The "hypothetical case"
is not all 
>that hypothetical. As speeds go up, memory prices come down and the
buffering of 
>devices goes thru the roof. It is cheap way to cover a slow processor, bad
algorithm,  
>sloppy backplane fabric etc..   Further more, the only thing that I know
about the 
>ingress is the format and contents of the packet and amount being handed
the device. 
>The egress is where the proof is in the pudding. 

The I-D states "Ingress observations alone are not sufficient", you state
"egress is where the proof is in the pudding".  Are they both saying the
same thing?  Packet loss is equal to ingress packets minus the egress
packets.  We both agree with paragraph 3.

>This definition needs to be tabled and reworked., it's a mess. 

Where to you work Mark?  I am curious where your expertise lie.  Your email
address was from Mark E. Robinson [[email-masked]].  I am trying to
figure out what the BMWG has to do with Witchcraft.

Jerry.
_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: "Perser, Jerry" <[email-masked]>
Date: Mon, 7 Apr 2003 15:57:49 -0700

Mark,

the offered
congested. If the
congestion? 

the complete 
for 
what he/she is 
is still 
who did 
failure at any 
basic 
talk with 

caused by 
inference of this 
give you 
is simply 
is 100 
stuff is 
googolplex of 

a packet, 

the 

device.  

is not all 
buffering of 
algorithm,  
about the 
the device. 

Jerry.

---

From: Al Morton <[email-masked]>
Date: Mon, 07 Apr 2003 21:16:58 -0400

>figure out what the BMWG has to do with Witchcraft.

Comments like "it's a mess" are not helpful,
and prompt other bad behaviors.

This stuff stops here.

Keep it constructive, or keep it off the list.

Al

---

From: Al Morton <[email-masked]>
Date: Mon, 07 Apr 2003 21:16:58 -0400

This stuff stops here.

Al