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

From: <[email-masked]>
Date: Wed, 13 Jun 2018 12:54:23 +0000

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. 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?
  *   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?
  *   I'd also be interested in a discussion, whether WRED, Codel or PIE could be combined with priority-switching.
  *   That said, operation under congestion and comparison with WFQ with deployed AQM and the impact on Transport performance might be an interesting topic.
  *   I don't expect you to provide results. A discussion and an identification where more research may be useful would be nice.

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

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.

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?

Regards,

Ruediger