Tom,
To clarify; the purpose of my original message wasn't to point out an
error in any solution. As far as I know, no solutions have been proposed
nor are PAUSE frames (or other extensions to the MAC Control frame)
likely to be the only solutions proposed - case in point: your implied
comment that something other than frame based protocols may be more
effective, cost efficient and less disruptive to the development
process.
Perhaps you'll expand on this in a future email.
The purpose was to continue a discussion between a very small group
of people in order to get more opinions. We have already formed a
study group and we have at least 2 meetings available to us to make
progress. Let's see what comes out of it before we try to slam the door
on it.
Regards,
Ben
Thomas Dineen wrote:
Brad And All:
As a veteran of Fiber Channel, Infiniband, Rapid IO and other
protocols
I am well aware of the concepts being discussed and how they might be
used!
Yes, the ideas you discuss below could be crafted into protocols and
standardized.
In fact nothing I have heard so far is new, this was one of my main
objections
to the Data Center Ethernet Call For Interest. The issue is whether
frame based
protocols would be effective in managing congestion on any scale of
interest.
I continue to have grave doubts they would be effective at any
reasonable cost.
Please reconsider Ben's comments below he seems to have hit the nail on
the head.
Also while queuing is inevitably a part of such an architecture do
not forget to
consider the substantial cost associated with the amount of queuing
implied by the
latency of a frame based protocol. Also please consider the number of
queues required
to provide any effective QOS Service. Having worked on similar
architectures for
other applications I can speak from experience that the cost sky
rockets. For the above
reasons I believe that a frame based protocol would be ineffective.
My core concern in writing this morning is the fixation of 802.3 on
frame based
protocols to the xenophobic exclusion of all others. Inevitability the
group will craft
and adopt another frame based protocol similar to 802.3x pause which
will prove
both in effective, costly, and disruptive to the development process.
This is why I
continue to to oppose this study group as a waist of effort.
Thomas Dineen
Booth, Bradley wrote:
Tom,
Flow- or class-based flow control could still use the 802.3x PAUSE
frames. The difference is that unlike the existing 802.3x which halts
all flows/classes/traffic types a flow/class/traffic based flow control
would only halt the data that corresponds to that flow/class/traffic
type.
I also believe that the terminology we want to use is queues. The MAC
responds to multiple queues: one for data, one for slow protocol frames
and one for pause frames. Maybe this is could be done by adding a few
new queues, maybe it requires some enhancements to flow control. I'm
sure there are many ideas of how to make improvements to the way
Ethernet handles multiple forms of traffic.
Thanks,
Brad
-----Original Message-----
From: owner-stds-802-3-cm@listserv.ieee.org
[mailto:owner-stds-802-3-cm@listserv.ieee.org] On Behalf Of Thomas
Dineen
Sent: Friday, April 23, 2004 1:36 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] To Pause or not to Pause, That is the Question
All:
Ben's statements below bring up some interesting points
many of which I agree with! However to me there is a bit
of a snicker here in that I have grave doubts that a 802.3
Task Force and the 802.3 Working Group would ever seriously
consider anything that was not a frame based pause type protocol,
thus rendering the entire effort a waist of time. This is why I voted
against the study group.
Thomas Dineen
Benjamin Brown wrote:
All,
This note is in response to a private thread that began before the
reflector was in place. I've moved it here without reproducing all
the previous material. Those who generated that material are
encouraged to raise their arguments again or to simply continue
this thread.
So, most agree that PAUSE doesn't work except in very special
cases or for some handpicked tests and, even then, it can have a big
impact on throughput. It sounds like PAUSE exacerbates the problem
of congestion, spreading it backwards through the network.
Why do we think that flow- or class-based PAUSE will work? What
problem does this fix that link-based PAUSE can't? Don't answer too
quickly.
Each flow/class on a particular link is likely to have multiple
sources
so by PAUSEing one of them, doesn't that have the same effect that
link-based PAUSE has, though perhaps only for one flow/class?
A flow can be defined many different ways and, based on your
definition, there can be many, many flows over a single link. When
we use PAUSE, either link-based or flow/class-based, we're acting
on a buffer. We can't act on each flow individually. That's not
practical
for a real implementation because it is not practical for a device to
have
a buffer for each flow. Therefore, numerous flows are combined into
a "class" (and I use this term generically) and each class is assigned
a buffer. All we can do is flow-control that buffer.
So, now I'll ask the question again. What does flow/class-based PAUSE
have over link-based PAUSE? An answer to this is critical is we're to
stand up in WG 802.3 on Thursday, July 15 and ask to become a Task
Force.
Regards,
Ben
--
-----------------------------------------
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???)
-----------------------------------------
--
-----------------------------------------
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???)
-----------------------------------------
|