Re: Unrecoverable loss pattern

[Martin Thomson <[e-mail]>]

I assume that this is the language you refer to:

   A server MUST process ACK frames in unprotected packets
   until the TLS handshake is reported as complete, or it receives an
   ACK frame in a protected packet that acknowledges all of its
   handshake messages.

That talks about ACK frames, not Finished.

On Mon, Feb 26, 2018 at 1:25 AM, Marten Seemann <[e-mail]> wrote:
> I’ve been playing around with QUIC loss recovery and in my tests I’m
> encountering one specific loss pattern which it seems impossible to recover
> from. It's pretty rare, because there are a couple of conditions that must
> be fulfilled for it to occur:
>
> 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.
>
> I think the solution for this is to also retransmit 1-RTT packets in a case
> like this. Can we just apply the normal retransmission rules in
> OnLossDetectionAlarm, even if there are still handshake packets outstanding?
>
>