RE: EF% vs. BCN

[Raj Sharma <raj@xxxxxxxxxxxxxxxxxxxx>]

Title: RE: EF% vs. BCN

Hi Gunes,

Maybe I failed to clarrify.

EF can be bursty data or constant bit rate source.
EF could be rate limited. Once admitted at the ingress
it assumes a very unique personality. In fact, it cannot be
shapped. As a matter of fact, most EF are more like TDM
traffic.
It has a specific queue treatment: it must be
sentout immediately without preempting the current packet
or getting preferential treatment over another EF packet
in the queue.
This preferential treatment gives it a "speedup" over other packets
and hence all packets will get clumped near a choke point At this choke
point the rest of the traffic has to wait till the "EF train"
passes through.

So, this would be similar to assesing traffic congestion by the average
wait time for cars on a road upstream from a railroad crossing.
The train always gets priority over the cars.

Which point in time will you pick to signal congestion?

-----Original Message-----
From: Gunes Aybay [mailto:gunes@xxxxxxxxxxxxxxxxx]
Sent: Friday, August 18, 2000 11:33 AM
To: Reflector RPRSG
Subject: Re: EF% vs. BCN

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