[tsvwg] L4S Review

[Kuhn Nicolas <[e-mail]>]

All,

This is a quick review on two L4S related drafts (draft-ietf-tsvwg-ecn-l4s-id-05 and draft-ietf-tsvwg-aqm-dualq-coupled-08).

draft-ietf-tsvwg-ecn-l4s-id-05 proposes modification to ECN semantics to introduce a new L4S network service
draft-ietf-tsvwg-aqm-dualq-coupled-08 describes DualQueue

In general, the draft says either too much or too little on the general picture and it is somehow confusing to see the interactions between all the contributions.
I would propose you to have a replicated section on all drafts explaining their interaction (or a pointer to a web page, another document, etc.).

Some detailed comments:

*******
Identifying Modified Explicit Congestion Notification (ECN) Semantics
                   for Ultra-Low Queuing Delay (L4S)
                     draft-ietf-tsvwg-ecn-l4s-id-05

Review of https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05
*******

What happens if the codepoints are used by the sender but the sender does not comply with the prerequisite detailed in section 4.3?
Also, another network component on the path could exploit this semantic for other purpose.

Is there a way to mention what should not be done with this new semantics ?
One should not use it for other purposes that the one proposed in the whole L4S framework ?




   o  it SHOULD not lead to some packets of a transport-layer flow being

      served by a different queue from others.
I do not understand this point. You may want to make it clearer.


   The Diffserv architecture provides Expedited Forwarding [RFC3246<https://tools.ietf.org/html/rfc3246>], so

   that low latency traffic can jump the queue of other traffic.

   However, on access links dedicated to individual sites (homes, small

   enterprises or mobile devices), often all traffic at any one time

   will be latency-sensitive.  Then Diffserv is of little use.  Instead,

   we need to remove the causes of any unnecessary delay.

IMHO some more info should be provided here. AFAIK, the Diffserv architecture does not provide hints on how to schedule packets afterwards.
Hierarchical queuing would be necessary when control, management and data traffic share the same (let's say) wireless link.
To make it clearer, I would propose you to point the draft-briscoe-tsvwg-l4s-diffserv-02 draft at this stage or remove that statement.


The likelihood that an AQM drops a Not-ECT Classic packet (p_C) MUST

   be roughly proportional to the square of the likelihood that it would

   have marked it if it had been an L4S packet (p_L).  That is

If you want this part to be self-content, I would propose you to explain the rationale behind this. Also, I am not sure this is necessary in this draft.
Indeed, it raises questions on the link with Diffserv architecture and where AQM would be deployed on it.


flow.  Such a switch-over is likely to be very rare, but It could be
Typo

*******
DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput
                                 (L4S)
                 draft-ietf-tsvwg-aqm-dualq-coupled-08
Review of https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08
*******


   This document specifies a `DualQ Coupled AQM' extension that solves

   the problem of coexistence between scalable and classic flows,

   without having to inspect flow identifiers.  The AQM is not like

   flow-queuing approaches [RFC8290<https://tools.ietf.org/html/rfc8290>] that classify packets by flow

   identifier into numerous separate queues in order to isolate sparse

   flows from the higher latency in the queues assigned to heavier

   flows.  In contrast, the AQM exploits the behaviour of scalable

   congestion controls like DCTCP so that every packet in every flow

   sharing the queue for DCTCP-like traffic can be served with very low

   latency.

I would propose you to first define what DualQ is before saying what is is not and comparing it with flow queue schemes.



The following

   parameters MAY be operator-configurable, e.g. to tune for non-

   Internet settings:

To be generic, you may want to tune both the frequency at which the AQM parameters are adapted and the delay target.
It is confusing with the notion of maximum RTT and typical RTT.