Subject: Hole in loss recovery algorithm?

From: Martin Duke <[email-masked]>
Date: Wed, 29 Apr 2020 14:23:15 -0700

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?

---

From: Ian Swett <[email-masked]>
Date: Wed, 29 Apr 2020 18:02:53 -0400

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 <[email-masked]> wrote:

> I'm probably missing something silly, but I'll file an issue if there is
> in fact a problem here:
>

---

From: Martin Duke <[email-masked]>
Date: Wed, 29 Apr 2020 17:59:51 -0700

I would personally put it both there and in 5.2.1.

---

From: Martin Duke <[email-masked]>
Date: Wed, 29 Apr 2020 18:22:19 -0700

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.

---

From: Martin Duke <[email-masked]>
Date: Wed, 29 Apr 2020 18:28:29 -0700

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 <[email-masked]> 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
>>> 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.
>>>
>>>> I'm probably missing something silly, but I'll file an issue if there
>>>> is in fact a problem here:
>>>>
>>>> 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?
>>>>
>>>