Subject: Consensus call for Late-Stage documents, pre-IETF 108 edition

From: Lucas Pardue <[email-masked]>
Date: Fri, 21 Aug 2020 00:44:30 +0100

Folks,

The following issues have proposals for resolution, and discussion so far
seems
to support consensus to accept them. If you object, please do so on the
issue or
in response to this message (changing the Subject appropriately!). Absent
any
pushback, we'll direct the editors to incorporate them.

See <https://github.com/quicwg/base-drafts/projects/5> for the current
state of
issues in the Late Stage process, itself defined at
<https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md>.

* #4035: Uncapped ACK Delay and RTT estimates
  The proposal is <https://github.com/quicwg/base-drafts/pull/3874>

* #4001: Offloads should not delay ACKs
  The proposal is <https://github.com/quicwg/base-drafts/pull/4000>

* #3997: QUIC's Initial Congestion Window specification is incorrect
  The proposal is <https://github.com/quicwg/base-drafts/pull/3993>

* #3995: Request forgery attacks
  The proposal is <https://github.com/quicwg/base-drafts/pull/3996>

* #3991: Reserved frame types error
  The proposal is <https://github.com/quicwg/base-drafts/pull/3993>

* #3989: Allow server to enforce post-Retry packet numbering
  The proposal is <https://github.com/quicwg/base-drafts/pull/3990>

* #3980: Processing buffered packets can cause hugely inflated RTT
measurements
  The proposal is <https://github.com/quicwg/base-drafts/pull/3874>

* #3956: Suggest endpoints may recognize acks after loss is declared
  The proposal is <https://github.com/quicwg/base-drafts/pull/3957>

* #3954: HTTP/2 Settings reservation isn't called out
  The proposal is <https://github.com/quicwg/base-drafts/pull/3955>

* #3944: Reno does not require window reduction on loss
  The proposal is <https://github.com/quicwg/base-drafts/pull/3978>

* #3939: It's unclear if persistent congestion is a per-PN-space property
  The proposal is <https://github.com/quicwg/base-drafts/pull/3961>

* #3927: Reset min_rtt on persistent congestion
  The proposal is <https://github.com/quicwg/base-drafts/pull/3975>

* #3892: MUST requirement on bursts smaller than IW is too restrictive
  The proposal is <https://github.com/quicwg/base-drafts/pull/3936>

* #3842: Do I need to reset congestion info when the port changes?
  The proposal is <https://github.com/quicwg/base-drafts/pull/3842>

* #3838: Remove API requirement for resource allocation
  The proposal is <https://github.com/quicwg/base-drafts/pull/3935

* #3821: Desirable behavior when it takes time to derive the traffic keys
for the next PN space
  The proposal is <https://github.com/quicwg/base-drafts/pull/3874>

* #3788: New confidentiality and integrity limits
  The proposal is <https://github.com/quicwg/base-drafts/pull/3789>

* #3765: disable_active_migration with SPA
  The proposal is to close with no action.

Cheers,
Lars, Lucas and Mark
QUIC WG Chairs

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 21 Aug 2020 13:10:21 +0000

For this issue there is still some discussion ongoing:

* #3944: Reno does not require window reduction on loss
  The proposal is <https://github.com/quicwg/base-drafts/pull/3978<https://protect2.fireeye.com/v1/url?k=9a767cbb-c4d6c6d5-9a763c20-861d41abace8-4b48c5854f444e4b&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3978>>

I think the original issue is appropriately addressed by this PR, however, this PR does changes more things.

Mirja

From: QUIC <[email-masked]> on behalf of Lucas Pardue <[email-masked]>
Date: Friday, 21. August 2020 at 01:45
To: QUIC WG <[email-masked]>
Subject: Consensus call for Late-Stage documents, pre-IETF 108 edition

Folks,

The following issues have proposals for resolution, and discussion so far seems
to support consensus to accept them. If you object, please do so on the issue or
in response to this message (changing the Subject appropriately!). Absent any
pushback, we'll direct the editors to incorporate them.

See <https://github.com/quicwg/base-drafts/projects/5<https://protect2.fireeye.com/v1/url?k=21a146de-7f01fcb0-21a10645-861d41abace8-1916916727a00ea4&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fprojects%2F5>> for the current state of
issues in the Late Stage process, itself defined at
<https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md<https://protect2.fireeye.com/v1/url?k=cdc9d61c-93696c72-cdc99687-861d41abace8-afb6d27726416e7b&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fblob%2Fmaster%2FCONTRIBUTING.md>>.

* #4035: Uncapped ACK Delay and RTT estimates
  The proposal is <https://github.com/quicwg/base-drafts/pull/3874<https://protect2.fireeye.com/v1/url?k=3675ac24-68d5164a-3675ecbf-861d41abace8-00da8afd46be54b6&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3874>>

* #4001: Offloads should not delay ACKs
  The proposal is <https://github.com/quicwg/base-drafts/pull/4000<https://protect2.fireeye.com/v1/url?k=bdff62cf-e35fd8a1-bdff2254-861d41abace8-d97bfd9a44e26722&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F4000>>

* #3997: QUIC's Initial Congestion Window specification is incorrect
  The proposal is <https://github.com/quicwg/base-drafts/pull/3993<https://protect2.fireeye.com/v1/url?k=e79f4264-b93ff80a-e79f02ff-861d41abace8-c32c7259fa0c9266&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3993>>

* #3995: Request forgery attacks
  The proposal is <https://github.com/quicwg/base-drafts/pull/3996<https://protect2.fireeye.com/v1/url?k=b8eff897-e64f42f9-b8efb80c-861d41abace8-9666a4a7cf24f32e&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3996>>

* #3991: Reserved frame types error
  The proposal is <https://github.com/quicwg/base-drafts/pull/3993<https://protect2.fireeye.com/v1/url?k=9cac9c48-c20c2626-9cacdcd3-861d41abace8-16d70341b27d6b5d&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3993>>

* #3989: Allow server to enforce post-Retry packet numbering
  The proposal is <https://github.com/quicwg/base-drafts/pull/3990<https://protect2.fireeye.com/v1/url?k=c9ae9651-970e2c3f-c9aed6ca-861d41abace8-ae27dec6a23dd856&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3990>>

* #3980: Processing buffered packets can cause hugely inflated RTT measurements
  The proposal is <https://github.com/quicwg/base-drafts/pull/3874<https://protect2.fireeye.com/v1/url?k=308e1a45-6e2ea02b-308e5ade-861d41abace8-fe5f0e2a256c6985&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3874>>

* #3956: Suggest endpoints may recognize acks after loss is declared
  The proposal is <https://github.com/quicwg/base-drafts/pull/3957<https://protect2.fireeye.com/v1/url?k=e0b38c5c-be133632-e0b3ccc7-861d41abace8-34f3d690e95a884a&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3957>>

* #3954: HTTP/2 Settings reservation isn't called out
  The proposal is <https://github.com/quicwg/base-drafts/pull/3955<https://protect2.fireeye.com/v1/url?k=a0e6d93e-fe466350-a0e699a5-861d41abace8-87503a96c41cb4a9&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3955>>

* #3944: Reno does not require window reduction on loss
  The proposal is <https://github.com/quicwg/base-drafts/pull/3978<https://protect2.fireeye.com/v1/url?k=9a767cbb-c4d6c6d5-9a763c20-861d41abace8-4b48c5854f444e4b&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3978>>

* #3939: It's unclear if persistent congestion is a per-PN-space property
  The proposal is <https://github.com/quicwg/base-drafts/pull/3961<https://protect2.fireeye.com/v1/url?k=1604b587-48a40fe9-1604f51c-861d41abace8-266d5dd69947bcbb&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3961>>

* #3927: Reset min_rtt on persistent congestion
  The proposal is <https://github.com/quicwg/base-drafts/pull/3975<https://protect2.fireeye.com/v1/url?k=0b9d6936-553dd358-0b9d29ad-861d41abace8-9d3bb8a2c70f75b0&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3975>>

* #3892: MUST requirement on bursts smaller than IW is too restrictive
  The proposal is <https://github.com/quicwg/base-drafts/pull/3936<https://protect2.fireeye.com/v1/url?k=3691274a-68319d24-369167d1-861d41abace8-d5d803170cfa0ae9&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3936>>

* #3842: Do I need to reset congestion info when the port changes?
  The proposal is <https://github.com/quicwg/base-drafts/pull/3842<https://protect2.fireeye.com/v1/url?k=0b08f110-55a84b7e-0b08b18b-861d41abace8-63525342bb51e05e&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3842>>

* #3838: Remove API requirement for resource allocation
  The proposal is <https://github.com/quicwg/base-drafts/pull/3935<https://protect2.fireeye.com/v1/url?k=c3313670-9d918c1e-c33176eb-861d41abace8-095668bcaee4c05d&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3935>

* #3821: Desirable behavior when it takes time to derive the traffic keys for the next PN space
  The proposal is <https://github.com/quicwg/base-drafts/pull/3874<https://protect2.fireeye.com/v1/url?k=aba7d2d8-f50768b6-aba79243-861d41abace8-b2fc18f54cf0d25b&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3874>>

* #3788: New confidentiality and integrity limits
  The proposal is <https://github.com/quicwg/base-drafts/pull/3789<https://protect2.fireeye.com/v1/url?k=a2af99b7-fc0f23d9-a2afd92c-861d41abace8-238687af66a800d6&q=1&e=4aeac5ba-3848-4c4b-b240-e8e68f6a264a&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3789>>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 21 Aug 2020 09:07:33 -0700

>   The proposal is <https://github.com/quicwg/base-drafts/pull/3993>

The URL incorrectly points to 3993, should be:
https://github.com/quicwg/base-drafts/pull/3998.
<https://github.com/quicwg/base-drafts/pull/3993>

>   The proposal is <https://github.com/quicwg/base-drafts/pull/3975>

I left a comment on this one. The handling of Min RTT depends largely on
the congestion control protocol. I would definitely not implement the
proposal if using LEDBAT, because resetting Min RTT on congestion would
result in a wrong behavior. It would trick the sender into believing
that the congestion is gone. Other delay based algorithms have similar
issues. But as long as we understand the recovery requirements to only
specify the behavior when implementing RENO, I am fine.

>   The proposal is <https://github.com/quicwg/base-drafts/pull/3842>

The proposal is actually <https://github.com/quicwg/base-drafts/pull/3945>

>   The proposal is to close with no action.

I have reviewed these proposals, approved some and do not object to the
other, even 3975. Left some comments on GitHub.

-- Christian Huitema

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 21 Aug 2020 17:31:55 +0100

Hi Christian,

Thank you for catching the incorrect proposal links and supplying the
correct ones.

Cheers
Lucas

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 22 Aug 2020 15:42:47 -0700

What is the timeline for this consensus call?

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 22 Aug 2020 23:45:45 +0100

Good question,

The consensus call is 1-week in length, from the date of issue (so CoP
August 28).

Lucae

---

From: Lars Eggert <[email-masked]>
Date: Mon, 24 Aug 2020 12:50:35 +0300

Hi,

On 2020-8-21, at 16:10, Mirja Kuehlewind <mirja.kuehlewind=[email-masked]> wrote:
>   The proposal is https://github.com/quicwg/base-drafts/pull/3978
> 

I don't see any discussion on the issue (#3944).

There are some comments on the PR (#3978), however. Which changes specifically do you object to?

Thanks,
Lars

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 24 Aug 2020 12:01:32 +0000

HI Lars,

yes the issue on reduction on loss is actually fine. It's about the change in the PR to use normatively language for  the increase: "MUST NOT increase the congestion window faster". 

There is also the other discussion about when the cwnd should be reset. This is probably a separate issue but it the same text that this PR changes.

Mirja

On 24.08.20, 11:51, "Lars Eggert" <[email-masked]> wrote:

    Hi,

    Thanks,
    Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 24 Aug 2020 16:47:00 +0300

> yes the issue on reduction on loss is actually fine. It's about the change in the PR to use normatively language for  the increase: "MUST NOT increase the congestion window faster".

Thanks for clarifying. Let's see if there are other opinions on this one.

> There is also the other discussion about when the cwnd should be reset. This is probably a separate issue but it the same text that this PR changes.

If it's a separate issue, please file one if we don't have one yet?

Thanks,
Lars

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 24 Aug 2020 13:55:32 +0000

On 24.08.20, 15:47, "Lars Eggert" <[email-masked]> wrote:

Actually not fully sure where we are now, as this discussed started with PR #4005 then moved over to this PR... Ian, should we open a separate issue on this?

Mirja

---

From: Ian Swett <[email-masked]>
Date: Mon, 24 Aug 2020 14:54:09 -0400

On Mon, Aug 24, 2020 at 9:55 AM Mirja Kuehlewind <
[email-masked]> wrote:

>     > yes the issue on reduction on loss is actually fine. It's about the
> change in the PR to use normatively language for  the increase: "MUST NOT
> increase the congestion window faster".
>

I added this due to @Jana Iyengar <[email-masked]> and @Martin Thomson
<[email-masked]> requesting it.  I'm happy to remove the MUST NOT or
make a different adjustment.

>
>     > There is also the other discussion about when the cwnd should be
> reset. This is probably a separate issue but it the same text that this PR
> changes.
>
> Actually not fully sure where we are now, as this discussed started with
> PR #4005 then moved over to this PR... Ian, should we open a separate issue
> on this?
>

This probably deserves its own issue, since it was something noticed in the
the review of #4005.

After thinking about this, I have a slight preference for saying "MUST
reduce the CWND to the ssthresh by the time recovery is exited and
implementations MAY use a variety of mechanisms to reduce bytes in flight,
including reducing it immediately, packet conservation, PRR(RFCXXXX) or
decreasing the pacing rate."

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 24 Aug 2020 18:43:11 -0700

(Splitting from [Re: Consensus call for Late-Stage documents, pre-IETF 108
edition])

    On 2020-8-24, at 15:01, Mirja Kuehlewind <mirja.kuehlewind=
>> [email-masked]> wrote:
I've made my point on the PR there, but that is a requirement of the
congestion controller specified in this document, not for QUIC in general.
The recovery doc specifically says that endpoints can unilaterally choose
other controllers, so I don't understand the issue here.

" This document specifies a congestion controller for QUIC similar to TCP
NewReno ({{?RFC6582}}).

The signals QUIC provides for congestion control are generic and are
designed to support different algorithms. Endpoints can unilaterally choose
a different algorithm to use, such as Cubic ({{?RFC8312}}).

If an endpoint uses a different controller than that specified in this
document, the chosen controller MUST conform to the congestion control
guidelines specified in Section 3.1 of {{!RFC8085}}."

> This probably deserves its own issue, since it was something noticed in
> the the review of #4005.
>

I've responded in detail on the PR there, but the short of it is that we
have agreed to not use RFC 5681 as a normative reference for precisely this
reason -- there's no point in mindlessly reproducing behavior that makes no
sense to reproduce. This is one such case. I'm fine with Ian's proposed
language, FWIW.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 25 Aug 2020 09:47:44 +0100

See below.

On 25/08/2020 02:43, Jana Iyengar wrote:
> (Splitting from [Re: Consensus call for Late-Stage documents, pre-IETF 
> 108 edition])
>
>             On 2020-8-24, at 15:01, Mirja Kuehlewind
>         <mirja.kuehlewind=[email-masked]
>         <mailto:[email-masked]>> wrote:
>             > yes the issue on reduction on loss is actually fine.
>         It's about the change in the PR to use normatively language
>         for  the increase: "MUST NOT increase the congestion window
>         faster".
>
> congestion controller specified in this document, not for QUIC in 
> general. The recovery doc specifically says that endpoints can 
> unilaterally choose other controllers, so I don't understand the issue 
> here.
>
> " This document specifies a congestion controller for QUIC similar to 
> TCP NewReno ({{?RFC6582}}).
>
I think that sentence is already problematic, but I expect well intentioned:

What I mean is: I'm less interested in the similarity with (New)Reno; If 
this is an intention to have "a reaction to detected congestion that is 
similar to Reno TCP" we really need to say that.

> designed to support different algorithms. Endpoints can unilaterally 
> choose a different algorithm to use, such as Cubic ({{?RFC8312}}).
>
Cubic is specified by an RFC, so the example of Cubic seems fine to me.
> guidelines specified in Section 3.1 of {{!RFC8085}}."
This to me, is where to me things start to get more blurry. RFC8085 is 
an important piece - it lists important things to include in a design, 
but does not set specific requirements on what to do.

However, while RFC8085 urges the use of CC, it does not set best current practice for how to design the CC mechanisms.
It defers to RFC2914 - which (I have already said) is woefully in need of revision.
I understood the goal of QUIC's current work was to define a CC that was like Reno for TCP,
while also ensuring the design was not constrained by the way in which TCP evolved.
I think decoupling from TCP means there needs to be some bounds for new CC methods.

>
>             > There is also the other discussion about when the cwnd
>         should be reset. This is probably a separate issue but it the
>         same text that this PR changes.
>
>         Actually not fully sure where we are now, as this discussed
>         started with PR #4005 then moved over to this PR... Ian,
>         should we open a separate issue on this?
>
>
>     This probably deserves its own issue, since it was something
>     noticed in the the review of #4005.
>
>     After thinking about this, I have a slight preference for saying
>     "MUST reduce the CWND to the ssthresh by the time recovery is
>     exited and implementations MAY use a variety of mechanisms to
>     reduce bytes in flight, including reducing it immediately, packet
>     conservation, PRR(RFCXXXX) or decreasing the pacing rate."
>
>
I agree with the intention of this proposed text - BTW: I suspect 
"pacing rate", might be "sending rate" (to me pacing is something else).
> I've responded in detail on the PR there, but the short of it is that 
> we have agreed to not use RFC 5681 as a normative reference for 
> precisely this reason -- there's no point in mindlessly reproducing 
> behavior that makes no sense to reproduce. This is one such case. I'm 
> fine with Ian's proposed language, FWIW.

I know QUIC is different to TCP, and I expect differences in the CC - 
and perhaps fundamental differences in future. I doubt if I would be 
content with the way the proposed changes are currently going (e.g., the 
text on "increases the congestion window" appears to have been cut, 
which seems essential).

However, I think whatever emerges in QUIC needs to be judged against the 
Charter for QUIC, and specifically whether it has met the goal of "Work 
on congestion control will describe use of a standardized congestion 
controller as a default scheme for QUIC." This really needs seeing all 
the CC text at one time and review by the wider transport community who 
work on CC.

Gorry

-- 
G. Fairhurst, School of Engineering

---

From: Lars Eggert <[email-masked]>
Date: Tue, 25 Aug 2020 11:51:06 +0300

Hi,

On 2020-8-25, at 11:47, Gorry Fairhurst <[email-masked]> wrote:
> However, I think whatever emerges in QUIC needs to be judged against the Charter for QUIC, and specifically whether it has met the goal of "Work on congestion control will describe use of a standardized congestion controller as a default scheme for QUIC." This really needs seeing all the CC text at one time and review by the wider transport community who work on CC.

the time for this wider review is now. What would be the best way of getting this done?

Lars

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 25 Aug 2020 11:00:33 +0000

I’m fine with Ian’s proposal as well. Only the examples need some twisting: “including reducing it immediately, packet conservation, PRR(RFCXXXX) or decreasing the pacing rate.“

Reducing it immediately probably needs a warning that this leads to not sending data for half an RTT but then sending it with the same rate as previously.

Packet conservation is the wrong term, for QUIC at least, because QUIC has more accurate feedback. Rate halving is probably still the right term.

PRR is basically rate halving plus handling the case correctly when cwnd falls below ssthresh. I believe that case is handled correctly in the QUC spec already. So probably no need to name it separately.

And decreasing the pacing rate needs probably slightly more words, like: decreasing the pacing compared to the pacing rate when recovery was entered, e.g. halving it in case of NewReno.

Mirja

From: Jana Iyengar <[email-masked]>
Date: Tuesday, 25. August 2020 at 03:43
To: Ian Swett <[email-masked]>
Cc: Mirja Kuehlewind <[email-masked]>, Martin Thomson <[email-masked]>, Lars Eggert <[email-masked]>, QUIC WG <[email-masked]>, Lucas Pardue <[email-masked]>
Subject: Discussion on cwnd reduction text

(Splitting from [Re: Consensus call for Late-Stage documents, pre-IETF 108 edition])

I've made my point on the PR there, but that is a requirement of the congestion controller specified in this document, not for QUIC in general. The recovery doc specifically says that endpoints can unilaterally choose other controllers, so I don't understand the issue here.

" This document specifies a congestion controller for QUIC similar to TCP NewReno ({{?RFC6582}}).

The signals QUIC provides for congestion control are generic and are designed to support different algorithms. Endpoints can unilaterally choose a different algorithm to use, such as Cubic ({{?RFC8312}}).

If an endpoint uses a different controller than that specified in this document, the chosen controller MUST conform to the congestion control guidelines specified in Section 3.1 of {{!RFC8085}}."

This probably deserves its own issue, since it was something noticed in the the review of #4005.

After thinking about this, I have a slight preference for saying "MUST reduce the CWND to the ssthresh by the time recovery is exited and implementations MAY use a variety of mechanisms to reduce bytes in flight, including reducing it immediately, packet conservation, PRR(RFCXXXX) or decreasing the pacing rate."

I've responded in detail on the PR there, but the short of it is that we have agreed to not use RFC 5681 as a normative reference for precisely this reason -- there's no point in mindlessly reproducing behavior that makes no sense to reproduce. This is one such case. I'm fine with Ian's proposed language, FWIW.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 25 Aug 2020 09:23:06 -0700

On 8/25/2020 4:00 AM, Mirja Kuehlewind wrote:
>
> I’m fine with Ian’s proposal as well. Only the examples need some
> twisting: “including reducing it immediately, packet conservation,
> PRR(RFCXXXX) or decreasing the pacing rate.“
>
>  
>
> Reducing it immediately probably needs a warning that this leads to
> not sending data for half an RTT but then sending it with the same
> rate as previously.
>
>  
>
> Packet conservation is the wrong term, for QUIC at least, because QUIC
> has more accurate feedback. Rate halving is probably still the right term.
>
>  
>
> PRR is basically rate halving plus handling the case correctly when
> cwnd falls below ssthresh. I believe that case is handled correctly in
> the QUC spec already. So probably no need to name it separately.
>
>  
>
> And decreasing the pacing rate needs probably slightly more words,
> like: decreasing the pacing compared to the pacing rate when recovery
> was entered, e.g. halving it in case of NewReno.
>
I don't think we need to specify "in the case of new Reno" -- the whole
recovery document is covering the case of New Reno. The recovery draft
documents New Reno fully, so developers that have no other information
can implement that and get a QUIC stack that works reasonably well. On
the other hand, there is broad consensus that implementation may very
well deploy new congestion control algorithms if they see fit. The
requirements set in the recovery document explicitly do not apply to
these other congestion control algorithms.

I don't know whether we need broad requirements on the congestion
control algorithms, but if we do these requirements belong in the
transport draft, not the recovery draft. Also, they need to be expressed
in general terms, such as "reducing rate" or "reducing the congestion
window", without referencing New Reno specific concepts like "ssthresh".

-- Christian Huitema

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 25 Aug 2020 17:22:25 -0700

I've changed the text in the PR based on this discussion and the one in the
PR. I think it captures necessary changes, but I'm happy to take more
changes if needed.

On the question of whether we should require a specific congestion
controller -- we can require it all we want, but deployments are already
doing other things. We are doing what we believe to be sensible:
- provide a good default, and
- point to RFC 8085 as a backstop.

This is what the recovery doc attempts to do.

If we don't have a general backstop to provide, that's not fixable in the
recovery doc. Gorry and I have had this conversation, and we realized that
we are missing a document here; but that's a missing piece that we need to
write separately. In the meantime, I think what we have is good enough.

Requiring broad congestion control guards that we don't know how to
articulate is not a problem that the WG should be solving at this stage.

On Tue, Aug 25, 2020 at 9:28 AM Christian Huitema <[email-masked]>
wrote:

> Reducing it immediately probably needs a warning that this leads to not
> sending data for half an RTT but then sending it with the same rate as
> previously.
>
>
>
> Packet conservation is the wrong term, for QUIC at least, because QUIC has
> more accurate feedback. Rate halving is probably still the right term.
>
>
>
> PRR is basically rate halving plus handling the case correctly when cwnd
> falls below ssthresh. I believe that case is handled correctly in the QUC
> spec already. So probably no need to name it separately.
>
>
>
> And decreasing the pacing rate needs probably slightly more words, like:
> decreasing the pacing compared to the pacing rate when recovery was
> entered, e.g. halving it in case of NewReno.
>
> documents New Reno fully, so developers that have no other information can
> implement that and get a QUIC stack that works reasonably well. On the
> other hand, there is broad consensus that implementation may very well
> deploy new congestion control algorithms if they see fit. The requirements
> set in the recovery document explicitly do not apply to these other
> congestion control algorithms.
>
> I don't know whether we need broad requirements on the congestion control
> algorithms, but if we do these requirements belong in the transport draft,
> not the recovery draft. Also, they need to be expressed in general terms,
> such as "reducing rate" or "reducing the congestion window", without
> referencing New Reno specific concepts like "ssthresh".
>
> -- Christian Huitema
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Aug 2020 11:57:32 -0700

>  The proposal is <https://github.com/quicwg/base-drafts/pull/3996>

I think this text misses several potential attack modalities. I added
some comments that we probably need to discuss.

>   The proposal is <https://github.com/quicwg/base-drafts/pull/3990>

I don't object to this particular decision, but I would have assumed
that you could always abort a connection whenever the peer violates a
MUST, and the decision to have a MAY here potentially implies otherwise.
Is that not a correct interpretation of the spec.

>   The proposal is <https://github.com/quicwg/base-drafts/pull/3789>

Sent an editorial change.

-Ekr

---

From: Marten Seemann <[email-masked]>
Date: Sat, 29 Aug 2020 10:43:41 +0700

I agree with Ekr regarding 3990, and I don't think this PR adds any value.
I'd be unhappy if we had to add a statement saying "An endpoint MAY abort
the connection if the peer violated this particular MUST" after every
single MUST that we have in the document.

---

From: Ian Swett <[email-masked]>
Date: Sat, 29 Aug 2020 17:15:15 -0400

I updated the PR(link
<https://github.com/quicwg/base-drafts/pull/3978/files/04f523dccd5f87a88847dcf4034b96283b0bac6f..08e4abb131f757b6c9b220ad5c305efefdf77e89>)
today to move the case of sending one packet immediately when halving the
CWND into a separate paragraph about ways to reduce the CWND during
recovery.  I think it reads more clearly now and sending one packet
immediately is less of a special case.  PTAL.

This doesn't substantively change the approach in my opinion, and I thought
the PR was otherwise very good.

Thanks, Ian

On Tue, Aug 25, 2020 at 8:22 PM Jana Iyengar <[email-masked]> wrote:

> I've changed the text in the PR based on this discussion and the one in
> the PR. I think it captures necessary changes, but I'm happy to take more
> changes if needed.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 31 Aug 2020 09:52:15 +1000

> some comments that we probably need to discuss.

Both of the items you raise are already addressed in the pull request.  It appears as though this is just editorial feedback regarding structure.

1. You point out that Retry presents a server with an opportunity to control the Destination Connection ID in Initial packets.  This is explicitly addressed here:

> Sending a Retry packet ({{packet-retry}}) offers a server the option to change the Token field. After sending a Retry, the server can also control the Destination Connection ID field of subsequent Initial packets from the client. [...] However, the exchange of a Retry packet validates the server's address, thereby preventing the use of subsequent Initial packets for request forgery.

2. The plaintext of a message can be controlled, which can be used to influence ciphertext.  This is explicitly addressed in generic text preceding this:

> There are no measures in this version of QUIC to prevent indirect control over the encrypted portions of packets. [...]

Do you think that this is incorrect, misleading, or insufficient?

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 31 Aug 2020 06:02:06 -0700

Sorry, I seem to have missed these.

With that said, I think the combination of this tight control of the
contents of the packet and the behavior specified in S 9.3 is quite
problematic. As I understand it, an attacker can set up a connection then
forge an apparent migration with the source address of the victim. A
complaint endpoint (per 9.3) can then send to that address up to the
minimum congestion window (S 9.3.1). And because the attacker effectively
controls the contents of the packet, this means that they are able to
transmit to the victim. This seems like a fairly dangerous set of
properties, and I'm starting to think we should consider some in-protocol
some countermeasures.

-Ekr

On Sun, Aug 30, 2020 at 4:52 PM Martin Thomson <[email-masked]> wrote:

> Both of the items you raise are already addressed in the pull request.  It
> appears as though this is just editorial feedback regarding structure.
>
> 1. You point out that Retry presents a server with an opportunity to
> control the Destination Connection ID in Initial packets.  This is
> explicitly addressed here:
>
> > Sending a Retry packet ({{packet-retry}}) offers a server the option to
> change the Token field. After sending a Retry, the server can also control
> the Destination Connection ID field of subsequent Initial packets from the
> client. [...] However, the exchange of a Retry packet validates the
> server's address, thereby preventing the use of subsequent Initial packets
> for request forgery.
>
> 2. The plaintext of a message can be controlled, which can be used to
> influence ciphertext.  This is explicitly addressed in generic text
> preceding this:
>
> > There are no measures in this version of QUIC to prevent indirect
> control over the encrypted portions of packets. [...]
>

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 31 Aug 2020 14:26:36 +0100

> properties, and I'm starting to think we should consider some in-protocol

Hi EKR,

Can you please clarify if you're happy for us to proceed with the proposal
in #3996? It sounds like we can create separate follow-up items to consider
the points you mention.

Cheers
Lucas

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 31 Aug 2020 07:23:22 -0700

> in #3996? It sounds like we can create separate follow-up items to consider

I'm not sure I understand the question. I think the text is more or less OK
in terms of documenting the attack, but it doesn't address the issue
itself, which is about what to do about the attack.

-Ekr

Cheers

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 31 Aug 2020 16:13:33 +0100

On Mon, Aug 31, 2020 at 3:23 PM Eric Rescorla <[email-masked]> wrote:

>> Can you please clarify if you're happy for us to proceed with the
>> proposal in #3996? It sounds like we can create separate follow-up items to
>> consider the points you mention.
>>
>
> I'm not sure I understand the question. I think the text is more or less
> OK in terms of documenting the attack, but it doesn't address the issue

The original issue is https://github.com/quicwg/base-drafts/pull/3995, in
which MT says " I'm proposing that we simply document the risks and add
some small mitigations provided that they don't cost much.". It sounds like
you're not satisfied with the mitigations in PR 3996. I'm trying to
understand if this is sufficient pushback to prevent us landing the changes
at this time or if it would be reasonable to follow up with additional
issues /proposals.

Cheers
Lucas

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 31 Aug 2020 08:16:45 -0700

On Mon, Aug 31, 2020 at 8:13 AM Lucas Pardue <[email-masked]>
wrote:

> you're not satisfied with the mitigations in PR 3996.
>

Or at least I'm not sure I am satisfied.

I'm trying to understand if this is sufficient pushback to prevent us
> landing the changes at this time or if it would be reasonable to follow up
> with additional issues /proposals.
>

I think we need an open issue to track whether we ought do more in terms of
mitigations, so I don't think this text should close this issue. I don't
much care whether we land this text in the meantime.

-Ekr

---

From: Martin Duke <[email-masked]>
Date: Mon, 31 Aug 2020 08:39:34 -0700

I found ekr's exact words here describing the attack to be a lot more clear
about the threat model. The PR as it stands uses more abstract language
that I found harder to follow. In particular, calling this a "request"
forgery in this case muddies the waters.

On Mon, Aug 31, 2020 at 6:03 AM Eric Rescorla <[email-masked]> wrote:

>> Both of the items you raise are already addressed in the pull request.
>> It appears as though this is just editorial feedback regarding structure.
>>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 31 Aug 2020 09:00:47 -0700

I wanted to add that there is a pretty straightforward mitigation for the
false migration version of this (sorry if this was suggested on the thread,
but I don't recall): prior to having validated the address, the sender
prepends a random value M to the packet (e.g., between the number and the
payload). M is used to randomize the ciphertext [0]. We can borrow a bit
from the reserved bits in the header to indicate this and because it only
needs to be done prior to probing, overhead should be acceptably low. This
only addresses the forged content attack not the forged DCID attack, though
if we were serious we could actually provide a defense against that as well
by having *all* pre-validation packets have a randomizer; this would be a
larger change, of course.

-Ekr

[0] Details matter here, but for the purposes of this discussion, assume
that we use it to key a cipher that is used to superencrypt the payload and
authentication tag.

On Mon, Aug 31, 2020 at 8:39 AM Martin Duke <[email-masked]> wrote:

> I found ekr's exact words here describing the attack to be a lot more
> clear about the threat model. The PR as it stands uses more
> abstract language that I found harder to follow. In particular, calling
> this a "request" forgery in this case muddies the waters.
>
>>> > Sending a Retry packet ({{packet-retry}}) offers a server the option
>>> to change the Token field. After sending a Retry, the server can also
>>> control the Destination Connection ID field of subsequent Initial packets
>>> from the client. [...] However, the exchange of a Retry packet validates
>>> the server's address, thereby preventing the use of subsequent Initial
>>> packets for request forgery.
>>>

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 31 Aug 2020 11:35:01 -0700

Thanks, Ian, I like this -- it simplifies things!

On Sat, Aug 29, 2020 at 2:15 PM Ian Swett <[email-masked]> wrote:

> This doesn't substantively change the approach in my opinion, and I
> thought the PR was otherwise very good.
>
> Thanks, Ian
>
>>> control algorithms, but if we do these requirements belong in the transport
>>> draft, not the recovery draft. Also, they need to be expressed in general
>>> terms, such as "reducing rate" or "reducing the congestion window", without

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 1 Sep 2020 01:11:49 +0100

Hi Folks,

The consensus call has ended.

Most proposals, unless mentioned below, received no pushback and we can
declare that they have consensus.

Proposals 3945 and 3990 received some comments but we think we're close to
addressing those and that they'll have consensus very soon.

Proposal 3996 appears to need a little more time, so we'll run that one
through the Late Stage Process again.

Cheers
Lucas
On behalf of the QUIC WG Chairs

---

From: Christian Huitema <[email-masked]>
Date: Mon, 31 Aug 2020 21:31:48 -0700

On 8/31/2020 9:00 AM, Eric Rescorla wrote:

> I wanted to add that there is a pretty straightforward mitigation for
> the false migration version of this (sorry if this was suggested on
> the thread, but I don't recall): prior to having validated the
> address, the sender prepends a random value M to the packet (e.g.,
> between the number and the payload). M is used to randomize the
> ciphertext [0]. We can borrow a bit from the reserved bits in the
> header to indicate this and because it only needs to be done prior to
> probing, overhead should be acceptably low. This only addresses the
> forged content attack not the forged DCID attack, though if we were
> serious we could actually provide a defense against that as well by
> having *all* pre-validation packets have a randomizer; this would be a

A "defensive" peer can also advance the sequence number by some random
value before sending packets to a not-yet-validated address. As the
sequence number is injected in the IV, this will make the ciphertext
much harder to predict without causing a lot of transmission overhead.

-- Christian Huitema

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 01 Sep 2020 16:42:51 +1000

Let's not try to design a complicated solution for a problem that is - as yet theoretical.  As I said when I raised the issue, I'm not aware of any service that might be vulnerable in this way.

Ekr's suggested design is good, but it is more complexity, and it requires a fairly significant amount of surgery for a case that will not be exercised often.  We would have to find extra bits in the header, define new fields, and then apply additional processing to packets.  If this were TCP, I'd argue we have to do something; TCP full of boxes that apply the Robustness Principle well beyond its intended meaning.  For UDP, we have no direct evidence of attack.

In addition, as noted, the worst attack is the spoofed migration, which only affects server deployments.  My expectation is that servers will be more able to implement defenses for adjacent services before deploying QUIC.  A note in the manageability or applicability documents regarding this might help if someone were so inclined. 

I'm going to propose being much clearer about the fact that we're not designing a robust defense against request forgery attacks into the protocol.  We could, following the suggested design, but I would prefer to finish the protocol than spend another few months doing that.

> much harder to predict without causing a lot of transmission overhead.

You need to skip at least N^2 packets where N is the number of attempts the peer might have to perform a spoofing attack.  Right now, that number is based on the initial window, or maybe the existing congestion window, plus maybe some packets sent on PTO, which is to say ¯\(°_o)/¯.  And with small safety margins, you probably need extra to guard against multiple tries.  Our packet numbers only go to 2^32, which gives us less than 2^30 as a maximum gap, and so we have much less entropy than we typically require for path validation (2^64 is our baseline for both ODCID and PATH_CHALLENGE).