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
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
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
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
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:
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
|