| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
David,
We are testing mechanisms that deal with the transient congestion issues in our simulation efforts. I agree that prioritization does nothing for transient congestion incurred by like traffic. It is only a solution for mixed traffic that is differentiate-able.
One solution to the transient issue is to use lots of buffer in switches, but that tends to be at a severe cost in latency and latency variation.
We have tested some mechanisms that are very effective in limited topologies, but we are still exploring their limits. There is also a cost of some additional complexities that may be offset by much smaller switch buffers. We have also shown we can very effectively control latencies and latency variations. However, these mechanisms require some support by both 802.3 and 802.1.
Gary
-----Original Message-----
Manoj,
Just trying to understand, with a few questions.
1) 802.17 has a classC, which allocated bandwidth in a weighted fashion among the applicants, so that (after feedback settles) applicantions with near-constant rate inputs will eventually be provided with their weighted fair shared of the available bandwidth.
From you email response, I assume this is what CMSG desires.
2) 802.17 also has classA (real time) and classB (preferential), which may be similar to differentiation and priorities. To make them work, access controls are also required, which (I believe) is not currently included in 802.3. I think, however, that you think this handles the transient issues, but I am highly skeptical. However, no point is arguing, since its not the scope of the CMSG project.
3) Another problem, that often occurs in clusters, is the transient overload problem. With computer backplanes, this is the classical every processor reads from one memory. Doesn't happen all that happen, cannot be characterized by an average load, and isn't helped by priority (all processors tend to have the same priority).
Problem (3) is being addresses by RBR, extensions to RPR, with appropriate extensions of computer-backplane like flow destination-asserted flow control, where the "destination" can also be an intermediate bridge. This can be found at:
I was hoping the RBR Working Group could leverage some of the CMSG advances. However, given the differences between (3) and (1), with the apparent CMSG leaning towards (1), I guess not.
I think (1) is an even harder problem, so I admire your initiative. Best of luck!
DVJ
David V. James
|