Re: [EToSat] QUIC ACK Strategy

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 <ted.ietf@gmail.com>
> *Sent:* Tuesday, April 16, 2019 5:41 PM
> *To:* Border, John <John.Border@hughes.com>
> *Cc:* etosat@ietf.org
> *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 <John.Border@hughes.com 
> <mailto:John.Border@hughes.com>> 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
>     EToSat@ietf.org <mailto:EToSat@ietf.org>
>     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
> EToSat@ietf.org
> https://www.ietf.org/mailman/listinfo/etosat