Re: [tsvwg] L4S and QUIC

[Ingemar Johansson S <[e-mail]>]

Sebastian.

 

The QUIC recovery draft specifies a Reno like congestion control for “classic” ECN and loss based congestion control. Implementers are free to implement whatever ACME CC they feel fit for their purpose.

The same applies to L4S support, yes, it is understood that DCTCP does not deliver it all, but it is reasonably little code and guess that there can be a resistance against adding 1000s of lines of code in the QUIC recovery drafts. And as is the case with the “classic” congestion control, real implementations are more likely to use BBRv2 or Prague.

 

/Ingemar 

 

 

From: Sebastian Moeller <[e-mail]> 
Sent: den 2 november 2020 09:16
To: Ingemar Johansson S <[e-mail]>
Cc: [e-mail]; Christian Huitema <[e-mail]>
Subject: Aw: [tsvwg] L4S and QUIC

 

Hi Ingemar,

 

  

  

Gesendet: Montag, 02. November 2020 um 09:00 Uhr
Von: "Ingemar Johansson S" <ingemar.s.johansson=[e-mail] <mailto:ingemar.s.johansson=[e-mail]> >
An: "[e-mail] <mailto:[e-mail]> " <[e-mail] <mailto:[e-mail]> >
Cc: "Christian Huitema" <[e-mail] <mailto:[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 <https://protect2.fireeye.com/v1/url?k=1d33dc14-42a8e516-1d339c8f-869a14f4b08c-4eaad222abafe313&q=1&e=40db647b-0c41-40c2-a4ba-56f976ebb56d&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fwiki%2FECN-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] <mailto:[e-mail]> 

www.ericsson.com <http://www.ericsson.com/> 

 

Talk about a dream, try to make it real

                  Bruce Springsteen

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