Re: [tsvwg] L4S and QUIC

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,

 

 

 

Gesendet: Montag, 02. November 2020 um 09:00 Uhr
Von: "Ingemar Johansson S" <ingemar.s.johansson=[e-mail]>
An: "[e-mail]" <[e-mail]>
Cc: "Christian Huitema" <[e-mail]>
Betreff: [tsvwg] L4S and QUIC

Hi

As a kind of clarification (if needed/wanted) on the topic.

L4S was considered early on when ECN support was added to QUIC. See for instance this page

https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC" target="_blank" rel="nofollow">https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC

At some stage it was discussed if a report on CE marked bytes would have been beneficial but it was deemed that packet counters were sufficient.

 

L4S support is currently not defined in the QUIC recovery drafts, I believe that the rationale was too keep the functionality minimal in the first QUIC version.

 

Now that L4S appears to be getting traction then I would believe that it makes sense to add L4S support also in QUIC and because DCTCP is already an RFC I believe that it can be a good idea to add the necessary pseudo code for DCTCP in a future version of the QUIC recovery draft and the necessary procedures to enable L4S in QUIC transport.

 

       [SM] How is that going to be compliant to the L4S drafts? The proposal, as I understand is that use of ECT(1) is contingent upon a transport protocol fulfilling the protocol requirements, which means that currently ONLY TCP Prague complies (barely), I am confident that e.g. Picoquic does not qialify (it does neither implement the 15ms CC response dynamics hack, nor rfc3168 detection/fall-back. And what is the status of sream in that regard, does it fulfill the requirements yet (and are you planning to imp[lement changes ot make stream L4S compliant in the near future?)

 

 

The reference to DCTCP does of course not preclude the use of other CCs like Prague or BBRv2 but I believe that DCTCP is reasonably small (pseudo code wise) and it can also work well for interop testing and for instance edge cloud experiments. And it also gives some additional time for BBRv2 and Prague to mature.
 

       [SM] I disagree, for use with L4S Prague seems to be the only way to go, or rather every other CC needs to be modified to fulfill the L4S requirements dubbed the Prague requirements.

This apparent confusion on your side supports my hypothesis, that fixing a mis designed AQM by inventinf requirements for protocols is aloosing proposition, as protocols will simply not do this, especially if the AQM in question does neither monitor or enforce compliance to said requirements. As much as it pains me to say, that is simply not a robust design/ And I have problems believing that after roughly a decade of development this robustness issue has not been understood by the L4S designers.

Best Regards

        Sebastian

 

/Ingemar

================================

Ingemar Johansson  M.Sc.

Master Researcher

 

Ericsson Research

RESEARCHER

GFTL ER NAP NCM Netw Proto & E2E Perf

Labratoriegränd 11

977 53, Luleå, Sweden

Phone [phone]

SMS/MMS [phone]

[e-mail]

http://www.ericsson.com/" target="_blank" rel="nofollow">www.ericsson.com

 

Talk about a dream, try to make it real

                  Bruce Springsteen

=================================