Subject: RE: QDIM issue: changing real32's to uint32's

From: Walter Weiss <[email-masked]>
Date: Fri, 18 Aug 2000 11:56:54 -0400

Bob,

Comments inline.

regards,

-Walter

> 
> There are 16 properties in draft-ietf-policy-qos-
> device-info-model-01.txt (from now on I'm just
> going to say "QDIM-01") that have as their syntax
> "32-bit real number."  While it's true in general
> that an information model should be concerned only
> with capturing the true semantics of a property,
> and leave to each individual data model the task
> of determining how to encode these semantics, we
> need not pretend that an information model exists
> in a vacuum.  We know that this QDIM model will be
> mapped to a MIB, a PIB, and (most likely) to an
> LDAP schema, so it's legitimate to give some
> thought, and some weight, to the problem of how to
> map the information model to these data models.
> 
> Based on my experience with MIBs, my inclination
> is to see how many of these properties can be
> changed to a syntax of uint32.  For every property
> that we can change in this way, we will turn the
> difficult task of mapping a real32 to each data
> model (and the difficult task of dealing with it
> once it's there) to the much simpler task of
> mapping a uint32.  To determine whether a property
> can be changed to a uint32, we need to check
> three things:
> 
>   - Are all of its values non-negative?
>   - What is its maximum value?
>   - What granularity is needed for its values?
> 
> The last two of these questions are obviously
> related, since, by playing with the units, we
> can trade off bits between the maximum value for
> a property and its granularity.
> 
> I'll now go through the 16 properties one by one,
> with a goal of showing that all 16 of them can be
> changed to uint32's without losing the ability to
> represent the desired semantics.  Since all 16 of
> the properties represent non-negative values, I
> won't bother saying that each time.
> 
> 1. AverageRateMeter.AverageRate
> 2. EWMAMeter.AverageRate
> 3. TokenBucketMeter.AverageRate
>      These three properties already have kilobits
>      per second as their units.  I'll claim that
>      1 kilobit per second is a fine enough
>      granularity for these meters, and that
>      2**32 kilobits per second is a sufficiently
>      large maximum average rate for these meters.
> 
I am ok with this.

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

> 6. EWMAMeter.Gain
>      I'm a bit out of my element here, but some
>      of my coauthors have assured me that a
>      uint32 provides sufficient granularity and
>      maximum size for this time constant, which
>      has no units.
> 
Gain specifies the same thing as the SmoothingWeight parameter below.

> 7. TokenBucketMeter.PeakRate
>      This property's units are already kilobits
>      per second.  So it should work as a uint32
>      just as the three average rates do.
> 
> 8. TokenBucketMeter.BurstSize
> 9. TokenBucketMeter.ExcessBurstSize
>      These properties are already expressed in
>      units of kilobytes.  This yields a
>      granularity of 1000 bytes, and a maximum
>      value somewhere up in the terabytes.
> 
> 10. REDDropperService.MinQueueThreshold
> 11. REDDropperService.MaxQueueThreshold
>      These two objects don't have any units
>      in the QDIM-01 document.  In the Diffserv
>      MIB, however, there are two pairs of
>      queue threshold objects:  one pair with
>      units = "bytes", and a second pair with
>      units = "packets".  All four of the MIB
>      objects have the syntax Unsigned32
>      (uint32).  Based on the MIB, it's clear
>      that uint32's will be fine for these
>      objects in the QDIM.  We need to decide,
>      though, whether to follow the Diffserv
>      MIB in defining two pairs of objects.
>      And if we decide that one pair is
>      sufficient, then we need to pick either
>      bytes or packets as their units.
> 
> 12. REDDropperService.StartProbability
> 13. REDDropperService.StopProbability
>      Currently in QDIM-01 the range of these
>      properties is said to be from 0 to 100.
>      Unless somebody says otherwise, I think
>      a reasonable granularity for these
>      properties is whole percents, which
>      means that the set of possible values
>      for each of these objects is the set of
>      integers from 0 to 100.
> 
This is not granular enough. In effect this says that for every 100 packets
passing through the queue between 0 and 100 should be dropped. My
recollection was that the recommended value was something on the order of 2
in a 1000. However, I don't know how link speeds factor into this. Therefore
I would recommend not representing this as a percentage but as a
probablistic dropped packet count. The minimum upper bound should be 10000.
We may need to increase that as experience demands.

> 14. WeightedREDDropperService.Weight
> 15. QueuingService.SmoothingWeight
> 16. WeightedRoundRobinPacketSchedulingService.
>         WeightingFactor
>      All three of these properties are used
>      to establish differences in treatment
>      among traffic streams, by giving some
>      of them more "weight" than the others
>      in various calculations.   As in the
>      preceding case, the integers between 0
>      and 100 would seem to give an
>      administrator more than enough values to
>      use for establishing these differences
>      of treatment among traffic streams.
> 
I can't speak for WeightedREDDropperService.Weight since I have not seen the
implementation for it. However, SmoothingWeight is very different from
WeightingFactor. A weighting factor is often specified in terms of a
increment on a counter (queue with the highest counter gets to send). In
contrast the SmoothingWeight is a fraction usually falling on multiples of 2
(1/2, 1/4, 1/16, 1/64, etc.), since hardware divides are expensive and bit
shifts are cheap. Since all implementations I know of use multiples of 2, we
could represent SmoothingWeight as the number of bits that are shifted.
However, this may preclude alternate implementations. Therefore, specifying
this as the denominator (with the explicitly documented assumption of a 1 as
the numerator) is reasonable.

regards,

-Walter

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 21 Aug 2000 17:05:29 +0200

Adding my prior concerns for a long living standart.
Take a future upper bound of lets say 1 Tb, there we are in trouble.

Marcus

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

-- 

Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

New address starting 9/1/2000
Postal Mail:
Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 905110
Fax:   +49 (0)6221/ 9051155

Address valid until 8/31/2000
Postal Mail:
Hardenbergplatz 2
D-10623 Berlin
Germany

Phone:  +49 (0)30/ 25 42 30 17
Fax:    +49 (0)30/ 25 42 30 99