Response to lost handshake packets

[martinduke]

I would like to see some language in the loss recovery document about client actions when the first handshake message is lost. We have overloaded this loss signal with multiple meanings/responses:

(1) Retransmit (due to garden-variety network loss)
(2) Change MTU and retransmit (due to MTU problems, though we might see ICMP here?)
(3) Failover to TCP (middleboxes eating QUIC)
(4) Give up (path failure)

If I were implementing a client using these documents, I am not sure how I would handle a CHLO loss given these conflicting imperatives. I could accept having SHOULDs instead of MUSTs, but there ought to be something.

[martinduke]

There is a fifth (extremely improbable) possibility: the chosen connection ID happens to have collided with a connection ID already active on the server, failed decryption, and been dropped. It might be good to change the connection ID on subsequent ClientHellos.

[ianswett]

Changing the connection id has a few negatives. One is that if the first packet isn't lost, it would create two connections. The second is that if the CHLO is lost, and the 0RTT packets are not, the second CHLO is for a different connection, so the 0RTT packets are useless.

[martinduke]

Good points, there are various considerations. I know that in some prior iteration Stateless Rejects proposed a new Connection ID, but that doesn't help us here.

Changing it on retransmission #1 is too much, for sure. Perhaps at some later stage, after multiple CHLO retransmissions, the 0RTT data is more or less dead anyway. As the least probable cause, the response can come as a last-ditch effort.

We don't have a multipath draft in scope, but if there was some sort of mechanism to report available addresses, that would allow us to distinguish these packets as bad-luck CHLOs and SREJ them.

[mnot]

As discussed in Tokyo, (2) is addressed by packet size being 1280, (3) is an application issue, and (1) and (4) should be addressed by retransmitting a number of times and then aborting, a la TCP.

[martinthomson]

@ianswett, do you consider this to be closed now?

[ianswett]

Yes, I meant to close it with my PR.