Subject: [EToSat] QUIC ACK Strategy

From: "Border, John" <[email-masked]>
Date: Tue, 16 Apr 2019 21:11:13 +0000

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

---

From: Ted Hardie <[email-masked]>
Date: Tue, 16 Apr 2019 14:41:11 -0700

You might want to take a look at
https://tools.ietf.org/html/draft-ietf-quic-recovery-19#page-6

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/etosat
>

---

From: "Border, John" <[email-masked]>
Date: Tue, 16 Apr 2019 22:19:07 +0000

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 <[email-masked]>
Sent: Tuesday, April 16, 2019 5:41 PM
To: Border, John <[email-masked]>
Cc: [email-masked]
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:

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 <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
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=>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 16 Apr 2019 15:43:35 -0700

Howdy,

On Tue, Apr 16, 2019 at 3:19 PM Border, John <[email-masked]> 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.
>

Because QUIC acknowledges data rather than packets, it is relatively easy
to make the baseline ACK-aggregating.

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.
>
>
When we come around to v2 you may want to follow the discussion of
connection-wide flow control.  The discussion between Roberto Peon and Nick
Banks during the last run touched on the difficulties of waiting a round
trip before increasing per-stream limits, but your use cases were probably
not that well described (the discussion resulted in discussion of Nick's
change shifting to v2).

regards,

Ted

>
>
>
>
> John
>
>
>
>
>
>
>
> *From:* Ted Hardie <[email-masked]>
> *Sent:* Tuesday, April 16, 2019 5:41 PM
> *To:* Border, John <[email-masked]>
> *Cc:* [email-masked]
> *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.
>
>
>
> <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:
>
>
>
> <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=>
>
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 17 Apr 2019 08:39:38 +0100

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
>
> *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.
>
>     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
>
>     [email-masked] <mailto:[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 Apr 2019 11:20:53 +0000

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

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------