| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
-----Original Message-----
From: Krishna Pattabhiraman [mailto:Krishna@xxxxxxxxxxxxxxx]
Sent: Wednesday, September 20, 2000 12:43 PM
To: 'Sanjay Agrawal'
Subject: RE: EF% vs. BCNSanjay,Here is an example - used usoft word because it was simpler for diagram. In this example, I'll show how delay accumulates over each hop. Even though the burstiness on a link does not exceed the # of voice flows, it is possible for delays to accumulate due to the "spatial" burstiness - over number of hops, it then translates to a burst in the flow itself even if it was shaped coming into the network.Krishna-----Original Message-----
From: Sanjay Agrawal [mailto:sanjay@xxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, September 19, 2000 6:07 PM
To: 'Krishna Pattabhiraman'
Subject: RE: EF% vs. BCNHi Krishna,I am famaliar with Anna Charny's work. I have had few interactions with her regarding this. Van Jacobson, and Kathy have tried to convince her but without any luck. Problem with her assumption is that she is not considering provisioning for the critical link on the diffserv network. At each hop she is considers all the possible new flows. Total number of flows provisioned for the critical link are much smaller than number of flows than can accumulate at each hop. This equations is a result of this basic error. The maximum burst will never exceed the number of voice flows at any provisioning level unless there is provisioning error.-Sanjay K. Agrawal-----Original Message-----
From: Krishna Pattabhiraman [mailto:Krishna@xxxxxxxxxxxxxxx]
Sent: Tuesday, September 19, 2000 1:28 PM
To: 'Sanjay Agrawal'; Raj Sharma; Reflector RPRSG
Cc: 'Gunes Aybay'
Subject: RE: EF% vs. BCNHi Sanjay,
If you do not shape, and maintain a very small EF utilization in the network, you can get some delay bounds - however they are only reasonable for small utilizations and small number of hops in the network. But in general, for higher utilizations, all bets are off, and examples can be given when in fact burstiness/delays grow at least as fast as (1+util)^(hop count) times f(util) where f(util) is linear in util (EF utilization factor).
I dont know if you followed the discussion on the diffserv work. I would refer you to work by Anna Charny on this - u'll find references to it in the mailing list.
Following up on why EF should not be shaped (actually I had posed this question earlier!!) - If you shape aggregate EF traffic at each hop, the worst case behavior is even worse than if you do not shape it (intuitively this is because you can think of aggregate shaping as roughly running EF on links of small capacity which are fully utilized by EF, so by the above, you get worse behavior).
If you shape EF on an *edge-to-edge* aggregate basis (that is the aggregate of all EF flows between a particular ingress and egress pair), then you can indeed substantially improve the jitter and delay bounds. That requires identification of *edge-to-edge "flows" at each internal hop at the domain - so just looking at the DS codepoint no longer suffices.
Regarding the ECN discussion - I did not propose ECN as a mechanism - I just chanced upon the posting and commented generally on it. Pardon me for nit-picking, RED (in its pure VJ/SallyFloyd form) is also not the best mechanism for transient or persistent congestion - there are variants that perform better. Again, best, better or worse depends on the metrics of interest for the service provide/eqmt maker.
I hope that helps.
Krishna
-----Original Message-----
From: Sanjay Agrawal [mailto:sanjay@xxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, September 19, 2000 4:08 PM
To: 'Krishna Pattabhiraman'; Raj Sharma; Reflector RPRSG
Cc: 'Gunes Aybay'
Subject: RE: EF% vs. BCNHi Krishna,I have few comments.EF train will grow but it can never grow to be more than EF packets equal to number of active connections unless there is a provisioning problem. For provisioning please see Van Jacobson's and Kathleen Nichols's recent results inhttp://www.ietf.org/internet-drafts/draft-ietf-diffserv-ba-vw-00.txt
Voice streams produce packets periodically with a fixed time period. If provisioned right within the fixed time frame there will never be voice packets more than number of connections. Shaping won't help to reduce jitter it may help to reduce N degree buffering requirements at each node which is no big deal.RED accomplishes both transient and persistent congestion. ECN helps remove persistent congestion through marking instead of dropping. Unfortunately, it is not widely utilized.-------------------------------------Sanjay K. Agrawal, Ph.D.Luminous NetworksCupertino, CA 95014-----Original Message-----
From: Krishna Pattabhiraman [mailto:Krishna@xxxxxxxxxxxxxxx]
Sent: Wednesday, August 30, 2000 9:06 AM
To: 'Raj Sharma'; Reflector RPRSG
Cc: 'Gunes Aybay'
Subject: RE: EF% vs. BCNHi 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