Two reasons to exceed bytes in flight

[martinthomson]

It might pay to reconcile:

An endpoint MUST NOT send a packet if it would cause bytes_in_flight (see
{{vars-of-interest}}) to be larger than the congestion window, unless the packet
is sent on a PTO timer expiration; see {{pto}}.

And

When entering recovery, a single packet MAY be sent even if bytes in flight
now exceeds the recently reduced congestion window.

Now, you might implement the latter using PTO machinery, but that text doesn't really suggest that in any way.

[marten-seemann]

Where does this second sentence come from? I'm pretty sure I haven't implemented anything like this in quic-go. Should I?

[martinthomson]

That sentence is the the definition of the recovery period. We haven't implemented that either, and I was wondering if it truly helps.

[mirjak]

For TCP this second case if important because as long as you don't retransmit the lost packet you will not get any ACK that acknowledges new data. I guess we don't need that for QUIC.

[ianswett]

The second sentence was added later in #3443, and the MUST wasn't updated, so I'll fix that.

Chromium currently implements PRR(RFC6937), which is a more complex variant of this which is designed to keep the ACK clock going. I thought we discussed adding an informative reference to PRR when we added this text, and I'm not sure why we didn't.

[mirjak]

#3483 seems to be the wrong issue you are pointed to...

[ianswett]

Good catch, it's #3443