Pathological loss recovery case with Finished

[martinthomson]

@marten-seemann writes:

1. Client and server perform the handshake, no packets are lost so far. Client and server both arrive at the CONNECTED state, and the server receives all ACKs for handshake packets it sent. The client receives ACKs for all handshake packets except for the one containing the FINISHED message is lost (the packet containing the ACK for the FINISHED is lost).
2. The client starts using 1-RTT keys, and it sends two packets: First, a packet only containing an ACK, and then a packet containing stream data (e.g. a request). The request packet is then lost.
3. The server receives the ACK in the 1-RTT packet, and it stops accepting unencrypted packets according to 6.1.2 of the TLS draft. It doesn’t generate an ACK in response, since the packet only contained an ACK.
4. The client is now missing acknowledgements for two packets: the (unencrypted) packet containing the FINISHED message, and the (1-RTT) packet containing the request. It runs its loss recovery algorithm (OnLossDetectionAlarm), and since there is one outstanding handshake packet, it retransmit all outstanding handshake packets.

Now we’ve run into a situation we can’t recover from: The server won’t even open packet sent as a retransmission (since these packets are unencrypted, and arrive after it already received a 1-RTT packet), and the client will never retransmit the request packet. Furthermore, the server won't send any other packets, since it's just waiting for a request from the client.

[janaiyengar]

Discussed at editors meeting. We believe the following resolution might work. An endpoint acknowledges everything until (i) the handshake is complete, and (ii) it is certain that the peer has seen an acknowledgement sent after this point. Supporting this, an acknowledgement of an ACK that was sent prior to handshake completion cannot be used to remove ACK ranges from future acknowledgments.

[janaiyengar]

After the server believes that the handshake is complete (Finished message from the client included), it sends a HS_COMPLETE frame, which is reliable. When this frame is received at an endpoint, it ceases all retransmissions of any handshake frames.

[martinthomson]

Note: Removing client Finished (as some have suggested) is not sufficient because we need to address this problem for handshakes with client authentication.

[martinthomson]

I had an insight yesterday. Maybe the newly proposed CRACK frame can elicit acknowledgments.

[ianswett]

I think that may solve the problem with some constraints, but HANDSHAKE_DONE or some equivalent seems easier to me.