When/how often to send ACK frames

[mirjak]

The spec just doesn't say anything about this so far. You at least want to put in some minumum requirement (like MUST send at least X ACKs per RTT).

Also related but might be a separate issue that I'm not sure about yet: Is there a value in having a mechanism for the sender to tell the receiver how often it would like to receive ACKs?

[martinthomson]

@ianswett, @janaiyengar, do you want to take this with the loss recovery draft?

[mirjak]

I think this bit should be in the transport draft (mainly because it's the receiver behavior that is rather independent of the recovery and congestion control at the sender)

[ianswett]

I tend to think this should be in the transport draft as well.

[acmacm]

I suggest to make any requirement on ACK reduction simple (1 ACK : N Packets Received). For reasons I'm sorting-through (and may have to wait till Chicago), I suspect that 1:1 should be allowed because feedback helps understand performance. (acmacm is Al Morton)

[martinthomson]

@acmacm, you can edit your GitHub profile here and put your name in. It won't show on the UI for reasons I don't fully understand, but we'll all eventually make the connection.

[acmacm]

Thanks Martin! From: Martin Thomson [mailto:notifications@github.com] Sent: Wednesday, March 01, 2017 7:55 PM To: quicwg/base-drafts Cc: MORTON, ALFRED C (AL); Mention Subject: Re: [quicwg/base-drafts] Given recommendations on when/how often to send ACK frames (#230) @acmacm<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_acmacm&d=DQMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=2jNl3-3CmU12dNAwUtHJbn69Th9QwFS563VHeqkjVyQ&s=z3fV1W1awuVo_aW34O92SXD3q77NMVsTGbcfsW6emvA&e=>, you can edit your GitHub profile here<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_settings_profile&d=DQMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=2jNl3-3CmU12dNAwUtHJbn69Th9QwFS563VHeqkjVyQ&s=GhEMeGMWeRZ7k-fBQ2Bm49SJGqaGZUawruqkjTmKsBc&e=> and put your name in. It won't show on the UI for reasons I don't fully understand, but we'll all eventually make the connection. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_quicwg_base-2Ddrafts_issues_230-23issuecomment-2D283521494&d=DQMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=2jNl3-3CmU12dNAwUtHJbn69Th9QwFS563VHeqkjVyQ&s=V0buh__ikJFiPZ5vRphJin2sidrbaa9pbs4bs5gYDkE&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AJC8GFNGU9jSIgh1DbgXqJTUlZNX-2DaiCks5rhhNegaJpZM4LtKZ4&d=DQMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=2jNl3-3CmU12dNAwUtHJbn69Th9QwFS563VHeqkjVyQ&s=YkDVCRff7J3NL-RNs9DoPcBjgFaJrOp1foaUBZ1eTF0&e=>.

[martinthomson]

It would be good if someone could provide N. I hear that GQUIC uses N=2. I agree that 1:1 should be fine. I also think that having an ACK on every (live) RTT is valuable as well, especially if you aren't sending anything else (as sometimes happens in HTTP).

[ianswett]

1:1 acking is ok as long as that excludes acks. Acks must be acked at a rate much less than 1:1, I would advise at most 1 ack for every two acks.

GQUIC follows TCP's approach of N=2 with a delayed ack timer, but we use a delayed ack timer of 25ms. TCP delayed ack timers vary substantially by platform in practice, but tend to default to ~200ms in internet environments.

I think we should recommend a default, for which I'd suggest as TCP/GQUIC's default, as well as the ability to negotiate other values of N and the delayed ack timer. If we don't want to allow negotiation, we should at least allow the peer to inform the sender of their ack algorithm.

[martinthomson]

I would have been happy with ANY rationale, but that rationale is excellent Ian, thanks!

[martinthomson]

@ianswett, I forgot to ask something.

Say you make the configurable parameters (the ratio of ACK-only packets to acknowledgments, the delayed acknowledgment timer) known. And say you define two new transport parameters, one for each. What does the recipient of that information do with this newly acquired knowledge?

[mirjak]

In TCP this is would be useful to do a more appropriate RTT and RTO estimation. However, in QUIC you have more fine grained timing information in the ACK frame itself, so maybe that's actually not that useful anymore. However, there is a trade-off between overhead and responsiveness (of †he congestion control). I think it would actually be useful to some kind of negotiation, where the data sender/ack receiver can specify a min and may ack rate, because that peer a) might know something about any access link restrictions (-> don't send more ACK than this because otherwise it will overload my link), and b) know the congestion control use (my cc scheme needs at least an ack every x packets to function correctly).

[acmacm]

Adding to @mirjak point on negotiation: c) peer might know about their access link loss conditions, and potentially improve responsiveness by preferring an ACK ratio approaching 1:1.

[martinthomson]

@acmacm, @mirjak, were you talking about ACK ratios for regular packets? Because the discussion was originally about ACK ratios for packets that only contain ACK frames (and padding).

[acmacm]

Hi @martinthomson, Sorry for the noise, I see now that you narrowed your question to a part of @ianswett 's Mar 2 statement on ACK of ACKs ratio.

[mirjak]

I actually didn't distinguish this. However, you are right that if you only send an ACK there might be scenarios were you'd like to maintain a low rate, e.g. to not wake up the radio to often... on the other hand if you receive data you can also send out an ACK that is queued to be send out...

[ianswett]

Knowing the delayed ack timer allows you to set timers for TLP and RTO without creating spurious retransmits, because the ack timer can be incorporated into the min timeout when there's only one packet outstanding. See the recovery doc(https://tools.ietf.org/html/draft-tsvwg-quic-loss-recovery-00), section 3.1.

Currently most TCP implementations have to use a very conservative min TLP timeout and RTO because they assume the peer likely uses a 100 or 200ms delayed ack timer.

I don't think knowing the ratio tells you much of interest, and it's fairly easy to just observe, but Mirja's right that some congestion control schemes deal better with stretch acks than others. That being said, ideally congestion controls should deal with them anyway, since they are created by other network elements, so I don't see a large need to communicate this to the peer.

For related info, see https://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-00

[ianswett]

The text was improved with #907 The intent is to add detailed considerations and recommendations in the recovery doc.

[pravb]

Knowing the max stretch ACK does help the ABC computation on the sender for ACK clocked congestion control. It would be useful to document some recommended values for delayed ACK frequency and timeout to avoid the mess with TCP implementations with each one doing something different.

[martinthomson]

This issue seems a little open-ended now. Can we recast this more narrowly so that it has some hope of being resolved? I note that we have a lot better advice in the transport doc about this. If we want to have explicit signaling for ACK delays, we should open new issues for that.

[ianswett]

Agreed, #1139 adds a first version of the extra text I thought was necessary in the recovery doc. There's already an issue for explicit ack delay, so I'm closing this.