Subject: [tsvwg] L4S and QUIC

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 2 Nov 2020 08:00:38 +0000

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

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

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

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 09:16:19 +0100

Hi Ingemar,

Gesendet: Montag, 02. November 2020 um 09:00 Uhr

Von: "Ingemar Johansson S" <ingemar.s.johansson=[email-masked]>

An: "[email-masked]" <[email-masked]>

Cc: "Christian Huitema" <[email-masked]>

Betreff: [tsvwg] L4S and QUIC

Hi

L4S was considered early on when ECN support was added to QUIC. See for instance this page

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

Labratoriegränd 11

977 53, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

www.ericsson.com

Bruce Springsteen

---

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

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.

/Ingemar 

From: Sebastian Moeller <[email-masked]> 
Sent: den 2 november 2020 09:16
To: Ingemar Johansson S <[email-masked]>
Cc: [email-masked]; Christian Huitema <[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

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> 

 

Best Regards

        Sebastian

/Ingemar

Ingemar Johansson  M.Sc. 

Master Researcher

Ericsson Research

RESEARCHER

Labratoriegränd 11

977 53, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

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

                  Bruce Springsteen

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 2 Nov 2020 10:20:27 +0100

Hi Ingemar,

Gesendet: Montag, 02. November 2020 um 10:06 Uhr

Von: "Ingemar Johansson S" <[email-masked]>

An: "Sebastian Moeller" <[email-masked]>

Cc: "[email-masked]" <[email-masked]>, "Christian Huitema" <[email-masked]>, "Ingemar Johansson S" <[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 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

Hi Ingemar,

Hi

Best Regards

Sebastian

/Ingemar

Ingemar Johansson  M.Sc.

Master Researcher

Ericsson Research

RESEARCHER

Labratoriegränd 11

977 53, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

www.ericsson.com

Bruce Springsteen

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 2 Nov 2020 09:29:38 +0000

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]> 
Sent: den 2 november 2020 10:20
To: Ingemar Johansson S <[email-masked]>
Cc: [email-masked]; Christian Huitema <[email-masked]>; Ingemar Johansson S <[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.

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,

Hi

 

Best Regards

        Sebastian

/Ingemar

Ingemar Johansson  M.Sc. 

Master Researcher

Ericsson Research

RESEARCHER

Labratoriegränd 11

977 53, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

                  Bruce Springsteen

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 2 Nov 2020 10:50:32 +0100

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

Betreff: RE: RE: [tsvwg] L4S and QUIC

Sebastian…

/Ingemar

Hi Ingemar,

Sebastian.

Best Regards

Sebastian

/Ingemar

Hi Ingemar,

Hi

Best Regards

Sebastian

/Ingemar

Ingemar Johansson  M.Sc.

Master Researcher

Ericsson Research

RESEARCHER

Labratoriegränd 11

977 53, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

www.ericsson.com

Bruce Springsteen

---

From: "De Schepper, Koen (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 2 Nov 2020 13:05:59 +0000

Hi Ingemar,

Would indeed be very useful! I would suggest to include on top of DCTCP, the Prague extensions we added for better pacing and RTT independence. We know that the current DCTCP implementation has quite some flaws and performs worse than expected. Agreed that this is mainly due to the implementation (precision limitations and interaction with GRO) and not due to the principles. I think whatever we is proven and stable in Prague can easily be included.

Regards,
Koen.

From: Ingemar Johansson S <[email-masked]>
Sent: Monday, November 2, 2020 9:01 AM
To: [email-masked]
Cc: Christian Huitema <[email-masked]>; Bob Briscoe ([email-masked]) <[email-masked]>; De Schepper, Koen (Nokia - BE/Antwerp) <[email-masked]>; Ingemar Johansson S <[email-masked]>
Subject: L4S and QUIC

Hi

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 15:02:30 +0000

Hi

Yes, it is perhaps a good idea to start with the L4S support in the QUIC
standard, I guess the agenda is likely bloated this meeting but it could be
proposed in the QUIC tracker. 

It is of course possible to add the Prague extensions to the pseudo code,
reason why I suggested DCTCP is that it is relatively small form factor,
considering that the QUIC recovery draft is already quite large. But this is
a later struggle.

/Ingemar 

From: De Schepper, Koen (Nokia - BE/Antwerp)
<[email-masked]> 
Sent: den 2 november 2020 14:06
To: Ingemar Johansson S <[email-masked]>; [email-masked]
Cc: Christian Huitema <[email-masked]>; Bob Briscoe
([email-masked]) <[email-masked]>
Subject: RE: L4S and QUIC

Hi Ingemar,

Would indeed be very useful! I would suggest to include on top of DCTCP, the
Prague extensions we added for better pacing and RTT independence. We know
that the current DCTCP implementation has quite some flaws and performs
worse than expected. Agreed that this is mainly due to the implementation
(precision limitations and interaction with GRO) and not due to the
principles. I think whatever we is proven and stable in Prague can easily be
included.

Regards,

Koen.

From: Ingemar Johansson S <[email-masked]
<mailto:[email-masked]> > 
Sent: Monday, November 2, 2020 9:01 AM
To: [email-masked] <mailto:[email-masked]> 
Cc: Christian Huitema <[email-masked] <mailto:[email-masked]> >;
Bob Briscoe ([email-masked] <mailto:[email-masked]> )
<[email-masked] <mailto:[email-masked]> >; De Schepper, Koen
(Nokia - BE/Antwerp) <[email-masked]
<mailto:[email-masked]> >; Ingemar Johansson S
<[email-masked] <mailto:[email-masked]>
Subject: L4S and QUIC

Hi

https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC
<https://protect2.fireeye.com/v1/url?k=681efe53-3785c6b1-681ebec8-86073b36ea
28-106649c3119e65a1&q=1&e=9a6b7f51-1b89-47d6-a7cc-6a4717cda95b&u=https%3A%2F
%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fwiki%2FECN-in-QUIC> 

/Ingemar

Ingemar Johansson  M.Sc. 

Master Researcher

Ericsson Research

RESEARCHER

Labratoriegränd 11

977 53, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

                  Bruce Springsteen

---

From: Christian Huitema <[email-masked]>
Date: Mon, 2 Nov 2020 07:45:44 -0800

On 11/2/2020 7:02 AM, Ingemar Johansson S wrote:

> Hi
>
>  
>
> Yes, it is perhaps a good idea to start with the L4S support in the
> QUIC standard, I guess the agenda is likely bloated this meeting but
> it could be proposed in the QUIC tracker.
>
> It is of course possible to add the Prague extensions to the pseudo
> code, reason why I suggested DCTCP is that it is relatively small form
> factor, considering that the QUIC recovery draft is already quite
> large. But this is a later struggle.
>
The recovery draft is meant to provide an example of implementation, and
the WG was constrained by its charter to only consider RENO. Adding new
examples using different protocols will require a charter update, which
at best will take some time and add some frustration. It might be much
simpler to write a short L4S for QUIC draft, but first we would have to
decide what this draft actually specifies: the current "prague"
congestion control, defined as a set of changes to RENO; or, a general
"congestion response guideline", describing how congestion control
algorithms are expected to react to L4S-style ECN marking.

QUIC implementers will first try to understand how the L4S-AQM actually
behaves, independently of the general L4S high level goals. From this
discussion, I retain that L4S gives three signals: rate of marking lower
than two marks every 15 ms; rate higher than that; and rate about equal
to two every 15 ms. The expectation is that these signals amount to "may
accelerate; slow down; keep going". It it easy enough to write code that
reacts in this fashion, and produce a "tcp-prague" equivalent in QUIC --
much like the "prague.c" code developed for Picoquic. Defining that for
QUIC has value: explain how to react based on the ECN counters in QUIC,
explain the relation with parameters like pacing rate and maximum burst
size. But the problem does not stop there -- the practical requirement
is that code behaves well on the Internet as it is.

Running on the Internet as is means dealing with the currently deployed
zoo of router behaviors. The problem becomes much harder. Most
implementations will be willing to slow down if they see lots of ECN
marks, but when we get to "a small rate of ECN marks" we have a problem.
Should we ignore that small rate of marking as L4S suggests? L4S defines
"small" as "20 marks or fewer in the last 150 ms". What if other
algorithms have different definitions? In presence of a small rate of
marking, how do we treat packet losses, or delay increases? Do we have
experience of that, end-to-end measurements, telemetry from big
deployments? It would be nice if the hypothetic L4S for QUIC draft
addressed those questions.

-- Christian Huitema

---

From: "Gorry (erg)" <[email-masked]>
Date: Mon, 2 Nov 2020 16:38:27 +0000

> On 2 Nov 2020, at 15:46, Christian Huitema <[email-masked]> wrote:
> 
> 
>> Yes, it is perhaps a good idea to start with the L4S support in the QUIC standard, I guess the agenda is likely bloated this meeting but it could be proposed in the QUIC tracker.
>> It is of course possible to add the Prague extensions to the pseudo code, reason why I suggested DCTCP is that it is relatively small form factor, considering that the QUIC recovery draft is already quite large. But this is a later struggle.
> The recovery draft is meant to provide an example of implementation, and the WG was constrained by its charter to only consider RENO. Adding new examples using different protocols will require a charter update, which at best will take some time and add some frustration. It might be much simpler to write a short L4S for QUIC draft, but first we would have to decide what this draft actually specifies: the current "prague" congestion control, defined as a set of changes to RENO; or, a general "congestion response guideline", describing how congestion control algorithms are expected to react to L4S-style ECN marking.
> 
> QUIC implementers will first try to understand how the L4S-AQM actually behaves, independently of the general L4S high level goals. From this discussion, I retain that L4S gives three signals: rate of marking lower than two marks every 15 ms; rate higher than that; and rate about equal to two every 15 ms. The expectation is that these signals amount to "may accelerate; slow down; keep going". It it easy enough to write code that reacts in this fashion, and produce a "tcp-prague" equivalent in QUIC -- much like the "prague.c" code developed for Picoquic. Defining that for QUIC has value: explain how to react based on the ECN counters in QUIC, explain the relation with parameters like pacing rate and maximum burst size. But the problem does not stop there -- the practical requirement is that code behaves well on the Internet as it is.
> 
> Running on the Internet as is means dealing with the currently deployed zoo of router behaviors. The problem becomes much harder. Most implementations will be willing to slow down if they see lots of ECN marks, but when we get to "a small rate of ECN marks" we have a problem. Should we ignore that small rate of marking as L4S suggests? L4S defines "small" as "20 marks or fewer in the last 150 ms". What if other algorithms have different definitions? In presence of a small rate of marking, how do we treat packet losses, or delay increases? Do we have experience of that, end-to-end measurements, telemetry from big deployments? It would be nice if the hypothetic L4S for QUIC draft addressed those questions.
> 
> -- Christian Huitema
> 
Stepping back a little...

QUIC has the basic functions to allow ECN to be used, we first need to publish that, and this is in IETF LC.

L4S will soon go to WGLC, but does not address the details for QUIC.

I would expect a L4S for QUIC draft, would be a great idea to follow, and consolidate as experienced is gained. Happy to see that discussion on tsvwg list initially if there is interest.

However: In the mean time there are also a number of other ECN specs to complete!

Gorry

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 6 Nov 2020 12:11:28 +0000

Christian,

On 02/11/2020 15:45, Christian Huitema wrote:
>> code, reason why I suggested DCTCP is that it is relatively small 
>> form factor, considering that the QUIC recovery draft is already 
>> quite large. But this is a later struggle.
>>
> The recovery draft is meant to provide an example of implementation, 
> and the WG was constrained by its charter to only consider RENO. 
> Adding new examples using different protocols will require a charter 
> update, which at best will take some time and add some frustration. It 
> might be much simpler to write a short L4S for QUIC draft, but first 
> we would have to decide what this draft actually specifies: the 
> current "prague" congestion control, defined as a set of changes to 
> RENO; or, a general "congestion response guideline", describing how 
> congestion control algorithms are expected to react to L4S-style ECN 
> marking.
>
> QUIC implementers will first try to understand how the L4S-AQM 
> actually behaves, independently of the general L4S high level goals. 
> From this discussion, I retain that L4S gives three signals: rate of 
> marking lower than two marks every 15 ms; rate higher than that; and 
> rate about equal to two every 15 ms. The expectation is that these 
> signals amount to "may accelerate; slow down; keep going".
>

[BB] There may be a misunderstanding here. In future researchers might 
develop algorithms that work in three modes like you say, but I assume 
your priority now is just to implement in QUIC what is already known in 
TCP. DCTCP doesn't work in three modes - the average of 2 marks per RTT 
is an emergent property of the very simple change to the Reno algo 
described below, which it only arrives at after a dozen or so rounds in 
steady state. You mustn't force it to 2 marks per RTT too quickly, 
otherwise it would go very unstable.

A major difference between the current ('Classic') Internet and 
DCTCP/L4S is that responsibility for filtering out short-term queue 
variability shifts from the network to the sender. With L4S the 
network's CE marking exposes all the rapid changes to the queue 
(obviously delayed by the feedback loop but not by any filtering or 
smoothing). If the sender responded to these signals immediately, as 
Reno or Cubic does, it would be jumping all over the place.

The motivation for this shift of responsibility has always been in 
l4s-arch. But we realized it wasn't mentioned in the draft that focuses 
on the congestion control, so we added a section last Monday: 
draft-ietf-tsvwg-ecn-l4s-id-11#section-4.4 
<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-11#section-4.4>

DCTCP is very similar to Reno code, so that's definitely where you would 
start from. These are the main additions to Reno to get to DCTCP (the 
DCTCP RFC <https://tools.ietf.org/html/rfc8257> desribes these more 
carefully):
1. Measure the ECN (CE) marking feedback per round trip
2. Maintain an Exponentially Weighted Moving Average (EWMA) of that 
(I'll call it alpha)
3. When feedback of a single marking arrives, change the Reno decrease
     OLD: ssthresh = cwnd/2
     NEW: ssthresh = alpha * cwnd /2

That's it, in a nutshell.

Like Reno, after a reduction, DCTCP enters CWR (congestion window 
reduced) state, so it won't do another reduction for a round.
But it continues to count all legitimately cast ECN marks :)
Because it's still doing items 1 and 2 continually.

> It it easy enough to write code that reacts in this fashion, and 
> produce a "tcp-prague" equivalent in QUIC -- much like the "prague.c" 
> code developed for Picoquic. Defining that for QUIC has value: explain 
> how to react based on the ECN counters in QUIC, explain the relation 
> with parameters like pacing rate and maximum burst size. But the 
> problem does not stop there -- the practical requirement is that code 
> behaves well on the Internet as it is.
>

[BB] I'm writing up a draft for iccrg describing the further changes we 
found we had to make from DCTCP to Prague. It is for all transport 
protocols, including QUIC, and there will be protocol-specific notes 
(most about TCP, 'cos it hasn't got the modern feedback machinery that 
newer protocols have). I won't outline all the diffs between Prague & 
DCTCP here, when I could be using the time to write the draft.

> Running on the Internet as is means dealing with the currently 
> deployed zoo of router behaviors. The problem becomes much harder.
>

[BB] Of course. That's what's behind the Prague requirements in 
ecn-l4s-id (and the Linux reference implementation and the draft I'm 
writing give one way they have been addressed). But that's just what we 
know will be problematic before we get to assigning ECT(1) so we can 
test on the real Internet.

> Most implementations will be willing to slow down if they see lots of 
> ECN marks, but when we get to "a small rate of ECN marks" we have a 
> problem. Should we ignore that small rate of marking as L4S suggests? 
> L4S defines "small" as "20 marks or fewer in the last 150 ms". What if 
> other algorithms have different definitions? In presence of a small 
> rate of marking, how do we treat packet losses, or delay increases? Do 
> we have experience of that, end-to-end measurements, telemetry from 
> big deployments? It would be nice if the hypothetic L4S for QUIC draft 

[BB] I don't know where that quote comes from (is it in a draft or 
someone's email?). L4S does not define "a small rate of marking" 
anywhere AFAIK.

Cheers

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 11 Nov 2020 08:09:16 -0600

Just chiming in ...

On Mon, Nov 2, 2020 at 9:46 AM Christian Huitema <[email-masked]>
wrote:

> considering that the QUIC recovery draft is already quite large. But this
> is a later struggle.
>
> examples using different protocols will require a charter update, which at
> best will take some time and add some frustration. It might be much simpler
> to write a short L4S for QUIC draft, but first we would have to decide what
> this draft actually specifies: the current "prague" congestion control,
> defined as a set of changes to RENO; or, a general "congestion response
> guideline", describing how congestion control algorithms are expected to
> react to L4S-style ECN marking.
>
The current charter says "Work on congestion control will describe use of a
standardized congestion controller as a default scheme for QUIC. Defining
new congestion control schemes is explicitly out of scope for this group.
QUIC is expected to support rapid, distributed development and testing of
features."

This is a question for currently serving ADs, but I don't think that
rechartering would be required. if there's a non-Reno standardized
congestion controller, ISTM that would slide right in.

This was the point of having a separate recovery document - so that the
QUIC protocol could include new congestion controllers as they were
developed (and standardized).

Alternatively, someone could suggest rechartering QUIC to relax the
constraint that only standardized congestion controllers would be in scope.
But that's a conversation for another mailing list ... :-)

Best,

Spencer