[quicwg/base-drafts] Handshake Flow Control can result in hung connections (#1764)

[martinduke <[e-mail]>]

Section 4.7 of the handshake draft states:

>    Servers MUST NOT send more than three datagrams including Initial and
>    Handshake packets without receiving a packet from a verified source
>    address.  Source addresses can be verified through an address
>    validation token (delivered via a Retry packet or a NEW_TOKEN frame)
>    or by receiving any message from the client encrypted using the
>    Handshake keys.

As written, there are two scenarios where no one can transmit. If the client successfully sends the initial ACK to the server, and *either* the server's handshake flight or the client's handshake acks are lost, then (1) the client has nothing to do, and (2) the server does not have the flow control credit to retransmit the lost packets.

It would be nice to minimize the resource and amplification implications for the server. Ekr proposed the following conditions that apply when the path has not been verified:
1) The client initial must be padded to 1200 bytes, as today.
2) The client must retransmit its initial until it has a Handshake Crypto frame to send (i.e. it has received the entire server's first flight.)
3) Until the server gets an hs pkt (the path has been verified), it only retransmits in response to the Client Initial; this response is all server packets that have not been acked. With no retransmissions, the server will need to have some kind of timer to clean up the state if the connection is dead.

There are many other ways to solve this problem; this is an example.

-- 
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/1764