Re: [EToSat] QUIC ACK Strategy

Howdy,

On Tue, Apr 16, 2019 at 3:19 PM Border, John <John.Border@hughes.com> 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 <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>
> 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
> 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=>
>
>