RE: [Diffserv] problems with Virtual Wire and RFC2598

[ROBERTS James FTRD/DAC/ISS <[e-mail]>]

I share Jean-Yves' doubts. One specific problem is the condition applied in
the draft to explain why an EF packet cannot wait behind another packet from
the same customer. 

It is stated that the EF property ensures that a customer EF stream of rate
R is served at rate R, averaged over any time scale of S/R or longer. In
fact, the EF property in question in RFC 2598 applies to the configured rate
for the EF traffic aggregate.

To say each customer stream is served at its nominal rate in any interval as
short as its interpacket interval seems to imply synchronous switching: the
period must be conserved exactly.

Applying the EF property as in RFC 2598 (ie, for the aggregate) does not
keep all the packets of one stream in their jitter window in the following
case. 
One stream of rate R is aggregated with m streams of rate r<<R. The
aggregate is served at rate X > R+mr. Assume constant packet size. Suppose
all the little streams generate one packet just before a packet arrives from
the big stream so that the latter is delayed by m packet slots. It is
sufficient that m/X >1/R for the succeeding big stream packet to catch up
and be delayed by its predecessor. The delay is proportional to m and can be
made as big as we like by choosing r sufficiently small.

Jim




> ----------
> De : 	Kathleen Nichols[SMTP:[e-mail]]
> Date :	mardi 28 mars 2000 03:13
> A :	Jean-Yves Le Boudec
> Cc :	[e-mail]
> Objet :	Re: [Diffserv] problems with Virtual Wire and RFC2598
> 
> 
> 
> Jean-Yves Le Boudec wrote:
> > 
> > I have some problems understanding RFC2598 and
> > draft-ietf-diffserv-ba-vw-00
> > 
> > a) RFC2598 requires that the service given to an aggregate flow
> > guarantees a rate down to a small time scale and further gives as
> > example
> > "A simple priority queue will give the appropriate behavior as long as
> > there is no higher priority queue that could preempt the EF for more
> > than a packet time at the configured rate. "
> > 
> > I have the impression that this statement ignores the phenomenon of
> > jitter accumulation due to aggregate multiplexing. When several flows
> > share their fate in a multiplex, then there is accumulation of jitter
> > from network node to network node, well beyond the bounds given in
> > this internet draft. The fact that flows are shaped at the network
> > input does not guarantee a bound on jitter after several hops. Some
> > bounds do exist, but they are not straightforward, and it is not even
> > clear whether finite bounds exist in all cases where the maximum
> > network utilization factor is less than 1. In the particular case
> > where the network topology is a ring, the answer is yes, however, in
> > general, it is unknown (as far as I know). See for example the
> > references below.
> > 
> 
> So this is what a lot of the discussion in the vw draft is
> attempting to address. We've tried to spell out what
> the assumptions are and how they get used. I'm hoping
> that in today's meeting we can figure out what is
> missing in the explanation so the next roll can make
> this clearer. Anna Charney's work uses a different set
> of assumptions.
> 
> There are some university folks who believe they can work
> out the analysis under the assumptions we work under. 
> Hopefully, they'll get something worked out and made
> publically available.
> 
> > It seems to me that the only way to guarantee the requirement
> > described in RFC2598 is to shape every aggregate at the output of
> > *every* network node, a solution that requires per aggregate
> > information which is not compatible with diffserv.
> 
> This comes out under Charney's assumptions since they are
> no more restrictive than the rules we assume for individual
> domains. Thus this is like the rules for shaping at the
> edge of every domain.
> 
> 	Kathie
> 
> _______________________________________________
> diffserv mailing list
> [e-mail]
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

_______________________________________________
diffserv mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/