Re: [8023-CMSG] To Pause or not to Pause, That is the Question
Hi Ben -
Personal opinion is that .3 is not the right place or the right people for dealing with congestion management.
I disagree that PAUSE doesn't work. It does exactly what its supposed to do - it <dynamically> lowers the effective bandwidth of an Ethernet link. I don't know that it was ever intended as a congestion management solution. How can anyone argue it as a negative that pause lowers throughput? Thats its intent. Its a bull$@!& argument.
A flow (or queue or class) based PAUSE will still have the exact same effect of exacerbating the problem by pushing congestion back thru the network. If all traffic happens to be one class, the behavior is exactly the same as link-based PAUSE.
I also believe its a bad idea to be introducing flows/queues/classes into .3. We work best when we're a pipe. Everything above .3 has the concept of flows/queues/classes (802.1, IP, etc). We don't need to introduce a similar and contradictory concept when the higher layers know .3, are designed to treat it as a pipe, and have much more complex and efficient QoS methods than .3 can ever have.
Any kind of congestion feedback is best delivered end-to-end from the source and sink of the traffic. 802.3 has no capability to address that problem as it simply covers MAC to MAC, and rarely are source/sink limited to the same Ethernet link. So we can't solve the problem even if we wanted to. We're not a network, we're a link, and its the forwarding/relay elements that have to handle congestion.
IMHO we should leave congestion handling to the bridges/routers/hosts.
- Matt
> -----Original Message-----
> From: Benjamin Brown [mailto:benjbrown@COMCAST.NET]
> Sent: Friday, April 23, 2004 12:32 PM
> To: STDS-802-3-CM@LISTSERV.IEEE.ORG
> Subject: [8023-CMSG] To Pause or not to Pause, That is the Question
>
>
> 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???)
> -----------------------------------------
>