Re: Hole in loss recovery algorithm?

[Martin Duke <[e-mail]>]

also, the pseudocode sets the PTO timer when receiving an ACK. I'm not 100%
sure that's necessary, but it's not described in 5.2.1.

But wait, I see 5.2.2 says this: When Initial or Handshake keys are
discarded, the PTO and loss detection timers MUST be reset, because
discarding keys indicates forward progress and the loss detection timer
might have been set for a now discarded packet number space.

I think we're good.

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

> Filed #3613 <https://github.com/quicwg/base-drafts/issues/3613>. A couple
> of more notes:
>
> - HANDSHAKE_DONE doesn't cover the client case where all 0RTT is lost and
> the client doesn't have any more data to send. It may never send a 1RTT
> ack-eliciting packet.
> - Doing it when discarding the keys works, but it would be better to do it
> when the handshake completes, not confirms. That's when the 1RTT PTO
> prohibition lifts.
>
> On Wed, Apr 29, 2020 at 5:59 PM Martin Duke <[e-mail]>
> wrote:
>
>> 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?
>>>>
>>>