Subject: [tsvwg] David Black's Review of draft-finzi-priority-switching-scheduler

From: "Black, David" <[email-masked]>
Date: Mon, 7 May 2018 19:53:20 +0000

I write as an individual, not as WG co-chair.  I appreciate the effort that the authors have made to bring this draft to the IETF.

Draft status page:
https://datatracker.ietf.org/doc/draft-finzi-priority-switching-scheduler/
Slides from London tsvwg meeting (March 2018):
                https://datatracker.ietf.org/meeting/101/materials/slides-101-tsvwg-sessb-33-priority-switching-scheduler-00

I like the slides much more than I like the draft.   My initial thought on reading the draft was to suggest switching the order of Sections 2 and 3 so that discussion of the problem in Diffserv context (important for IETF) would precede explanation of the solution.  After looking at the slides, I realized that what's really wanted is a shorter up-front summary of how this scheduling technique can benefit a Diffserv router implementation, as slide 3 concisely explains.  Sections 2 and 3 should then be fine in their current order if an analogous (to slide 3) explanation of how this scheduler benefits a Diffserv router implementation is added to Section 1, perhaps to follow the current Section 1.1.

As this draft is not intended to be standards track, I strongly suggest that the authors submit a PDF version in addition to the text version, as the PDF diagrams should be much more comprehensible by comparison to ASCII graphics, and it should be possible to include more detailed graphs.

The implementation pseudo-code and discussion in Section 2.2 might be better moved to an Appendix.

Are there any results from simulated or actual traffic?

Section 3.2's pointer to the Globecom paper for the results of the scheduler scenario described in Section 3.1 is unsatisfying - please include content analogous to slide 14.

Obviously, Section 4 (Security Considerations) needs to be written ;-).  At a minimum, I suggest comparing this scheduler to others that it might replace on opportunities for theft or denial of service - e.g., is one of the schedulers more prone to starvation of a class of traffic than another?

Finally, this text on p.7 bothered me:

   the Assured Forwarding

   (AF) class deals with elastic traffic as defined in [RFC4594<https://tools.ietf.org/html/rfc4594>] (data

   transfer, updating process, ...) while all other remaining traffic is

   classified inside the default (DE) best-effort class.

I traced my concern back to this text in Section 1.5 of RFC 4594 ...

   While Differentiated Services is a general architecture that may be

   used to implement a variety of services, three fundamental forwarding

   behaviors have been defined and characterized for general use.  These

   are basic Default Forwarding (DF) behavior for elastic traffic, the

   Assured Forwarding (AF) behavior, and the Expedited Forwarding (EF)

   behavior for real-time (inelastic) traffic.

In other words, a lot of the best-effort traffic is elastic, so it's not correct to imply that all elastic traffic would use AF.   For AF, I'd suggest instead picking a relevant service class or two from RFC 4594, perhaps High-Throughput Data or Low-Latency Data.  Also, "(DE)" -> "(DF)".

I think another version of this draft would be a good idea.

Thanks, --David
----------------------------------------------------------------
David L. Black, Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953    Mobile: +1 (978) 394-7754
[email-masked]<mailto:[email-masked]>
----------------------------------------------------------------

---

From: Emmanuel Lochin <[email-masked]>
Date: Wed, 30 May 2018 16:35:14 +0200

Dear David,

Many thanks for this review and feedback. We keep working on the draft 
content but have uploaded a new version with yours and Nicolas 
suggestions. My answers in-line:

Le 07/05/2018 à 21:53, Black, David a écrit :
>
> I write as an individual, not as WG co-chair.  I appreciate the effort 
> that the authors have made to bring this draft to the IETF.
>
> Draft status page:
>
> I like the slides much more than I like the draft.   My initial 
> thought on reading the draft was to suggest switching the order of 
> Sections 2 and 3 so that discussion of the problem in Diffserv context 
> (important for IETF) would precede explanation of the solution.  After 
> looking at the slides, I realized that what’s really wanted is a 
> shorter up-front summary of how this scheduling technique can benefit 
> a Diffserv router implementation, as slide 3 concisely explains.  
> Sections 2 and 3 should then be fine in their current order if an 
> analogous (to slide 3) explanation of how this scheduler benefits a 
> Diffserv router implementation is added to Section 1, perhaps to 
> follow the current Section 1.1.
>

As said to Nicolas, we are still thinking how to better organize this 
part. At this stage we have modified and polished the text.

> As this draft is not intended to be standards track, I strongly 
> suggest that the authors submit a PDF version in addition to the text 
> version, as the PDF diagrams should be much more comprehensible by 
> comparison to ASCII graphics, and it should be possible to include 
> more detailed graphs.
>

Done, we uploaded a PDF version containing SVG figures following RFC7996

> Are there any results from simulated or actual traffic?

Yes, we implemented PSS using the TUN/TAP GNU/Linux interface and 
obtained similar behavior than those we previously got with ns-2. The 
code will be soon released in the same time than a draft paper 
presenting the results obtained.

> Section 3.2’s pointer to the Globecom paper for the results of the 
> scheduler scenario described in Section 3.1 is unsatisfying – please 
> include content analogous to slide 14.
>

We added the figure slide 14 to clarify this part.

> Obviously, Section 4 (Security Considerations) needs to be written 
> ;-).  At a minimum, I suggest comparing this scheduler to others that 
> it might replace on opportunities for theft or denial of service – 
> e.g., is one of the schedulers more prone to starvation of a class of 
> traffic than another?
>
Done
>     (AF) class deals with elastic traffic as defined in [RFC4594 <https://tools.ietf.org/html/rfc4594>] (data
> I traced my concern back to this text in Section 1.5 of RFC 4594 …
>
> In other words, a lot of the best-effort traffic is elastic, so it’s 
> not correct to imply that all elastic traffic would use AF.   For AF, 
> I’d suggest instead picking a relevant service class or two from RFC 
> 4594, perhaps High-Throughput Data or Low-Latency Data.  Also, “(DE)” 
> -> “(DF)”.
>
Done
> I think another version of this draft would be a good idea.
Thanks again !

EL

> [email-masked] <mailto:[email-masked]>
>

-- 
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 +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45
Web :http://personnel.isae.fr/emmanuel-lochin/