cc/cubic: consider >2 MSS increase on ACK

[mxinden]

Currently on_packets_acked, we at most increase by 2 MSS per ACK:

neqo/neqo-transport/src/cc/classic_cc.rs

Lines 243 to 257 in 207d309

	// If enough credit has been accumulated already, apply them gradually.
	// If we have sudden increase in allowed rate we actually increase cwnd gently.
	if self.acked_bytes >= bytes_for_increase {
	self.acked_bytes = 0;
	self.congestion_window += self.max_datagram_size();
	}
	self.acked_bytes += new_acked;
	if self.acked_bytes >= bytes_for_increase {
	self.acked_bytes -= bytes_for_increase;
	self.congestion_window += self.max_datagram_size(); // or is this the current MTU?
	}
	// The number of bytes we require can go down over time with Cubic.
	// That might result in an excessive rate of increase, so limit the number of unused
	// acknowledged bytes after increasing the congestion window twice.
	self.acked_bytes = min(bytes_for_increase, self.acked_bytes);

I am not sure this artificial limit is needed, especially since outgoing packets will be paced.

This code was added in #1074.

Note that the pacer was already in place (#618) at this time, i.e. the 2 MSS limit was likely not due to missing a pacer.

I don't think the 2 MSS limit is specified anywhere. Please correct me if I am wrong. RFC 9002 suggests an increase relative to the amount of bytes acked. If I understand RFC 3465 correctly, the suggested behavior is as well allowed.

//CC @ddragana and @mwelzl as discussed earlier

[mwelzl]

Am I misreading this? Section 2.3 says that the limit is 2 * SMSS ("MAY use L=2SMSS bytes and MUST NOT use L > 2SMSS bytes"). I talked about slow start - actually this section seems to state this limit more generally, and says that one MUST use 1 * SMSS for slow start.

Surely nobody thought about pacing when this was written... it's also an Experimental RFC, so probably ok to ignore :-)

Correction: this has been rolled into the main spec of Reno in RFC 5681. Anyway, we probably don't really care about TCP here, let alone Reno.

[mwelzl]

... but this is QUIC, not TCP. From a quick (tsk) look, RFC 9002 doesn't seem to specify such a limit at all.

[mxinden]

Section 2.3 says that the limit is 2 * SMSS ("MAY use L=2SMSS bytes and MUST NOT use L > 2SMSS bytes").

You are right. Thank you. The full quote:

This document specifies that TCP implementations MAY use L=2SMSS bytes and MUST NOT use L > 2SMSS bytes.

https://datatracker.ietf.org/doc/html/rfc3465?utm_source=chatgpt.com#section-2.3

This might be the origin of the current limit in Neqo?

That said, I think we agree: we have a pacer and RFC 9002 doesn't specify the limit, thus it is fine to remove.

[larseggert]

What do other implementations do?