Re: [tsvwg] L4S Review

["Scheffenegger, Richard" <[e-mail]>]

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.


 > Also, another network component on the path could exploit this
 > 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).
> 
> 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.
>