Subject: [tsvwg] L4S Review

From: Kuhn Nicolas <[email-masked]>
Date: Tue, 27 Nov 2018 11:18:22 +0000

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.

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 28 Nov 2018 16:04:19 +0100

Hi Nicolas,

There is the architecture draft also, which gives a higher level overview:

https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-03

Pointing back to that in the other l4s documents might be useful.

 > semantic for other purpose.

There have been measurements in the public internet, which show no use 
of ECT(1) at all. Also, as these drafts are experimental, private 
environments could choose not to participate.

However, if you know of a concrete example (SatCom?) where ECT(1) is 
used as a specific signal (possibly between network elements, bleaching 
out again before the end systems can observe it), please speak up!

Best regards,
    Richard

Am 27.11.2018 um 12:18 schrieb Kuhn Nicolas:
> 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).
> 
> 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:
> 
> *******
> 
> What happens if the codepoints are used by the sender but the sender 
> does not comply with the prerequisite detailed in section 4.3?
> 
>     The Diffserv architecture provides Expedited Forwarding [RFC3246  <https://tools.ietf.org/html/rfc3246>], so
> 
> 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.
> 
> 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.
> 
>     flow-queuing approaches [RFC8290  <https://tools.ietf.org/html/rfc8290>] that classify packets by flow
> 
> 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
> 
> To be generic, you may want to tune both the frequency at which the AQM 
> parameters are adapted and the delay target.
>