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

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 

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