Re: [quicwg/base-drafts] Which DCID do Handshake retransmissions use? (#3348)

[Kazuho Oku <[e-mail]>]

As I can see, there are three options:
* a) let the receiver of NCID to send Handshake packets using the new CIDs
* b) require (or recommend) receiver of NCID to continue using the original DCID until the handshake is confirmed
* c) require (or recommend) the sender to withhold the emission NCID (with a non-zero RTP) to until it sees an ACK for handshake confirmation

I prefer requiring (c) (or maybe (b)), because (a) has corner cases even though it might seem easy.

Consider the case where a server sends TP.preferred_address then as the first packet, sends the NCID frame with RTP set to 2. If we adopt (a), this would mean that the client would have only one CID that it can use (the one being embedded in the NCID frame) even though it needs two (one for the original path, and another for the path specified by TP.preferred_address).

As you can see, the design of the NCID has been based on the assumption that providing one new CID alongside a retirement request guarantees that the receiver would have enough active CIDs. But in this particular case, that is not the case.

Based on this observation, and based on my assumption that a non-zero RTP would be sent by only some of the endpoints (the necessity of CID retirement is questionable for HTTP/3, the scope of QUIC v1, as the HTTP connections can be short-lived and most likely be gracefully terminated to induce a new connection), my preference goes to (c): a server that uses RTP should cover the cost.

-- 
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/3348#issuecomment-574493824