Subject: RE: [Diffserv] ID-VW-BA, questions on jitter

From: Shahram Davari <[email-masked]>
Date: Tue, 4 Apr 2000 13:55:18 -0700

Hi Siamak,

Please see my comments below:

>-----Original Message-----
>From: Siamack Ayandeh [mailto:[email-masked]]
>Sent: Wednesday, March 22, 2000 3:28 PM
>To: [email-masked]
>Subject: [Diffserv] ID-VW-BA, questions on jitter
>
>
>I appreciate if the authors of the draft would comment
>on the following factors impacting jitter for virtual wire
>behavior aggregate (VW-BA).
>
>1. Neither RFC 2598 nor VW deal with the jitter induced by inband
>control
>and routing traffic which may be of higher priority than EF. Relative
>to "network" precedence is EF
>
>a)  at a  higher priority?
>b)  Is it of the same priority where each Class Selector CP
>      is limited to emitting one packet using a token bucket.
>c)  Or of lower priority.

I think a higher priority (than EF) class is acceptable only if it does not
emit more than 1 MTU size packet at a time. As you mentioned one way of
ensuring this property is probably to shape the higher priority flow to MTU
size packets.

>
>2. Related question is that ID-VW-BA page-5 talks of "EF's priority
>queuing model".  RFC 2598 does not impose such a requirement.
>
>3.  Given that the MTU size is likely to be >> than (fixed) EF packet
>size (S),  "n" in equation-1 should be at least 2 x MTU/S.
>Leading to the need for fragmentation on slow links carrying EF.
>This limits the plausible share of EF to 5% of link bandwidth or
>less.
>

Although your computation is a little off (in fact n > 1 + MTU/S, because
MTU/B < S/R - S/B), but your point is valid, and this limitation exist in
low speed links.

>4. Does this residual service time of  (2 x MTU/S)  also arise in the
>context
>of non-prority schedulers such as non-bursty WFQ?  Is the new
>limit k x 2 xMTU/S where k+1 is the number of scheduling classes.
>

When WFQ is going to be used to emulate Priority Queing (PQ), the weight
assigned to EF should not correspond to its configured rate, but the weight
should be much higher ( W >> R/B). For example if 5% of the link is EF, the
weight of the EF queue should be set to 90% not 5%. Your point is valid to
some extent if improper weight is used. But with proper selection of weight
the jitter (due to other queues) can be limited to 1 MTU size packet at
output rate.

>5. Given that "k" may be of order of 10s if not hundreds (of
>class-queues),
>what guidelines do authors suggest should be followed in terms of
>limiting
>"k".
>
>6. If this limit on "k" is not acceptable, then is EF-PHB and the VW
>behavior
>aggregate  limiting  scheduler implementations?
>
>7. Given that S, the packet size would be different for various EF
>flows, the
>jitter window discussed in the draft is an upper bound based on the
>largest
>packet size.  How does this bound on jitter window effect the idea of a
>virtual wire for flows carrying the smaller packets?
>
>Many thanks, Siamack
>
>
>
>
>
>_______________________________________________
>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/

---

From: Siamack Ayandeh <[email-masked]>
Date: Thu, 06 Apr 2000 14:31:53 -0400

Shahram,

Thanks for the reply. My comments are inserted below.

Regards, Siamack

> ensuring this property is probably to shape the higher priority flow to MTU

Even this scenario would lead to packet  inter leaving of "network" and "EF".
This would not be acceptable according to the VW-BA definitions. I guess
the definitions assume "ideal" conditions.

> MTU/B < S/R - S/B), but your point is valid, and this limitation exist in

My computation simply followed the logic of the draft since I was seeking
clarification.

> the jitter (due to other queues) can be limited to 1 MTU size packet at

So you are agreeing that "k" has be kept small. In general the scheduler
needs to visit the EF queue after visiting every other queue.  For EF queue
the burst limit is the number of active flows, while for the other classes it
would be one packet. For similar size packets the share of the EF would be
50% in the scenario you described above (no need to set it to 90%). I
guess this is how the factor of 2 shows up in the equation.

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