Subject: [tsvwg] Comments to draft-finzi-priority-switching-scheduler-02

From: Vincent Roca <[email-masked]>
Date: Mon, 10 Sep 2018 15:17:31 +0200

Dear authors,

Please find below my comments after reading your I-D 
	draft-finzi-priority-switching-scheduler-02
Those comments are not from a CC specialist as you know
and I cannot judge the accuracy of the claims.

Regards,

  Vincent

————
Abstract:

** the text first opposes "time constrained and elastic flows" from BE flows.
Then, just after "Usual implementations of rate scheduler schemes", it opposes the AF and BE flows.
From a logical point of view, are the elastic flows  part of AF flows? I don't think so but there's
an ambiguity here: does this proposal consider the same flow classes as the "usual schedulers"?

** The text could also be clarified WRT its use of "queues",  "traffic flow", and "traffic class".
Since this is just an abstract that needs to be kept small and easy to understand, may be selecting
one term would be sufficient.

** Finally the AF and BE acronyms are used but not expanded (I don't think it's appropriate to also
expand WRR and DRR though, leave it as it is).

Introduction:

** Section 1.1: you say: "... depends on the amount of traffic crossing other queues".
Do you really mean crossing or arriving at? Does "crossing" have the same meaning as "output rate"?

** Section 1.1: I don't understand where's the difficulty in having controlled queues: if I always
immediately schedule packets arriving at a "controlled queue", it's output rate will not depend on
other BE traffic and uncertainty of the output rate will be kept minimum (once again WRT BE traffic).
The scientific problem must be better stated. We understand what is expected by reading Section 1.3,
but that's a section that describes the technical proposal, not the problem.

** Section 1.2: why do you put this section here? 1.3 should immediately follow the context/motivation
section.

** Section 1.3: once again, I'd like to know if "queue" and "flow" are synonymous or not.
Can two flows share the same queue? What's the mapping between them?

** Section 1.3: I'd suggest simplifying a bit the sentence:
s/each priority denoted p[i],/each priority p[i]/
and
s/credit counter, i.e., credit[i]/credit counter credit[i]/

** Section 1.3: In sentence "Then a Priority Scheduler is used", you use "e.g., ".
Is it really an example, i.e., could a different approach be used as suggested?

** Section 1.3, last paragraph: I don't understand what "queues scheduled with a simple Priority Scheduler"
refers to, especially when the authors add, concerning this simple PS: "(when only one priority is set)".
Could you clarify your point?

** Is there a reference (e.g., article) for this proposal, beyond the [BLS] mentioned earlier?

Section 2.1 "Specifications":

** The relation: "p_high[q] < p_low[q]" is strange... Usually high > low, not the opposite.

** the "maximum level" associated acronym should be ML and not "LMs[q]". Same comment for "LRs[q]"
unless there's something I've missed.
What's the "C" parameter in the idle/sending slopes formulas? The output link capacity?
Reading the formulas and assuming C is a birate, I understand that "BWs[q]" could a ratio. Is that
the case? More generally, for the various parameters the unit (and possibly a quick definition)
should be provided.

** In the paragraph describing the impacts of LMs[q], the authors use "non-premption" as a synonymous
to "maximum sending windows", or at least this is the way I understand it since this is not clarified.
I suggest removing "non-preemption" and sticking to "maximum sending windows" (or the opposite) to
avoid confusion.

** s/premption/preemption/ (3 occurences).

** s/However, there are two cases keeping track of the transmission raises an issue:/However, two cases raise an issue:/
or something else.

** In: "LRs[q]= Lmax(..." it is not clear to me what Lmax is.

** Globally: you should add a section for acronyms (e.g., section 1.4 to create).

** s/until the priority change/until the priority changes/

** s/This highlight/This highlights/

** About Figure 2 and Figure 3: I don't understand. It shows (y-axis) the evolution of credit[q] over
time (x-axis). I don't understand where's the priority change. There's no such axis.
I don't understand what the @@@ and ooo refer to (different periods?).
I guess that the vertical lines refer to a network condition change, but which one?

Section 2.2 "Implementation":

** In "The new dequeuing algorithm is presented in the PSS Algorithm." please an explicit reference to Fig. 4.

** In Fig. 4, instead of "credits" (and all other input arguments where a final "s" is added), use
credit[] to remind it's a table.
Also, it seems that in "credit[q] = max(credit[q]-dtime[q].C.BWs[q],0)" the « . »  are in fact «  * ».

Section 3.1 "Motivations"

** s/Thank to the increase predictability/Thanks to the increased predictability/

Section 6.2:

** Remove "<acceptedPaper>" but add a link to http://oatao.univ-toulouse.fr/18448/ open archive.