Re: Hole in loss recovery algorithm?

[Martin Duke <[e-mail]>]

I would personally put it both there and in 5.2.1.

On Wed, Apr 29, 2020 at 3:03 PM Ian Swett <[e-mail]> wrote:

> 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?
>>
>