Subject: mail rispedita-il ccds

From: [email-masked]
Date: Thu, 26 Jun 1997 13:26:42 +0200

Date: Tue, 24 Jun 1997 10:27:11 +0200
From: [email-masked]
To: [email-masked]
Subject: mail rispedita - il ccds
Sender: [email-masked]

From: Dimitrios Stiliadis <[email-masked]>
Subject: Re: Traffic Policing and domino effect
To: [email-masked] (Roch Guerin)
Date: Sat, 21 Jun 1997 09:18:36 -0400 (EDT)
Cc: [email-masked]
Sender: [email-masked]

Roch,

> 
> You certainly cannot give hard guarantees such as those of GS, but
> you still can do a lot to ensure adequate performance.  For example,
> with a WFQ like scheduler I can give the flow a rate guarantee and
> also allocate some (dedicated) buffering plus access to a shared
> buffer pool with some limitations on how much each flow can grab 
> from the shared pool.  This wont avoid real bad cases, where you
> have schedulers that do a lot of lumping, but you can still go a
> long way.

Hard guarantees is definately not the goal of a Controller Load 
service type. My feeling, however, is that the known analytical
results are inadequate to make an efficient use of the Controlled
Load traffic class. 

1. If we assume a per-flow scheduler how can one specify the
   necessary bandwidth to assure adequate sharing?
   If things like the TSpec leaky bucket rate are used, then no
   overbooking can be made, and the statistical multiplexing 
   gain will be low. From the network node resources point of view this 
   is the same as GS. If measurements are used, it is not clear yet
   how one can capture variance of traffic with long tails
   (if such tails exist ?) And what if measurements are wrong ?
   What if we understimated or overestimated the effective bandwidth
   and result in weights that are not accurate? The whole WFQ model
   is based on the assumption that weights are accurate. And,
   anyway how can static weights capture the variability of traffic
   over time ?
2. Even if we assume that 1 can be done, there is still no theory
   available for estimating effective bandwidth for anything else
   than a FIFO scheduler. The state-dependency of most per-flow
   schedulers make this a very difficult problem.
3. For me it is still an open question, whether the information
   captured in TSpec (average,peak, mx burst)  is saficient
   to allow network nodes to make effective admission control decisions
   that will ensure good support of Controlled Load and efficient
   use of resources. But I guess, we have to survive with that .. :)
> 
> In any case, the main point I was trying to make is that you should
> not do hard policing within the network.  Instead, you need to have
> mechanisms to ensure that excess traffic from one flow does not 
> degrade overall performance, but without assuming that anything
> that does not conform to the TSpec is excess.

I have to totally agree with that. It is my feeling however, that 
we have a long way to go before we can *efficiently* use a Controlled
Load traffic class.

Dimitrios