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

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

Hi

Please see inline

/Ingemar

> -----Original Message-----
> From: Sebastian Moeller <[e-mail]>
> Sent: den 2 november 2020 12:48
> 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: RE: More SCReAMs... (was RE: RE: RE: [tsvwg] L4S and QUIC)
> 
> 
> 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.
[IJ] No.. It is just that the source (video) is rate limited, this means that SCReAM often runs out of data to transmit. The cure is to make SCReAM drive congestion a bit harder. 

> > 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?
[IJ] The SCReAM source code is freely available for anybody to try out. But as said.. it is work in progress.

> 
> > 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/tr
> > > ac/tsvwg/ticket/28][https://trac.ietf.org/trac/tsvwg/tick[https://tr
> > > ac.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@ericsso
> > > n.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@ericsso
> > > n.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@ericsso
> > > n.c
> > > om]>
> > > Cc: [e-mail][mailto:[e-mail]]; Christian Huitema
> > > <[e-mail][mailto:[e-mail]]>; Ingemar
> Johansson
> > > S
> > > <[e-mail][mailto:ingemar.s.johansson@ericsso
> > > n.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@ericsso
> > > n.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@ericsso
> > > n.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.iet
> > > f.org/doc/html/draft-]
> > > ietf-tsvwg-ecn-l4s-id-10#section-
> > > 4.3[https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-i
> > > d-[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@ericsso
> > > n.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.fir
> > > eeye.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:ingemar.s.johansson@ericsson
> > > .co
> > > m]
> > >
> www.ericsson.com[http://www.ericsson.com][http://www.ericsson.com/[h
> > > ttp://www.ericsson.com/]]
> > >
> > > Talk about a dream, try to make it real Bruce Springsteen
> > > =================================
> > >
> >
> >