Re: Hole in loss recovery algorithm?

[Ian Swett <[e-mail]>]

When the Client Finished arrives, the server is handshake complete, so it
should arm PTO for the 1RTT data, though I don't see text making that
explicit.  Should it be added here
<https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-recovery.md#discarding-keys-and-packet-state-discarding-packets>
?

In the psuedocode, the PTO timer is reset when a PN space(the server's
Handshake in this case) is dropped.

Also, after the Client Finished arrives, the server sends HANDSHAKE_DONE,
which would also re-arm the timer and fix the issue, but I'd rather not
rely on HANDSHAKE_DONE to solve all the problems.

On Wed, Apr 29, 2020 at 5:23 PM Martin Duke <[e-mail]> wrote:

> I'm probably missing something silly, but I'll file an issue if there is
> in fact a problem here:
>
> - Server sends its handshake flight and some 1RTT data.
> - The PTO is timer is set for the handshake data only per 5.2.1 of
> quic-recovery.
> - HS ACKs arrive, but the 1RTT is lost.
> - Client Finished arrives.
>
> If this order of operations occurs, and there is no further 1RTT
> communication, is the 1RTT ever going to recover? A literal reading of the
> spec, if IIUC, is that when the HS acks arrive we're going to cancel the
> PTO timer and, as the handshake is not yet complete, we will not restart it
> for the outstanding 1RTT.
>
> A sentence saying you have to start it when completing the handshake, if
> 1RTT data is outstanding, would solve the problem. Perhaps I'm missing
> something more obvious?
>