Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [8023-CMSG] To Pause or not to Pause, That is the Question

Title:
Thomas
As a veteran of Fast Ethernet, Gigabit Ethernet and 802.3X, 802.3p, 802.3Q, I would like to share with you a very Ethernet way of thinking.
Ethernet is all about simplicity.
Ethernet is all about meeting market demand.
Ethernet is about evolution, not revolution.
That is why it has lasted so long, and became so ubiquitous.
Unlike other more sophisticated protocols like TokenRing, FDDI, ATM and maybe others you have mentioned.
Every product that uses Ethernet has a different cost performance requirements.
Some require excellent performance with the cost of great complexity
Some don't. They just want the means to make the best effort, under congested situations.
Field demand drives, the establishment of a task force.
Ethernet's way, is to deliver something that
a - works right out of the box
b - has merit
c - has great performance
There are zillion other protocols that do traffic management great, for many years.
If there is a demand for such functionality to be included in Ethernet, then it has probably to do with something other protocols are missing.
Simplicity.
It is an Ethernet tradition to implement the unbelievable.

Thanks

Gadi Lahat

TeraChip

From: Thomas Dineen [mailto:tdineen@IX.NETCOM.COM]
Sent: Saturday, 24 April, 2004 02:16
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???)
-----------------------------------------