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

From: Subodh Iyengar <[email-masked]>
Date: Mon, 08 Apr 2019 16:11:44 +0000 (UTC)

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

---

From: ianswett <[email-masked]>
Date: Wed, 10 Apr 2019 19:21:25 +0000 (UTC)

There's text on this edge case, but not the interaction with persistent congestion.
https://tools.ietf.org/html/draft-ietf-quic-recovery-19#section-6.3.2
"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."

I think if you follow either suggestion listed, you shouldn't inadvertently declare persistent congestion from being idle, since in one case you immediately declare packet loss and in the other, you'd only declare persistent congestion if the subsequent PTOs established it?

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

---

From: ianswett <[email-masked]>
Date: Wed, 10 Apr 2019 12:23:08 -0700

I think if you follow either suggestion listed, you shouldn't inadvertently declare persistent congestion from being idle, since in one case you immediately declare packets lost and in the other, you'd only declare persistent congestion if the subsequent PTOs established it?

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

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 12 Apr 2019 16:42:33 -0700

I agree with @ianswett. This is definitely an interesting case, and it is in line with an explicit assumption we've made -- that either the PTO timer is running, or we have nothing outstanding. @siyengar :  Do you think adding text along these lines might be helpful?

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

---

From: Subodh Iyengar <[email-masked]>
Date: Fri, 12 Apr 2019 16:55:51 -0700

Ya i think that's a decent mitigation there. The text assumes an implementation that keeps the PTO armed even if there is a packet outstanding that does not have new or expired data. In our case we don't arm the timer when there is a packet with no new data. The assumption that the spec makes is that if you have outstanding packets to send you have outstanding data, however we explicitly check whether we have outstanding data to send rather than using outstanding packets as a proxy.

Oh now that you brought up PTO, I'm thinking about what would happen if data was being sent slowly, that is if data is sent just before PTO expires and in response to new requests which are trickling in. Is the intent of persistent congestion here to mark this case as persistent congestion as well?

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