Subject: [quicwg/base-drafts] Mention every Transport Parameter in section on values for 0-RTT (#3756)

From: Nick Harper <[email-masked]>
Date: Wed, 10 Jun 2020 14:01:50 -0700

The section for &quot;Values of Transport Parameters for 0-RTT&quot; specifies
which parameters a client MUST or MUST NOT remember. It does not do the
same for a server. (It implies that ones a client MUST NOT remember also
don&#39;t need to be remembered by a server, and it lists a subset of the
remaining as ones the server MUST remember.) This commit adds the
remaining parameters to a list that the server need not remember.

Fixes #3755 
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3756

-- Commit Summary --

  * Mention every Transport Parameter in section on values for 0-RTT

-- File Changes --

    M draft-ietf-quic-transport.md (10)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3756.patch
https://github.com/quicwg/base-drafts/pull/3756.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756

---

From: David Schinazi <[email-masked]>
Date: Wed, 10 Jun 2020 15:46:24 -0700

@DavidSchinazi approved this pull request.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#pullrequestreview-428478972

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Jun 2020 16:57:45 -0700

@martinthomson commented on this pull request.

The reason that this is left unstated is the problem I've identified below.  I would prefer not to do this.

> @@ -1749,6 +1749,16 @@ values for 0-RTT.  This includes initial_max_data and either
 initial_max_streams_bidi and initial_max_stream_data_bidi_remote, or
 initial_max_streams_uni and initial_max_stream_data_uni.
 
+When accepting 0-RTT data, a server may set values for the following parameters

```suggestion
When accepting 0-RTT data, a server MAY set values for the following parameters
```
?

> @@ -1749,6 +1749,16 @@ values for 0-RTT.  This includes initial_max_data and either
 initial_max_streams_bidi and initial_max_stream_data_bidi_remote, or
 initial_max_streams_uni and initial_max_stream_data_uni.
 
+When accepting 0-RTT data, a server may set values for the following parameters
+that are smaller than the values remembered by the client. Because the previous
+values set for these parameters do not affect what values can be set when
+accepting 0-RTT data, it is not necessary that the server be able to recover the
+values it previously sent.
+
+* max_idle_timeout
+* max_udp_payload_size

But this does affect 0-RTT.  Though we accepted @kazuho's argument that this manifests in a fashion indistinguishable from a change in Path MTU, that doesn't mean that changing it has no consequence, as this text implies.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#pullrequestreview-428504751

---

From: Nick Harper <[email-masked]>
Date: Wed, 10 Jun 2020 17:34:44 -0700

@nharper commented on this pull request.

What transport parameters a server sends cannot, as currently specified, affect 0-RTT, because a client MUST only use remembered transport parameters when sending 0-RTT packets. If changing the max_udp_payload_size does somehow affect 0-RTT, then we need to revisit more of the 0-RTT Transport Parameter handling.

As currently specified, there is no prohibition on the server changing (including reducing) the max_udp_payload_size when accepting 0-RTT. As far as I can figure out, the only implication for accepting 0-RTT and reducing max_udp_payload_size is that some 0-RTT packets might get lost. If the server remembers this parameter, it could choose to reject 0-RTT which explicitly signals to the client to retransmit all frames. The server (whether or not it remembers this parameter) could also accept 0-RTT, process whichever packets get through, and let the client's loss/recovery algorithm retransmit frames. It seems like we end up at the same place either way, possibly with different performance characteristics.

What I'm trying to say is "it is not a requirement to remember parameters on this list". I'm not trying to say "don't remember parameters on this list".

Should we add some language here to state that a server may wish to remember some of these?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#discussion_r438475514

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 10 Jun 2020 17:45:55 -0700

@kazuho commented on this pull request.

I think it might be a good idea to change the reasoning to something like: "Because the previous values set for these parameters do not affect what can be carried by 0-RTT packets"

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#discussion_r438482537

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 15 Jun 2020 14:18:22 -0700

@janaiyengar commented on this pull request.

How about something like this: "While changing the value of these parameters can degrade performance of this connection, the connection is expected to proceed correctly. It is therefore acceptable for the server to not recover the values it previously sent."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#discussion_r440452630

---

From: Nick Harper <[email-masked]>
Date: Mon, 15 Jun 2020 14:21:32 -0700

Something like that sounds reasonable. I'll work on wording to say something along those lines and "your implementation is not incorrect if it chooses not to remember those values, but there may be optimizations that could involve remembering them".

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#discussion_r440454153

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 15 Jun 2020 14:27:00 -0700

Whether this is an optimization or not depends on the implementations in question. Basically, I think this boils down to what do we want default behavior to be. I would suggest saying that there could be performance penalties for not remembering them, simply because a server that doesn't remember max_udp_payload_size but drops packets that are larger will cause perf penalties.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#discussion_r440456616

---

From: David Schinazi <[email-masked]>
Date: Mon, 15 Jun 2020 21:35:04 -0700

@DavidSchinazi commented on this pull request.

Can someone provide an example of how remembering max_udp_payload_size can lead to an optimization? I’m failing to see how remembering it can provide benefits

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#discussion_r440580607

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Jun 2020 21:39:44 -0700

If the number is large relative to the PMTU, then there is no benefit.  If the client remembers PMTU it might choose to attempt 0-RTT using the same PMTU.  That allows for a larger congestion window and more data transferred in 0-RTT.  That might be more requests, which is a tiny benefit at best.

However, if the server forgets the max_udp_payload_size, and has a lower value now than the remembered PMTU, those 0-RTT packets will be dropped as they arrive.  If the server accepts 0-RTT in that case without considering the effect of max_udp_payload_size, then all those packets will be considered by the client to be lost.  The client will tell its congestion controller and reduce the congestion window.  Rather than staying in slow start, the client will exit very early and performance will be terrible.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#discussion_r440581742

---

From: David Schinazi <[email-masked]>
Date: Tue, 16 Jun 2020 09:52:33 -0700

Ah thanks @martinthomson that makes sense! Based on that I agree that mentioning this could help.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#discussion_r440999782

---

From: Nick Harper <[email-masked]>
Date: Wed, 17 Jun 2020 16:26:12 -0700

@nharper pushed 1 commit.

2a269e6058b7ff8494bed7ba4b19c7529aed1c75  Mention every Transport Parameter in section on values for 0-RTT

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756/files/b801abbc45f1d153e8efcb22e3450d47a06e95f6..2a269e6058b7ff8494bed7ba4b19c7529aed1c75

---

From: Nick Harper <[email-masked]>
Date: Wed, 17 Jun 2020 16:28:55 -0700

Thanks all for the comments on this. I reworded this paragraph choosing not to mention whether changing these values can affect 0-RTT data, and explicitly mentioned the perf impact. (I also added an RFC 2119 "OPTIONAL".)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#discussion_r441887311

---

From: David Schinazi <[email-masked]>
Date: Wed, 17 Jun 2020 17:23:14 -0700

I like the latest text!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#pullrequestreview-432860573

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Jun 2020 18:28:48 -0700

Works for me.

> +It is OPTIONAL for a server to be able to recover the previously sent values of
+the max_idle_timout, max_udp_payload_size, and disable_active_migration
+parameters. Lowering the values of these parameters while also accepting 0-RTT

I know that OPTIONAL and RECOMMENDED are in RFC 2119, but they encourage the passive voice, .

```suggestion
A server MAY choose to recover the previously sent values of the
max_idle_timout, max_udp_payload_size, and disable_active_migration parameters
and reject 0-RTT if it selects smaller values.
Lowering the values of these parameters while also accepting 0-RTT
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#pullrequestreview-432879783

---

From: Marten Seemann <[email-masked]>
Date: Wed, 17 Jun 2020 20:15:03 -0700

@marten-seemann commented on this pull request.

> @@ -1749,6 +1749,13 @@ values for 0-RTT.  This includes initial_max_data and either
 
+It is OPTIONAL for a server to be able to recover the previously sent values of
+the max_idle_timout, max_udp_payload_size, and disable_active_migration
+parameters. Lowering the values of these parameters while also accepting 0-RTT
+data could degrade the performance of the connection. Specifically, lowering the

How does lowering the `max_idle_timeout` degrade the performance of the connection (unless you lower it to a value smaller than the time it takes the client to receive the new transport parameters)?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#pullrequestreview-432911716

---

From: Nick Harper <[email-masked]>
Date: Thu, 18 Jun 2020 11:25:40 -0700

I agree that active voice is better than passive voice. However, I think this suggested change changes the meaning slightly: saying the "server MAY choose to recover" refers to the server making a choice at the time it would be recovering, while "OPTIONAL for a server to be able to recover" refers to the server making a choice at the time it is storing (or otherwise encoding) parameters to be able to recover at a future point in time. I'm trying to be more clear that the option (whether active voice MAY or passive voice OPTIONAL) is when storing the transport parameters, not when recovering.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#discussion_r442419954

---

From: Nick Harper <[email-masked]>
Date: Thu, 18 Jun 2020 11:31:59 -0700

Of the listed parameters, I _think_ `max_udp_payload_size` is the only one that if decreased could lead to performance degradation. I don't think the others have been analyzed as carefully, so I went for a (possibly over) broad statement.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#discussion_r442423323

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 18 Jun 2020 13:11:41 -0700

Modulo the editorial nit, this LGTM.

Change "MAY choose to recover" to "MAY store and recover". @nharper, any other way of making this active is also good.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#pullrequestreview-433612199

---

From: Nick Harper <[email-masked]>
Date: Thu, 18 Jun 2020 13:51:22 -0700

"MAY choose to store and recover" sounds good to me.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#discussion_r442495120

---

From: Nick Harper <[email-masked]>
Date: Thu, 18 Jun 2020 13:54:33 -0700

e3d689f947ba0bc0a5e11db287b0038fec36e743  Use active voice and mention why the server might remember these values

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756/files/2a269e6058b7ff8494bed7ba4b19c7529aed1c75..e3d689f947ba0bc0a5e11db287b0038fec36e743

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 18 Jun 2020 15:21:44 -0700

> @@ -1749,12 +1749,13 @@ values for 0-RTT.  This includes initial_max_data and either
 
-It is OPTIONAL for a server to be able to recover the previously sent values of
-the max_idle_timout, max_udp_payload_size, and disable_active_migration
-parameters. Lowering the values of these parameters while also accepting 0-RTT
-data could degrade the performance of the connection. Specifically, lowering the
-max_udp_payload_size could result in dropped packets leading to worse
-performance compared to rejecting 0-RTT data outright.
+A server MAY choose to store and recover the previously sent values of the

```suggestion
A server MAY store and recover the previously sent values of the
```

> +max_idle_timout, max_udp_payload_size, and disable_active_migration parameters
+and reject 0-RTT if it selects smaller values. Lowering the values of these

This new phrase "reject 0-RTT if it selects smaller values" is confusing. What are you trying to convey?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#pullrequestreview-433684136

---

From: Nick Harper <[email-masked]>
Date: Thu, 18 Jun 2020 15:29:44 -0700

That was from MT's suggestion. It's saying how the server might use the remembered values. It might be redundant with the following sentence - I don't care either way whether it's here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#discussion_r442535951

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Jun 2020 15:53:00 -0700

"if the server chooses values for the resumed connection that are smaller than the original connection." ?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#discussion_r444551247

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 23 Jun 2020 15:53:14 -0700

@janaiyengar pushed 1 commit.

8f453832bdc72e7ad64502c8598bfa64e81ba439  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756/files/e3d689f947ba0bc0a5e11db287b0038fec36e743..8f453832bdc72e7ad64502c8598bfa64e81ba439

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 23 Jun 2020 15:53:41 -0700

> @@ -1749,6 +1749,14 @@ values for 0-RTT.  This includes initial_max_data and either
 
+A server MAY store and recover the previously sent values of the

```suggestion
A server MAY store and recover previously sent values of the
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#pullrequestreview-436213692

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 23 Jun 2020 15:56:07 -0700

I think the sentence is fine. I don't know why I was unable to parse it last time.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#discussion_r444552380

---

From: Nick Harper <[email-masked]>
Date: Tue, 23 Jun 2020 16:06:28 -0700

This still looks good with the latest commit Jana pushed.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#issuecomment-648473178

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 23 Jun 2020 16:08:48 -0700

Merged #3756 into master.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3756#event-3475134546