Subject: RE: QDIM: Changing two QoS Model properties to uint64, units = na noseconds

From: "Weiss, Walter" <[email-masked]>
Date: Thu, 26 Oct 2000 15:34:12 -0400

> On Thursday, October 26, 2000 3:06 PM John Schnizlein wrote:
> To: Weiss, Walter; Robert Moore/Raleigh/IBM
> Cc: [email-masked]
> Subject: RE: QDIM: Changing two QoS Model properties to 
> uint64, units =
> nanoseconds
> 
> 
> At 11:45 AM 10/26/2000 -0400, Weiss, Walter wrote: 
> >
> >The purpose of DeltaIntervals are to specify specific points in time 
> >at which an action should occur. 
> 
> Do you really think timing precision of nanoseconds is necessary, 
> or even feasible for this specification?
>
Do you think microseconds are enough for the queue depth averaging function?
If the algorithm is different from that one, this aspect of the discussion
is not relevant.
 
> >For DeltaInterval, the property describes the interval for sampling. 
> >My understanding is that the algorithm is identical to the algorithm 
> >used to calculate the averaged queue depth. If my 
> understanding of the 
> >algorithm is flawed, then we will probably need to 
> reconsider properties 
> >as well.
> 
> I suspect it is an error to imply a particular algorithm in 
> the information
> model, even for the device model. Otherwise, an more-scalable 
> algorithm
> than calculating the average at the maximimum arrival rate of 
> the minimum
> packet should be considered.

Algorithms always influence the management parameters. That is why there are
different parameters for different classes of schedulers, meters, droppers,
etc. Further, an algorithm  does not necessarily translate to an
implementation. If you want to propose a different set of parameters such
that the semantics of the algorithm can be supported, I'm ok with that.

regards,

-Walter

---

From: "Weiss, Walter" <[email-masked]>
Date: Thu, 26 Oct 2000 16:50:15 -0400

John,

> The point here was the timing precision of policy actions; the 
> averaging function is a different question (below). Is it reasonable
> to attempt to specify the timing of a policy action to the precision
> of nanoseconds? .. microseconds?
> 
The precision of the policy has nothing to do with it. This describes the
precision of the averaging function of a meter in one or more devices. If we
want to change the averaging interval in a set of routers through a policy,
you would use this property to make the change. 

> My opinion is that implying a particular algorithm for computing the
> moving average queue depth in an information model that might become
> standards-track is wrong.
> 
Why. AF is described in terms of a very specific algorithm (probablistic
droppers). The MIB specifies those attributes necessary to configure the
majority of probablistic droppers. I believe the MIB is standards track.

> The choice of algorithm is essentially an implementation decision.
> My advice is that it is silly to recompute frequently the 
> average that 
> is intended to discriminate long-term congestion from expected bursts.
> If you wanted the rapidly-changing queue depth, you wouldn't average.
> Implying silly implementation in the information model is a good way
> to get people to ignore it.
> 
This is exactly the way that the majority of RED droppers work and how the
DS MIB describes it. As a matter of fact, the interval attribute specified
in the MIB is to allow algorithmic flexibility should implementations not
wish to calculate the average every time a packet is sent.

> John