Subject: RE: [Diffserv] Second proposal for Diffserv MIB - Droppers

From: Andrew Smith <[email-masked]>
Date: Fri, 2 Jun 2000 13:13:28 -0700

Fred,

Thanks for writing this up. I'd also prefer to have
diffServRandomDropInvWeight inverted but can live with your current
formulation - I too believe that few implementations will use the entire
generality of that variable as formulated which does diminish its usefulness
quite a bit.

But, modulo the one really open issue, I think this might be a good
compromise.

Andrew

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, June 02, 2000 12:15 PM
> To: [email-masked]
> Subject: [Diffserv] Second proposal for Diffserv MIB - Droppers
> 
> 
> This is a second version of the random drop MIB proposal. Andrew has
> already sketched in the text changes proposed, so I won't go through
> them again; this simply addresses the actual Random Dropper Table.
> 
> I don't claim this to be a consensus description; it's where I think
> we're at right now.
> 
> I do note that the various descriptions of the Weight, including
> Nabil's original proposed text, remain an Exponentially 
> Weighted Moving
> Average; we're arguing about the form of the factors, not how they are
> used. I'm a little concerned that few implementations will 
> actually use
> the entire generality of what is described in the text below, which is
> adapted from Nabil's - I don't see why they would use a divide
> instruction in software (CPU-cycle expensive) or a hardware divider
> (monetarily expensive) in a circuit to maintain this.  But there's
> nothing to stop a vendor from saying "the values I accept in 
> this field
> are powers of two" or whatever else he chooses to allow.
> 
> Maybe I'm showing my age. I have been known to jump up and down on
> junior engineers benighted enough to use multiply or divide
> instructions in anything other than exception paths in code that
> executes more often than once a second.  And then there's this guy who
> came around the other day with a wonderful algorithm that "only"
> required 35 FLOPS per interface every 10 milliseconds or so, and I
> started thinking about residential DSLAMs...
> 
> I believe that there is one really open issue -
> 
> Some would like to see some correlation from the dropper table back to
> (one of?) the classifier(s) that got us to that place. This has issues
> in information hiding and object design, and eliminates the 
> possibility
> of using two disjoint classifiers to get to the same action. However,
> the model seems to feel it is very important.  I for one would like to
> hear from others on the topic.
> 
> diffServRandomDropTable OBJECT-TYPE
>     SYNTAX       SEQUENCE OF DiffServRandomDropEntry
>     MAX-ACCESS   not-accessible
>     STATUS       current
>     DESCRIPTION
>        "The random drop table augments the algorithmic drop table. 
>        It contains entries describing a process that drops packets
>        randomly. It is pointed to by diffServAlgDropSpecific in such
>        cases."
>     REFERENCE
>         "[MODEL] section 7.1.3"
>     ::= { diffServTables ? }
> 
> diffServRandomDropEntry OBJECT-TYPE
>     SYNTAX       DiffServRandomDropEntry
>     MAX-ACCESS   not-accessible
>     STATUS       current
>     DESCRIPTION
>        "An entry describes a process that drops packets according to
>        a random Algorithm."
>     INDEX { ifIndex, diffServAlgDropIfDirection,
>             diffServAlgDropId }
>     ::= { diffServRandomDropTable 1 }
> 
> DiffServRandomDropEntry ::= SEQUENCE  {
>     diffServRandomDropMinThreshold      Unsigned32,
>     diffServRandomDropMaxThreshold      Unsigned32,
>     diffServRandomDropInvWeight         Unsigned32,
>     diffServRandomDropInvMaxProbability Unsigned32
> }
> 
> diffServRandomDropMinThreshold OBJECT-TYPE
>     SYNTAX       Unsigned32
>     UNITS        "packets"
>     MAX-ACCESS   read-create
>     STATUS       current
>     DESCRIPTION
>        "The average queue depth beyond which traffic has a
> 	non-zero probability of being dropped or marked." 
>     ::= { diffServRandomDropEntry 1 }
> 
> diffServRandomDropMaxThreshold OBJECT-TYPE
>     SYNTAX       Unsigned32
>     UNITS        "packets"
>     MAX-ACCESS   read-create
>     STATUS       current
>     DESCRIPTION
>        "The average queue depth beyond which traffic has a
> 	100% probability of being dropped or marked. Note that this
> 	differs from the physical queue limit, which is stored in
> 	diffServAlgDropQThreshold."
>     ::= { diffServRandomDropEntry 2 }
> 
> diffServRandomDropInvWeight OBJECT-TYPE
>     SYNTAX       Unsigned32
>     MAX-ACCESS   read-create
>     STATUS       current
>     DESCRIPTION
> 	"The weighting of past history in affecting the calculation of
> 	the current queue average.  The moving average of the queue
> 	depth uses the inverse of this value as the factor for the new
> 	queue depth, and one minus that inverse as the factor for the
> 	historical average.
> 
> 	Implementations may choose to limit the acceptable set of
> 	values to a specified set, such as powers of 2."
>    ::= { diffServRandomDropEntry 3 }
> 
> diffServRandomDropInvMaxProbability OBJECT-TYPE
>     SYNTAX       Unsigned32
>     MAX-ACCESS   read-create
>     STATUS       current
>     DESCRIPTION
> 	"The inverse of the worst case random drop probability.  If
> 	every packet may be dropped in the worst case (100%=1/1), this
> 	is therefore one, and if in the worst case one percent of
> 	traffic (1%=1/100) may be dropped, it is 100."
>    ::= { diffServRandomDropEntry 4 }
> 
> diffServMIBCompliance MODULE-COMPLIANCE
> ...
>     MANDATORY-GROUPS {
>         diffServMIBClassifierGroup, diffServMIBSixTupleClfrGroup,
> >       diffServMIBActionGroup, diffServMIBRandomDropGroup,
>         diffServMIBAlgDropGroup, diffServMIBQueueGroup,
>         diffServMIBSchedulerGroup }
> 
>     OBJECT diffServRandomDropMinThreshold
>     MIN-ACCESS read-only
>     DESCRIPTION
>        "Write access is not required."
> 
>     OBJECT diffServRandomDropMaxThreshold
>     MIN-ACCESS read-only
>     DESCRIPTION
>        "Write access is not required."
> 
>     OBJECT diffServRandomDropInvWeight
>     MIN-ACCESS read-only
>     DESCRIPTION
>        "Write access is not required."
> 
>     OBJECT diffServRandomDropInvMaxProbability    
>     MIN-ACCESS read-only
>     DESCRIPTION
>        "Write access is not required."
> 
> diffServMIBRandomDropGroup OBJECT-GROUP
>     OBJECTS {
>             diffServRandomDropMinThreshold, 
> diffServRandomDropMaxThreshold,
>             diffServRandomDropInvWeight, 
> diffServRandomDropInvMaxProbability
>     }
>     STATUS current
>     DESCRIPTION
>        "The Random Drop Group augments the Algorithmic Drop Group for
>        random dropper operation and configuration."
>     ::= { diffServMIBGroups ? }
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Fred Baker <[email-masked]>
Date: Fri, 02 Jun 2000 13:48:31 -0700

At 01:13 PM 6/2/00 -0700, Andrew Smith wrote:
>I'd also prefer to have
>diffServRandomDropInvWeight inverted

not sure what you mean by that. Given that there is religious opposition to 
supporting real numbers in SNMP, and the inverse is between zero and one, 
the alternative would be something like diffServRandomDropWeightPercent 
(represent it as some number of discrete units of size smaller than one and 
greater than zero) or to represent the integer exponent of 2 in the case.

The issue with real numbers has historically been something about having 
six different formats in ASN.1 and wouldn't we have to pick one and by the 
way there is no valid utility for real numbers in datagram networking, 
things like this and like Integrated Services being completely beside the 
point. But that's another rant.

---

From: Keith McCloghrie <[email-masked]>
Date: Fri, 2 Jun 2000 17:35:57 -0700 (PDT)

> point. But that's another rant.

I think the format issue was a red herring.  I recently (re-)investigated
this issue by asking some (embedded-system) implementators how easy/hard
had it been for them to support RSVP/IntServ's floating-point numbers.
Their answer was that while general-purpose floating point would have
been (very) hard, RFC 2215 does not require numbers less than one, and
it encourages accuracy to 0.1%.  So, they internally store all of
IntServ's floating-point numbers as integers scaled up by a thousand.
This means to me that RFC 2215 might equivalently (albeit inelegantly)
have specified the use of INTEGERs scaled up by a thousand.  Therefore,
my conclusion was that the use of floating-point numbers can either be
reduced (inelegantly perhaps) to scaled-up integers, or the
implementators tell me it's hard.

Keith.

---

From: Fred Baker <[email-masked]>
Date: Fri, 02 Jun 2000 18:00:08 -0700

At 05:35 PM 6/2/00 -0700, Keith McCloghrie wrote:
>I think the format issue was a red herring.

OK, I won't tell the list who has been using it to end discussion of 
floating point numbers whenever I have brought it up.

>Therefore,

Well, we could discuss Cisco's implementation.

Cisco doesn't support real numbers on any of its equipment, even though 
some of it has floating point instructions; this has to do with the 
libraries involved and so on. SO for Int-Serv, I wrote some conversion 
routines. Yes, I internally represent the numbers as long long and scale 
the few that need it. I figure that 2^64 would be plenty for the 
foreseeable future.

But the reason Int-serv uses real numbers is not because of fractions - I'm 
not sure there are any. The values are the burst sizes and rates in a token 
bucket, maybe a couple of other things. The problem is that rates are going 
through the roof, and nobody wanted to take a swag at what the fastest 
possible line would be twenty years from now. If we need to represent the 
number 1,000,000,000,000,000, and we are limited to 32 bit integers (SNMP 
has a religious bias against arbitrary sized integers as well), how do we 
do that? So they chose to figure out how to use IEEE Floating Point as a 
way of future-proofing things.

Doing what little I have to do with integrated service numbers in our CPUs 
in software is trivial, and we have simply made it happen. Since I wrote 
the code, I think of myself as one of the implementors.