Re: [EFM] RE: Pause frame usage in transport networks
Carlos,
I agree 100% with your assessment, but only for "packet" services. Since
most what is being referred to as "broadband services" is actually a form
what the ITU has defined as "packet" services your assessment would also
apply to those so called "value added services". I believe that your
assessment of the implementation of different types of congestion control
would only apply to "broadband services" or other types of "packet" services.
For "Frame Relay", the data link layer is defined to have a from of
congestion control. For the Frame Relay protocol, it uses forward explicit
congestion notification (FECN) and backward explicit congestion
notification (BECN). In some respects these operate similarly to "pause"
MAC Control frames defined in 802.3x. FECN and BECN are "in-band" with
the customer traffic and thus belong to, and for the use of the service
provider. FECN and BECN are generally set by the service provider for
network congestion control within the service provider facilities. FECN
and BECN might also be seen by the customer's equipment at each end of the
service, and would be required to respond accordingly
802.3x MAC Control frames are in band with the customer traffic in the
link. For services that are not "broadband", "packet", or "Frame Relay",
the specific traffic in the link belongs to the customer and is only for
the customer's use. Where the access bandwidth is greater than the
transmission bandwidth, the transmission facility can issue a message to
the customer facility that prevents the customer facility from
"overrunning" the transmission facility. Within the link, end to end, both
the access facility at each end and the transmission facility in the middle
are considered by law to be the temporary "property" of the customer. This
is what is meant as a "leased circuit". The law in most countries treat
"switched circuits" the same way while the "circuit" is established end to
end. For these services, your assessment would not apply, and another from
of congestion control must be used. This is where 802.3x will be useable.
Thank you,
Roy Bynum
At 10:29 PM 2/20/2003 -0300, Carlos Ribeiro wrote:
>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