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