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

---

From: "David Newman" <[email-masked]>
Date: Fri, 14 Mar 2003 16:52:56 -0800

And speaking of messes, thanks in advance for avoiding future congestion by
posting in plain ASCII, not HTML.

------------------------------------

MR: "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?
at determines if a DUT/SUT will become congested. If the tester sends a
Offered Load of 0 percent then what would cause the congestion?"

------------------------------------

DN: Perhaps you missed the phrase "introduced strictly by the tester on
ingress" in the discussion.

The fact that we offer various traffic classes to ONE interface doesn't
prevent us from offering background traffic to other interfaces. Ergo,
forwarding congestion may exist on an egress interface because of a
many-to-one traffic pattern.

The problem with existing definitions in 1242 and 2285 is that they deal
with overload on ingress. We're really interested here in the egress side,
which is what's new in this definition.

I'm not going to respond to the rest of your various assertions because no
bmwg methodology can determine your requirement that "the test person ...
understand[s] what he/she is doing." While I agree that is a laudable goal,
if your intent is to measure such a thing you might be better served by the
psychology department of your local university.

Kind regards,
David Newman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark E.
Robinson
Sent: Friday, March 14, 2003 4:05 PM
To: [email-masked]
Subject: [bmwg] dsmterm-05 - Forwarding Congestion

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

---

From: "David Newman" <[email-masked]>
Date: Fri, 14 Mar 2003 16:52:56 -0800

Kind regards,
David Newman

-----Original Message-----

Mark Robinson