Re: [tsvwg] More SCReAMs... (was RE: RE: RE: L4S and QUIC)

[Sebastian Moeller <[e-mail]>]

Ingemar,
 
 
 more below in-line, prefixed [SM].
 

Gesendet: Montag, 02. November 2020 um 11:06 Uhr
Von: "Ingemar Johansson S" <[e-mail]>
An: "Sebastian Moeller" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "Christian Huitema" <[e-mail]>, "Wesley Eddy" <[e-mail]>, "Gorry Fairhurst" <[e-mail]>, "Ingemar Johansson S" <[e-mail]>
Betreff: More SCReAMs... (was RE: RE: RE: [tsvwg] L4S and QUIC)

Sebastian
 
Change subject line as you redirected the topic
        [SM] Sarcasm, typically is the most effective way to encourage a more civil discourse, I agree.
 
L4S support in SCReAM is still work in progress. The main beef, that you’ll find out if you read the master thesis report, is that it is too responsive and this backs off too easily. So yes, it definitely satisfy the requirements in L4S ID.  

        [SM] That still is no clear answer whether you are going to respoct section 4.3 or not, But I take it, rather not. Yes, it is annoying to be put on a spot with a question like this, But this is an email list, where you can write a small essay showing why your way forward is sane and good, not respnding however, less convincing.
 
Speaking seriously.. This becomes more of trolling the group, it does not lead anywhere and only serves to suck energy from the group, and it really does a real good job at it.

        [SM] I take offence in that characterisation. I keep measuring L4S reality agsainst its claims. It is not my fault that it comes up negative in that comparison, I was neither involved in its design and implementation, nor did I write the claims. And even before my involvement in this mailing list, L4S progress has been glacial, so do not blame me for that either.
 
 
You could have found the answer if you had read Davide Brunello’s master thesis report. Instead you toss out statements and challenges and I see it only as a way to wear down the interest in L4S.  

        [SM] Oh, I instead had a look at the code repository to see whether I would find anything related to L4S' 5 protocol requirements, and I came up short. I do not claim to have done exhaustive research, but I did look at the source; and as you confirmed, the 5 requirements are not consciously addressed in SCReAM. Which is independent of having read that thesis, no?
And no, I am convinced, by the data we have seen so far, that current L4S design and implementation is not fit for release onto the wider internet, and poses a real thread also to my own traffic (if sharing an L4S bottleneck).
        I am not trying to "wear down the interest in L4S" I am trying to clarify that it is going to be active harmful to the internet, so I am trying to discourage the deployment of L4S, until its problematic parts have been fixed. Again I take offence in your characterisation. I typically have a theory what is wrong and often can point to test data demonstrating the issue, sure I can be wrong, but I am willing to be convinced by data. Interestingly, data that is also recommended to be collected, analysed and presented to the IETF in the CC guidelines in RFC5033 (guidelines (2), (3), (6), and (7), come to mind as currently under-explored). It is fine to agree with the bigger goals of L4S and see its potential, but I do not believe that that should lead towards turning a blind eye towards where the current implementation fails to achieve its goals. Once deployment started, the horse has left the barn, and L4S is going to be much harder to fix, so getting this right is important. 
 
Sebastian
 
 
 
/Ingemar
 

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

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 "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[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][mailto:[e-mail]]>
An: "Sebastian Moeller" <[e-mail][mailto:[e-mail]]>
Cc: "[e-mail][mailto:[e-mail]]" <[e-mail][mailto:[e-mail]]>, "Christian Huitema" <[e-mail][mailto:[e-mail]]>, "Ingemar Johansson S" <[e-mail][mailto:[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][mailto:[e-mail]]>
Sent: den 2 november 2020 10:20
To: Ingemar Johansson S <[e-mail][mailto:[e-mail]]>
Cc: [e-mail][mailto:[e-mail]]; Christian Huitema <[e-mail][mailto:[e-mail]]>; Ingemar Johansson S <[e-mail][mailto:[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][mailto:[e-mail]]>
An: "Sebastian Moeller" <[e-mail][mailto:[e-mail]]>
Cc: "[e-mail][mailto:[e-mail]]" <[e-mail][mailto:[e-mail]]>, "Christian Huitema" <[e-mail][mailto:[e-mail]]>, "Ingemar Johansson S" <[e-mail][mailto:[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[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][mailto:[e-mail]]>
Sent: den 2 november 2020 09:16
To: Ingemar Johansson S <[e-mail][mailto:[e-mail]]>
Cc: [e-mail][mailto:[e-mail]]; Christian Huitema <[e-mail][mailto:[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
=================================