Re: Unrecoverable loss pattern

[Marten Seemann <[e-mail]>]

I don’t think this will fix the problem. All handshake packets (sent by the
server) were received by the client and acknowledged (in the first 1-RTT
packet sent by the client).

On Mon 26. Feb 2018 at 00:52, Nick Banks <[e-mail]> wrote:

> Perhaps 6.1.2 should be changed just to say the server must continue to
> process unprotected packets until all the handshake packets are received,
> and remove the part about receiving an ACK that acknowledges its handshake
> messages?
>
>
>
> - Nick
>
>
>
> *From:* QUIC <[e-mail]> *On Behalf Of * Marten Seemann
> *Sent:* Sunday, February 25, 2018 6:26 AM
> *To:* QUIC WG <[e-mail]>
> *Subject:* Unrecoverable loss pattern
>
>
>
> 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?
>
>
>