Re: TE REQ - Dynamic Adjustment of Scheduler Parameters

[Nabil Seddigh <nseddigh@tropicnetworks.com>]

I agree that handling of the dynamic scheduler adjustment
should not be standardized. i.e in terms of what the parameters
are or how the queue parameter is tied to the CAC algorithm.

However, I do think a strong statement would be useful to say that
some sort of configurable parameter should be at the disposal of
the admin for the case where a single CT in the control plane
corresponds to more than 1 queue in the data plane. This can be 
a SHOULD instead of a MUST. 

Otherwise, how on earth will a node decide on how to alter
the queue weights for multiple queues that correspond to 1 CT?

Best,
Nabil 



Francois Le Faucheur wrote:
> 
> Nabil,
> 
> If I was coding an implementation of the optional scheduling adjustement, I
> would personaly make configurable the parameters that control this
> automatic adjustment.
> 
> But the approach we took with respect to the "optional scheduling
> adjustements" is that it should be considered as a local mechanism which
> does not require standardisation. It seems perfectly fine that some of the
> LSRs do not support this automatic adjustement, while some LSRs support it
> one way (with a given set of parameters such as : fixed ratios, a maximum
> weight for scheduler ,...) while some other LSRs supports it in a differnet
> way (with a different set of parameters  such as time-dependent
> wind-dependent ratios and a minimum weight for the scheduler)...
> Pretty much like every LSR is free to implement its own CAC algorithm.
> 
> Do you agree that this is basically an optional local "enhancement"?
> Then, should we not stay out of standardising how this is actually done and
> what are the associated parameters?
> 
> Maybe we should add some clarification about that?
> 
> thanks
> 
> Francois
> 
> 51 25/02/2002 -0500, Nabil Seddigh wrote:
> 
> >The ratio will vary depending on the network, the device and
> >the traffic mix. Hard-coding an "assumption" does not appear a
> >wise approach. Moreover, if more than one class are aggregated,
> >multiple ratios will be required.
> >
> >If a ratio is to be used it seems to me that it is better
> >that it be configurable.
> >
> >Best,
> >Nabil
> >
> > >
> > > Yes, when one can reasonably assume a ratio, then one could put both into
> > > one E-LSP!
> > >
> > > see thread index of http://psg.com/lists/te-wg/te-wg.2001/msg00279.html
> > > for some discussion on this.
> > >
> > > Jim
> > >
> > > On Fri, 22 Feb 2002, Nabil Seddigh wrote:
> > >
> > > >
> > > > I just read v03 of the DS-TE requirements draft and had a
> > > > comment regarding section 3.6. This section talks about dynamically
> > > > adjusting scheduler parameters based on signaled traffic parameters.
> > > >
> > > > The concern relates to the case where class-types (CT) are used to
> > > > aggregate multiple classes or OAs. In this case, the signalled
> > > > traffic parameters for a single CT may cover traffic that is treated
> > > > by 2 different PSCs: AF1x and AF2x. This raises the question
> > > > of how to adjust the separate queue parameters for AF1x and AF2x.
> > > >
> > > > The only way that I can think of tackling this problem is through
> > > > some pre-set ratio. Thus, the LSR would assume that y% of traffic
> > > > for CT1 is AF1x and (1-y)% is AF2x! If three classes are combined
> > > > into 1 CT then 2 different parameters y1 and y2 are required.
> > > > In this case, it is desirable that "y" be a user configurable
> > > > parameter and not hard-coded.
> > > >
> > > > I suggest that this section needs some kind of discussion
> > > > on the above and the addition of the user-configurable parameter.
> > > >
> > > > Thoughts?
> > > >
> > > > ---
> > > > Best
> > > > Nabil Seddigh
> > > > nseddigh@tropicnetworks.com
> > > >