Re: TE REQ - Dynamic Adjustment of Scheduler Parameters

[Francois Le Faucheur <flefauch@cisco.com>]

Nabil,

At 11:34 26/02/2002 -0500, Nabil Seddigh wrote:
>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.

I am not sure we can really come up with a "strong" statement about some 
sort of parameter for an optional mechanism which is not to be 
standardised. But we can certainly add a statement.
We'll do that in next rev unless someone raises issues about it.

Thanks

Francois

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