Subject: RE: [Diffserv] Diffserv MIB - droppers

From: Constantinos <[email-masked]>
Date: Thu, 1 Jun 2000 16:35:49 -0500 (CDT)

> So what we need are peoples' opinions as to:
>  - what are the *common* knobs
>  - what are they used for, operationally, in a multi-vendor network of
> Diffserv devices which potentially implement different algorithms within the
> Precedence, EF and AF specifications. 
> 

IMHO, the dropper-related knobs that are visible to the network manager
should not be related to specific algorithms or implementations. In 
the DiffServ context, and especially in the case of the Class Selectors,
I think that a meaningful set of knobs would be the ratios of the class loss
rates. For example, the network manager can set the loss rate
in class-1 to be twice the loss rate in class-2, and say 10 times the
loss rate in class-3 (which is say the really fancy and expensive class).
Of course, controlling the ratios of the loss rates does not mean that
we can control the absolute magnitude of the loss rates. That depends
on the actual magnitude of the load, service capacity, # of buffers, etc,
and it is a provisioning issue.

In this context, for a set of N classes, the MIB should have N-1 parameters
for the ratios of the loss rates between each class and class-1, for example.
It turns out, that we should probably include one more parameter in the MIB,
referring to the time interval in which the loss rates are measured and 
adjusted; this time interval could be measured in absolute time or # of
arrived packets. A paper that discusses the proportional loss rate buffer
management, together with a couple of related dropper mechanisms, will be
presented next week in Pittsburgh at IWQoS'2000:
	http://www.cae.wisc.edu/~dovrolis/Papers/iwqos00.ps

In anyway, whether the loss rate ratios is a good selection of MIB knobs
is hard to tell at this point, as there is not much of experience about
this idea and no commercial implementations. The main point that I
wanted to bring in this discussion is that it is not a good idea to 
standardize MIB parameters that are specific to an implementation 
or algorithm, and that they do not directly translate into something
that the network manager can see, performance-wise, or sell.

Constantinos 

> This, as opposed to a list of the union of all configurable parameters that
> might exist in total in existing real implementations, is what the MIB
> should contain.
> 
> Andrew
> 
> 
> > -----Original Message-----
> > From: jamal [mailto:[email-masked]]
> > Sent: Wednesday, May 31, 2000 6:31 PM
> > To: Kathleen Nichols
> > Cc: [email-masked]
> > Subject: Re: [Diffserv] Diffserv MIB - droppers
> > 
> > 
> > 
> > Kathie,
> > 
> > On Wed, 31 May 2000, Kathleen Nichols wrote:
> > 
> > > One of the problems with getting too specific about
> > > how people set/interpret the various RED parameters
> > > can be seen in two of your recent emails to the list.
> > > 
> > 
> > [..]
> > 
> > So in general i agree with you but it seems tricky to ignore some
> > implementation specifics in the case of some _very important_
> > parameters. 
> > 
> > ones i have seen being kicked around are:
> > 
> > -  the time constant, w or some concept used for its derivation can be
> > visualized/represented in a variety of ways to the network manager: 
> >   +as a floating point number, 
> >   +as the negative log 2 number, 
> >   +as a "queue sampling time"  
> >   +and as i just described in my earlier post using the 
> > "burst" parameter. 
> > 
> > - the drop probability; 
> > +if you time sample offline then it is possible to say to the 
> > data path
> > "drop after x packets" (refering to Van's presentation to 
> > NANOG which i
> > think is the scheme Fred is preaching)
> > +if you use the ns-like implementation then in the simple case you do
> > actually roll the dice in the fast path
> > 
> > So the dilema is: you cant leave these parameters out and 
> > neither can you
> > ignore the existence of "implementation specifics"
> > If inter-operability is key then there should be some 
> > compromise; imagine
> > multiple vendor boxes and some poor ISP network manager 
> > trying to get a
> > service created inter-operating them ;-<
> > 
> > cheers,
> > jamal
> > 
> > 
> > 
> > 
> > _______________________________________________
> > diffserv mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> > 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

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