Subject: [quicwg/base-drafts] Refine Discussion of 0-RTT Transport Parameters (#2467)

From: martinduke <[email-masked]>
Date: Thu, 14 Feb 2019 14:56:12 -0800

Fixes #2464, but there are some value judgments here. I believe the new layout is much clearer for implementers.

I made max_packet_size optional for reasons that I think are self-evident. I thought saving max_ack_delay might be useful for clients setting loss timers on their 0-RTT stuff. Everything else is required or forbidden.

Per @MikeBishop's suggestion, I put all the new TPs in the required category.

I also specified behavior when the EE msg omits a TP. I thought it would be simpler for servers that spit out a standard set of TPs to do things that way.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Refine Discussion of 0-RTT Transport Parameters

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2467.patch
https://github.com/quicwg/base-drafts/pull/2467.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/2467

---

From: Mike Bishop <[email-masked]>
Date: Thu, 14 Feb 2019 15:42:53 -0800

MikeBishop approved this pull request.

Looks reasonable to me.  I'm not opposed to @ianswett's suggestion that lets future transport parameters decide whether they need to be remembered or not, either.

> -A server MAY accept 0-RTT and subsequently provide different values for
-transport parameters for use in the new connection.  If 0-RTT data is accepted
-by the server, the server MUST NOT reduce any limits or alter any values that
-might be violated by the client with its 0-RTT data.  In particular, a server
-that accepts 0-RTT data MUST NOT set values for the following parameters
-({{transport-parameter-definitions}}) that are smaller
-than the remembered value of those parameters.
+The value of the server's previous original_connection_id, preferred_address,
+stateless_reset_token, and ack_delay_exponent MUST NOT be used when
+establishing a new connection; rather, the client should wait to observe the
+server's new values in the handshake.
+
+The client MAY store the server's original max_ack_delay and max_packet_size
+transport parameters. The server MAY accept 0-RTT and subsequently provide
+different values for these transport parameters for use in the new connection.
+The client MUST use these values after acknowledging them. If the server does

```suggestion
The client MUST use these values after the handshake completes. If the server does
```
...modulo any rewrapping needed from line-length changes.

> +establishing a new connection; rather, the client should wait to observe the
+server's new values in the handshake.
+
+The client MAY store the server's original max_ack_delay and max_packet_size
+transport parameters. The server MAY accept 0-RTT and subsequently provide
+different values for these transport parameters for use in the new connection.
+The client MUST use these values after acknowledging them. If the server does
+not provide a new value, the client MUST use the default value.
+
+A client that attempts to send 0-RTT data MUST remember all other transport
+parameters used by the server, including new transport parameters
+({{new-transport-parameters}}) that it is able to process. The server can
+remember these transport parameters, or store an integrity-protected copy of
+the values in the ticket and recover the information when accepting 0-RTT
+data. A server uses the transport parameters in determining whether to accept
+0-RTT data.

I think this comment about the server remembering needs to be paired with the prohibition on the server reducing values.  Since you've split out the "in particular" ones already, it might be reasonable to say that the server must not reduce limits / alter values in the transport parameters the client is required to remember.

This is especially true if we go with Ian's suggestion to require future transport parameter definitions to specify which remembering category they fall in.

>  A server MUST either reject 0-RTT data or abort a handshake if the implied
 values for transport parameters cannot be supported.
 
-
-### New Transport Parameters
+### New Transport Parameters {#new-transport-parameters}

Technically unnecessary, since that's the auto-generated anchor anyway.  But it doesn't hurt anything.

-- 
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/2467#pullrequestreview-204018138

---

From: martinduke <[email-masked]>
Date: Thu, 14 Feb 2019 15:44:24 -0800

@martinduke pushed 1 commit.

9d26bb01b3bf2f4b2a20aec931471bdc62f2c8e2  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/2467/files/c0aaf2b6d35bf65c8220c4525092de86a1d9bf73..9d26bb01b3bf2f4b2a20aec931471bdc62f2c8e2

---

From: martinduke <[email-masked]>
Date: Thu, 14 Feb 2019 15:59:05 -0800

1dd258aced8e9861e11e395a916dc575d189c3e8  changed handling of new TPs

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2467/files/9d26bb01b3bf2f4b2a20aec931471bdc62f2c8e2..1dd258aced8e9861e11e395a916dc575d189c3e8

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Feb 2019 15:59:49 -0800

martinthomson commented on this pull request.

I've come to realize that this is the right answer, but we need to be more principled about this.  Can we categorize things better, maybe add a column to the table we use to list transport parameters even.

If we do use the table, I would move it from the IANA considerations to this section.

>  ### Values of Transport Parameters for 0-RTT {#zerortt-parameters}
 
-A client that attempts to send 0-RTT data MUST remember the transport parameters
-used by the server.  The transport parameters that the server advertises during
-connection establishment apply to all connections that are resumed using the
-keying material established during that handshake.  Remembered transport
+The transport parameters that the server advertises during connection
+establishment generally apply to all connections that are resumed using

"generally" is a little to squishy a word to use here.  I'd prefer to be crisp:

> The value of transport parameters from a connection are remembered and apply to any 0-RTT packets that are sent in subsequent connections that are resumed from that connection, except for those transport parameters that are explicitly excluded.  Remembered transport parameters apply to the new connection until the handshake completes and the client starts sending 1-RTT packets.  Once the handshake completes, the client uses the transport parameters established in the handshake.
>
> Any transport parameter that does not or cannot apply to 0-RTT packets does not need to be remembered.  This includes max_ack_delay, <list>.  Any transport parameter that applies to the connection as a whole does not need to be remembered.  This includes disable_migration, <list>.  Endpoints are not obligated to remember and use unknown transport parameters.

Then I think we can tabulate transport parameters and add a "0-RTT" column, indicating whether it applies to 0-RTT or not.

> -when accepting 0-RTT data.  A server uses the transport parameters in
-determining whether to accept 0-RTT data.
-

max_packet_size is important.  That is the one in addition to the flow control stuff that needs to be respected.

> -when accepting 0-RTT data.  A server uses the transport parameters in
-determining whether to accept 0-RTT data.
-

max_ack_delay is not needed for 0-RTT, though it can help in loss recovery, it's a value that can change.

-- 
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/2467#pullrequestreview-204030041

---

From: martinduke <[email-masked]>
Date: Thu, 14 Feb 2019 16:30:52 -0800

martinduke commented on this pull request.

I figure the client always has the option of using 1200B packets until the handshake's done.

-- 
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/2467#discussion_r257067007

---

From: martinduke <[email-masked]>
Date: Thu, 14 Feb 2019 16:32:15 -0800

The client may find it useful to retain this information to set its 0-RTT loss timer properly, rather than having to wait for the handshake and reset it properly. Am I not thinking clearly on how this is done?

-- 
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/2467#discussion_r257067314

---

From: martinduke <[email-masked]>
Date: Thu, 14 Feb 2019 16:33:29 -0800

I like this wording. I'll try go get to this in the next few days.

-- 
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/2467#discussion_r257067548

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Feb 2019 17:19:02 -0800

The client can do that for Handshake and Initial, but not 1-RTT.  0-RTT should follow the same rules though.

No, you are right.  I think that what you have is fine for that one.

-- 
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/2467#discussion_r257075528

---

From: Martin Thomson <[email-masked]>
Date: Fri, 15 Feb 2019 00:58:44 -0800

I realize now what bothered me about max_ack_delay.  This is not something you use in 0-RTT, but it is something you might remember in the same way you might remember the RTT.  It's not guaranteed to be good, but it is certainly better than the defaults for return connections.  You should remove this from this section and maybe add it where we talk about remembering the RTT (if we do that, it's late and I couldn't find it).

-- 
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/2467#discussion_r257149892

---

From: martinduke <[email-masked]>
Date: Fri, 15 Feb 2019 07:33:08 -0800

Why don't you use it in 0RTT? You have to set the loss detection timer, which involves using peer max_ack_delay. If I read the recovery draft correctly?

I made it optional because I suppose someone could update the timer based on the new TPs. The more I think about it, better to just save it.

-- 
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/2467#discussion_r257280088

---

From: martinduke <[email-masked]>
Date: Fri, 15 Feb 2019 07:35:11 -0800

I don't understand your comment. The safe thing to do is to send 0-RTT at 1280 until a new probe can be sent. I can also understand the opposite choice, which is why this is a MAY.

-- 
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/2467#discussion_r257280913

---

From: martinduke <[email-masked]>
Date: Fri, 15 Feb 2019 15:57:17 +0000 (UTC)

b07ac2036b9b2d67b52aa78f28b8357edc9a475a  Adopted some of MT's rewording

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2467/files/1dd258aced8e9861e11e395a916dc575d189c3e8..b07ac2036b9b2d67b52aa78f28b8357edc9a475a

---

From: Martin Thomson <[email-masked]>
Date: Sun, 17 Feb 2019 11:32:53 -0800

The point of max_packet_size is to limit the size of packets.  I realize that if you are making a new connection, the limit applies only to 1-RTT packets because Initial and Handshake packets are sent without knowing what the limits are (the server could comply with a request to send smaller Handshake packets, and maybe the client could also, but it's not something we can guarantee).  However, when sending 0-RTT, you know what the limit was, so why not respect it?

-- 
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/2467#discussion_r257519311

---

From: Martin Thomson <[email-masked]>
Date: Sun, 17 Feb 2019 12:18:21 -0800

A few suggestions, but I like this.  Maybe I will do the tabulation thing later.

-determining whether to accept 0-RTT data.
-
-A server MAY accept 0-RTT and subsequently provide different values for
-transport parameters for use in the new connection.  If 0-RTT data is accepted
-by the server, the server MUST NOT reduce any limits or alter any values that
-might be violated by the client with its 0-RTT data.  In particular, a server
-that accepts 0-RTT data MUST NOT set values for the following parameters
-({{transport-parameter-definitions}}) that are smaller
-than the remembered value of those parameters.
+Clients remember the value of transport parameters from a server and apply
+them to any 0-RTT packets that are sent in subsequent connections, except
+for transport parameters that are explicitly excluded. Remembered transport
+parameters apply to the new connection until the handshake completes and the
+client starts sending 1-RTT packets. Once the handshake completes, the client
+uses the transport parameters established in thehandshake.

```suggestion
uses the transport parameters established in the handshake.
```

> -than the remembered value of those parameters.
+Clients remember the value of transport parameters from a server and apply
+them to any 0-RTT packets that are sent in subsequent connections, except
+for transport parameters that are explicitly excluded. Remembered transport
+parameters apply to the new connection until the handshake completes and the
+client starts sending 1-RTT packets. Once the handshake completes, the client
+uses the transport parameters established in thehandshake.
+
+The value of the server's previous original_connection_id, preferred_address,
+stateless_reset_token, and ack_delay_exponent MUST NOT be used when
+establishing a new connection; rather, the client should wait to observe the
+server's new values in the handshake. If the server does not provide a new
+value, the client MUST use the default value.
+
+The client MAY store the server's original max_packet_size transport
+parameter.

```suggestion
```

-than the remembered value of those parameters.
+Clients remember the value of transport parameters from a server and apply
+them to any 0-RTT packets that are sent in subsequent connections, except
+for transport parameters that are explicitly excluded. Remembered transport
+parameters apply to the new connection until the handshake completes and the
+client starts sending 1-RTT packets. Once the handshake completes, the client
+uses the transport parameters established in thehandshake.
+
+The value of the server's previous original_connection_id, preferred_address,
+stateless_reset_token, and ack_delay_exponent MUST NOT be used when
+establishing a new connection; rather, the client should wait to observe the
+server's new values in the handshake. If the server does not provide a new
+value, the client MUST use the default value.
+
+The client MAY store the server's original max_packet_size transport

```suggestion
```

+The definition of new transport parameters ({{new-transport-parameters}}) MUST
+specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A client need
+not store a transport parameter it cannot process.
+
+A client that attempts to send 0-RTT data MUST remember all other transport
+parameters used by the server. The server can remember these transport
+parameters, or store an integrity-protected copy of the values in the ticket
+and recover the information when accepting 0-RTT data. A server uses the
+transport parameters in determining whether to accept 0-RTT data.
+
+If 0-RTT data is accepted by the server, the server MUST NOT reduce any
+limits or alter any values that might be violated by the client with its
+0-RTT data.  In particular, a server that accepts 0-RTT data MUST NOT set
+values for the following parameters ({{transport-parameter-definitions}})
+that are smaller than the remembered value of those parameters.

```suggestion
that are smaller than the remembered value of those parameters:
```

-A server MAY accept 0-RTT and subsequently provide different values for
-transport parameters for use in the new connection.  If 0-RTT data is accepted
-by the server, the server MUST NOT reduce any limits or alter any values that
-might be violated by the client with its 0-RTT data.  In particular, a server
-that accepts 0-RTT data MUST NOT set values for the following parameters
-({{transport-parameter-definitions}}) that are smaller
-than the remembered value of those parameters.
+Clients remember the value of transport parameters from a server and apply
+them to any 0-RTT packets that are sent in subsequent connections, except
+for transport parameters that are explicitly excluded. Remembered transport
+parameters apply to the new connection until the handshake completes and the
+client starts sending 1-RTT packets. Once the handshake completes, the client
+uses the transport parameters established in thehandshake.
+
+The value of the server's previous original_connection_id, preferred_address,

I think that maybe this paragraph can be moved after the one starting with "The definition of"

-- 
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/2467#pullrequestreview-204578050

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Feb 2019 19:25:24 -0800

kazuho 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/2467#pullrequestreview-206644695

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 21 Feb 2019 19:35:36 -0800

janaiyengar commented on this pull request.

One editorial suggestion.

Editorial rewrite suggestion:  "A client MUST NOT use remembered values for the following parameters: original_connection_id, preferred_address, stateless_reset_token, ack_delay_exponent.  The client MUST use the server's new values in the handshake instead, and absent new values from the server, the default value."

-- 
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/2467#pullrequestreview-206645202