Subject: [Diffserv] miscellaneous comments on draft-ietf-diffserv-pdb-vw-00

From: Anna Charny <[email-masked]>
Date: Wed, 26 Jul 2000 21:22:20 -0400

Kathie, Van and Kedar,

Below are miscellaneous comments on the  new VW draft.  Part of the 
comments are simply clarification requests, while others are issues which 
appear to exist with the draft.   Two major issues - one regarding the 
limitation on the individual VW circuit rates (section 2.4.3),  and  the 
other regarding the impact of non-EF traffic  on Ef traffic unaccounted for 
in the VW draft are discussed in separate messages.

Best regards,
Anna Charny

====================================================================================================================================

1.  sec 2.2 p. 3, 4   The definition of VW is the EF definition of RFC 2598 
with a SHOULD replaced by MUST.  However, draft-charny-ef-definition-oo 
shows that this definition is unimplementable. Unless someone can explain 
the flaw in that draft there will clearly need to be some change to this 
part of the VW draft.

2.  The Rules in section 2.2. state that "the bandwidth limit of each 
output interface SHOULD be configured as described in section 
2.4".  However, section 2.4. describes limitations not only on the 
bandwidth limit on the VW interface, but also a bandwidth limit on each 
individual "VW circuit". This should be reconciled and the implications of 
this limitation clearly stated out.   To limit the length of this message, 
I am putting the discussion of this limitation in a separate message.

3.  sec 2.4  p. 4 should give definition of "phase jitter" or at least give 
reference to which "QoS papers" give this definition.

4.  what exactly is the "EF bound" described in RFC2598?  I have looked 
through the entire RFC and have searched for "RF bound", but it appars that 
RFC 2598 does not actually mention "EF bound" at all.  Can you please 
define it?

5.  sec 2.4.1 p.6 "jitter independence" is not properly defined. Exactly 
what is it?  The text of the draft states that jitter independence means 
that each packet remains within its own jitter window. Is that the property 
of jitter independence, or is it the definition of jitter 
independence?   Further, the text after Fig 4 at page 6 of the pdf version 
states that jitter is independent. Is the statement that jitter is 
independent  (whatever it means) only in Fig 4 or is the statement that 
jitter is always independent for VW?  In the latter case, why is it so?

In the next paragraph:  is delta = jitter window = EF bound equal to S/R or 
can it be chosen arbitrarily?

6.  p. 7. in fig 5, why do packets of different colors get served in a 
different order at hop?  Is the service order here NOT a FIFO? Then what is 
it, and how can it be reconciled with footnote 1? If the service order is 
FIFO, why wouldn't the order of packets be the same at each hop after the 
first?

7.  p. 7 par in the middle begins with the sentence "jitter independence 
means that we only have to compare jitter window of Equation 1 to the worst 
case of the total queue wait that can be seen by a single VW packet...". 
However, as noted above, it has not been shown that jitter independence 
actually holds! In fact, isn't the goal of section 2.4.2. to actually 
demonstrate that it does hold? If that is the case, how can you use the 
fact of jitter independence to show that jitter independence 
holds?  Furthermore, Eq 1 also uses the fact that jitter is independent, 
rather than demonstrates it?  Perhaps I did not understand the logical 
argument here.  Can you please explain?

8.  p. 7.    footnote 1 is very unclear in its relationship to the 
statement that a VW packet can wait at most for a single non-EF MTU. While 
it is certainly true for PQ, this is not true for other schedulers that 
footnote 1 appears to refer to. "Priority queue up to a certain rate" still 
may allow multiple non-EF packets be sent before a given EF 
packet.  Furthemore,  many of the schedulers listed in the implementation 
section of RFC 2598 (such as WRR) as well as most WFQ-like schedulers do 
not actually behave like "priority queue limited to configured rate".  Can 
you please explain what you meant? Did you mean that PQ is the only 
possible implementation of EF capable of delivering VW, or did you mean 
that even with other schedulers listed in the implementation section of RFC 
2598 there can only be one non-Ef packet that interfere with
VW per hop? Or did you mean that even if it is more than one packet, it is 
still OK?

More importantly, the impact of multiple non-EF packets (or even a single 
large non-EF packet) with non-PQ scheduler can be quite pronounced, and can 
violate the "jitter independence" and resulting jitter bound, as I tried 
to  show in my previous message on VW delay bounds.

9.  p. 7 footnote 2.  The footnote states that the limit of 50% of the link 
speeed has nothing to do with overprovisioning but is a consequence of 
non-pre-emptive scheduler. It further states that any scheme that bounds 
jitter on mixed traffic must include a similar limit.  This statement is 
very misleading. As already noted in draft-charny-ef-definition,  the 50% 
bandwidth limit is a consequence of the EF definition of RFC 2598, more 
specifically it is a consequence of the requirement that the
EF aggregate receives its configured rate in any interval of length MTU/R 
or larger.
There could be several alternative definitions that do not impose the limit 
on the bandwidth (see for example draft-charny-ef-definition-00.txt).
It is true that in order to find a meaningful bound on EF jitter in an 
*arbitrary topology*
it is hard to expect to have more than 50% bandwidth limit (and in fact 
much less than that).  However, in simple topologies a tight jitter bound 
can be obtained without any limitations on the rate (for example, in the 
case of a full-mesh network).

10.  sec. 2.4.4.

Exactly what does it mean to "make all customers use the smallest jitter 
window"?  Does it mean that the worst case jitter will be largest 
packet/smallest rate?  In that case, it appears that the arguments in 
sections 2.4.1 - 2.4.3. needs to be modified, since they will obviously not 
hold (in particularm there certainly may be two packets of the same 
"circuit" in the queue?

If different codepoints are used for different rates, and the different 
queues will be served in the rate magnitude order, then it would clearly be 
the case that for a single rate queue, a packet atthe head of that queue 
may need to wait for many packets of other queues before it can be sent. 
This will only increasethe problem of jitter accumulation of VW traffic 
discusse above in the context of intercation with non-EF traffic.

Regards,
Anna

---------------------------------------
Anna Charny
Cisco Systems, Inc
300 Apollo Drive
Chelmsford, MA  01824
Tel. (978)-244-8172
Fax (978)-244-8126

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