| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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:
|