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

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 2 Nov 2020 10:06:04 +0000

Sebastian

Change subject line as you redirected the topic 

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.  

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. 

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.  

/Ingemar

From: Sebastian Moeller <[email-masked]> 
Sent: den 2 november 2020 10:51
To: Ingemar Johansson S <[email-masked]>
Cc: [email-masked]; Christian Huitema <[email-masked]>; Ingemar Johansson S <[email-masked]>; Wesley Eddy <[email-masked]>; Gorry Fairhurst <[email-masked]>
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). 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" <[email-masked] <mailto:[email-masked]> >
An: "Sebastian Moeller" <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "Christian Huitema" <[email-masked] <mailto:[email-masked]> >, "Ingemar Johansson S" <[email-masked] <mailto:[email-masked]> >
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 <[email-masked] <mailto:[email-masked]> >
Sent: den 2 november 2020 10:20
To: Ingemar Johansson S <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; Christian Huitema <[email-masked] <mailto:[email-masked]> >; Ingemar Johansson S <[email-masked] <mailto:[email-masked]> >
Subject: Aw: RE: [tsvwg] L4S and QUIC

Hi Ingemar,

Gesendet: Montag, 02. November 2020 um 10:06 Uhr
Von: "Ingemar Johansson S" <[email-masked] <mailto:[email-masked]> >
An: "Sebastian Moeller" <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "Christian Huitema" <[email-masked] <mailto:[email-masked]> >, "Ingemar Johansson S" <[email-masked] <mailto:[email-masked]> >
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 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 <[email-masked] <mailto:[email-masked]> >
Sent: den 2 november 2020 09:16
To: Ingemar Johansson S <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; Christian Huitema <[email-masked] <mailto:[email-masked]> >
Subject: Aw: [tsvwg] L4S and QUIC

Hi Ingemar,

Gesendet: Montag, 02. November 2020 um 09:00 Uhr
Von: "Ingemar Johansson S" <ingemar.s.johansson=[email-masked] <mailto:ingemar.s.johansson=[email-masked]> >
An: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Cc: "Christian Huitema" <[email-masked] <mailto:[email-masked]> >
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 +46-1071 43042

SMS/MMS +46-73 078 3289

[email-masked] <mailto:[email-masked]> 

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

Talk about a dream, try to make it real

                  Bruce Springsteen

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

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 2 Nov 2020 11:52:59 +0100

Ingemar,

 more below in-line, prefixed [SM].

Gesendet: Montag, 02. November 2020 um 11:06 Uhr
Von: "Ingemar Johansson S" <[email-masked]>
An: "Sebastian Moeller" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Christian Huitema" <[email-masked]>, "Wesley Eddy" <[email-masked]>, "Gorry Fairhurst" <[email-masked]>, "Ingemar Johansson S" <[email-masked]>
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.

        [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.

        [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.

        [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

Ingemar,

        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).

Best Regards

        Sebastian

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

Sebastian…

/Ingemar

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

Hi Ingemar,

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

Sebastian.
 
[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:
 
Best Regards
        Sebastian
 
/Ingemar

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

Hi Ingemar,

Gesendet: Montag, 02. November 2020 um 09:00 Uhr
Von: "Ingemar Johansson S" <ingemar.s.johansson=[email-masked][mailto:ingemar.s.johansson=[email-masked]]>
An: "[email-masked][mailto:[email-masked]]" <[email-masked][mailto:[email-masked]]>
Cc: "Christian Huitema" <[email-masked][mailto:[email-masked]]>
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.

 

 
/Ingemar
 
Ericsson Research
RESEARCHER
GFTL ER NAP NCM Netw Proto & E2E Perf
Labratoriegränd 11
977 53, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked][mailto:[email-masked]]
www.ericsson.com[http://www.ericsson.com/]

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 2 Nov 2020 11:26:33 +0000

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. 
Does this sound OK ?. 
If not , then I can't help you anymore. I have not more answers to give in this thread.

/Ingemar

> -----Original Message-----
> Sent: den 2 november 2020 11:53
> Cc: [email-masked]; Christian Huitema <[email-masked]>; Wesley Eddy
> <[email-masked]>; Gorry Fairhurst <[email-masked]>; Ingemar
> Johansson S <[email-masked]>
> Subject: Aw: More SCReAMs... (was RE: RE: RE: [tsvwg] L4S and QUIC)
> 
> 
> Ingemar,
> 
> 
> Cc: "[email-masked]" <[email-masked]>, "Christian Huitema"
> <[email-masked]>, "Wesley Eddy" <[email-masked]>, "Gorry
> Fairhurst" <[email-masked]>, "Ingemar Johansson S"
> <[email-masked]>
> 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
> 
> 
> Cc: [email-masked]; Christian Huitema <[email-masked]>; Ingemar
> Johansson S <[email-masked]>; Wesley Eddy <wes@mti-
> systems.com>; Gorry Fairhurst <[email-masked]>
> 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/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).
> 
> 
> 
> Von: "Ingemar Johansson S"
> <[email-masked][mailto:[email-masked]
> om]>
> Cc: "[email-masked][mailto:[email-masked]]"
> <[email-masked][mailto:[email-masked]]>, "Christian Huitema"
> <[email-masked][mailto:[email-masked]]>, "Ingemar Johansson
> S"
> <[email-masked][mailto:[email-masked]
> om]>
> 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
> 
> 
> To: Ingemar Johansson S
> <[email-masked][mailto:[email-masked]
> om]>
> Cc: [email-masked][mailto:[email-masked]]; Christian Huitema
> <[email-masked][mailto:[email-masked]]>; Ingemar Johansson S
> <[email-masked][mailto:[email-masked]
> om]>
> Von: "Ingemar Johansson S"
> <[email-masked][mailto:[email-masked]
> om]>
> Cc: "[email-masked][mailto:[email-masked]]"
> <[email-masked][mailto:[email-masked]]>, "Christian Huitema"
> <[email-masked][mailto:[email-masked]]>, "Ingemar Johansson
> S"
> <[email-masked][mailto:[email-masked]
> om]>
> 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
> 
> 
> 
> To: Ingemar Johansson S
> <[email-masked][mailto:[email-masked]
> om]>
> Cc: [email-masked][mailto:[email-masked]]; Christian Huitema
> <[email-masked][mailto:[email-masked]]>
> Von: "Ingemar Johansson S"
> <ingemar.s.johansson=[email-masked][mailto:ingemar.s.joha
> nsson=[email-masked]]>
> Cc: "Christian Huitema"
> <[email-masked][mailto:[email-masked]]>
> 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-
> 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

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 2 Nov 2020 12:48:24 +0100

Hi Ingemar,

more below in-line, prefixed [SM2].

> Gesendet: Montag, 02. November 2020 um 12:26 Uhr
> Betreff: RE: More SCReAMs... (was RE: RE: RE: [tsvwg] L4S and QUIC)
>
> Sebastian.
>

[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.

> > (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]
> > [SM] I believe you are mistaken, https://datatracker.ietf.org/doc/html/draft-[https://datatracker.ietf.org/doc/html/draft-]
> > 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:
> > instance this page https://protect2.fireeye.com/v1/url?k=b1bdc278-[https://protect2.fireeye.com/v1/url?k=b1bdc278-]
> > www.ericsson.com[http://www.ericsson.com][http://www.ericsson.com/[http://www.ericsson.com/]]
> >

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 2 Nov 2020 12:42:57 +0000

Hi

Please see inline

/Ingemar

> Sent: den 2 november 2020 12:48
> Subject: Aw: RE: More SCReAMs... (was RE: RE: RE: [tsvwg] L4S and QUIC)
> 
> 
> Hi Ingemar,
> 
> > 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.

> [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.
> 
> 
> 
> *) 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
> >
> >
> > > Cc: [email-masked]; Christian Huitema <[email-masked]>; Wesley
> > > Eddy <[email-masked]>; Gorry Fairhurst <[email-masked]>;
> > > Ingemar Johansson S <[email-masked]>
> > > 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.
> > >
> > > 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
> > >
> > >
> > > Johansson S <[email-masked]>; Wesley Eddy
> > > <wes@mti- systems.com>; Gorry Fairhurst <[email-masked]>
> > > the
> > > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-
> > > 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).
> > >
> > >
> > >
> > > <[email-masked][mailto:[email-masked]]>, "Ingemar
> > > Johansson S"
> > > 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
> > >
> > >
> > > <[email-masked][mailto:[email-masked]]>; Ingemar
> Johansson
> > > S
> > > <[email-masked][mailto:[email-masked]]>, "Ingemar
> > > Johansson S"
> > > 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-]
> > > 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
> > >
> > >
> > >
> > > <ingemar.s.johansson=[email-masked][mailto:ingemar.s.
> > > joha nsson=[email-masked]]>
> > > https://protect2.fireeye.com/v1/url?k=b1bdc278-[https://protect2.fir
> > > eeye.com/v1/url?k=b1bdc278-]
> > > 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
> > > GFTL ER NAP NCM Netw Proto & E2E Perf Labratoriegränd 11
> > > 977 53, Luleå, Sweden
> > > Phone +46-1071 43042
> > > SMS/MMS +46-73 078 3289
> > > [email-masked][mailto:ingemar.s.johansson@ericsson
> > > .co
> > > m]
> > >
> > > Talk about a dream, try to make it real Bruce Springsteen