Subject: [tcpm] Poll for CUBIC RFC updates

From: Vidhi Goel <[email-masked]>
Date: Mon, 16 Nov 2020 18:08:05 -0800

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 <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 <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 <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.

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

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 17 Nov 2020 07:29:50 +0100

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.
>
> Issue link https://github.com/NTAP/rfc8312bis/issues/1
> 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.
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 17 Nov 2020 17:50:12 +0000

Agreed, the below changes are useful and we would adopt them for the Windows TCP implementation. 

-----Original Message-----
From: tcpm <[email-masked]> On Behalf Of Scheffenegger, Richard
Sent: Monday, November 16, 2020 10:30 PM
To: Vidhi Goel <vidhi_goel=[email-masked]>; [email-masked] Extensions <[email-masked]>
Subject: [EXTERNAL] Re: [tcpm] Poll for CUBIC RFC updates

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNTAP%2Frfc8312bis&amp;data=04%7C01%7Cpravb%40microsoft.com%7C9d4e5956e1ad4ac34fcf08d88ac23ac7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637411914695336574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=BVjKhWEzDza%2FpugYvkIyC4mSeTnOtfuAbS3EIh2M7a0%3D&amp;reserved=0.
> 1. Update K definition (Eq. 2) to account for Fast Convergence Issue 
> link 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2FNTAP%2Frfc8312bis%2Fissues%2F1&amp;data=04%7C01%7Cpravb%40mic
> rosoft.com%7C9d4e5956e1ad4ac34fcf08d88ac23ac7%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C1%7C637411914695336574%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am
> p;sdata=W3SR3xbcELrJ3v82l%2BmgqXM2NmBxBBs057EFcHyBqi8%3D&amp;reserved=
> 0 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2FNTAP%2Frfc8312bis%2Fissues%2F2&amp;data=04%7C01%7Cpravb%40mic
> rosoft.com%7C9d4e5956e1ad4ac34fcf08d88ac23ac7%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C1%7C637411914695336574%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am
> p;sdata=V2nw3vKUv69kTxm%2BfYFIRQbWTDKk4Nupkqly3hEnKrM%3D&amp;reserved=
> 0 This is a suggestion to improve performance after cwnd > W_max. 
> Apple's Cubic implementation for both TCP and QUIC already use this.
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=04%7C01%7Cpravb%40micros
> oft.com%7C9d4e5956e1ad4ac34fcf08d88ac23ac7%7C72f988bf86f141af91ab2d7cd
> 011db47%7C1%7C1%7C637411914695336574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;s
> data=tCMh2tFG%2BFeIhBscfRMdtaXl%2FzNcqcGNuPobA9QquMg%3D&amp;reserved=0
>

_______________________________________________
tcpm mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=04%7C01%7Cpravb%40microsoft.com%7C9d4e5956e1ad4ac34fcf08d88ac23ac7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637411914695346567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=WOPxcTHniE4e9nuNKPpPbAE3OQorWII0RsMRrsod0rY%3D&amp;reserved=0

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 17 Nov 2020 09:50:43 -0800

> > 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: Christian Huitema <[email-masked]>
Date: Tue, 17 Nov 2020 11:41:02 -0800

> 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.
> Reno AIMD based on the number of packets per ACK. This also avoids

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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 18 Nov 2020 10:28:30 +0200

> section 4.2 with an AIMD emulation (Linux's approach).

<snip>

I created https://github.com/NTAP/rfc8312bis/issues/20 to track this suggestion.

Thanks,
Lars

---

From: Neal Cardwell <[email-masked]>
Date: Fri, 20 Nov 2020 11:26:25 -0500

On Mon, Nov 16, 2020 at 9:08 PM Vidhi Goel
<vidhi_goel=[email-masked]> wrote:
>
> 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.

Yuchung and I chatted about (2.) (
https://github.com/NTAP/rfc8312bis/issues/2 ) and we agreed this looks
like a nice and worthwhile fix, which we should be able to integrate
into the Linux TCP CUBIC implementation.

Thanks for this effort!

best,
neal

---

From: Ian Swett <[email-masked]>
Date: Fri, 20 Nov 2020 15:39:01 -0500

As with the PRR update, I'd like to see some text(ideally non-normative)
describing any changes necessary for implementing Cubic in QUIC.