CC_DCTCP(4)

πŸ’– cc_dctcp β€” the DCTCP Congestion Control Algorithm πŸ’–

okay bestie, welcome to cc_dctcp(4), straight outta the Kernel Interfaces Manual ✨ this is your girl explaining data center TCP like we're texting at 2am, but fr fr every detail is here, no cap 🫢


🌸 DESCRIPTION 🌸

So. The DCTCP (that's data center TCP) congestion control algorithm is literally that girl β€” she's trying to maximise throughput AND minimise latency in data center networks, which is giving main character energy ✨ and she does it by utilising the proportion of Explicit Congestion Notification (ECN) marks she receives from capable hardware as a congestion signal. iconic behavior, honestly πŸ’…

DCTCP uses the fraction of ECN marked packets to update the congestion window. The window reduction ratio is always <= 1/2 β€” like, she never goes below half, periodt. Only when all of the packets are marked does the congestion window get halved. πŸ’€

To keep the accuracy of the ECN marked fraction, a DCTCP receiver mirrors back incoming (or missing) CE marks by setting (or clearing) ECE marks. This feedback methodology is also adopted when the receiver uses delayed ACK. she's thorough, we love that πŸŽ€

The FreeBSD DCTCP implementation includes two minor modifications for the one-sided deployment:

  • When DCTCP is used as sender and classic ECN is used as receiver, DCTCP sets the CWR flag as the reaction to the ECE flag. πŸ”₯
  • When classic ECN is used as sender and DCTCP is used as receiver, DCTCP avoids to mirror back ACKs only when the CWR flag is set in the incoming packet. πŸ¦‹

The other specifications are based on the paper and the RFC referenced in the β€œSEE ALSO” section below. iykyk πŸ“š


🧚 MIB Variables 🧚

The algorithm exposes the following tunable variables in the net.inet.tcp.cc.dctcp branch of the sysctl(3) MIB:

  • alpha β€” the initial value to estimate the congestion on the link. The valid range is from 0 to 1024, where 1024 reduces the congestion window to half, if a CE is observed in the first window and alpha could not yet adjust to the congestion level on that path. Default is 1024. ✨
  • shift_g β€” an estimation gain in the alpha calculation. This influences the responsiveness when adjusting alpha to the most recent observed window. Valid range from 0 to 10, the default is 4, resulting in an effective gain of 1 / ( 2 ^ shift_g ), or 1/16th. πŸ’…
  • slowstart β€” a flag if the congestion window should be reduced by one half after slow start. Valid settings 0 and 1, default 0. 🌸

πŸ”₯ SEE ALSO πŸ”₯

cc_chd(4), cc_cubic(4), cc_hd(4), cc_htcp(4), cc_newreno(4), cc_vegas(4), mod_cc(4), tcp(4), mod_cc(9)

Mohammad Alizadeh, Albert Greenberg, David A. Maltz, Jitendra Padhye, Parveen Patel, Balaji Prabhakar, Sudipta Sengupta, and Murari Sridharan, β€œData Center TCP (DCTCP)”, ACM SIGCOMM 2010, http://research.microsoft.com/pubs/121386/dctcp-public.pdf, 63-74, July 2010.

Stephen Bensley, Dave Thaler, Praveen Balasubramanian, Lars Eggert, and Glenn Judd, Data Center TCP (DCTCP): TCP Congestion Control for Data Centers, https://tools.ietf.org/html/rfc8257.


⭐ HISTORY ⭐

The cc_dctcp congestion control module first appeared in FreeBSD 11.0. πŸ‘‘

The module was first released in 2014 by Midori Kato studying at Keio University, Japan. πŸŽ“πŸ’–


πŸ‘‘ AUTHORS πŸ‘‘

The cc_dctcp congestion control module and this manual page were written by Midori Kato katoon@sfc.wide.ad.jp and Lars Eggert lars@netapp.com with help and modifications from Hiren Panchasara hiren@FreeBSD.org 🫢


and that's the whole vibe check bestie β€” shoutout to the Debian crew, this page is dated July 29, 2019, and yes it's still out here as CC_DCTCP(4) in the Kernel Interfaces Manual πŸ’–βœ¨πŸŽ€πŸ¦‹πŸŒΈπŸ’…πŸ«Ά
πŸ“¦ where this page comes from