Subject: [Diffserv] restrictions on VW "circuit" rates in draft-ietf-diffserv-pdb-vw-00

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

Hi,

There appears to be a new fundamental restriction on the rates of VW 
"circuits" in the new VW PDB draft.   The Rules section 
2.2.  states  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".  More specifically, 
section  2.4.3. states that the rate of of any "VW circuit"  j cannot 
exceed 1/(1+max(n_j)) of the bandwidth of any link, where n_j is the 
maximum number of times circuit j can potentially merge with other VW 
circuits.

This restriction was not mentioned in the previous version of the draft, 
and has several fundamental implications.  I have a number of comments on it.

1.  Since as argued in section 2.4.3 without this restriction the 
properties claimed in the VW draft do not hold,   this restriction should 
probably be explicitly mentioned up front, in the Rules section 2.2, 
together with the total bandwidth limitation on the combined VW rate at 
each interface.

2.  It appears that there are two ways of enforcing this restriction. One 
is to perform per-VW-circuit admission control inside the cloud and 
maintain knowledge inside the cloud of how many VW circuits have already 
been admitted, and accumulating this information along the path of the 
circuit through the cloud.  While this may be a feasible option, it appears 
to be in contradiction to the Diffserv philosophy that the internal nodes 
of the cloud have only aggregate knowledge based on the behavior aggregate
(i.e. collection of all packet belonging to all VW circuits crossing a 
given link).  If this is how we  expect diffserv to be used, it would be 
nice to make that fact explicit.

Another option would be to imply no knowledge of the routes and consider 
the worst case number N of VW circuits in the Diffserv cloud and  require 
that the rate of any VW circuit does not exceed 1/N of the bottleneck link 
bandwidth.  That implies that the total amount of VW bandwidth that can be 
supported by a Diffserv domain is upper bounded by the capacity of the a 
single (bottleneck) link in the cloud.  This limitation seems 
rather  restrictive in real-world networks with any substantial degree of 
redundancy and/or highly variable link capacity (such as multiple fiber 
paths between pairs of nodes and several parallel layer 3 links per fiber).

Note that even in the case of per-circuit admission control, the 
restriction on the rates may be highly  limiting. As can be seen from 
example similar to that shown in Fig. 6 of the VW draft, if one flow enters 
at each node in the chain and exits at the next node, while one circuit 
traverses the entire chain, the max rate of any circuit  is limited to 
1/(h+1), where h is the number of hops in the chain, while any individual 
link is shared by at most 2 flows.  Note also that if a single flow 
traversing each hop is replaced by K flows of smaller rates, it would 
appear that the rate of the circuit that traverses the entire chain must be 
further reduced by a factor of K, even though the total rate of the cross 
traffic on each link remained unchanged.  So if one assumes that there are 
10 circuits per hop  that traverse a single hop, and there are 10 hops, the 
total amount of VW traffic in this network would be limited to 2%  (two 
circuits per link, 1% of the link bandwidth each; here max n_j = 100).

Next, since the limitation is per "circuit" rather than per the entire 
behavior aggregate (i.e. all VW packets on a link), there are significant 
implications in passing the aggregate VW traffic across the diffserv domain 
boundary to another diffserv cloud.  It appears necessesary  to know the 
number of and also the rates of all individual circuits constituting 
the  entire VW aggregate at the domain boundary link, and to perform 
admission control on a per-circuit basis rather than per-aggregate boundary.

These limitations are very important and  should be brought up up front and 
made very clear.

Finally, ingress policing must be done on a per-VW-circuit basis rather 
than per EF aggregate basis, which is also something that was not 
previously required.

3.    It appears that n_j should be the number of *times* the circuit j 
merges with other 	circuits rather  than the number of circuits.  This is 
needed to account for the fact that   any two circuits can merge and split 
several times, and hence one flow can meet  another flow (and be affected 
by its packets) multiple times.  Of course, this phenomenon is rather rare 
in today's networks due to SPF routing. It may occur, however,  in the 
context of  explicit routing or load-balancing.

4.    Once the restriction that the rate of every VW circuit cannot exceed 
1/(1+max(n_j) of the bottleneck link is accepted, the authors might 
consider citing prior work that demonstrates that under a set of 
assumptions (that are stricter than those of the VW draft - see below) the 
bound on queuing delay (and hence jitter) is in fact S/R.  This prior work is:

           I. Chlamtac et al. "A Deterministic Approach to the End-to-End 
Analysis of Packet flows in Connection-Oriented Networks",  IEEE/ACM 
Transactions on Networking,  Vol.  6,   No. 4, August 1998.

The paper proves that in a connection-oriented slotted  globally 
synchronized FIFO 	network with identical link speeds, a single class 
traffic (i.e. no lower priority class ) and fixed-size packets,  if the 
rate of each flow is limited by 1/RIN, and each flow is ideally shaped to 
that rate at the source,  then the  end-to-end queuing delay of a packet is 
bounded by RIN packet slots. Here RIN is the routing interference number, 
which is defined as the number of times the route of a given flow merges 
with routes of other flows (which has the same meaning as n_j)

This result is generalized to unsynchronized (but still  slotted single 
traffic class fixed-size packet) networks in

Hongbiao Zhang, "Design and analysis of protocols with QoS guarantees in 
Packet-Switch networks", Ph.D. dissertation, Boston Univ., Boston, MA, May 
1997.

To the best of my knowledge there does not exist a published proof of a 
similar statement under more general conditions of the VW draft 
(namely,  in the presence of non-Ef traffic, variable link speeds and 
variable packet lengths).

5.   As mentioned earlier ,  the limitation on the VW circuit rates is a 
consequence of the desire to limit the edge-to-edge jitter by 
S/R.   However, is the deterministic jitter (or queuing delay bound)  of 
S/R actually required by any application?  Since section 2.2. of the VW 
draft requires the existence of the reshaper at the egress router, it 
certainly seems that  jitter can in fact be larger and be simply absorbed 
by a reshaping buffer at the egress edge. Hence, *jitter* bound of S/R 
certainly seems artificial.  So the question remains on whether there exist 
any applications that requires *queuing delay* bound to be S/R.  Voice does 
not appear to need such a strict small deterministic bound.  It would also 
appear that all applications listed in section 2.1. of the draft  do not 
need such strict delay bounds either.  What are then the applications that 
do need such a delay bound and that justify the new rate restrictions on 
the VW "circuit" rates?

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/