Re: [8023-CMTF] 802.3ar/D0.9 is available
All,
There is a set of enhancements to Ethernet switching architecture for a
"Next Generation" Ethernet-only network, which solve the Congestion
Management dilemma. It is briefly described in the IEEE CommMag/GCN, pp.
2-4, October 2005, available [on-line]:
http://www.lmdata.es/uets/uets-gcn.pdf
The proposed architecture, which uses a new technique we call Ethernet
Fabric Routing or “EFR”, makes possible to build bigger and faster network
nodes, which will interact closely with terminals to perform flow and
congestion control in collaboration between them, to turn Ethernet’s service
into deterministic and guaranteed.
Best,
Jose Morales Barroso
jmb@ieee.org
Michael Hathaway writes:
> Done all this. My point is that layer 2 of Ethernet ( on physical
> connection boundaries) is the wrong place for a static rate limiting
> function and question how useful it will be without ballooning in
> complexity and violating #3 in our list of objectives. I don't see how we
> are to satisfy the diverse needs of those who want congestion management
> in Ethernet if we assume that rate limiting happens below the layer that
> manages sessions/connections.
>
> -m.hathaway
>
> Hugh Barrass wrote:
>
>> Michael,
>>
>> You should take a look at the related work in 802.1. The proposal for
>> Backward Congestion Notification does exactly what you ask. It is not in
>> 802.3 because it is not related to the MAC or PHY. You should also look
>> at the Task Force work and agreements on the website. We give the
>> justification for the rate control mechanism (which is not intended to
>> deal with dynamic congestion) and we recognize that the congestion only
>> occurs at layer 2 and above (where traffic converges).
>>
>> Hugh.
>>
>> Michael Hathway wrote:
>>
>>> We've had this discussion in the past and it gets ignored or over ridden
>>> at the next meeting, but I'll put it forward one last time. What we've
>>> proposed for #1 below is either too little to be useful and would
>>> violate #3 if it were modified to actually perform a useful funciton.
>>>
>>> The current proposal performs static rate limiting at layer 2 by
>>> throttling the IPG to reduce all traffic being transmitted from the MAC
>>> based on an undefined congestion signaling mechanism.
>>>
>>> A computer connects to a network, which means it communicates with more
>>> than one device up stream. If the WAN device throttles my 1GB Ethernet
>>> MAC back to 500K I'd be rather disappointed with performance on
>>> connections to my printer, and media center. Unfortunately, as simple
>>> and benign as this proposal seems, in reality, static rate limiting is
>>> only useful if it is done on a, per connection or per session basis. Any
>>> given layer 2 connection has many of these. In fact the problem is that
>>> the number is un-bounded.
>>>
>>> Since Layer 3 is where connections, and sessions are established, the
>>> only logical place for a static rate limiting mechanism to exist is
>>> above layer 3, NOT IN THE MAC! Unless of course you want to violate
>>> objective #3 below. Need I remind us all that the ATM guys tried this
>>> and lost to Ethernet when it came to cost, complexity and scalability.
>>>
>>> The problem is that there are folks with diverse needs who want to have
>>> a congestion management funciton over Ethernet. One, all encompasing
>>> layer 2 solution won't fit all of their needs. What we could be doing,
>>> is defining some primitive MAC layer functions that would facilitate a
>>> variety of fabric management solutions that could be implemented on top
>>> of Ethernet. If we bother to look at the needs of those who've come to
>>> meetings in the past, it would be obvious that they need
>>> session/connection level rate limiting and we simply can't do this at
>>> layer 2 in Ethernet without it becoming something more like ATM,
>>> PCI-Express, etc..
>>>
>>> I'd propose that we discuss how the MAC can help with the following:
>>>
>>> 1. Supporting in band congestion signaling ( pushing congestion messages
>>> to the head of queue)
>>> 2. Link utilization threshold alarms
>>>
>>> There's complexity in what I've just proposed above as well. The MAC
>>> layer at best, can only expect to communicate primitive status to a
>>> higher layer management agent. We need to keep any mechanism we propose
>>> simple, such that it doesn't add to cost, complexity or latency. This
>>> can be done, but not without involving (or God forbid even embracing)
>>> other standards out of the purview of the IEEE, and there in lies our
>>> problem.
>>>
>>> If we want to blissfully believe that throtting all traffic from a MAC
>>> layer solves our problem, we can claim success and move forward, in
>>> spite of the fact that we have no idea what the actual mechanism is that
>>> will be controling this feature. On the other hand are we truly putting
>>> the necessary rigor into this standard by doing so?
>>>
>>>
>>> -m.hathaway
>>>
>>> Kevin Daines wrote:
>>>
>>>> David,
>>>> Not sure what you mean by "primary objective". Perhaps you didn't
>>>> intend to use the "reserved word" objective. The following are the (4)
>>>> TF objectives:
>>>> 1) Specify a mechanism to limit the rate of transmitted data on an
>>>> Ethernet link
>>>> 2) Specify a mechanism to support the communication of congestion
>>>> information
>>>> 3) Preserve the MAC/PLS service interfaces
>>>> 4) Minimize throughput reduction in non-congested flows
>>>> The CMTF adopted a proposal to satisfy CMTF objective #1.
>>>> Recently, proposals related to (backward) congestion notification have
>>>> been made in 802.1 (related to #2).
>>>> Kevin Daines
>>>> Chair, P802.3ar TF
>>>>
>>>> -----------------------------------------------------------------------
>>>> -
>>>> *From:* David V James [mailto:dvj@alum.mit.edu]
>>>> *Sent:* Tuesday, October 25, 2005 11:04 PM
>>>> *To:* Kevin Daines; STDS-802-3-CM@listserv.ieee.org
>>>> *Subject:* RE: [8023-CMTF] 802.3ar/D0.9 is available
>>>>
>>>> Kevin,
>>>> I would claim that the TF has still not provided any promising
>>>> solutions for avoiding dropped frames in a short-distance
>>>> (computer room) environment.
>>>> Thus, since it doesn't currently meet its primary objective,
>>>> I would smile (rather than frown) at radical new ideas that
>>>> have a chance of meeting the primary objective.
>>>> DVJ
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> *From:* Kevin Daines [mailto:Kevin.Daines@WWP.COM]
>>>> *Sent:* Tuesday, October 25, 2005 5:20 PM
>>>> *To:* STDS-802-3-CM@listserv.ieee.org
>>>> *Subject:* Re: [8023-CMTF] 802.3ar/D0.9 is available
>>>>
>>>> Asif,
>>>> As with any TF meeting pre-D1.0, presentations in support of
>>>> or
>>>> related to the TF objectives are welcome and encouraged.
>>>> Post-D1.0, the TF naturally shifts its focus to perfecting the
>>>> draft. During that phase, radically new ideas are generally
>>>> frowned upon.
>>>> That said, the plans for the meeting are
>>>> 1) Review D0.9 and prepare D1.0. Since we have adopted one
>>>> proposal in support of one of our objectives, it is the first
>>>> order of business.
>>>> 2) Entertain presentations, if any, in support of or related to
>>>> the TF objectives. I'll send my customary "Call for
>>>> presentations" e-mail shortly.
>>>> Kevin Daines
>>>> Chair, P802.3ar TF
>>>>
>>>> -----------------------------------------------------------------------
>>>> -
>>>> *From:* Asif Hazarika [mailto:ahazarik@FMA.FUJITSU.COM]
>>>> *Sent:* Tuesday, October 25, 2005 5:10 PM
>>>> *To:* STDS-802-3-CM@listserv.ieee.org
>>>> *Subject:* Re: [8023-CMTF] 802.3ar/D0.9 is available
>>>>
>>>> Kevin,
>>>> Hello. Time to discuss about the plans for the plenary
>>>> meeting.
>>>> What are the plans? We would like to meet and discuss the draft
>>>> and get updates.
>>>> regards
>>>> asif
>>>>
>>>>
>>>> -----Original Message-----
>>>> *From:* Kevin Daines [mailto:Kevin.Daines@WWP.COM]
>>>> *Sent:* Tuesday, October 25, 2005 3:51 PM
>>>> *To:* STDS-802-3-CM@listserv.ieee.org
>>>> *Subject:* [8023-CMTF] 802.3ar/D0.9 is available
>>>>
>>>> Congestion Management TF members,
>>>> At the July 2005 IEEE 802 Plenary meeting in San
>>>> Francisco, we (the P802.3ar CMTF) passed the following motion:
>>>> "Adopt changes to Clause 4, Annex 4A & Clause 30
>>>> described
>>>> in barrass_1_0505.pdf as a baseline proposal for
>>>> 802.3ar/D1.0. The changes to Clause 4 will be made after the
>>>> changes to Annex 4A have been solidified in 802.3ar TF review."
>>>> In order to jumpstart our progress on D1.0, Hugh
>>>> Barrass and
>>>> I have prepared P802.3ar/D0.9 for CMTF preview. It may be
>>>> found here:
>>>>
>>>> http://www.ieee802.org/3/ar/public/0511/802.3ar-d0_9.pdf
>>>> Please note this draft has no official status. It is
>>>> being
>>>> made available for TF preview, prior to the November
>>>> meeting, in order to more efficiently prepare P802.3ar/D1.0
>>>> and commence TF ballot after we meet in November. Hope to
>>>> see you in Vancouver.
>>>> Kevin Daines
>>>> Chair, P802.3ar CMTF
>>>>
>>>>
>>>
>>> --
>>> Michael Hathaway
>>> Pico Innovations
>>> Voice: 512-327-9563
>>> Fax: 877-408-0059
>>> Email: mhathaway@picoinnovations.com
>>>
>>>
>
> --
> Michael Hathaway
> Pico Innovations
> Voice: 512-327-9563
> Fax: 877-408-0059
> Email: mhathaway@picoinnovations.com
>