Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt

From: Andrew Smith <[email-masked]>
Date: Wed, 14 Jun 2000 11:28:56 -0700

Please see below.

> -----Original Message-----
> From: Yasusi Kanada [mailto:[email-masked]]
> Sent: Wednesday, June 14, 2000 12:28 AM
> To: Andrew Smith; [email-masked]; [email-masked]
> Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt
> 
...
> Do you mean, if I want to use CBQ-like queuing, I can cascade queues
> instead of connecting queues to a scheduler?  This is possible, but
> then, what is the difference between a queue and a scheduler?  I am
> not sure.

A Queue is where packets are stored, a Scheduler is the algorithm that takes
them out of the the Queue and on to the next stage (or out onto the link
itself). The Conceptual Model talks about TCBs and how to cascade them -
this is the way we intended CBQ to be modelled. There is no requirement that
a TCB have a Queue in it (or you could also model it as a Queue with a
single packet slot in it) so you can effectively connect multiple Schedulers
in series.

> Actually, in the previous version of the MIB, the difference between
> a queue and a queue set (which is something like a scheduler in the
> current version) was not very clear either.

Yes, it was that lack of clarity that we were trying to improve on with the
"cascaded TCBs" approach (I believe it is a superset of the capabilities we
had with Queue Sets, which originated in the COPS-PR/PIB work).

...
> >I believe that we do need the ability to have classifiers 
> other than "IP BA"
> >at this point e.g. an IEEE 802.1p or MPLS classifier.
> 
> I am interested in reading this.  I understand, if there should be a
> "dropper classifier", it must be able to point an external table.
> However, I think IEEE 802.1p or MPLS classifier is more like 
> BA than MF.

It may be "more like BA than MF" but it does not fit the precise definition
of BA that Diffserv uses - so we would have to write something like "a
dropper classifier may be a BA or a XXXX or a YYYY or ... classifier": I
think it is preferable to just say "a dropper classifier may be any type of
classifier" - I think implementers will be sensible as to which classifiers
they actually allow at this point (one other future example might be an "ECN
classifier" for example) although I acknowledge that it makes life harder
for a manager to know what is possible in the absence of any
capabilities-reporting mechanisms.

> >Note that you can restrict which (or how many) MFC filter 
> elements are able
> >to be created by limiting row-creation in the 6-tuple filter 
> table: these
> >table entries can be re-used/shared between the top level 
> classifier and the
> >"dropper classifier". You can also restrict which classifier 
> entries are
> >allowed to point at them (yes, this will make life confusing 
> for a manager
> >...).
> 
> We can put many restrictions on specific implementations of the MIB.  
> This would be OK for device-dependent managers.  But, if you 
> want a policy-
> based control in multi-vendor environment, this will cause headaques.
> I hope we will be able to solve this problem in Diffserv PIB, and ...
> will Config Management WG solve it?

Yes - Ibuprofen will be required as a temporary measure.

Andrew

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