Subject: Consensus Calls for Late Stage Documents

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 Jan 2020 14:56:58 +1100

Happy New Year, Working Group.

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 late next week.

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

* #3274: Encrypting Retry token
   The proposal is <https://github.com/quicwg/base-drafts/issues/3274>

* #3247: I am concerned the congestion control text is too permissive.
   The proposal is <https://github.com/quicwg/base-drafts/pull/3248>

* #3245: Make RFC 6928 normative
   The proposal is <https://github.com/quicwg/base-drafts/pull/3287>

* #3244: Can we make a normative ref to  RFC8085?
   The proposal is <https://github.com/quicwg/base-drafts/pull/3248>

* #3243: Add caution when using IW10 and fragmentation 
   The proposal is <https://github.com/quicwg/base-drafts/pull/3280>

* #3152: Client storage of tokens should be independent of other stored state
   The proposal is <https://github.com/quicwg/base-drafts/pull/3150>

* #3142: It is unspecified how a server sends Handshake packets during / after migration
   The proposal is <https://github.com/quicwg/base-drafts/pull/3145>

* #3094: congestion window increase on every ACKed packet could result in bursty sends
   The proposal is <https://github.com/quicwg/base-drafts/pull/3232>

* #3014: Handling of corrupt Retry packets
   The proposal is <https://github.com/quicwg/base-drafts/issues/3274>

* #2863: unrecoverable loss pattern leads to deadlock
   The proposal is <https://github.com/quicwg/base-drafts/pull/3145>

* #2789: Use a higher seed RTT for new paths
   The proposal is to close with no action.

* #2744: Idle Timer Can Fire Even with Outstanding Data to Send
   The proposal is <https://github.com/quicwg/base-drafts/pull/3266>

* #2602: Idle timeout needs more description and a recommendation
   The proposal is <https://github.com/quicwg/base-drafts/pull/3099>

--
Mark Nottingham   https://www.mnot.net/

---

From: Ian Swett <[email-masked]>
Date: Mon, 6 Jan 2020 17:30:54 -0500

Thanks for the call, all these resolutions look great to me, but I think
the PR is incorrect for the two Retry issues.

On Sun, Jan 5, 2020 at 10:57 PM Mark Nottingham <[email-masked]> wrote:

> 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 late next week.
>
> 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>.
>
I believe the proposal is https://github.com/quicwg/base-drafts/pull/3120

>    The proposal is <https://github.com/quicwg/base-drafts/issues/3274>
Also https://github.com/quicwg/base-drafts/pull/3120

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Jan 2020 10:14:14 +1100

Correct - sorry about that, my jet lag is obviously not quite finished.

Cheers,

> On 7 Jan 2020, at 9:30 am, Ian Swett <[email-masked]> wrote:
> 
> Thanks for the call, all these resolutions look great to me, but I think the PR is incorrect for the two Retry issues.
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Jan 2020 15:09:30 -0800

> I believe the proposal is https://github.com/quicwg/base-drafts/pull/3120

I added some editorial comments here but I can live with the substantive
outcome,

The rest of these look fine.

-Ekr

---

From: Vidhi Goel <[email-masked]>
Date: Wed, 15 Jan 2020 13:46:42 -0800

Hi Mark,

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

We would like to hold off on this change as we are working on specifying Pacing mechanism which would allow the implementations to decouple congestion window increase from sending rate and thus eliminate the need for 2MSS limit during slow start.
Below is the PR:
https://github.com/quicwg/base-drafts/pull/3351 <https://github.com/quicwg/base-drafts/pull/3351>

I will create a issue to start the discussion.

Thanks,
Vidhi

> On Jan 5, 2020, at 7:56 PM, Mark Nottingham <[email-masked]> wrote:
>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 Jan 2020 14:16:05 -0800

Vidhi,

The current draft already recommends use of a pacer, and your PR 3351
suggests a mechanism that an endpoint can use for doing it. That still
doesn't obviate the earlier need to specify a requirement for endpoints
that do not implement any pacing.

Basically, codifying an example pacer does not change the premise of PR
3232 - that implementations might choose to not pace.

Said differently, even if we were to specify one way of pacing, as PR 3351
does, PR 3232 still applies. I don't think we need to hold off on PR 3232
based on PR 3351.

- jana

On Wed, Jan 15, 2020 at 1:47 PM Vidhi Goel <vidhi_goel=
[email-masked]> wrote:

> We would like to hold off on this change as we are working on specifying
> Pacing mechanism which would allow the implementations to decouple
> congestion window increase from sending rate and thus eliminate the need
> for 2MSS limit during slow start.
> Below is the PR:
> https://github.com/quicwg/base-drafts/pull/3351
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 15 Jan 2020 14:25:47 -0800

> On Jan 15, 2020, at 2:16 PM, Jana Iyengar <[email-masked]> wrote:
> 
> Vidhi,
> 
> The current draft already recommends use of a pacer, and your PR 3351 suggests a mechanism that an endpoint can use for doing it. That still doesn't obviate the earlier need to specify a requirement for endpoints that do not implement any pacing.
> 
> Basically, codifying an example pacer does not change the premise of PR 3232 - that implementations might choose to not pace.
> 
> Said differently, even if we were to specify one way of pacing, as PR 3351 does, PR 3232 still applies. I don't think we need to hold off on PR 3232 based on PR 3351.

We can discuss more on the issues/PRs, but one quick note on why we'd like to hold off on merging anything just yet:

In our testing, the specific solution described in #3232 can actually cause some issues with underutilizing the link that are undesirable. Beyond that, it still leaves edge cases open in which burst can still occur, which is the problem originally described in #3094. The new PR is describing another approach to solve #3094.

The main spirit of the new PR is noting that the main problem with non-pacing implementations being too bursty is that the burst limit specified in the pacing section today gives a byte limit, but no time limit. It should be sufficient to specify some bounds on the delay between bursts to solve the problem described in #3094, without locking implementations into a specific congestion-control relationship with the number of ack packets (not just acked bytes as it is today).

Best,
Tommy

> 
> - jana
> 
> On Wed, Jan 15, 2020 at 1:47 PM Vidhi Goel <vidhi_goel=[email-masked] <mailto:[email-masked]>> wrote:
> Hi Mark,
> 
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3232 <https://github.com/quicwg/base-drafts/pull/3232>>
> 
>> On Jan 5, 2020, at 7:56 PM, Mark Nottingham <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> See <https://github.com/quicwg/base-drafts/projects/5 <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 <https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md>>.
>> 
>>   The proposal is <https://github.com/quicwg/base-drafts/issues/3274 <https://github.com/quicwg/base-drafts/issues/3274>>
>> 
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3248 <https://github.com/quicwg/base-drafts/pull/3248>>
>> 
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3287 <https://github.com/quicwg/base-drafts/pull/3287>>
>> 
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3248 <https://github.com/quicwg/base-drafts/pull/3248>>
>> 
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3280 <https://github.com/quicwg/base-drafts/pull/3280>>
>> 
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3150 <https://github.com/quicwg/base-drafts/pull/3150>>
>> 
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3145 <https://github.com/quicwg/base-drafts/pull/3145>>
>> 
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3232 <https://github.com/quicwg/base-drafts/pull/3232>>
>> 
>>   The proposal is <https://github.com/quicwg/base-drafts/issues/3274 <https://github.com/quicwg/base-drafts/issues/3274>>
>> 
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3145 <https://github.com/quicwg/base-drafts/pull/3145>>
>> 
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3266 <https://github.com/quicwg/base-drafts/pull/3266>>
>> 
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3099 <https://github.com/quicwg/base-drafts/pull/3099>>
>> 
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/ <https://www.mnot.net/>
>> 
>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 Jan 2020 14:42:56 -0800

Tommy,

The draft currently says that senders SHOULD pace, and PR 3351 gets into
more detailed guidance for a sender that does not follow our
recommendation. I have questions about the specific guidance in that PR,
but more to the point here, the wg was clear in Singapore that we should
not do more pseudo-code for cases we don't recommend. Description of more
mechanism for cases that are not recommended falls in a similar category.

PR 3232 is meant to be a safety mechanism to protect a network from a
sender that does not follow our recommendation to pace. I'm not opposed to
making such a sender performant, but it seems to me that we do not need to
get into this in the spec.

Perhaps it might help if we added a note about how a non-paced sender might
encounter performance issues?

- jana

On Wed, Jan 15, 2020 at 2:26 PM Tommy Pauly <[email-masked]> wrote:

> We can discuss more on the issues/PRs, but one quick note on why we'd like
> to hold off on merging anything just yet:
>
> In our testing, the specific solution described in #3232 can actually
> cause some issues with underutilizing the link that are undesirable. Beyond
> that, it still leaves edge cases open in which burst can still occur, which
> is the problem originally described in #3094. The new PR is describing
> another approach to solve #3094.
>
> The main spirit of the new PR is noting that the main problem with
> non-pacing implementations being too bursty is that the burst limit
> specified in the pacing section today gives a byte limit, but no time
> limit. It should be sufficient to specify some bounds on the delay between
> bursts to solve the problem described in #3094, without locking
> implementations into a specific congestion-control relationship with the
> number of ack packets (not just acked bytes as it is today).
>
> Best,
> Tommy
>
>
> - jana
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 15 Jan 2020 15:01:38 -0800

Hi Jana,

That definitely makes sense that we don't want to spend too much time in the text on a non-recommended case, such as not pacing. Let's use the new PR to discuss any text reworking that can get closer to that goal, while clarifying the recommendations.

With regards to #3232, one of the things we found in testing was that it could (a) still allow an implementation to be vulnerable to too much bursting (the original problem), but more importantly (b) locked receivers into an ack pattern of acking every other packet. My main concern is that this causes problems if receivers want to experiment with and change acking strategies going forward in way that otherwise would be fine.

Best,
Tommy

> On Jan 15, 2020, at 2:42 PM, Jana Iyengar <[email-masked]> wrote:
> 
> Tommy,
> 
> The draft currently says that senders SHOULD pace, and PR 3351 gets into more detailed guidance for a sender that does not follow our recommendation. I have questions about the specific guidance in that PR, but more to the point here, the wg was clear in Singapore that we should not do more pseudo-code for cases we don't recommend. Description of more mechanism for cases that are not recommended falls in a similar category.
> 
> PR 3232 is meant to be a safety mechanism to protect a network from a sender that does not follow our recommendation to pace. I'm not opposed to making such a sender performant, but it seems to me that we do not need to get into this in the spec.
> 
> Perhaps it might help if we added a note about how a non-paced sender might encounter performance issues?
> 
> - jana
> 
> On Wed, Jan 15, 2020 at 2:26 PM Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Jan 15, 2020, at 2:16 PM, Jana Iyengar <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Vidhi,
>>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 Jan 2020 15:11:09 -0800

Tommy,

Responses inline.

That definitely makes sense that we don't want to spend too much time in
> the text on a non-recommended case, such as not pacing. Let's use the new
> PR to discuss any text reworking that can get closer to that goal, while
> clarifying the recommendations.
>

SG.

> With regards to #3232, one of the things we found in testing was that it
> could (a) still allow an implementation to be vulnerable to too much
> bursting (the original problem), but more importantly (b) locked receivers
> into an ack pattern of acking every other packet. My main concern is that
> this causes problems if receivers want to experiment with and change acking
> strategies going forward in way that otherwise would be fine.
>

These are good points, thank you for raising them. If the PR does not help
with the original problem, I'm ok with holding off on merging. I'm much
less convinced that we need to specify anything as elaborate as PR 3351,
however.

I'm curious to understand more about your testing -- do you want to
continue this discussion on the original issue (3094) so we can find a way
forward?

- jana

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 15 Jan 2020 15:14:18 -0800

> On Jan 15, 2020, at 3:11 PM, Jana Iyengar <[email-masked]> wrote:
> 
> Tommy,
> 
> Responses inline.
> 
> These are good points, thank you for raising them. If the PR does not help with the original problem, I'm ok with holding off on merging. I'm much less convinced that we need to specify anything as elaborate as PR 3351, however. 
> 
> I'm curious to understand more about your testing -- do you want to continue this discussion on the original issue (3094) so we can find a way forward?

Sure, let's use the initial issue (#3094) for discussion!

Tommy

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Jan 2020 14:39:09 +1000

Seeing no pushback, consensus is declared for all but #3094, where discussion will continue.

> On 6 Jan 2020, at 1:56 pm, Mark Nottingham <[email-masked]> wrote:
>