Subject: [quicwg/base-drafts] Define idle period for congestion control (#2555)

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 26 Mar 2019 13:30:50 +0000 (UTC)

Currently the recovery draft 19 requires the sender to either reducing the cwnd to initial cwnd OR pace the send after idle. Idle is defined as "it ceases to send data and has no bytes in
   flight" . This will mean that just a very small delay in the sending application thread will cause QUIC to reset its cwnd when not pacing. IMO we need to define an interval for this which could be a function of kGranularity or as PTO. FWIW in TCP the idle period for cwnd restart is defined as one retransmission timeout (reference https://tools.ietf.org/html/rfc5681 Section 4.1). 

-- 
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/2555

---

From: ianswett <[email-masked]>
Date: Tue, 26 Mar 2019 08:51:29 -0700

However, this still has the problem that if I don't pace and I have a window of 100 packets, I can burst 100 packets into the network.  This seems suboptimal from both the sender and the network's perspective.

Now that I think about it, I think the concept of limiting the size of a burst is the key here, not so much idleness, and I think defining idle more accurately is both not necessary and likely to be difficult.  Ideally you would send no more than max(10, BW * kTimerGranularity) packets into the network at once.

-- 
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/2555#issuecomment-476714594