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

From: ianswett <[email-masked]>
Date: Tue, 11 Feb 2020 10:10:37 -0800

@ianswett pushed 1 commit.

91ced9e8d46e8d9b4a649f106bb5fd555b2fa818  Kazuho comments and remove one sentence

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/1ae98696a9afd8bd6adbe62661ec2adc74b02c14..91ced9e8d46e8d9b4a649f106bb5fd555b2fa818

---

From: ianswett <[email-masked]>
Date: Tue, 11 Feb 2020 10:13:52 -0800

ianswett commented on this pull request.

Thanks Kazuho, I made some minor updates, but can make further ones if you think they're needed.

> @@ -519,6 +519,26 @@ 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 packets prior to obtaining Handshake
+keys it may assume some or all of the server's Initial packets were lost.

True, suggestion taken.

> @@ -519,6 +519,26 @@ 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 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. A client MAY send an ack-eliciting packet with no
+CRYPTO data if all Initial data has been acknowledged.  The PTO can only be
+shortened once in this way. Subsequently, the PTO uses the normal calculation
+with exponential backoff.

Good question.  It is aimed at the case when there are no RTT estimates, but I think there are a few cases like the one you're outlining where speeding up retransmission of the Initial2 data from a standard PTO is sensible, even if the server gets an ACK of Initial1.  The PTO in this case is expected to be 3*RTT (SRTT + 4*RTTVar) vs 1*RTT if you follow this optimization.  Given that, any suggestions on changes?

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

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 11 Feb 2020 15:48:46 -0800

janaiyengar commented on this pull request.

> @@ -519,6 +519,25 @@ bytes.

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

```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.
 
+### 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.

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

> @@ -519,6 +519,25 @@ bytes.
 
+### 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.
 
+### 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.
 
+### 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.
 
+### 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
```

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

---

From: ianswett <[email-masked]>
Date: Sat, 15 Feb 2020 07:21:12 -0800

fcfa095f3c0a11cd02e001464820ff8e3d515d99  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/91ced9e8d46e8d9b4a649f106bb5fd555b2fa818..fcfa095f3c0a11cd02e001464820ff8e3d515d99

---

From: ianswett <[email-masked]>
Date: Sat, 15 Feb 2020 07:21:47 -0800

e3b814daa3fb57bddf8f60b4a2d2033c5dd99f14  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/fcfa095f3c0a11cd02e001464820ff8e3d515d99..e3b814daa3fb57bddf8f60b4a2d2033c5dd99f14

---

From: ianswett <[email-masked]>
Date: Sat, 15 Feb 2020 07:22:05 -0800

0c9c2f7f291ccc9633e7c9480a83833dc1f2b72c  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/e3b814daa3fb57bddf8f60b4a2d2033c5dd99f14..0c9c2f7f291ccc9633e7c9480a83833dc1f2b72c

---

From: ianswett <[email-masked]>
Date: Sat, 15 Feb 2020 07:23:11 -0800

2274b69508676e286b5b8ad3ba126f5d9dbd0846  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/0c9c2f7f291ccc9633e7c9480a83833dc1f2b72c..2274b69508676e286b5b8ad3ba126f5d9dbd0846

---

From: ianswett <[email-masked]>
Date: Sat, 15 Feb 2020 07:25:00 -0800

acd4454394249a7337718ead9fad7258b183b01f  Jana's suggestions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/2274b69508676e286b5b8ad3ba126f5d9dbd0846..acd4454394249a7337718ead9fad7258b183b01f

---

From: ianswett <[email-masked]>
Date: Sat, 15 Feb 2020 07:45:47 -0800

3b52d6f468e18aac7a8f0e51a820d0b64f23f2f3  Reflow Jana's suggestions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/acd4454394249a7337718ead9fad7258b183b01f..3b52d6f468e18aac7a8f0e51a820d0b64f23f2f3

---

From: ianswett <[email-masked]>
Date: Sat, 15 Feb 2020 09:01:29 -0800

da005487a8a902c672f362aab1d43263941f0ef8  More like Jana's first suggestion

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/3b52d6f468e18aac7a8f0e51a820d0b64f23f2f3..da005487a8a902c672f362aab1d43263941f0ef8

---

From: martinduke <[email-masked]>
Date: Sat, 15 Feb 2020 12:37:29 -0800

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

---

From: martinduke <[email-masked]>
Date: Sat, 15 Feb 2020 12:41:01 -0800

martinduke requested changes on this pull request.

> @@ -519,6 +519,24 @@ bytes.
 
+### Speeding Up Handshake Completion
+
+When a server receives an Initial packet containing duplicate CRYPTO data,
+it can assume the client did not receive all of the server's CRYPTO data sent
+in Initial packets, 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.

What is the consequence of the client assuming server initials were lost? What would it do in this case to speed up the handshake?

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

---

From: ianswett <[email-masked]>
Date: Wed, 19 Feb 2020 15:02:10 -0800

The client sending a packet can trigger this mechanism if the server implements it and it ensures the server is not blocked by the amplification factor.  I could add more detail in the second paragraph if it's helpful?

-- 
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#discussion_r381597621

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Feb 2020 15:25:45 -0800

martinthomson commented on this pull request.

I like the first paragraph.  I'd lose the second.

+### Speeding Up Handshake Completion
+
+When a server receives an Initial packet containing duplicate CRYPTO data,
+it can assume the client did not receive all of the server's CRYPTO data sent
+in Initial packets, 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 up handshake completion under these conditions, an endpoint MAY send
+a packet containing unacknowledged CRYPTO data earlier than the PTO expiry,
+subject to address validation limits. (see Section 8.1 of {{QUIC-TRANSPORT}})

```suggestion
subject to address validation limits; see Section 8.1 of {{QUIC-TRANSPORT}}.
```

> +Peers can also use coalesced packets to ensure that each datagram elicits at least
+one acknowledgement.  For example, clients can coalesce an Initial packet
+containing PING and PADDING frames with a 0-RTT data packet and a server can
+coalesce an Initial packet containing a PING frame with one or more packets in
+its first flight.

I'm not sure about this paragraph.  It is implying something about packet composition into datagrams that is inconsistent with our general approach.

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

---

From: ianswett <[email-masked]>
Date: Wed, 26 Feb 2020 19:59:17 -0800

28959f9e29563bd0e7dff9185d760a8c1fb0175b  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/da005487a8a902c672f362aab1d43263941f0ef8..28959f9e29563bd0e7dff9185d760a8c1fb0175b

---

From: ianswett <[email-masked]>
Date: Wed, 26 Feb 2020 20:02:22 -0800

Thanks, I'm hoping to write text that's consistent with our approach(ie: one should not assume anything about other QUIC packets that happen to be in the same datagram) and yet note that implementations may want to bundle a small packet(ie: a PING) along with another packet in order to ensure one of the two receives an acknowledgement.  Feel free to suggest clearer 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/3080#discussion_r384902427

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Feb 2020 05:33:33 -0800

I guess that I misread it, but here is an alternative...

An endpoint can coalesce packet from multiple packet number spaces with a probe. This allows the peer can drive loss recovery even when it is unable to process some packet types. Endpoints can include a PING frame in packets from spaces other than the one that caused the probe to be 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/3080#discussion_r385127395

---

From: martinduke <[email-masked]>
Date: Thu, 27 Feb 2020 16:51:56 -0800

martinduke commented on this pull request.

Wait, do you mean "receives and successfully decrypts Handshake or 1-RTT", or I just get something that is marked as such?

-- 
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#discussion_r385454136