Re: [tsvwg] L4S and QUIC

[Sebastian Moeller <[e-mail]>]

Ingemar,

 

I take this as positive prove that SCReAM is not going to implement the https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-10#section-4.3" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-10#section-4.3 "requirements" but still is going to use L4S signaling?

 

        That fits my expectation what sane protocol designers implementers are going to do. I was not out to expose you as reluctant to implement them, but to confirm my hypothesis, that L4s's safety mechanisms, relaying on implementers, are simply insufficient. Thanks for supporting that point. You might not note, but I am still in the process of testing L4S afgainst its own internet drafts, and I take offence in being blamed for the fact the L4S continuosly falls short of its own drafts. Take that up with the folks who designed L4S and thos who wrote the internet dratfs. Yes, I might annoy you, sorrty for that. But I will not let that social inconvenience stop me from pointing out where and why L4S is not ready for wider deployment.

        If you diasagree, just show the data that demonstrates that L4S will work robustly and reliably over the existing internet under a saufficiently wide set of realistic conditions.

 

        The reluctance to implement protocol requirements also goes directlyto the core of issue #28 (https://trac.ietf.org/trac/tsvwg/ticket/28). It is only the ambiguously worded "elimination of RTT bias" requirement, that will avoid L4S violating RFC 2914 section 3.2. and only if implemters realize thay they are assumed to make up for DualQ's 15ms hole (which itself is not documented well).

 

I will also end this sub-thread, unless 

 

Best Regards

        Sebastian

 

 

Gesendet: Montag, 02. November 2020 um 10:29 Uhr
Von: "Ingemar Johansson S" <[e-mail]>
An: "Sebastian Moeller" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "Christian Huitema" <[e-mail]>, "Ingemar Johansson S" <[e-mail]>
Betreff: RE: RE: [tsvwg] L4S and QUIC

Sebastian…

 

I’ll drop that DCTCP reference for now. We can leave that for the QUIC standardization and then you are free to engage in infinite discussions in that group when the time is right.

 

/Ingemar

 

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

 

Hi Ingemar,

 

 

Gesendet: Montag, 02. November 2020 um 10:06 Uhr
Von: "Ingemar Johansson S" <[e-mail]>
An: "Sebastian Moeller" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "Christian Huitema" <[e-mail]>, "Ingemar Johansson S" <[e-mail]>
Betreff: RE: [tsvwg] L4S and QUIC

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.

[SM] I believe you are mistaken, https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-10#section-4.3" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-10#section-4.3 states:

"In order to coexist safely with other Internet traffic, a scalable congestion control MUST NOT tag its packets with the ECT(1) codepoint unless it complies with the following bulleted requirements. The specification of a particular scalable congestion control MUST describe in detail how it satisfies each requirement and, for any non-mandatory requirements, it MUST justify why it does not comply:"

followed by a list of 5 requirements (3 MUSTs, 2 SHOULDs), including MUST for elimination of RTT bias, rfc3168 compatibility, and standard response to packet loss. Which essentially are the Preague requirments, and ATM not even TCP Prague meets those. 

But as I already predicted, there "requirements" are really only in the internet draft to counter objections in the ratificaytion process, if actual compliance would be an important point to the L4S designers, there would be methjods to check and potentially enforce compliant behavior. As is these act as fig leaves to cover L4S obvious short-comings, and will be the first thing ignored/jettsioned once other protocolls implement ECT(1) signaling and responses. Case in point, neither picoquic nor SCReAm seemed to have bothered with caring for these "requirements".

But again, will you change SCReAM to at least honor the 3 MUST requirements before releasing it onto the wider internet? That is a simple question, with asimple answer that you avoided answering, so here afgain as explicit question, will you make SCReAMs L4S response comply with the L4S internet drafts?

 

Best Regards

        Sebastian

 

/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]>
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://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" 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

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