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




Finally, a voice of sanity in this discussion.

As Carlos wrote, the last thing any serious EFM customer needs is flow
control acting on *all* traffic on its perceived "point-to-point
Ethernet link". If link-by-link flow control has any use at all in this
scenario (and that is a separate debate that does not belong here), it
would be on a per-traffic-class basis. By all means define such a
protocol under a separate 802.3 PAR (or study it in an 802 ESG if you
prefer) but it is not part of this project.

Andrew Smith

-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org] On Behalf Of Carlos
Ribeiro
Sent: Thursday, February 20, 2003 5:29 PM
To: Shahram Davari; 'Siamack Ayandeh'; Roy Bynum
Cc: Ben Brown; Geoff Thompson; mattsquire@xxxxxxx; Chau Chak;
stds-802-3-efm@ieee.org
Subject: 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