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

[Emmanuel Lochin <[e-mail]>]

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

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

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
>
> 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)”.
>
Done
>
> I think another version of this draft would be a good idea.
>
Thanks again !

EL

> Thanks, --David
>
> ----------------------------------------------------------------
>
> David L. Black, Distinguished Engineer
>
> Dell EMC, 176 South St., Hopkinton, MA 01748
>
> [phone]    Mobile: [phone]
>
> [e-mail] <mailto:[e-mail]>
>
> ----------------------------------------------------------------
>

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