Re: [quicwg/base-drafts] Changing the Default QUIC ACK Policy (#3529)

[Kazuho Oku <[e-mail]>]

@gorryfair 
>> Please bear in mind that Chrome's ack policy of 1:10 works with BBR, not with Cubic or Reno.
> 
> I didn't find something in QUIC spec. that was a major concern. It looked to me like QUIC had learned from TCP how to handle stretch-ACKs.
> 
> After that, we changed quicly to use 1:10 with Reno, and things worked well. Didn't @kazuho <https://github.com/kazuho> also use Reno?

Just to clarify, in our experiment, we reduced the ACK frequency from the default (2) to `max(1/8 cwnd, 3 MTU)` after leaving slow start, then updated it every 4 PTO. I _think_ that would work fine on a high-bandwidth, stable network. But I am not sure if it would work as well as ack2 on all network conditions.

Anyways, I'd explain our experiment as an optimization of ack 2, as it was reduction of ack rate after leaving slow start. I think that that was a sensible choice, because IIUC having frequent acks during slow start is essential.

Assuming that we'd prefer using ack 2 during slow start, the question is if we need to hard-code in the base draft how to _optimize_ after leaving slow start. While I agree that continuing to use ack 2 after slow start is concerning for certain networks, I am reluctant to spending time on looking for such a fixed set of values across diverse networks (including much slower links or lossy ones).

Rather, my preference goes to shipping the base-draft as-is, then moving on to finalize the ack-frequency frame. I think we can assume most if not all of the popular clients to support the ack-frequency frame. Then, it becomes less of a question what the default in the base-draft is.

-- 
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/3529#issuecomment-636585635