Re: [tcpm] Poll for CUBIC RFC updates

On Mon, Nov 16, 2020 at 10:30 PM Scheffenegger, Richard <rs.ietf@gmx.at> 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).

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.

>
> >
> >  From my experience, these changes would improve Cubic’s performance.
> >
> > Please let us know if you already or would be ready to implement these
> > changes in your CUBIC’s implementation.
> >
> > Thanks,
> > Vidhi
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> >
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm