Subject: RE: [Diffserv] problems with Virtual Wire and RFC2598

From: Shahram Davari <[email-masked]>
Date: Fri, 7 Apr 2000 08:26:25 -0700

Hi,

I think Roberts has a point here. This case can't be explained by RFC-2598
either.

Regards,

-Shahram

>-----Original Message-----
>From: ROBERTS James FTRD/DAC/ISS
>[mailto:[email-masked]]
>Sent: Tuesday, March 28, 2000 8:18 AM
>To: Jean-Yves Le Boudec; 'Kathleen Nichols'
>Cc: [email-masked]
>Subject: RE: [Diffserv] problems with Virtual Wire and RFC2598
>
>
>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:[email-masked]]
>> Date :	mardi 28 mars 2000 03:13
>> A :	Jean-Yves Le Boudec
>> Cc :	[email-masked]
>> 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
>> [email-masked]
>> http://www.ietf.org/mailman/listinfo/diffserv
>> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>> 
>
>_______________________________________________
>diffserv mailing list
>[email-masked]
>http://www.ietf.org/mailman/listinfo/diffserv
>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>

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