Re: EF% vs. BCN
Gunes,
I rather agree with Raj on this point. Policing and shaping at the network
access points
cannot completely avoid packet clumping inside the network, especially in
the rings.
I agree that all the points you described "would" be the minimum for
supporting EF "services".
However, its performance impact on non-EF traffic due to packet clumping
within the ring
would be of particular interest for the comparison of various proposals.
Cheers,
BJ
At 11:33 AM 08/18/2000 -0700, Gunes Aybay wrote:
>I don't necessarily agree that EF packets will be arriving together when
>EF traffic is given
>the highest priority. In practice, EF will be used for types of traffic that
>require bandwidth,
>latency and jitter guarantee, which are typical of voice and multimedia
>applications. EF can
>also be used to emulate TDM services over IP. By definiton, I would expect a
>traffic class
>that requires commited bandwidth and controlled jitter and latency not to
>exceed
>the committed
>rate. In any realistic implementation, the ingress devices would actually have
>to do policing and
>shaping with minimal burst allowance to enforce this kind of behavior,
>otherwise, I cannot
>see how EF can be made to work in any kind of network topology. If individual
>EF traffic flows
>are shaped so that they do not exhibit bursty behavior, it would be
>reasonable
>to expect that
>aggregatetion of EF traffic would also not exhibit bursty behavior .
>
>I beleive a typical end-to-end EF deployment over an IP network would look
>like
>this:
>
>- Assignment to EF class would be subject to network level provisioning. The
>provisioning
> system would have to know the total and currently utilized EF
> capacity for
>each congestion
> point in the network.
>- EF traffic will flows will be relatively uniform (i.e. not burst) over
>time.
>- EF traffic flows will be subject to admission control at the original
>ingress
>point of the network.
> A policing based admission control scheme is OK for traffic that is not
>inherently bursty, but
> a shaping function may have to be used for bursty flows. (I don't see why
>one would map
> bursty flows into EF class, though)
>- EF traffic will be subject to aggregate admission control at the admission
>point to the ring. (It is
> easier to implement an aggregate shaping function at this point)
>
>In such an implementation, I would expect to see the state of the high
>priority
>queue used for EF to
>be near-empty in a sustained fashion, i.e., if the total bandwidth
>allocated for
>EF is less than
>the ring
>
>It is also interesting to look at the implications of spatial reuse and
>failover conditions on the
>network level provisioning mechanism that is used to manage EF traffic in a
>ring topology.
>
>Gunes Aybay
>RiverStone Networks