Re: [quicwg/base-drafts] unrecoverable loss pattern leads to deadlock (#2863)

[Kazuho Oku <[e-mail]>]

IIUC, we agreed today in Cupertino that forbidding handshake key discarding (#3121) is the solution (at least for the time being), based on the assumption that it works.

I am starting to wonder if it works as expected.

Consider the case where the client migrates to a new path once the handshake is confirmed. That is in fact the recommended behavior when server-preferred address is used.

But IIUC, the existing transport logic is designed based on the assumption that path migration happens only after the exchange of Handshake packets have ceased.

I think I have found at least one issue: when the client intentionally migrates to a new path while still having unacknowledged handshake data, how does it choose the new client CID when sending the Handshake packet? Current design assumes that the *server* to pick the client CID from the pool of the CIDs it has received with the NEW_CONNECTION_ID frames. That works for 1-RTT packets, because 1-RTT packet does not have the Source CID field. But when using the long header packets, the sender choose the Source CID (the source being the client in this particular case). What is the solution here?

-- 
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/2863#issuecomment-543540677