Re: [tsvwg] L4S Review

[Kuhn Nicolas <[e-mail]>]

-----Message d'origine-----
De : Scheffenegger, Richard <[e-mail]> 
Envoyé : mercredi 28 novembre 2018 16:04
À : Kuhn Nicolas <[e-mail]>; tsvwg IETF list <[e-mail]>
Cc : Bob Briscoe <[e-mail]>
Objet : Re: [tsvwg] L4S Review

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.

[NK] Thanks. It would indeed be relevant to point to it in all documents otherwise, it may be complicated to see the whole picture and understand the current document contribution. 

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

[NK] I am not aware of any example in that sense. That being said, TCP-splitters may break the end-to-end signaling. 

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