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

Re: [RE] Results of today's discussion



Title:

David,

The 802.1 piece of the project isn't quite as you described.We're
asking 802.1 to create a tag of sorts that it can use to generate
FECN (Forward Explicit Congestion Notification). TCP can
then use this to reduce traffic end-to-end before packets are
discarded. IP already has a mechanism to carry FECN but when
IP packets are encrypted, or other network layer protocols are
used that don't already have a mechanism, this may be a useful
addition. Some L3/L4 aware bridges already have this capability
in a proprietary fashion.

There may be other ideas that 802.1 comes up with.

I hope this helps.

Regards,
Ben

David V James wrote:
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



  

--
-----------------------------------------
Benjamin Brown
178 Bear Hill Road
Chichester, NH 03258
603-491-0296 - Cell
603-798-4115 - Office
benjamin-dot-brown-at-ieee-dot-org
(Will this cut down on my spam???)
-----------------------------------------