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

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,

more below in-line, prefixed [SM2].

> Gesendet: Montag, 02. November 2020 um 12:26 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: RE: More SCReAMs... (was RE: RE: RE: [tsvwg] L4S and QUIC)
>
> Sebastian.
>
> As said.. L4S in SCReAM is work in progress and the present implementation is a bit over-reacting to congestion.
> RFC8298 is an experimental RFC, eventually it MAY become standards track and then the L4S implementation will be vetted against the requirements in L4S ID.

[SM2] Sure, as I failed to convey, I do not think SCReAM or you are at fault here, it is an L4S problem that safety depends on protocol compliance, AND that this compliance is neither monitored nor enforced by the network nodes.

> Does this sound OK ?.

[SM2] Yes. One more question (again not intended as an attack on either SCReAM nor on the typical way of iteratively developing/testing code), will you restrict SCReAM tests with enabled L4S response module to network paths under your full control, or will you also test over the wider internet and if possible also test internet paths with knows L4S AQM nodes?

> If not , then I can't help you anymore.

[SM2] Now, since we are talking with each other, you are helping me immensely in trying to understand if "outsourcing" L4S' RFC-compliance to protocol implementers is a realistic path forward. 
        IMHO, as you might have guessed, I come down to a solid NO, as that runs counter to how I think and you confirmed for the case of SCReAM protocol development is performed in the real-world. In other words L4S needs to be robust against protocols not following its recommendations to the letter, and especially equitable sharing with non-ECT(1) traffic should not depend on expecting all flows following section 4.3*
Again no offence intended against either SCReAM nor yourself.



I have not more answers to give in this thread.

        [SM2] Thanks for the answers you gave.

Best Regards
        P.


*) Interestingly the thesis "Destruction Testing: Ultra-Low Delay using Dual Queue Coupled Active Queue Management" shows in Figures 12.X that equatable sharing between queues not only suffers for short RTTs < 15ms, but also that unresponsive traffic in ANY queue, will cause greater utilisation reduction on the non-ECT(1) traffic in L4S deep queue. I add this as one more case where DualQ's coupling proves itself to be an imprecise heuristic not up to either the state of the art nor the expectations gained from reading the L4S internet drafts. But that is pretty much more of the same, and by now what I expect to find when I look a bit deeper into the data.

>
> /Ingemar
>
>
> > -----Original Message-----
> > From: Sebastian Moeller <[e-mail]>
> > Sent: den 2 november 2020 11:53
> > To: Ingemar Johansson S <[e-mail]>
> > Cc: [e-mail]; Christian Huitema <[e-mail]>; Wesley Eddy
> > <[e-mail]>; Gorry Fairhurst <[e-mail]>; Ingemar
> > Johansson S <[e-mail]>
> > Subject: Aw: More SCReAMs... (was RE: RE: RE: [tsvwg] L4S and QUIC)
> >
> >
> > 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 <wes@mti-
> > systems.com>; 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][https://trac.ietf.org/trac/tsvwg/tick[https://trac.ietf.org/trac/tsvwg/tick]
> > et/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:ingemar.s.johansson@ericsson.c
> > om]>
> > 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:ingemar.s.johansson@ericsson.c
> > om]>
> > 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:ingemar.s.johansson@ericsson.c
> > om]>
> > Cc: [e-mail][mailto:[e-mail]]; Christian Huitema
> > <[e-mail][mailto:[e-mail]]>; Ingemar Johansson S
> > <[e-mail][mailto:ingemar.s.johansson@ericsson.c
> > om]>
> > 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:ingemar.s.johansson@ericsson.c
> > om]>
> > 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:ingemar.s.johansson@ericsson.c
> > om]>
> > 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-[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-[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:ingemar.s.johansson@ericsson.c
> > om]>
> > 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.joha
> > nsson=[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://protect2.fireeye.com/v1/url?k=b1bdc278-[https://protect2.fireeye.com/v1/url?k=b1bdc278-]
> > ee26fb3c-b1bd82e3-861d41abace8-d33a553b5c52f9be&q=1&e=5c4401f7-
> > bb0c-4d81-a51c-
> > 595bf89c0e0f&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-
> > drafts%2Fwiki%2FECN-in-
> > QUIC%5Bhttps%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D1d33d
> > c14-42a8e516-1d339c8f-869a14f4b08c-
> > 4eaad222abafe313%26q%3D1%26e%3D40db647b-0c41-40c2-a4ba-
> > 56f976ebb56d%26u%3Dhttps%253A%252F%252Fgithub.com%252Fquicwg%
> > 252Fbase-drafts%252Fwiki%252FECN-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]
> > m]
> > www.ericsson.com[http://www.ericsson.com][http://www.ericsson.com/[http://www.ericsson.com/]]
> >
> > Talk about a dream, try to make it real
> > Bruce Springsteen
> > =================================
> >
>
>