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

From: "Weiss, Walter" <[email-masked]>
Date: Thu, 26 Oct 2000 11:45:24 -0400

John,

Bob kicked me today to respond by pointing out that he was quoting me. My
comments follow inline.

regards,

-Walter

> -----Original Message-----
> From: John Schnizlein [mailto:[email-masked]]
> Sent: Wednesday, October 25, 2000 12:14 PM
> To: Robert Moore/Raleigh/IBM
> Cc: [email-masked]
> Subject: Re: QDIM: Changing two QoS Model properties to 
> uint64, units =
> nanoseconds
> 
> 
> 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 purpose of DeltaIntervals are to specify specific points in time at
which an action should occur. In the case of the average queue depth
measurement (TimeInterval), the value is already specified in nano-seconds
for the reasons already cited. 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.

There are two other issues. First, does line rate influence granularity. If
the conclusion is that the line rate does not have an affect on sampling
interval, then the question reduces to one of range of valid values. If the
range is small, it can easily be represented in a 32 bit property with an
appropriate units (10ns, 100ns, 1ms, etc.) For this first question, I can
argue either side, so perhaps I am not the best person to advocate one over
the other. I for one, would welcome some research or deployment experience
here.

The second issue relates to the mapping of the model to specific
implementations. Your comment seems to imply that some implementations don't
need this level of granularity because they don't perform the calculation on
a per packet basis. This comment, to my mind, is inappropriate to
determining the appropriate bounds of an Information Model. The purpose of a
model is to stand the test of time. The purpose of data models and mappings
of data models to specific products is to take advantage of more specific
knowledge and work around specific limitations in the protocols, data
stores, or specific implementations.  
> 
> 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.

I keep flipping on this issue. On the one hand, REALs allow you to sacrifice
precision in favor of greater flexibility in the ranges. On the other hand,
REALs are painful to support in devices. I think my second comment above is
the main arguement for using REALs: This is an information model. Specific
mappings of this model to data models like MIBs inherently require a mapping
of the data type because of limitations in the data type specifications, or
limitations on the part of the applications using the protocol to support
the data type.
> 
> 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. 
> "
> 
> 
> At 10:59 AM 10/25/2000 -0400, Robert Moore/Raleigh/IBM wrote:
> >
> >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)
> >
> >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.
>

---

From: John Schnizlein <[email-masked]>
Date: Thu, 26 Oct 2000 15:06:08 -0400

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?

>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.

John