Subject: Re: [tsvwg] Comments on draft-finzi-priority-switching-scheduler-02.txt

From: Emmanuel Lochin <[email-masked]>
Date: Wed, 17 Oct 2018 11:06:12 +0200

Dear Ruediger

Thank you for the time spent to read this draft and for providing 
interesting and relevant comments. Sorry to not have been able to answer 
sooner. During summer, we did an implementation of this proposal within 
a TUN/TAP device and spent most of our time to test and assess the real 
performance of PSS. The implementation will be released for the 
community before the next IETF meeting.

Please find in-line answer to your questions :

On 13/06/2018 14:54, [email-masked] wrote:
>
> Hi Emmanuel,
>
> I’ve read your draft and have a couple of comments.
>
> The scope says the aim is to isolate “time constrained and elastic 
> traffic flows from best-effort traffic”. By priority switching, you 
> are able to produce WRR like behavior with a strict priority 
> scheduler, if I got that right.
>
Definitely right.
>
> As the scope starts with a hint to transport or application 
> properties, my expectation would have been that there’s a discussion 
> of the expected effect on Layer 4 and above services. I’ve also read 
> your conference paper which you refer to in your draft, but this 
> discussion seems to be missing. I’d like to learn more about the 
> following:
>
>   * A suggestion in which part of the network priority-switching
>     should be deployed. You mention that IEEE Time-Sensitive
>     Networking Task Group started to work on a Burst Limiting Shaper,
>     and that motivated your work. Is LAN/Layer 2/Access Network the
>     answer?
>
Actually, this scheduling mechanism (initially called Burst Limiting 
Shaper: BLS) has been proposed by the IEEE TSN task group to mainly 
mitigate the impact of the burstiness of first class traffic in a 
switching context. BLS  is "yet another attempt" to approach a GPS 
approximation but propose an interesting approach compare to WFQ or 
WFQ2+ for instance, as it does not implement a virtual clock. Basically 
we borrowed the idea and adapted it to be used at the IP level as 
illustrated in Section 3 with the DiffServ core network use-case. So 
concerning the layering, although all scheduling mechanisms could be 
deployed at any layers, we only focus on the IP layer in this draft.

Concerning the deployment inside the network : such mechanism is of 
interest to be deployed anywhere traffic management is needed, in 
particular when rate scheduling is mandatory. We tested the interest of 
deploying PSS within a satellite gateway and inside a core network 
router. Other use-cases can be envisioned over edge/home access. To 
clarify this part and as you requested, we added further information in 
Section 3.

>   * Please discuss whether and what impact there is on the Transport
>     layer and on queue configuration. If a queue is changing priority,
>     it changes dequeue rate.. That means buffers fill. Do packet loss
>     and jitter patterns differ from WFQ under similar load?
>
We have these statistics following the tests we did with the real 
implementation and we will add a reference to the paper in this draft 
(as a draft should only contains implementation details and not 
performance measurements). However, we can explain the interest for the 
transport layer, this will be added.
>
>   * I’d also be interested in a discussion, whether WRED, Codel or PIE
>     could be combined with priority-switching.
>
Indeed, as for all rate scheduling, the administrator can choose to 
combine PSS with any kind of AQM.
>
>   * That said, operation under congestion and comparison with WFQ with
>     deployed AQM and the impact on Transport performance might be an
>     interesting topic.
>
Definitely, and this is one of the material provided in our paper that 
will be cited in the draft.
>
>   * I don’t expect you to provide results. A discussion and an
>     identification where more research may be useful would be nice.
>
We agree, a draft should not deal with performance analysis but 
implementation details. A discussion will be added.
>
> From the draft I learn, that you start from the following assumption:
>
>   * The EF service is not rate limited and can use full link bandwidth
>     (highest priority)
>   * AF has a configured rate
>   * Default has got no configured minimum rate (lowest priority)
>
Yes, this part lays on RFC5865.
>
> Your idea is not to starve Default or not to starve Default as fast as 
> WFQ would do und similar conditions.. To do so, there’s a minimum and 
> a maximum bandwidth assigned to AF by the priority-switching scheduler.
>
Right and this is the objective of any rate scheduler (depending on the 
configuration chosen by the administrator).
>
> To me, an unlimited strict priority queue is a somewhat unlikely 
> configuration, as would be a Default queue without minimum resources 
> (to me that sounds like Lower Effort). Are there benefits if 
> priority-switching is deployed in other DiffServ environments? If so, 
> what are they?
>
For instance, if you choose only 2 priorities all managed by PSS and not 
one by SP (EF) and the two others remaining by PSS (AF and BE), you 
obtain an equivalent rate scheduler scheme. May be we could also 
illustrate this case in the draft as another use-case (this is a good 
idea indeed as it would bring a different use-case).

> Regards,
Once again many thanks !

Emmanuel

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