Subject: [quicwg/base-drafts] It is unspecified how a server should send Handshake packets during / after migration (#3142)

From: Kazuho Oku <[email-masked]>
Date: Wed, 23 Oct 2019 19:25:29 -0700

At the moment, each endpoint reaches handshake confirmed by it's own.

That means that, a client might confirm the handshake and initiate a migration, and that migration might complete, while the server is transmitting Handshake packets, in case the 1-RTT acks sent by the client is repeatedly lost. This is a possibility, as we do not require 1-RTT acks to be bundled with packets carrying PATH_CHALLENGE or PATH_RESPONSE frames.

However, we do not specify if the path used for sending Handshake packets migrate or continue to use the old path. In case it is the former, we also need to specify how the server fills in the SCID field of the Handshake packets it sends.

-- 
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/issues/3142

---

From: ianswett <[email-masked]>
Date: Wed, 23 Oct 2019 19:36:29 -0700

I think there is a key principle we've previously agreed upon.

The 5-tuple doesn't change during the handshake.  That means we should not send Handshake packets down the new path.

-- 
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/issues/3142#issuecomment-545715695

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 23 Oct 2019 20:21:15 -0700

@ianswett 
> The 5-tuple doesn't change during the handshake. That means we should not send Handshake packets down the new path.

I agree.

Assuming that is the case, we need to define a mechanism that allows the server to drop Handshake keys and the path before migration completes, or even better before the sends the first packet in response to a migration attempt. Otherwise, the server would be required to have a special-case for handle the original path.

Proposed solution is #3141.

-- 
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/issues/3142#issuecomment-545724898

---

From: Eric Kinnear <[email-masked]>
Date: Wed, 23 Oct 2019 22:56:43 -0700

I think this comes back to a lot of what @huitema was bringing up during the interim -- there are other things that rely on having a explicit signal for the handshake being entirely complete, and this is one of them. 

Having a well-defined moment where we're entirely done and can move on from Handshake packets would make this a lot nicer.

-- 
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/issues/3142#issuecomment-545757727