Subject: guaranteed rate service

From: [email-masked] (Pawan Goyal)
Date: Mon, 28 Aug 1995 09:10:14 -0500

I believe the error term C as specified in the "Network Element Data 
Handling Requirements" does not correctly capture the semantics it is
supposed to. To illustrate, the Network Element Data Handling Requirements
section says:
 
 " The fluid delay of a flow obeying a token bucket (r,b) and being
   served by a line with bandwidth R is bounded by b/R as long as R is
   no less than r.
 
   The network element must ensure that the delay of any packet be less
   than b/R+C/R+D where C and D describe the maximal deviation away from
   the fluid model. "

It can be easily shown that for  many scheduling algorithms 
(WFQ, Virtual Clock...) C as defined above is 0. However, for 
the purpose of computing Ctot, even in a network of only WFQ servers, 
C can not be chosen to be 0.

The main problem, I believe, is that the term Ctot in a network
environment  comes into play because of the packetized nature 
of transmission and not  the behaviour of individual
network elements. Hence, even if a network element ensures
that delay of any packet is less than  b/R+D, the term C
would exist in the end-to-end delay computations. 
Hence,  C is "independent" of the network element behaviour.

The correct semantics would be captured if a network element
is required to ensure maximum delay of b/R +D and  Ctot is 
interpreted as the number of servers on the path of a flow. 
In such a case, the e2e delay would be computed as:

	b/R + (Ctot -1)*L_max/R + Dtot

where  L_max is the maximum packet length of a flow. Observe 
that since L_max is a property of a flow, the network element 
has to characterize its behaviour by only one parameter D. 
Though it is possible that removing C from the characterization
of a network element may not allow capturing the behaviour
of all network elements (although I do not believe so),
its current definition can lead to incorrect behaviour. 

Pawan