Subject: Re: [quicwg/base-drafts] Sender-Controlled Delayed ACK Ratio (#1978)

From: IngJohEricsson <[email-masked]>
Date: Tue, 04 Dec 2018 23:47:26 -0800

A bit late into this discussion. 
Have you discussed something like two dimensionless parameters K and N
Where 
MaxAckDelay = RTT/K
MaxPacketsBeforeAck = N

The values K and N are signaled/negotiated between the peers. Suggested default values would be K=4 and N=10  or whatever is deemed as proper.
One issue I see is that RTT may be unknown in the (first part of) the initial handshake. And then one can discuss if it should be RTT or SRTT.. 
One positive property (as I see it) is that we avoid fixing ourselves into discussions about time unit and that can be good as QUIC may be used in long haul as well as data center applications. 

/Ingemar

-- 
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/1978#issuecomment-444390258

---

From: ianswett <[email-masked]>
Date: Wed, 05 Dec 2018 03:38:13 -0800

@IngJohEricsson, gQUIC has an implementation of what you're describing where K is 4 or 8 and N is 10 or 20, and it works very well in production.

There are some drawbacks to this approach:
 1) Sender and receiver's view of RTT are different, and could be substantially so, so the sender can't rely on the receiver's max ack delay being RTT/K for timeouts.
 2) gQUIC's version is fixed over the lifetime of the connection, but acks every 2 packets for the first 100 under the theory that you want to increase the window quickly in slow start.  But 100 is a fixed value and is too short for some connections slow start and too long for others.  And maybe it should increase to 4 or 8 later in slow start as well?

Given there's interest in this, but it's clearly an area that needs further experimentation, I believe @janaiyengar and I are going to write up an extension draft to allow changing the N value during the connection via a new frame and leave MaxAckDelay fixed for now.

-- 
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/1978#issuecomment-444455713

---

From: IngJohEricsson <[email-masked]>
Date: Fri, 07 Dec 2018 05:16:09 -0800

Thanks for the explanation and nice to hear that you have tried this N and K version. I overlooked the possibility of different estimated RTTs on the two sides of a connection. 
Looking in TCP traces one can see that for example Android clients seem to ACK every 2nd segment in the initial phase and later on they typically go down to every 8th segment it does however not seem to be too conclusive and it is difficult to to see in the ACKs are pruned on lower protocol layers, in some cases one can see very long stretch ACKs (up to 100 segments).
 
/Ingemar

-- 
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/1978#issuecomment-445229529

---

From: janaiyengar <[email-masked]>
Date: Tue, 11 Dec 2018 15:17:57 -0800

I'll park this issue, and it can be picked up when we do an extension for 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/1978#issuecomment-446399938