Re: [tsvwg] Review of "draft-finzi-priority-switching-scheduler-01"

[Emmanuel Lochin <[e-mail]>]

Hi Nicolas,

Thanks for this review, answers in-line:

Le 26/03/2018 à 17:53, Kuhn Nicolas a écrit :
>
> Hi,
>
> Following the presentation of 
> draft-finzi-priority-switching-scheduler-01 " Priority Switching 
> Scheduler " at IETF,
>
> I have some comments on the actual version of the draft.
>
> Thanks a lot for this interesting work.
>
> ============================
>
> General comments
>
> ============================
>
> I find the proposal very interesting.
>
> That being said,
>
> - the presentation of the motivation and the description of the algorithm
>
>   should be improved in the document
>
We are still thinking how to better organize this part but we reviewed 
all the text (and added several new parts) before submitting this new 
version.

> - knowledge of the BW: do the algorithm need to know the BW of the 
> system ?
>
>   if this is the case, is it the maximum/average/minimal value ?
>

BW is the percentage of capacity dedicated to BLS, it corresponds to the 
bandwidth you seek to control (for AF it will be the capacity ratio 
attributed to the class). Then this value is used inside the algorithm 
as an entry parameter.
New explanations are given starting in section 2.1 starting at "The 
available capacity is mostly impacted by the guaranteed capacity
    BWs[q].  Hence BWs[q] sh (...)"

> - more generally, there should be a section describing what parameters 
> should be
>
>   set when deploying such schemes
>
Done
>
> - what are the relations between the low/high probabilities and 
> typical QoS metrics?
>

You mean high/low priority ?

> - in the algorithm presentation, you may want to describe how the 
> different priorities
>
>   values are used when dequeuing packets
>
> ============================
>
> Detailed comments
>
> ============================
>
> Comments on the text
>
> - Abstract:
>
> Some parts of the abstract are not clear to me.
>
> e.g.
>
> "
>
> that switches the priority of one or several queues.
>
> "
>
> -> ?
>

We rephrased this part and choose to use "change the priority" rather 
than "switch the priority"
>
> "
>
> This scheduler aims at carrying and isolating time constrained and 
> elastic
>
> traffic flows from best-effort traffic.
>
> "
>
> -> this is not different from other mechanisms.
>
> I would propose something around:
>
> "
>
> Usual implementations with rate schedulers (such as WRR, DRR, ...) do 
> not allow
>
> to efficiently quantify the capacity that is dedicated to each of the 
> EF, BE and AF classes.
>
> This results in an excessiv margin on the guaranteed capacity that 
> impact on the
>
> amount of users that could be accepted in the network.
>
> This memo presents a credit based sceduler mechanim called Priority 
> Switching Scheduler
>
> that allow a more predictable output rate per traffic class.
>
> "
>

Agree, we change as proposed

> - Introduction
>
> "
>
> However, with these solutions, the capacity available to a class is
>
> strongly impacted by the other classes. With this new scheduler
>
> denoted Priority Switching Scheduler (PSS), we wish to reduce this
>
> impact on some classes and provide them with a more predictable
>
> output rate, reporting the impact on other classes.
>
> "
>
> -> I think this should be rephrased. Since it is not clear to me whether
>
> you are actually providing a predictable output rate for each queue or 
> all
>
> the queues.
>
> "However, with classical solutions, the output rate of a given queue
>
> is related to the amount of traffic on the other queues.
>
> Our proposal aims at reducing the uncertainty of the output rate of each
>
> queue.
>
> "
>

Agree and done

> "Priority Switching Scheduler in a nutshell"
>
> -> You may want to start this section with a generic example.
>
> As it is in the current version of the document, it is not clear how the
>
> priority, the credit counter, the priority of the queue are actually used
>
> by your mechanisms. This results in sentences that are quite difficult to
>
> understand. The whole section 1..2 is not clear.
>
> It may be worth to either better present the algorithm at that point or
>
> propose discussion section after the presentation of the algorithm in 
> section 2.1.
>

We have added (and commented) a new figure to give the big picture of 
the mechanism (see Fig. 1 in the update)

> - Section 2.1
>
> When you list the different parameters, you may want to quickly 
> describe their use.
>
> You may want to further describes the examples of figures 1 & 2.
>

A full page has been provided in this update to better explain and 
illustrate these parameters.

> When you speak off priorities, you actually speak about a priority 
> value and then
>
> the dequeuing is done by selecting the packet with the lowest priority 
> value ?
>
> it is not clear how the priority p_low/high is related to the 
> priorities of figure 4
>

We also update this part

> "
>
> Finally, for the dequeuing process, a Priority Scheduler selects the
>
> appropriate frame using the current p[q] values.
>
> "
>
> -> this should be further detailed.
>

We change with " Finally, for the dequeuing process, a Priority 
Scheduler selects the
    appropriate packet using the current p[q] values, e.g., among the
    queues with available traffic, the first packet of the queue with the
    highest priority is dequeued."

> The beginning of this section might describe how the priorities of the 
> different queues
>
> are used.
>

Fig 2 and 3 have now detailed explanations.

Thanks Nicolas for your valuable feedback.

EL


-- 
Emmanuel LOCHIN
Professeur ISAE
ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -
http://www.isae-supaero.fr
Tel [phone] - Fax [phone]
Web :http://personnel.isae.fr/emmanuel-lochin/