Re: [RE] Results of today's discussion
Shvodian,
In the old days, one could require coordination through a variety
of mechanisms. From what I understand (from Geoff Thompson) there
is no longer any way to formally specify a coordination requirement.
However, understanding other similar activities is always
a good idea. Even if the groups start apart, charters
and ideas can change, so close cooperation is always valuable.
One can always sign up on the reflector and attend
teleconferences, which I do. I think the CM group is also
preparing a tutorial, with a teleconference on this topic
tomorrow. That tutorial might be a good thing to attend.
DVJ
-----Original Message-----
From: owner-stds-802-3-re@ieee.org
[mailto:owner-stds-802-3-re@ieee.org]On Behalf Of Shvodian
William-r63101
Sent: Tuesday, November 02, 2004 8:48 AM
To: STDS-802-3-RE@listserv.ieee.org
Subject: 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