Re: [RE] Results of today's discussion
John,
I agree that CM has evolved to where it appears to have little
in common with RE and we should not rely on this group to solve
the distinct RE technical problems.
It never hurts to stay informed, though, since things
can sometimes change.
The RE and CM groups _do_ appear to have a common organizational
characteristic. Both efforts may involve coordinated work by
distinct 802.1/802.3 subgroups/subprojects/subenties/WGs/??.
The organization of the effort could overlap, even if the
technical aspects do not.
DVJ
-----Original Message-----
From: owner-stds-802-3-re@ieee.org
[mailto:owner-stds-802-3-re@ieee.org]On Behalf Of John Gildred
Sent: Wednesday, November 03, 2004 2:19 PM
To: STDS-802-3-RE@LISTSERV.IEEE.ORG
Subject: 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