Re: [tcpm] Poll for CUBIC RFC updates

[Christian Huitema <[e-mail]>]

On 11/17/2020 9:50 AM, Yuchung Cheng wrote:
> On Mon, Nov 16, 2020 at 10:30 PM Scheffenegger, Richard <[e-mail]> wrote:
>> We have been working on improving the FreeBSD Cubic implementation, to
>> bring it up from the originally implemented (early draft) version of
>> Cubic, to a more production ready state which is inline with the adopted
>> RFC version.
>>
>> Having said this, the below changes sound reasonable and I will try to
>> adopt them for FreeBSD.
>>
>> Richard
>>
>>
>> Am 17.11.2020 um 03:08 schrieb Vidhi Goel:
>>> Hello,
>>>
>>> As Lars mentioned earlier, there are a couple of issues/proposals filed
>>> for updating the CUBIC RFC 8312 and are currently under discussion. The
>>> GitHub repo is at https://github.com/NTAP/rfc8312bis.
>>> We would like to gather information on which CUBIC implementations
>>> already or would be ready to adopt these changes.
>>>
>>> 1. Update K definition (Eq. 2) to account for Fast Convergence
>>> Issue link https://github.com/NTAP/rfc8312bis/issues/1
>>> Linux already has this change. Apple's Cubic implementation for both TCP
>>> and QUIC already use this.
>>>
>>> 2. Congestion window TCP friendly region after W_max
>>> Issue link https://github.com/NTAP/rfc8312bis/issues/2
>>> This is a suggestion to improve performance after cwnd > W_max. Apple's
>>> Cubic implementation for both TCP and QUIC already use this.
> I'd recommend replacing the modelled TCP Reno window approach in
> section 4.2 with an AIMD emulation (Linux's approach).
I second that. That's exactly what I ended up doing when implementing
Cubic from the RFC, and realizing that the emulation approach was very
hard to make work correctly.
>
> In our experience, TCP-friendly regions are the predominant mode of
> (Linux) Cubic for any regular Internet connection. IOW Cubic is often
> "Reno" unless the loss rate is abysmal. The modelled approach is based
> on a simple bulk transfer where modern network applications are mostly
> structured traffic (burst, idle, repeat). Under such traffic
> structures the model has two issues:
>
> The model assumes cwnd overshoot causes losses that are repaired in
> one round of fast recovery. In reality, the losses are often due to
> bursts to short messages, causing more rounds and even timeouts to
> repair. So the overall loss rate "p" tends to be higher than the ideal
> model, causing the model to underestimate the window (hence runs in a
> more conservative Reno). Instead Linux's approach is to simply emulate
> Reno AIMD based on the number of packets per ACK. This also avoids
> square-root operation.

That, and another issue caused by the use of RTT estimates in the RENO
modelled presented in the RFC. If there is jitter on the network, the
RTT estimates are going to fluctuate quite a bit, and the modelling will
amplify those fluctuations.

-- Christian Huitema