Re: [quicwg/base-drafts] Changing the Default QUIC ACK Policy (#3529)

[ianswett <[e-mail]>]

> As currently specified, the default QUIC ACK policy models TCP’s ACK policy, but consumes significantly more return path capacity. This can impact resource usage of the return channel, can constrain forward throughput, and can impact the performance of other sessions sharing an uplink (draft-fairhurst-quic-ack-scaling). This was not discussed in Zurich - where discussion moved instead to the separate topic of draft-iyengar-quic-delayed-ack.

I don't believe QUIC ACKs are significantly larger.  In fact, I believe the ACK frame itself is typically smaller than TCP ACKs, but the savings there are used on QUIC's 16-byte auth hash and likely a non-zero-length CID.  Do you have a size analysis written up somewhere?

> 
> In many current network segments (e.g., cable networks, mobile cellular, WiFi and other radio tech), the effects of asymetry are presently mitigated by network devices RFC3449 that rely upon observing TCP headers. This results in ossification problems, but does practically have beneit. It reduces the TCP ACK rate over the constrained link, it reduces consumption of "radio" transmission opportunities, and reduces traffic volume from ACKs. These mitigations are not possible, nor desirable for QUIC. However, the default performance of QUIC is therefore much worse than for TCP.

I think this is the core issue.  It's not that QUIC ACKs are really consuming significantly more capacity in terms of bytes on the wire, it's that middleboxes can't decide to thin the ACKs, because they don't know which packets are ACK-only packets.

> 
> In QUIC, the default ACK Ratio has to set by the endpoints implementing the protocol because the sender and receiver have no information about the "cost" of sending an ACK using a link along an asymmetric path. These endpoints can also choose a non-default value to enable a new CC, scale to higher rates, etc (e.g. draft-iyengar-quic-delayed-ack).
> 
> We have shown there can be significant benefit from an ACK Ratio of 1:10 and this is expected to alos have benefit for higher levels of asymmetry. The proposed change from 1:2 to 1:10 is predicated on QUIC's design decisions: starting a connection with an Initial Window of 10 is acceptable, QUIC uses PTO as the loss detection method (a predicate to issue #3357), and QUIC has some form of pacing at the sender, at least to mitigate IW bursts.

Did you implement the optimization already described in the recovery draft?: "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."

@larseggert did and I believe found it hugely reduce the number of ACKs, sometimes too much.

As I've said before, I would really prefer not specify an approach in QUIC transport that is a heuristic like the PR attached to this issue does.  In particular, on lower bandwidth networks, 10 packets may be the entire congestion window and is too large a value.  On higher bandwidth networks, every 20 packets has shown to be slightly better than 10, at least when using BBR.  I wrote #3518 to add some editorial text about why every 2 packets is a SHOULD, not a MUST.  Chrome did not to default enable the ACK strategy #3501 recommends until BBR was launched, because there was a performance regression with Cubic.  I'd rather not assume everyone is using BBR or a BBR-like congestion controller.

@martinduke BBR does fine with stretch ACKs.  Cubic and Reno suffer in some cases, however.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3529#issuecomment-602233642