Re: [quicwg/base-drafts] Retransmit server initial upon second Initial (#3080)

[Jana Iyengar <[e-mail]>]

janaiyengar commented on this pull request.



> @@ -519,6 +519,25 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
 
+### Speeding Handshake Completion
+
+When a server receives duplicate Initial CRYPTO data, it can assume the client

```suggestion
When a server receives an Initial packet containing duplicate data in a CRYPTO frame, it can assume the client
```

> @@ -519,6 +519,25 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
 
+### Speeding Handshake Completion
+
+When a server receives duplicate Initial CRYPTO data, it can assume the client
+did not receive all Initial CRYPTO data or the client's estimated RTT is too

```suggestion
did not receive all of the server's CRYPTO data sent in Initial packets, or the client's estimated RTT is too
```

> @@ -519,6 +519,25 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
 
+### Speeding Handshake Completion
+
+When a server receives duplicate Initial CRYPTO data, it can assume the client
+did not receive all Initial CRYPTO data or the client's estimated RTT is too
+small. When a client receives Handshake or 1-RTT packets prior to obtaining
+Handshake keys it may assume some or all of the server's Initial packets were
+lost.
+
+To speed handshake completion, either peer MAY send a packet containing

```suggestion
To speed up handshake completion under these conditions, an endpoint MAY send a packet containing
```

> @@ -519,6 +519,25 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
 
+### Speeding Handshake Completion

```suggestion
### Speeding Up Handshake Completion
```

> @@ -519,6 +519,25 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
 
+### Speeding Handshake Completion
+
+When a server receives duplicate Initial CRYPTO data, it can assume the client
+did not receive all Initial CRYPTO data or the client's estimated RTT is too
+small. When a client receives Handshake or 1-RTT packets prior to obtaining
+Handshake keys it may assume some or all of the server's Initial packets were
+lost.
+
+To speed handshake completion, either peer MAY send a packet containing
+unacknowledged Initial CRYPTO data subject to the path validation limits, as

```suggestion
unacknowledged CRYPTO data, subject to path validation limits, earlier than the PTO period.
```

> @@ -519,6 +519,25 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
 
+### Speeding Handshake Completion
+
+When a server receives duplicate Initial CRYPTO data, it can assume the client
+did not receive all Initial CRYPTO data or the client's estimated RTT is too
+small. When a client receives Handshake or 1-RTT packets prior to obtaining
+Handshake keys it may assume some or all of the server's Initial packets were
+lost.
+
+To speed handshake completion, either peer MAY send a packet containing
+unacknowledged Initial CRYPTO data subject to the path validation limits, as
+though the PTO expired. The PTO MUST only be shortened once in this way.

```suggestion
```

> @@ -519,6 +519,25 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
 
+### Speeding Handshake Completion
+
+When a server receives duplicate Initial CRYPTO data, it can assume the client
+did not receive all Initial CRYPTO data or the client's estimated RTT is too
+small. When a client receives Handshake or 1-RTT packets prior to obtaining
+Handshake keys it may assume some or all of the server's Initial packets were
+lost.
+
+To speed handshake completion, either peer MAY send a packet containing
+unacknowledged Initial CRYPTO data subject to the path validation limits, as
+though the PTO expired. The PTO MUST only be shortened once in this way.
+Subsequently, the PTO uses the normal calculation with exponential backoff.

```suggestion
```

> @@ -519,6 +519,25 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
 
+### Speeding Handshake Completion
+
+When a server receives duplicate Initial CRYPTO data, it can assume the client
+did not receive all Initial CRYPTO data or the client's estimated RTT is too
+small. When a client receives Handshake or 1-RTT packets prior to obtaining
+Handshake keys it may assume some or all of the server's Initial packets were
+lost.
+
+To speed handshake completion, either peer MAY send a packet containing
+unacknowledged Initial CRYPTO data subject to the path validation limits, as
+though the PTO expired. The PTO MUST only be shortened once in this way.
+Subsequently, the PTO uses the normal calculation with exponential backoff.
+
+Peers can also use coalesced packets to ensure each datagram elicits at least

```suggestion
Peers can also use coalesced packets to ensure that each datagram elicits at least
```

> +### Speeding Handshake Completion
+
+When a server receives duplicate Initial CRYPTO data, it can assume the client
+did not receive all Initial CRYPTO data or the client's estimated RTT is too
+small. When a client receives Handshake or 1-RTT packets prior to obtaining
+Handshake keys it may assume some or all of the server's Initial packets were
+lost.
+
+To speed handshake completion, either peer MAY send a packet containing
+unacknowledged Initial CRYPTO data subject to the path validation limits, as
+though the PTO expired. The PTO MUST only be shortened once in this way.
+Subsequently, the PTO uses the normal calculation with exponential backoff.
+
+Peers can also use coalesced packets to ensure each datagram elicits at least
+one acknowledgement.  For example, clients can coalesce an Initial packet
+containing a PING and PADDING with 0-RTT data packets and a server can

```suggestion
containing PING and PADDING frames with a 0-RTT data packet and a server can
```

> +
+When a server receives duplicate Initial CRYPTO data, it can assume the client
+did not receive all Initial CRYPTO data or the client's estimated RTT is too
+small. When a client receives Handshake or 1-RTT packets prior to obtaining
+Handshake keys it may assume some or all of the server's Initial packets were
+lost.
+
+To speed handshake completion, either peer MAY send a packet containing
+unacknowledged Initial CRYPTO data subject to the path validation limits, as
+though the PTO expired. The PTO MUST only be shortened once in this way.
+Subsequently, the PTO uses the normal calculation with exponential backoff.
+
+Peers can also use coalesced packets to ensure each datagram elicits at least
+one acknowledgement.  For example, clients can coalesce an Initial packet
+containing a PING and PADDING with 0-RTT data packets and a server can
+coalesce an Initial packet containing a PING with one or more packets in

```suggestion
coalesce an Initial packet containing a PING frame with one or more packets in
```

-- 
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/3080#pullrequestreview-357073829