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

[ianswett <[e-mail]>]

Good question, @ekr 

It's definitely a detail point, but I think the above approach is likely the ideal fix.  But here's what I expect to happen now.

If the implementation stores some state saying "the tlp alarm fired, but I couldn't send anything, and I'll remember that in case there is some data I can send in the near future." then when there's new data, everything should be fixed, though you'll also only be able to send a single packet.  And if that packet or the corresponding ACK is lost, it'll be another TLP before you can send a packet.

Alternately, an implementation could fire the alarm, realize it can't send anything, then not re-arm the alarm(since if it was re-armed, it would just fire immediately and you'd spin).

The second approach is a deadlock.  The first one is just going to be very slow recovery.  Both seem somewhat suboptimal.

There's another solution to this, which is to declare all in-flight packets lost.  But that goes against the approach we use throughout QUIC loss recovery where we don't declare packets lost until a larger packet is acknowledged.

OT: @martinduke pointed out that this should be fixed for RTO as well, since it's possible between TLP and RTO(or between two RTOs) in-flight data is cancelled, so now there's nothing to retransmit.

-- 
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#issuecomment-435917790