Subject: [quicwg/base-drafts] Fix handling of Retry in recovery (#3148)

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Oct 2019 21:06:32 -0700

This section was well out of date.  Also, this covers what needs to be
retained across this transition better.  Basically, the only thing that
needs to go is the congestion and loss recovery state.  The rest can
stay; in fact, the crypto handshake has to stay.

Closes #2058.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Fix handling of Retry in recovery

-- File Changes --

    M draft-ietf-quic-recovery.md (28)

-- Patch Links --

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 24 Oct 2019 05:45:21 -0700

mikkelfj commented on this pull request.

> +## Handling Retry Packets
+
+A Retry packet causes a client to send another Initial packet, effectively
+restarting the connection process.  A Retry packet indicates that the Initial
+was received, but not processed.  A Retry packet cannot be treated as an
+acknowledgment.
+
+Clients that receive a Retry packet reset congestion control and loss recovery
+state, including resetting any pending timers.  Other connection state, in
+particular cryptographic handshake messages, is retained; see Section 17.2.5 of
+{{QUIC-TRANSPORT}}.
+
+The client MAY compute an RTT estimate to the server as the time period from
+when the first Initial was sent to when a Retry or a Version Negotiation packet
+is received.  The client MAY use this value in place of its default for the
+initial RTT estimate.

If the Retry moves from a server in Melbourne to Chicago, the RTT estimate might not be worth much. Since this could be common use of Retry, I'm not sure this advice is sound. But perhaps I'm missing something?

-- 
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/3148#pullrequestreview-306543049

---

From: ianswett <[email-masked]>
Date: Thu, 24 Oct 2019 06:56:28 -0700

ianswett approved this pull request.

Thanks, nice update!

> -
-A Retry or Version Negotiation packet causes a client to send another Initial
-packet, effectively restarting the connection process and resetting congestion
-control and loss recovery state, including resetting any pending timers.  Either
-packet indicates that the Initial was received but not processed.  Neither
-packet can be treated as an acknowledgment for the Initial.
-
-The client MAY however compute an RTT estimate to the server as the time period
-from when the first Initial was sent to when a Retry or a Version Negotiation
-packet is received.  The client MAY use this value to seed the RTT estimator for
-a subsequent connection attempt to the server.
+## Handling Retry Packets
+
+A Retry packet causes a client to send another Initial packet, effectively
+restarting the connection process.  A Retry packet indicates that the Initial
+was received, but not processed.  A Retry packet cannot be treated as an

```suggestion
was received, but not processed.  A Retry packet MUST NOT be treated as an
```

+

Given how IP routing works, accomplishing what you're suggesting would be quite difficult, but I agree there are cases this isn't perfect.  But it's typically better than any other available value, including the 1 second default.

-- 
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/3148#pullrequestreview-306591837

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Oct 2019 19:40:43 -0700

@martinthomson pushed 1 commit.

3a6f65f82156772609b98c180809db4230c06aac  cannot/MUST NOT

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

---

From: ianswett <[email-masked]>
Date: Tue, 29 Oct 2019 22:57:32 +0000 (UTC)

Merged #3148 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/3148#event-2754087652

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 29 Oct 2019 17:14:49 -0700

janaiyengar commented on this pull request.

+

@mikkelfj's point, IIUC, is that connection ID based routing within your server infrastructure could route your new Initial to a server that is far off. I think this is a legitimate use case, but using this sample as the initial RTT value is fine I'd argue, even if it is wrong some times. It is not expected to be the common case, and you replace it in the RTT estimate with the first actual measured value anyways.

-- 
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/3148#discussion_r340383833

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Oct 2019 20:57:38 -0700

martinthomson commented on this pull request.

+

I tend to agree.  I note that the goal would ordinarily to pick a server that is closer to the client.  In those cases, this will just produce a different overestimation of RTT.  Hopefully it is still less than 1 second.

-- 
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/3148#discussion_r340422202