Subject: [bmwg] dsmterm-05 - Forwarding Congestion

From: "Mark E. Robinson" <[email-masked]>
Date: Fri, 14 Mar 2003 16:05:18 -0800

3.1.3 Forwarding
Congestion Definition: A condition in which one or more egress interfaces are offered more
packets than are forwarded. Discussion: This condition is a superset of the overload definition [Ma98].
The
overload definition assumes the congestion is introduced strictly by the tester on ingress of a DUT/SUT.
That may
or may not be the case here.

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?

Another difference
between Forwarding Congestion and overload occurs when the SUT comprises multiple
elements, in that Forwarding Congestion may occur at multiple points. Consider an SUT comprising multiple
edge devices exchanging traffic with a single core device. Depending on traffic patterns, the edge devices
may
induce congestion on multiple egress interfaces on the core device. In contrast, overload [Br91] deals
only with
overload on ingress.

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.

Packet Loss, not
increased Delay, is the metric to indicate the condition of Forwarding Congestion. Packet Loss is
a deterministic indicator of Forwarding Congestion. While increased delay may be an indicator of Forwarding
Congestion, it is a non-deterministic indicator of Forwarding Congestion. External observation of increased
delay
to indicate congestion is in effect external observation of Incipient Congestion. [Ra99] states that
it is impractical
to build a black-box test to externally observe Incipient Congestion in a router. For the purpose of
"black-box"
testing a DUT/SUT, Packet Loss as the indicator of Forwarding Congestion is used.

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.

Throughput [Br91]
defines the lower boundary of Forwarding Congestion. Throughput is the maximum offered
rate with no Forwarding Congestion. At offered rates above throughput, the DUT/SUT is considered congested.

So what this means is that throughput
is the minimum rate at which you drop a packet, right? Ok with that
accepted what does it mean when packets go out of order and the latency increses 10 fold? 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.

Ingress observations alone are not sufficient to cover all cases in which Forwarding
Congestion may occur. A
device with an infinite amount of memory could buffer an infinite amount of packets, and eventually
forward all
of them. However, these packets may or may not be forwarded during the test duration. Even though ingress
interfaces accept all packets without loss, this hypothetical device may still be congested.

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.

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

Mark Robinson

--

"Good for nothing,
bad in bed, nobody likes you, your

better off dead, goodbye,
goodbye, we've all come to say

goodbye.."  Phantom
of the Paradise (1974)

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