Subject: Re: [Diffserv] Proposal for Diffserv MIB - droppers

From: "Nabil Seddigh" <[email-masked]>
Date: Thu, 01 Jun 2000 06:39:06 -0400

Fred Baker wrote:

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

Proper configuration of RIO allows the above - which
is great since that's a capability a number of folks
are interested in. I don't think there's anything in the 
MIB that prevents this.

> If QThreshold tells me the actual size of the queue, 
> that is potentially useful information, 

Agreed! If I understood correctly, you mentioned that 
QThreshold is the limit imposed by the device buffer.
That may certainly be true. However, I would suggest
that we want to make that value Writeable - there
are cases where we want to impose a 100% 
drop at a smaller threshold than that allowed
by the device. 

So to address Andrew's later question: suggest that 
DropQThreshold be read/write and that it be retained
in its current place - a field in diffServAlgDropEntry.

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

Without the connection between the classifier (actually 
the action arising out of the classifier match) and
the AlgDropEntry, we have to make a hidden device-specific
assumption as to which DSCPs the AlgDropEntry applies
against. Much better to make this configurable - IMHO.

The DS WG has already decoupled PHB (and thus DSCP)
from physical queues. Thus, instead of devices implicitly
assuming (and hard-coding) that AF1x goes into queue # 0 and
assuming that AF2x goes into queue #1, we have 
provided a facility through which this mapping
can be configured through the MIB. 

A similar kind of thing for the drop precedence
levels would be very useful.
 
I think this can be done easily enough. Currently, the
diffServActionEntry has a field with diffservActionNext
that points to the next datapath element. e.g. the Queue.
With this info, we can map DSCPs to specific Queues.
Why not have another entry in this structure that points
to the RED params. See below:

DiffservActionEntry::= SEQUENCE {
    .....
    diffServActionPointToDrop  RowPointer
    .....
}

diffServActionPointToDrop OBJECT TYPE{
    SYNTAX       RowPointer
    MAX-ACCESS   read/create
    STATUS       current
    DESCRIPTION
       "For those configurations that support multiple 
        instances of drop algorithms per queue, this 
        pointer indicates the instance of drop algorithm 
        to be applied against the stream of packets 
        associated with this action. This pointer
        points to a specific diffServRandomDropEntry"
    ::= { diffServActionEntry ? }

I am assuming that if we seek to maintain multiple
RED parameters per Q (a la MRED) then we would
have multiple entries of diffServRandomDropEntry 
as opposed to multiple entries of diffServAlgDropEntry.
If it is the latter then we can modify the action
to point to the AlgDropEntry instead.

How would this work?

Best,

---
Nabil Seddigh
[email-masked]

_______________________________________________
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: Thu, 01 Jun 2000 10:29:06 -0700

>against. Much better to make this configurable - IMHO.

One of us is missing something; maybe it's me. Tell me what I'm missing, 
please?

The MIB describes a TCB, which is a classifier, a potential meter, a 
potential set of actions of which this is one, and a queue number. You may 
think of it conceptually as:

         switch (ip_header->dscp) {
         case AF11:
                 if (traffic within table->meter1) {
                         update table->meter1
                         update table->counters
                         randomly drop(table->dropParameters1, 
queue[table->queue])
                         otherwise enqueue in queue[table->queue]
                         break;
                 }
         case AF12:
                 if (traffic within table->meter2) {
                         update table->meter2
                         mark ip_header->dscp := AF12
                         update table->counters
                         randomly drop(table->dropParameters2, 
queue[table->queue])
                         otherwise enqueue in queue[table->queue]
                         break;
                 }
         case AF13:
                 mark ip_header->dscp := AF13
                 update table->counters
                 randomly drop(table->dropParameters3, queue[table->queue])
                 otherwise enqueue in queue[table->queue]
                 break;
         case EF:
                 if (traffic within table->meter) {
                         update table->meter
                         update table->counters
                         enqueue in queue[table->queue]
                         break;
                 } else {
                         discard packet
                         break;
                 }
         lots of other cases...
         }

So now you're telling me that you can't "randomly 
drop(table->dropParameters1, queue[table->queue])" unless those parameters 
contain something that says "these parameters apply to the case AF13"? Why? 
Why doesn't the fact that your classifier got you to the case AF13 tell you 
everything you need to know about what case you're in? You're telling me 
that making that correlation is somehow device dependent. I made the above 
entirely without reference to devices; in what way is it device dependent?

It comes across to me as "I can't reason my way through a switch 
statement." Please, tell me what I'm missing?

>     ::= { diffServActionEntry ? }

how does this differ from diffServAlgDropSpecific?