| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-ba-vw-00.txt
Hi Raj,I fail to understand why you think that EF traffic cannot be shaped? Even the best of scheduler/rate controllers add at least a packet to the incoming burst length. So, if you do not shape the traffic on the way out, these bursts get accumulated and hence at hop h, you will see O(h) burst sizes even for EF traffic (which might have entered the network in a tdm/cbr manner). In such cases, buffer sizing for EF traffic has to take into account such bursts, else we'll notice pkt drops even for EF traffic (which is not preferrable).The above burstiness was just due to the rate limiter at each input port. Now in addition to that, we might have "spatial" burstiness - this adds a "fan-in" dimension to the burst. So, the "EF train" could grow to be a big one and rate limiters at downstream nodes may end up dropping them.Regarding congestion indication - there is persistent congestion and then there is transient congestion - the congestion that you are talking about looks like transient congestion and should ideally be dealt locally (pick your flavor of RED) - congestion of persistent nature needs to be propagated back to upstream nodes (using BECN etc).Krishna-----Original Message-----
From: Raj Sharma [mailto:raj@xxxxxxxxxxxxxxxxxxxx]
Sent: Friday, August 18, 2000 7:00 PM
To: Reflector RPRSG
Cc: 'Gunes Aybay'
Subject: RE: EF% vs. BCNHi 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 ringIt 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