transport: consider lower pacing rate in congestion avoidance

[mxinden]

Neqo currently paces over half the RTT, i.e. 2x the current rate:

neqo/neqo-transport/src/pace.rs

Lines 19 to 27 in 207d309

	/// This value determines how much faster the pacer operates than the
	/// congestion window.
	///
	/// A value of 1 would cause all packets to be spaced over the entire RTT,
	/// which is a little slow and might act as an additional restriction in
	/// the case the congestion controller increases the congestion window.
	/// This value spaces packets over half the congestion window, which matches
	/// our current congestion controller, which double the window every RTT.
	const PACER_SPEEDUP: usize = 2;

This is independent of the congestion control phase, i.e. same in slow start and congestion avoidance.

In slow start, we likely want to keep the aggressive pacing rate to keep up with the cwnd doubling.

In congestion avoidance, to prevent overflowing buffers and thus causing packet loss, we might want to reduce the rate to e.g. 1.2x times the rate.

What do others do?

• Linux TCP stack uses 2x in slow start and 1.2x in congestion avoidance.
• quic-go uses 1.25x

//CC @MarcoPolo and @marten-seemann since we discussed this over the week.
//CC @mwelzl thanks for the input on Linux.

[marten-seemann]

In slow start, we likely want to keep the aggressive pacing rate to keep up with the cwnd doubling.

Why is this needed? If you always pace at a rate determined by cwnd / rtt, this should not be necessary: During slow start, cwnd will grow, and thereby automatically increase the pacing frequency.

[mwelzl]

It's just a little too slow in slow start. Yes, the time gaps get smaller, but you also send twice as many packets / RTT. I'm attaching an Excel sheet that shows this for the second RTT (i.e., after IW).

paced_slowstart.xlsx