Re: [quicwg/base-drafts] Prevent an unlikely deadlock (#1965)

[martinduke <[e-mail]>]

martinduke approved this pull request.

I agree with the concept, though I have some problems with the explanatory text.

One zoom-out question about TLP in QUIC: If there's a tail loss, you'll have to wait for an entire delayed-ack timeout to send, wait at worst for another DAT to get the ack, then a reordering timeout to declare the intervening packets lost. How does that compare to a plain old RTO?

> @@ -418,6 +418,12 @@ used to send a probe into the network prior to establishing any packet loss,
 prior unacknowledged packets SHOULD NOT be marked as lost when a TLP timer
 expires.
 
+If no new data or unacknowledged data is available to send, a retransmittable
+frame SHOULD be sent.  Sending a retransmittable frame ensures that any in
+flight packets are acknowledged or declared lost in a timely manner,

I don't think TLP accelerates acknowledgment of in-flight pkts unless you happen to hit what the maximum number of delayed-acked pkts are.

So I would delete "acknowledged or"

> @@ -418,6 +418,12 @@ used to send a probe into the network prior to establishing any packet loss,
 prior unacknowledged packets SHOULD NOT be marked as lost when a TLP timer
 expires.
 
+If no new data or unacknowledged data is available to send, a retransmittable
+frame SHOULD be sent.  Sending a retransmittable frame ensures that any in
+flight packets are acknowledged or declared lost in a timely manner,
+potentially preventing a deadlock if all in flight packets contain no data

Delete everything after "deadlock."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1965#pullrequestreview-171445838