Use PTO to declare in-flight packets lost (#1965)

* Prevent an unlikely deadlock

QUIC, unlike TCP, allows the connection to get into a situation where there could be packets in flight, and a connection could even be CWND limited, but there may not be any outstanding data to retransmit.

The suggested solution is to send a retransmittable frame.

* Update draft-ietf-quic-recovery.md

* Update draft-ietf-quic-recovery.md

* Mike in-flight

* Update draft-ietf-quic-recovery.md

* Not a deadlock

* Update draft-ietf-quic-recovery.md

Co-Authored-By: ianswett <ianswett@users.noreply.github.com>

* Jana's suggestions

* Update draft-ietf-quic-recovery.md

* Proposed change: MUST mark inflight data as lost

A proposal: I think I prefer to mark things as lost instead of suggesting that a sender SHOULD send something when there's really nothing to be sent.  I was starting to rephrase your PR to say "SHOULD send ack-eliciting packet, but MAY mark as lost", and I needed to explain how a sender makes this choice. I realized that if it's been long enough (PTO is long enough) and there's nothing left to send, then maybe it is sensible to mark anything pending as lost. So, I changed my suggestion to that, which is this PR (against your PR).

* reflow

* add MAY re-arm PTO

* more rephrasing

* more simple

* comma

draft-ietf-quic-recovery.md

@@ -496,6 +496,13 @@ MAY use alternate strategies for determining the content of probe packets,
 including sending new or retransmitted data based on the application's
 priorities.
 
+When a PTO timer expires, new or previously-sent data may not be available to
+send and packets may still be in flight.  A sender can be blocked from sending
+new data in the future if packets are left in flight.  Under these conditions, a
+sender SHOULD mark any packets still in flight as lost.  If a sender wishes to
+establish delivery of packets still in flight, it MAY send an ack-eliciting
+packet and re-arm the PTO timer instead.
+
 
 #### Loss Detection {#pto-loss}