Subject: Re: QDIM: Changing two QoS Model properties to uint64, units = nanoseconds

From: "Robert Moore/Raleigh/IBM" <[email-masked]>
Date: Wed, 25 Oct 2000 10:59:26 -0400

John,

This change comes from a comment that Walter made earlier on
the mailing list:

(This excerpt has my text quoted, and Walter's response unquoted)
> 4. AverageRateMeter.DeltaInterval
> 5. EWMAMeter.DeltaInterval
>      The units for these properties are already
>      specified as microseconds.  If 1 microsecond
>      is sufficiently granular, then we have an
>      interval a little over 1 hour as the maximum
>      we can represent.
>
This deserves a warning. The minimum granularity for most intervals whether
for a meters or average queue depth calculations should be 1 packet length
time. Therefore, the lower bound is determined by the speed fo the link. At
current link speed upper bounds (10Gb) and assuming a minimum packet size
of 64 bytes (we way want to consider ATM cells, but let's ignore that for
the moment), the current lower bound should be .000000067 of a second.
(End excerpt)

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

John Schnizlein <[email-masked]> on 10/24/2000 03:19:29 PM

To:   Robert Moore/Raleigh/IBM@IBMUS, [email-masked]
cc:
Subject:  Re: QDIM: Changing two QoS Model properties to uint64, units =
      nanoseconds

At 10:54 AM 10/24/2000 -0400, Robert Moore/Raleigh/IBM wrote:
>In looking further at the QDIM draft, it appears that the
>DeltaInterval properties in AverageRateMeter and EWMAMeter
>don't have a fine enough granularity.  These properties
>were defined in QDIM-01 to have units = microseconds.
>In fact, though, they need to have units = nanoseconds.

Could you say a little about why microseconds are insufficient,
please?

---

From: John Schnizlein <[email-masked]>
Date: Wed, 25 Oct 2000 12:14:27 -0400

Some scrutiny should be given to the claim that 
   "The minimum granularity for most intervals whether for a meters 
    or average queue depth calculations should be 1 packet length time."

Not only do averages need not be computed for every packet, but the
parameters involved here are configured thresholds for compliance with
a service-level-specification of rate. Microsecond level specification
(32-bits) is already overkill, but not worth complaining about because 
justifying the economy of a 16-bit number is questionable. 

The more serious problem, which I thought someone else raised, is that
a "real number" has limited practical value in a forwarding device.
If real numbers were actually used, the exponent would presumably
cover nanosecond scale of accuracy for this period. 

To help people evaluate the claimed need for this precision, 
included here is the relevant portion of 
draft-ietf-policy-qos-device-info-model-01.txt:  
"...
 4.3.10.1. The Property AverageRate 

   This is a 32-bit real number that defines the rate that is used 
   to determine whether admitted packets are in conformance or not. 
   The value is specified in kilobits per second. 

 4.3.10.2. The Property DeltaInterval 

   This is a 32-bit real number that defines the time period over 
   which the average measurement should be taken.  The value is 
   specified in microseconds. 

 4.3.11. The Class EWMAMeter 

   This is a new concrete class, defined in this model. It is a 
   subclass of the MeterService class, and represents an 
   exponentially weighted moving average meter. This meter is a 
   simple IIR low-pass filter that measures the rate of incoming 
   packets over a small, fixed sampling interval. Any admitted 
   packet that pushes the average rate over a pre-defined limit is 
   defined to be non-conforming. Please see [DSMODEL] for more 
   information. 

   The class definition is as follows: 

       NAME                EWMAMeter 
       DESCRIPTION         A concrete class describing admitted 
                           traffic as either conforming or non- 
                           conforming, depending on whether the  
                           arrival of a packet in a small fixed  
                           sampling interval causes the average  
                           arrival rate to exceed a  
                           pre-determined value or not. 
       DERIVED FROM        MeterService 
       TYPE                Structural 
       PROPERTIES          AverageRate, DeltaInterval, Gain 
   
 4.3.11.1. The Property AverageRate 

   This attribute is a 32-bit real number that defines the average 
   rate against which the sampled arrival rate of packets should be 
   measured. Any packet that causes the sampled rate to exceed this 
   rate is deemed non-conforming. The value is specified in kilobits 
   per second. 

 4.3.11.2. The Property DeltaInterval 

   This attribute is a 32-bit real number that defines the sampling 
   interval used to measure the arrival rate in bytes. The 
   calculated rate is averaged over this interval and checked 
   against the AverageRate attribute. All packets whose computed 
   average arrival rate is less than the AverageRate are deemed 
   conforming.  

   The value is specified in microseconds. 
"