Re: [RE] Results of today's discussion
802.3 CM as I understand it, has very different requirements than RE. RE
requires the following:
(* could be done in 802.3, ** partially in 802.3)
1) Of course, fully supports 802.1
2) *Low cost (zero additional perceived cost per unit to consumer)
3) MAX 500uSec DELAY THROUGH EACH HOP (illustrated by Gibson)
4) Performance requirements are based on 7 hops maximum (3.5 milliseconds)
5) *Provide master clock with which all stations’ clocks maintain
bounded phase delay (illustrated by Pioneer, lip-sync and digital
speaker scenarios)
6) *Phase delay (between master and station clock) short term jitter
maximum is within a few microseconds
7) *Phase delay (between master and station clock) long term jitter
(drift) asymptotically approaches zero
8) *Isochronous traffic only supported over 100Mbps or greater full-duplex
9) *At least 75% of link bandwidth may be reserved for isochronous traffic
10) *At least 10% of link bandwidth is reserved for best-effort traffic
11) *Assumed cycle size is 8kHz (very widely used)
12) **Network provides a mechanism to request/assign resources for
isochronous transmission (e.g. bandwidth, channel) and the default
rule(s) for managing the resources
13) *Isochronous packets are never dropped nor delayed due to ANY other
network traffic
14) *Granularity (not minimum) of bandwidth allocation is on the order
of single bytes per cycle
15) By default, resource allocation is first-come-first-serve
16) **Network will automatically reclaim previously allocated but
currently unused resources
17) **Isochronous traffic is not disrupted when a station/session is
added/removed to/from the network
18) Allows bridging to isoch 802.11e
19) Allows bridging to isoch 1394
An end-to-end throttling mechanism, like what has been discussed in CM,
would not satisfy the RE requirements. I don't think what CM is trying
to do is anywhere close to RE. You could even say that they are
opposites, as a low resolution (more than per frame) throttling
mechanism would increase jitter. CM is for a very different application
than RE. Both may need coordination with 802.1, but that's the extent of
the similarity.
-John
Benjamin Brown wrote:
>
> 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???)
> -----------------------------------------
>
--
John Gildred
Vice President of Engineering
Pioneer Research Center USA
A Division of Pioneer Electronics
101 Metro Drive, 264
San Jose, California 95110
Office 408.437.1800 x105
Fax 408.437.1717
Mobile 510.295.7770