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

[ianswett <[e-mail]>]

@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