Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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???) ----------------------------------------- |