Subject: Re: draft-ietf-intserv-ctrl-load-svc-00.txt

From: Sugih Jamin <[email-masked]>
Date: Mon, 04 Dec 1995 13:04:17 -0800

Some comments on the new controlled-load service model.

>   acceptance of a request for controlled-load service is defined to
>   imply a commitment by the network element to provide the requestor
>   with service closely equivalent to that provided to uncontrolled
>   (best-effort) traffic under unloaded conditions. This definition may
>   be taken to include:
>     - Little or no average packet queueing delay over all timescales
>     significantly larger than the "burst time".

Given the rather stringent delay requirement above and the relatively
lax traffic specification required, the resulting network utilization 
could be rather low.  It would be nice to see some studies on the 
comparative link utilization under the different service models.

> a network element processing a number of flows with long-term 
> characteristics predicted through measurement may be able to
> overallocate its resources to some extent without reducing the 
> level of service delivered to the flows.

You can do that only if you know the lifetime of the flows to which
you are overallocating your resources, i.e. only if the new flows are
not going to stay beyond the next "swell" in the lrd (long-range 
dependent)
traffic can you overallocate your resources to them.  Yet, flow 
lifetime 
is not part of your TSpec.

>   A merged TSpec may be calculated over a set of TSpecs by taking the
>   largest token bucket rate, largest bucket size, smallest minimal
>   policed unit, and largest  maximum packet size across all members of
>   the set.

The choice of token rate and bucket size involves trade-offs between
the two.  Without external constraints, one would simply choose token 
rate equals to one's peak rate (with bucket size 1).  When selecting a 
smaller token rate, one picks a larger bucket size to allow for bursts.
By taking the largest token rate AND the largest bucket size you would
be over-reserving resources after the merge point and would likely see
unnecessary rejections.  [This comment applies to some of the other
service model drafts also.]

> Evaluation Criteria
> . . . .
>   The second is the
>   degree of long-term change in the controlled-load traffic within the
>   bounds of its TSpec.  (Changes in this characteristic will have great
>   effect on the effectiveness of certain admission control algorithms.)

To test lrd effect, you'd need to control the flow arrival pattern,
flow lifetime distribution, and the length of your evaluation run.
If the evaluation run is too short, you won't see the lrd effect.
If flow lifetimes are too short, you also won't see the lrd effect.
If flows arrive at a high frequency, the admission control algorithm
will have enough control over offered load to reduce admittance
when the low-frequency of the traffic rises.

---
sugih