Re: [EToSat] QUIC ACK Strategy

[Magnus Westerlund <[e-mail]>]

Hi,

There has been quite a lot of discussion of having sender control of ACK
strategy. Beyond the control of MAX_ACK_DELAY these will not be in QUIC
v1. One of the github issues resulting from these discussions are this one:

https://github.com/quicwg/base-drafts/issues/1978

I think this is one area where we most definitely will see extensions to
QUIC going forward. So there exist plenty of opportunity to provide
input on the needs here. I think especially in the high BDP scenarios of
geo satelites it become interesting what controlls one like to have. I
assume that one likely want some upper limit to how many packets one
receive before generating an ACK, even if that do results in more ACKs
than 8 per RTT for example.

Cheers

Magnus



On 2019-04-17 09:40, Gorry Fairhurst wrote:
> Yes, what I also heard in the meeting room was that future versions 
> could send an ACK less frequently and RTT/4 was mentioned. To me this 
> seemed like the effect could be something equivalent the "ACK 
> Compaction" effect in RFC3449 - which I do agree would be good for paths 
> with asymmetry in capacity/access ... I didn't grasp whether this 
> behaviour would be negotiated as a paramerer, learned from the measured 
> RTT, or configured by client - I expect we'll need to ask/suggest as 
> talk moves to QUIC v2!
>
> Gorry
>
>
> On 16/04/2019, 23:19, Border, John wrote:
>> Thanks. One of the functions that a TCP PEP for satellite performs is 
>> ACK aggregation over the satellite link. The originally ACK stream may 
>> or may not be replicated at the downlink side. We, of course, cannot 
>> do this with QUIC. The v1 iQUIC baseline seems to leave open a lot of 
>> flexibility for dealing with this. We will take a look at some 
>> concrete strategy proposals for version 2. My colleague reminded me 
>> that Ian had put something out there about one per 1/4 RTT. That is 
>> close to the same rate our PEP uses for TCP. And, I like the fact that 
>> being based on RTT the rate is adjusted automatically based on path 
>> characteristics.
>>
>> John
>>
>> *From:* Ted Hardie <[e-mail]>
>> *Sent:* Tuesday, April 16, 2019 5:41 PM
>> *To:* Border, John <[e-mail]>
>> *Cc:* [e-mail]
>> *Subject:* Re: [EToSat] QUIC ACK Strategy
>>
>> *CAUTION:*This email originated from outside of the organization. Do 
>> not click links or open attachments unless you recognize the sender 
>> and know the content is safe.
>>
>> You might want to take a look at 
>> https://tools.ietf.org/html/draft-ietf-quic-recovery-19#page-6 
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dquic-2Drecovery-2D19-23page-2D6&d=DwMFaQ&c=dIKa1mMv92xhhFzVXv5A3Q&r=9F44ji63_2hvW5HufmlpP-DFKXuFy4jDtL5PXwKlTqg&m=tA_S6UPMM5eclUJzsmisGq1F1w6cJVYwziQdvqTl_YY&s=np2E8eA7xZP1L5AbxnQ3VdUPfVGt9KLG1SsEssGyYTg&e=>
>>
>> The baseline is this:
>>
>>      As an optimization, a receiver MAY process multiple packets before
>>     sending any ACK frames in response.  In this case the receiver can
>>     determine whether an immediate or delayed acknowledgement should be
>>     generated after processing incoming packets.
>>
>> There are specific conditions which are ack-eliciting, but you are 
>> generally permitted to optimize this.
>>
>> Ted
>>
>> On Tue, Apr 16, 2019 at 2:11 PM Border, John <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>     We were looking at some gQUIC traces and noticed an ACK every
>>     other packet similar to TCP. Does anyone know if iQUIC includes
>>     being able to tune the ACK rate? At very high speeds, that is a
>>     lot of ACK traffic…
>>
>>     John
>>
>>     _______________________________________________
>>     EToSat mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/etosat
>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_etosat&d=DwMFaQ&c=dIKa1mMv92xhhFzVXv5A3Q&r=9F44ji63_2hvW5HufmlpP-DFKXuFy4jDtL5PXwKlTqg&m=tA_S6UPMM5eclUJzsmisGq1F1w6cJVYwziQdvqTl_YY&s=iZKE2UiNcIv0cbDSdcmIgcUfZyrJlt0jdHi9SK0lkY8&e=>
>>
>>
>>
>> _______________________________________________
>> EToSat mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/etosat
> _______________________________________________
> EToSat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/etosat
>

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------