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

From: [email-masked]
Date: Fri, 2 Jun 2000 12:14:44 -0700 (PDT)

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/

---

From: Fred Baker <[email-masked]>
Date: Fri, 02 Jun 2000 15:14:53 -0700

At 06:06 PM 6/2/00 -0400, Joel M. Halpern wrote:
>But the definition we have for diffServRandomDropMaxThreshold says that if 
>the average is over that, the drop probability will be 100%.  I can not 
>imagine any use for the discontuity (ie just below the limit, we are 
>dropping at maxp, and just over the limit (both in terms of average) we 
>are dropping at 100%.
>[The text below says taht at or above maxth, pb will be maxp, not 100%.  I 
>believe that is why I am confused.]

Comments from a side discussion with Joel - instead of saying "100%" in the 
DESCRIPTION of MaxThreshold, we should say 
"diffServRandomDropInvMaxProbability". That is consistent with the 
description in the RED93 paper, and (as Joel points out) avoids a bit of a 
discontinuity.

---

From: Simon Leinen <[email-masked]>
Date: 09 Jun 2000 13:54:42 +0200

>>>>> "f" == fred  <[email-masked]> writes:

That would provide very fine granularity for very small max_p's, but
in the "interesting" range between, say, 1/10 and 1/1, there are only
a few very large steps.

So I'd prefer to have this expressed as a percentage, multiple of
2^-32 or something similar.
-- 
Simon.