Subject: Re: [Diffserv] Diffserv MIB - droppers

From: "Nabil Seddigh" <[email-masked]>
Date: Thu, 01 Jun 2000 07:05:34 -0400

> 
>  From: Andrew Smith <[email-masked]>
>  To:   Nabil Seddigh'" <[email-masked]>
>  Cc:   [email-masked]
>  Date: Wed, 31 May 2000 14:19:26 -0700
> 
> >
> > I'm not sure I understand how you can measure solely
> > on one queue yet drop solely on another queue.
> 
> Do you mean "how" or "why"? I don't see any reason *how* 
> this would not be feasible. I cannot think of a very 
> good reason *why* you might want to do
> this though. A contrived example might be that you use congestion
> backpressure from a low-priority queue to also throttle down a
> high-priority
> stream.

I guess I meant "why"? I was asking that question
in the spirit of "don't include it unless there's
consensus or enough of a reason to include it".
I haven't seen any discussion to date that seems
to cry out for that capability....but that's
a minor point and I don't think there's
too much value pursuing it further :)

> 
> 
> Not sure what you mean by a "virtual queue". 
> We don't currently have such a concept in the Model.
> 

My apologies! I realize it's not in the model and
made an assumption about "popular" terminology -
probably a bad assumption. A "virtual queue" 
allows distinction of packets within a physical 
queue. All pkts within the physical queue are 
FIFO as far as movement thru the queue and
scheduling is concerned. However, the virtual 
queue allows different drop algorithms to 
be applied to different groupings of packets
within a physical queue. The notion of virtual
queue is specifically useful for explaining
implementation specifics of MRED algorithms.
Somehow packets need to be grouped into
these virtual queues. The grouping can be
done via hard-coded assumptions within a 
specific product or they can be gracefully
configurable. 

As long as the MIB supports M:N mapping where
M is the number of outputs of the classifer-action
and N is the # of dropAlgEntries within a specific 
physical queue, I think we can support the concept 
of a virtual queue. I don't know if it is worth 
including in the model draft or not.

I suspect we're in agreement on the above
point even if I'm not articulating properly.
I'll leave the above line of discussion and
pursue it in the context of Fred's concrete
proposal.

> >
> > The MIB is only intended to provide config and monitoring
> > info. It is not intended to model implementation.
> > Each queue will have a bunch of config info associated
> > with it. Why not have the queue point to the config info?
> 
> Be more precise.
> 

See earlier response to Fred.

> >
> > I think there's agreement on at least 3 parameters:
> > (Qmin, Qmax and Pmax).
> 
> Please provide definitions.
> 

See earlier posting in response to Fred...

> > As for the weight, different products
> > might use the weight differently but that is implementation
> > specific. Can't we just agree that there's a weight that
> > needs to be used?
> 
> Please provide a definition of "weight".
> 

See earlier posting....

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: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Jun 2000 11:50:05 -0500

Nabil Seddigh wrote:
...
> queue. 

In a conceptual model, all queues are "virtual" in this sense, since
we are modelling behaviour, not implementation.

  Brian