Subject: TE REQ - Dynamic Adjustment of Scheduler Parameters

From: Nabil Seddigh <[email-masked]>
Date: Fri, 22 Feb 2002 19:51:30 -0500

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
[email-masked]

---

From: Jim Boyle <[email-masked]>
Date: Sat, 23 Feb 2002 20:35:48 -0500 (EST)

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

---

From: Nabil Seddigh <[email-masked]>
Date: Mon, 25 Feb 2002 00:51:00 -0500

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 25 Feb 2002 17:39:45 +0100

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

---

From: Nabil Seddigh <[email-masked]>
Date: Tue, 26 Feb 2002 11:34:04 -0500

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 26 Feb 2002 18:58:33 +0100

Nabil,

>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