Re: [RE] Results of today's discussion
Bill,
I asked a few questions at the 802.3 Congestion Management (CM)
teleconference today, since 802.3 Residential Ethernet (RE)
folks expressed an interest.
The answers follow. I have CC'd this to Ben Brown, so mistakes
(if any) can be quickly corrected.
1) Question: When will the 802.3 CM tutorial be presented?
Response: At:
November 16, 2004
San Antonio, TX 802 Plenary meeting
2nd tutorial slot (thought to be 8:00PM)
2) Question: What is the rough scoping/strategy for CM?
Response: a) 802.3 will define a throttle that can limit the
station transmission rate. This limits only
the overall rate, not per-connection and/or
per-class rates.
b) 802.1 (if willing) would define the mechanisms
to sense congestion and/or loss within the
interconnect, to better facilitate the correct
setting of the throttle rate (2a).
3) Question: Is this a dynamic or static rate throttle?
Response: It is quasi-static.
Dynamic in the sense that it can vary based on (2b).
Static in the sense that it controls the smoothed
averaged rate. Rate updates are presumably done
on an infrequent (not per-frame) basis.
Note that these are my perceptions and rewording of 802.3CM
statements by participating individuals, not accurate quotes.
As with all groups, things can change over time and these
statements do not constrain current/future activities.
(My crude attempt at a "use at your own risk" disclaimer.)
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