Brad,
Definitely, yes. I won't say that I am categorically against any of the
other proposals, it's simply that by my calculations (for both
prioritized pause and preemption) indicate that they are not worth
doing. I will look forward to seeing some proof that I am wrong before
I change my position on those.
Throttling has some demonstrably good behavior in the case where a
device cannot service its input queue at line rate, therefore it should
ask the upstream device to throttle. This reduces the effective link
b/w and allows the device ahead of the choke point to control the
congestion (as it should be).
Hugh.
Booth, Bradley wrote:
Message
Hugh,
Can we sign you up as a supporter of link
throttling and then let the Task Force propose methods of performing
that throttling? I know a number of us have considered pause as a form
of throttling, but there are other methods as you've alluded to. Would
it be more palatable to you that the study group request doing
congestion management by using link throttling in their PAR?
Thanks,
Brad
David,
I would suggest that any form of feedback/pause mechanism is inherently
flawed, no matter which group does it (with the exception for link
throttling that I have already mentioned).
If you think deeply about the problem, you will see that the only way
for this to work is to extend the pause so that it goes from the choke
point back to the originating source of traffic that's causing the
overload. This type of problem has been around since the beginning of
networks and has, basically, two approaches for the solution:
1. Drop packets at the choke point (NOT anywhere else). Build upper
layer protocols that interpret dropped packets as indications that
congestion exists, therefore they reduce the system load. This works!
2. Build a network of channels (or virtual circuits if you will). As a
connection is defined from one end point to another, bandwidth is
reserved across all the links required for making the connection. This
also works, but is deprecated for (normally connectionless) packet
networks - traffic is going from each end point to many other end
points. Perhaps there will be a resurgence in channelized solutions for
self-contained networks, provided that the provisioning and management
problem is solved - this will not be Ethernet!
A congestion based pause mechanism has the effect of moving the
congestion point. This means that traffic passing through the false
congestion point is effected, whereas it wouldn't normally have been.
Depending on the network architecture and components, this false
congestion may cause increased latency or packet loss for the innocent
traffic. This will cause upper layer protocols to mistakenly react to
perceived congestion. It will also cause network level traffic
management to misinterpret the position of the choke point, causing bad
changes to routing configurations.
Hugh.
David Martin wrote:
Matt,
Thanks for
the reply.
I'm trying
to stay away from the organizational "where to do it" angle of .3 vs .1
and consider whether there is some backpressure that could be done at a
finer granularity like per-VLAN ID or per-CoS.
WG locale
aside, are you saying you're not a fan of either a per-VLAN ID or per-CoS
backpressure mechanism?
...
|