[quicwg/base-drafts] Persistent congestion interaction with app limited state (#2593)

[Subodh Iyengar <[e-mail]>]

We discovered one interesting edge case with Persistent congestion at least in mvfst. Due to TLP, we might retransmit data in a packet that is already outstanding if we don't have new data. We call this a "clone". If the original packet is acked, we do not get rid of the clone. We let the clone be outstanding and disable the loss timer, i.e. it's no use trying to retransmit the cloned packet. Instead we rely on regular loss recovery to get rid of the clone. So this means that it is possible to go into application idle state while having packets outstanding. What was surprising to us when we were implementing draft-19 loss was that this strategy might interact poorly with persistent congestion returning from app idle state. This is because the time between the smallest and largest loss packet if there is idle state in-between will most likely exceed the loss threshold. We're planning on fixing this by making a special case for idle state with persistent congestion.

I think others have a similar strategy of dealing with TLP transmissions. Would it be useful to document this edge case?

-- 
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/issues/2593