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

[IngJohEricsson <[e-mail]>]

Hi

 

Need to admit that I have not had too much time to follow the QUIC work lately. 

 

I too believe that draft-iyengar-quic-delayed-ack-00 is a good long term solution that allows endpoint to set a desired ACK frequency that is not more than necessary. As experiments show there are good incentives to keep the ACK frequency as low as possible in terms of client/server load and asymmetric links limitations. An ACK-FREQUENCY frame  will allow to find the proper balance between the requirements given by the congestion control, the traffic type and the above given limitations.


I am not too concerned if it takes an extra development/standards cycle to have that in place in the standard and in running code as long as the QUIC community shows other SDOs that the challenge with QUIC ACKs is being addressed. 

 

/Ingemar

 

From: Bob Briscoe <[e-mail]> 
Sent: den 2 maj 2020 18:50
To: quicwg/base-drafts <[e-mail]>
Cc: Ingemar Johansson S <[e-mail]>; Comment <[e-mail]>
Subject: Re: [quicwg/base-drafts] Changing the Default QUIC ACK Policy (#3529)

 

I'm greatly in favour of draft-iyengar-quic-delayed-ack-00 (BTW, where would you prefer me to give review comments about that?)

I am much less keen on any default delayed ACK policy, whether 1:2 as now in quic-transport, or the 2-10/100 numbers proposed in draft-fairhurst-quic-ack-scaling-02

My concerns would melt away if the default policy was explicitly /implementation-dependent/ and the draft instead gave /guidance/ to implementers.

*	The draft could still give the same 2-10/100 policy, but as /guidance/ for the current public Internet.
*	The draft should also state the conditions under which this guidance was determined (e.g. Internet paths with BDP between x and y, or whatever).

What's the difference? Stating a default policy implies this is a matter of interoperability. It's not. If we change to giving guidance, I'm sure most implementers will just use the guidance. However, implementers will be free to evolve their default as they gain experience.

This reduces the possibility that other behaviours will evolve around any default like 2-10/100. For instance, network monitoring using it as a signature. Or congestion controls optimizing around it. In turn, this will reduce the chance of ossification around the first numbers we thought of.

Senders can always use the ACK frequency frame to ask a receiver to change from its default. Then receivers will gradually learn what senders prefer them to do, and change their default accordingly. IMO, a continually improving default is important for short flows, so senders can avoid requesting a different ACK frequency right from the start.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <https://protect2.fireeye.com/v1/url?k=e0af5b33-be0fe15d-e0af1ba8-86b1886cfa64-01ac033f188a7bed&q=1&e=8abe6920-7020-473e-a5d8-baa4399162a3&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F3529%23issuecomment-622982264> , or unsubscribe <https://protect2.fireeye.com/v1/url?k=e5ce6fc1-bb6ed5af-e5ce2f5a-86b1886cfa64-3428571a7702a6a4&q=1&e=8abe6920-7020-473e-a5d8-baa4399162a3&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACRZ2GBG4MMKB4D2RGHJF53RPRFMBANCNFSM4LOJ4RQA> .  <https://github.com/notifications/beacon/ACRZ2GDOHHO3WOKEELVMNPTRPRFMBA5CNFSM4LOJ4RQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEUQ7I6A.gif> 



-- 
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-623289368