[CCWG] CWND increase in CUBIC and ACK policy

[Kazuho Oku <[e-mail]>]

Dear CCWG and QUICWG folks,

TL;DR: Sections 4.4 and 4.5 of RFC 9438 do not account for segments_acked
when increasing CWND outside the Reno-friendly region. As a result, a
literal implementation makes CUBIC's growth rate depend on the receiver's
ACK ratio, and causes measurable unfairness. It gets increasingly worse as
ACKs become less frequent.

While testing a vibe-coded CUBIC implementation, I think I've found a
peculiarity in RFC 9438.

Section 4.1 defines a "new ACK" as

> a "new
> ACK" is received, i.e., an ACK that cumulatively acknowledges the
> delivery of previously unacknowledged data.

Then, figure 4 in section 4.3 uses segments_acked to determine the amount
being acked, which is perfectly fine:

> West = West + αcubic * segments_acked / cwnd

It even notes that accounting for segments_acked is needed "for connections
with enabled or disabled delayed ACKs".

But in sections 4.4 and 4.5, the CWND increase is specified as:

> (target - cwnd) / cwnd

where the target is Wcubic(t + RTT). It does not take segments_acked into
account. This update rule approximates the intended increase toward
`target` over one RTT only when there are roughly `cwnd` ACK events per
RTT, i.e., approximately one ACK per segment.

Consequently, as ACKs become less frequent, the actual CWND increasingly
trails the CUBIC window function.

On a simulated 100 Mbps bottleneck with a full RTT of 80 ms, when competing
against an otherwise identical CUBIC flow using ACK1 (i.e.,
ack-every-packet), the bandwidth that a CUBIC flow doing ACKn (i.e., ack
every n packet) obtains is:

ACK1: 50.0%
ACK2: 45.29%    <-- 👀
ACK10: 10.07%

ACK2 is particularly interesting because acknowledging at least every
second packet is the conventional delayed-ACK behavior recommended by both
TCP and QUIC v1.

Changing the increase to:

> (target - cwnd) / cwnd * segments_acked

fixes the issue.

Perhaps unsurprisingly, this issue does not exist in the Linux TCP stack or
Google Quiche. Both account for the amount of newly acknowledged segments.
I see some QUIC stacks also doing the correct thing, especially those that
seem to have used CUBIC inside linux or Google Quiche as a reference.

But there also seems to be multiple QUIC stacks that contain this bug.

To paraphrase, under stable conditions and the receiver using the default
ACK2 policy, a literal implementation of RFC 9438 gets about 17% less
throughput than a stack that does not have this bug.

Attempts to reduce ACKs (e.g., draft-ietf-quic-ack-frequency) are
going to make the downside more prominent.

Am I missing something? Please let me know what you think.

-- 
Kazuho Oku