Re: [EFM] RE: Pause frame usage in transport networks
On Thursday 20 February 2003 17:19, Shahram Davari wrote:
> Siamak and all,
>
> I was just talking to a major carrier and in their initial deployment
> of EOS they are relying on customer shaping/rate limiting. They don't send
> any PAUSE at all.
>
> Yours,
> Shahram
I'm a little bit late on this thread, but I can tell something about my
particular experience when designing a FTTH network for a trial.
We would not rely on PAUSE for congestion management. The main reason is that
PAUSE does not know nothing about the nature of the affected traffic. Other
congestion management techniques are able to make better use of the
information available at the upper protocol layers to selectively 'throttle'
the traffic. Some techniques may affect the ordering of the packets, but this
by itself is not a problem; if you know what you are doing, it's possible to
improve throughput and reduce congestion, with (almost) unnoticeable side
effects.
Another cause for concern is that some applications may rely on unidirectional
communication (video streaming being the main application now); for these
applications, timely arrival is more important than congestion management.
Pausing is not good for this kind of traffic, specially if coupled with
logical channel separation over the same link (either at L2 or even L3/L4,
with tunneling techniques).
All that said, I think that PAUSE still has a place in the protocol design, as
the last safety net against congestion. In my vision as a network engineer, I
would do the protection in three levels:
- Statistical provisioning; reserve enough bandwidth for 'worst-usual'
traffic. Exceptions are exceptions and deserve to be treated as such
(although as nicely as possible).
- Customer shaping/rate limiting, always enabled, even when the link is
underutilized. The reason to limit bandwidth even when the link is
underutilized is related to the 'user experience'; it gives a constant
experience, something that people tend to prefer even if they say otherwise.
Links that go from 'very fast' to 'very slow' depending on the user load tend
to cause problems with complaining customers. The stability of the user
experience is a very important factor for success.
- Last of all, PAUSE. If it is really congested, at least we try to signal the
condition in the hope that someone far away will take notice and slow down a
little. But again, this is a last resort scenario, and one that the network
engineer probably don't want to see in production.
Carlos Ribeiro
cribeiro@xxxxxxxxxxxxxxxx