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

From: [email-masked]
Date: Thu, 17 Aug 2000 12:43:12 -0400

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.

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.

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.

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.

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.

     Note, by the way, that in a subsequent
     posting, I'm going to argue that the
     last of these properties is placed on
     the wrong class in QDIM-01.  This
     repositioning of the property doesn't
     impact the question we're asking here:
     whether its semantics can be captured
     adequately with a uint32.

If the WG buys my general thesis here, that
we should use the uint32 syntax rather than
the real32 syntax wherever uint32 works, then
the only remaining questions are whether
uint32 works for these 16 properties.  If we
need to change the units for some of the
properties in order to make uint32 work for
them, then we can have that discussion here
as well.

Regards,
Bob

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

---

From: "Yoram Snir" <[email-masked]>
Date: Fri, 18 Aug 2000 10:30:13 +0200

Moving to uint32 would also allow easier mapping from the qos info model to
the QDIM and the PIB/MIB.

------------------------------------------
Yoram Snir - Manager, Business Development
Cisco Systems
Tel.     +972-9-9700085
Mobile   +972-54-970085
------------------------------------------

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Thursday, August 17, 2000 6:43 PM
To: [email-masked]
Subject: QDIM issue: changing real32's to uint32's

6. EWMAMeter.Gain

Regards,
Bob

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

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 18 Aug 2000 11:35:50 +0200

Bob,

In the last decades, we had a lot of problems with the choice of fixed
upper bounds on sizes. So I would change the criterium of the maximum
value to "What is its maximum value in 20 years". (Or some other number
of years). And try to estimate it with todays knowledge.
 
> To determine whether a property

Comment only on the ones I don´t think it is a good idea to change.

>      just as the three average rates do.

Is 4 terabits in 20 years enough?

>      value somewhere up in the terabytes.

Here I see a problem with 1000 byte granularity in environments with
short packets (VoP etc.)

>      of treatment among traffic streams.

I´m not sure if 100 values are enough in high-speed environments (1
percent equals to 100Mbits on OC-192), but for sure the uint32 range is
enough.

Marcus

-- 

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Aug 2000 12:30:00 +0200

>>>>> Marcus Brunner writes:

Marcus> In the last decades, we had a lot of problems with the choice
Marcus> of fixed upper bounds on sizes. So I would change the
Marcus> criterium of the maximum value to "What is its maximum value
Marcus> in 20 years". (Or some other number of years). And try to
Marcus> estimate it with todays knowledge.

I agree. 

If the consens is that 32 bit integer is not enough, then this WG
should consider using 64 bit (unsigned) integers rather than
floats. (I think CIM supports 64 bit types. SPPI also has 64 bit types
and the SMI will have them sooner or later as well. I am not sure
about LDAP. Floats in SPPI and SMIv2 may take longer and are
definitely harder to implement in many real world devices.)

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: "Andrea Westerinen" <[email-masked]>
Date: Sat, 19 Aug 2000 13:13:36 -0700

Yes, CIM supports uint64s.
Andrea

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Juergen Schoenwaelder
Sent: Friday, August 18, 2000 3:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: QDIM issue: changing real32's to uint32's

I agree. 

/js