Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [RE] Results of today's discussion



OK, sorry for the confusion.  From now on I will include both full names of PARs that have been submitted for approval and a link or copy of or link to the PAR.  The 802.3ar congestion management PAR can be found here:

http://www.ieee802.org/3/cm_study/public/september04/802-3ar.pdf

The 802.3ar Congestion Management PAR does say:

"Ethernet networks are being used in an increasing number of application spaces (clustering, backplanes, storage, data centers, etc.) that are sensitive to frame delay, delay variation and loss. Study Group presentations have shown that Ethernet networks can experience higher throughput, lower delay, and lower frame loss by performing congestion management. This will improve Ethernet in its growing number of applications."

Maybe the key difference is that 802.3ar does not attempting to solve "real-time" delivery as David suggested, but the PAR definitely does address lower delay and delay variation.  I'll stand by my original statement/question that the TGs need to be coordinated.  After all, you don't want a congestion control mechanism that will try to reduce the throughput of a real-time stream below it's required throughput.

Bill

-----Original Message-----
From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG] On Behalf Of John Grant
Sent: Tuesday, November 02, 2004 4:03 AM
To: STDS-802-3-RE@listserv.ieee.org
Subject: Re: [RE] Results of today's discussion

At 09:08 01/11/2004 -0800, you wrote:
>All,
>
>Hmm...my search found a different affiliation. I guess that is a
>problem when tentative numbers are used before the PAR is actually
>approved.
>
>Congestion management is more closely affiliated to RE, but CM appears
>to be dealing more with dynamic load leveling, to reduce losses due to
>excess transmission rates through a congestion point.
>
>The CM group has not, from my observations, dealt with real-time
>delivery requirements. The CM work (or what I have observed of it) is
>dealing primarily with reduced losses, as opposed to the reduced
>latencies being addressed in RE.

RE should also be concerned with reducing (indeed, eliminating) losses, at least for the streamed-media traffic. As eliminating losses implies not overflowing buffers, which implies limited queueing time in switches (a packet must be forwarded before enough further packets have arrived to fill the buffer behind it), the mechanism for doing that will also have the effect of limiting latency anyway.


>Maybe in the future we should use numbers _and_ titles, when phrasing
>questions. That would reduce the context ambiguity.

Or not use numbers at all until they have appeared on the list at http://www.ieee802.org/3/


John Grant
   ___  ___  ___  ___    ___  ___  ___  ___  ___
  |   ||   ||   ||   |  |   ||   ||   ||   ||   |
  | N || i || n || e |  | T || i || l || e || s |
  |___||___||___||___|  |___||___||___||___||___|

Nine Tiles Networks Ltd, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com