Subject: [Diffserv] Proposal for Diffserv MIB - droppers

From: [email-masked]
Date: Tue, 30 May 2000 18:08:30 -0700 (PDT)

OK, I have a proposed set of changes to the MIB. I extracted the
text blobs that have something to do with Algorithmic Droppers and
built some text about random droppers based on them. I assume that
Andrew (who last held the pen) can do the right thing with the text once
we agree with it.

This re-uses the Algorithmic Drop Table in the way Andrew intended (I
think, and if it didn't, sorry, it intended to, so he can tell us how
to fix it). It does not include the queue depth (average or actual) as
I'm not convinced and I personally don't see consensus at this point
towards including it.

First, I want to change the following paragraph in this way:

<o    Random Droppers require more detailed specification of the
<     characteristics of their drop functions. Representations of these
<     functions are outside the scope of this MIB although they should
<     use the available diffServAlgDropQMeasure and
<     diffServAlgDropQThresh parameters where possible.
-------------------
>o    Random Droppers are recommended as a way to control congestion, in
>     [RFC 2309], and called for in the [RFC 2597]. Various implementations
>     exist, which agree on marking or dropping just enough traffic to
>     communicate with TCP-like protocols about congestion avoidance, but
>     differ markedly on their specific parameters. This MIB attempts to
>     offer a minimal set of controls and reports to control any random
>     dropper, but expects that vendors will augment the table with
>     additional controls in accordance with their implementation.

remove this paragraph:
-------------------------------------
One way to extend this MIB structure to accomodate a more complex
dropping algorithm might be to define a specific dropper table in
another MIB module, pointed at by diffServAlgDropSpecific, containing
its own parameters, as shown in figure 2. This algorithm might depend
for its operation e.g. on feedback of a queue's depth but pre-processed
by some type of smoothing function with its own parameters. The extended
table could still use some of the fields of the standard Algorithmic
Dropper Table, if relevant, although any divergent uses would have to be
well-documented in the extended MIB.

Remove the last sentence from this paragraph, regarding RED.
<(13) Droppers: we used to have a common "dropper" table that represented
<     all of: dropAlways, randomDrop, tailDrop with just some parameters
<     valid for the simpler ones. A simpler representation is to define
<     specific dropper tables for each type (e.g. a single OID to point
<     at for dropAlways since it is always the last action in a chain)
<     but this would mean a larger number of (simpler) MIB objects.
<     CHANGES: dropAlways is still an Action but the others are moved to
<     a diffServAlgDropTable. This table can handle tail/head drop. Other
<     algorithms, specifically RED, are out of scope for now but can be
<     added using the framework defined here.

decision reached on the list: apparently we do need this option.
<(21) Do we need diffServAlgDropType of both "headDrop" and "tailDrop" or
<     should we just represent the tail dropper by placing a dropper
<     after the queue instead of before the queue, as linked by the
<     diffServQNext and diffServAlgDropNext RowPointers? (the former).

Remove this paragraph from the diffServAlgDropEntry description:
<       Specifically, Random Drop algorithms are not directly represented
<       in this MIB but can be indicated by an entry in this table with
<       diffServRandomDropType of other(1) and extensions, pointed to by
<       diffServRandomDropSpecific, in some other MIB module that parallels
<       entries in this table e.g. by using the same index attribute(s)."

Add this text to diffServAlgDropType:
diffServRandomDropType OBJECT-TYPE
    SYNTAX       INTEGER { other(1),
			   tailDrop(2),
			   headDrop(3),
>			   randomDrop(4)
			 }
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION
       "The type of algorithm used by this dropper. A value of
       tailDrop(2) or headDrop(3) represents an algorithm that is
       completely specified by this MIB.  A value of other(1) requires
       further specification in some other MIB module.

       The tailDrop(2) algorithm is described as follows:
       diffServRandomDropQThreshold represents the depth of the queue
       diffServRandomDropQMeasure at which all newly arriving packets will
       be dropped.

       The headDrop(3) algorithm is described as follows: if a packet
       arrives when the current depth of the queue
       diffServRandomDropQMeasure is at diffServRandomDropQThreshold, the
       packet currently at the head of the queue is dropped and the new
       packet is enqueued at the tail of the queue.

>       The randomDrop algorithm is described as follows: on packet
>       arrival, an algorithm is executed which may randomly drop it, or
>       drop another packet from the queue in its place. The specifics
>       of the algorithm may be proprietary. In this case, a
>       diffServRandomDropEntry is pointed to by diffServAlgDropSpecific,
>       diffServAlgQThreshold is understood to be the absolute maximum
>       size of the queue, and additional parameters beyond those in the
>       diffServRandomDropTable may be found in a vendor-specific MIB."
    ::= { diffServRandomDropEntry 3 }

New Text:

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 ? }

Just a thought: this could literally AUGMENT {diffServTables 8} using the
Augments clause if we want it to. Not sure what anyone thinks.

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,
    diffServRandomDropAvgInterval      Unsigned32,
    diffServRandomDropMinSpace         Unsigned32,
    diffServRandomDropStatus           RowStatus
}

diffServRandomDropMinThreshold OBJECT-TYPE
    SYNTAX       Unsigned32
    UNITS        "packets"
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION
       "The target number of packets to be held in queue. If the average
       queue depth exceeds this amount, one will expect that traffic
       exercising this action (which is to say, traffic which either has
       the indicated DSCP or which will be marked to it as the result of a
       meter overflowing) 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 limit number of packets to be held in queue. If the average
       queue depth exceeds this amount, one one may presume that randomly
       dropping or marking them has not been successful in reducing the
       source's rate, and these packets must be dropped."
    ::= { diffServRandomDropEntry 2 }

 -- 
 -- this can be done in many ways. One could, for example, maintain an
 -- exponentially weighted moving average and put the binary logarithm
 -- ("k" in 2^k) here, which is what Cisco equipment does. I get lots of
 -- questions of the form "what is this 'k' thingie for?", and Cisco
 -- originally refused to put an equation into the manual, claiming that
 -- this was difficult for customers (read "English majors working in
 -- tech pubs") to understand. Since Kathy seems to think that an interval
 -- of milliseconds is about right, I propose we go with that...

diffServRandomDropAvgInterval OBJECT-TYPE
    SYNTAX       Unsigned32
    UNITS        "milliseconds"
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION
       "The number of milliseconds between calculations of the required
       drop rate, in milliseconds. Presumptively, every so often the
       drop rate is calibrated, either increasing it due to increased
       mean queue depth, or decreasing it because previous drops have
       had the necessary effect."
    ::= { diffServRandomDropEntry 3 }

diffServRandomDropMinSpace OBJECT-TYPE
    SYNTAX       Unsigned32
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION
       "The minimum number of packets that must be forwarded between
       successive marking or dropping events. The number zero implies that
       all packets are subject to drop; the number 99 indicates that at
       most 1% of packets may be dropped, as between any two packets there
       must be at least 99 packets forwarded. This has the effect of
       limiting the percentage drop rate to some bound."
    ::= { diffServRandomDropEntry 4 }

diffServRandomDropStatus OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION
       "The RowStatus variable controls the activation, deactivation, or
       deletion of this entry. Any writable variable may be modified
       whether the row is active or notInService."
    ::= { diffServRandomDropEntry 12 }

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 diffServRandomDropAvgInterval
    MIN-ACCESS read-only
    DESCRIPTION
       "Write access is not required."

    OBJECT diffServRandomDropMinSpace    
    MIN-ACCESS read-only
    DESCRIPTION
       "Write access is not required."

    OBJECT diffServRandomDropStatus
    MIN-ACCESS read-only
    DESCRIPTION
       "Write access is not required."

diffServMIBRandomDropGroup OBJECT-GROUP
    OBJECTS {
	    diffServRandomDropMinThreshold, diffServRandomDropMaxThreshold,
	    diffServRandomDropAvgInterval, diffServRandomDropMinSpace,
	    diffServRandomDropStatus
    }
    STATUS current
    DESCRIPTION
       "The Random Drop Group augments the Algorithmic Drop Group for
       random dropper operation and configuration."
    ::= { diffServMIBGroups ? }

At the end of the document, we need an appropriate reference to RED93, and
probably some subset of the papers that proceed from it.

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

---

From: Andrew Smith <[email-masked]>
Date: Wed, 31 May 2000 17:51:20 -0700

OK, things are getting clearer.

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: Wednesday, May 31, 2000 5:29 PM
> To: Andrew Smith
> Cc: [email-masked]
> Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers
...
> >[Andrew] Not sure of the difference between 
> diffServAlg(Drop)QThreshold in
> >the above description and diffServRandomDropMaxThreshold in 
> the table below.
> >Please clarify.
> 
> In the head/tail drop implementation, QThreshold is the 
> actual size of the 
> queue, and if we try to put more packets in it than it will 
> hold, something 
> falls on the floor. In the random drop implementation, the queue is 
> actually larger than max-threshold; we don't start dropping 
> everything 
> until the *mean* queue depth exceeds max-threshold. It is 
> quite possible 
> for the instantaneous queue depth to greatly exceed 
> max-threshold, but it 
> cannot do so for very long.
> 
> So to me, the actual size of the queue and the place you 
> start dropping 
> should the mean exceed that are two very different things. 

OK.

> You might, for 
> example, configure:
> 
>          min-threshold[AFx3] = 0
>          max-threshold[AFx3] <= min-threshold[AFx2]
>          max-threshold[AFx2] <= min-threshold[AFx1]
>          max-threshold[AFx1] = half the *actual* storage 
> space available 
> for the queue
> 
> In fact, I thought I heard someone say he literally wanted to 
> be dropping 
> all of AFxN+1 before dropping any of AFxN. Did you hear that desire?

I heard that from someone - don't remember who.

> If QThreshold tells me the actual size of the queue, that is 
> potentially 
> useful information, and I don't know how to interpret it in 
> the above context.

i.e. the "actual depth of queue at which 100% will be dropped", so we can
re-use the same QThreshold parameter as we had for hedDrop/tailDrop. Not
sure what you mean about not knowing how to interpret it. Do you think
QThreshold needs to be read/write for the RED scenario?

> >[Andrew] We need a way of indicating which indicated DSCP. 
> This is where we
> >need a RowPointer to the specific classifier element (or 
> filter element?).
> 
> Why? The classifier (or the meter, and in that AF case you 
> presumably have 
> just remarked the packet to the new DSCP) is what got you to 
> this action, 
> and is therefore implicit in the fact that you got here. We 
> can add the 
> column you propose, but we should add it to the AlgDropEntry, 
> as the same 
> question applies there, for tail drop (how did the packet get headed 
> towards the queue that is deciding to drop it?). And I think 
> we should not 
> add it unless there is a real utility for it.

This goes back to the "implicit classifier inside the dropper" discussion we
had with Dan and Brian. I'd argued that a dropper needed multiple "inputs"
in order for it to have multiple packet streams coming into it from separate
classifiers, for example. That way a dropper could treat AF11 differently to
AF12 (a requirement, I assume). But Dan argued that this was unnatural - you
end up duplicating functional elements in the picture unnecessarily (e.g.
you might want a single meter on AF1x, not on the individual DSCPs that make
up AF1); instead it should be considered as a single packet stream that has
different dropping applied to packets with different AF values i.e. there is
an implicit classifier inside the dropper - but I think *that* is unnatural.
The compromise was that there was some implied sort of linkage back to the
classifier for each DSCP - that was described in model-03 without any
details attached. Now I'm attempting to flesh out the details. But my
proposal is broken for the case where you have several DSCPs all to receive
the same drop treatment - an alternative, suggested by Jamal I think, is to
point from the classifier to the dropper: this allows for a many-to-1
mapping but it imposes a burden on *all* classifier elements, not just those
that impact dropping.

More tomorrow ...

Andrew