Re: [8023-CMSG] To Pause or not to Pause, That is the Question
Thomas,
>> the fixation of 802.3 on frame based protocols to the xenophobic
well phrased ^^^^^^^^^^
>> exclusion of all others.
Which others?
>> Inevitability the group will craft and adopt another frame based
>> protocol similar to 802.3x pause
What else do you prefer?
>> which will prove both in effective, costly, and
^ ineffective
>> disruptive to the development process.
>> ^^^^^^^^^^ How?
>> This is why I continue to to oppose this study group as a waist of
effort.
^^^^^
How does the "the narrowed part of the body between the thorax and hips"
relate to this project(:>).
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: dvj@alum.mit.edu
-----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 4:16 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] To Pause or not to Pause, That is the Question
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???)
-----------------------------------------