Talk:TCP congestion control

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Proposed merge[edit]

Several pages describe parts or variants of the TCP congestion control algorithm, with little coordination between them. I boldly suggest to merge them into a coherent and comprehensive description of various ways in which mitigation of network congestion is addressed in the TCP protocol, following the original Van Jacobson's algorithm and its derivatives. — JFG talk 03:49, 29 April 2014 (UTC)[reply]

Articles to merge[edit]

Proposed structure of the new article[edit]

  • TCP congestion control is... (intro defining the subject, with some historical background)
  • Congestion issues
  • Mitigation strategies
  • Slow-start algorithm (citing the original Van Jacobson paper)
    • Adjusting the congestion window
    • Additive increase/multiplicative decrease
    • Fast recovery (using fast retransmit)
  • Variants (taking information from TCP congestion-avoidance algorithm)
    • Early algorithms (Tahoe, Reno, Vegas, New Reno)
    • Later proposals (Hybla, BIC, CUBIC, HSTCP, etc.)
    • Classification (quick summary, pushing details to main page Taxonomy of congestion control)
  • Merge and clean up the See also, References and External links sections

Positions[edit]

  • I support this well thought through proposal. ~KvnG 19:50, 5 May 2014 (UTC)[reply]
  • I also support this proposal (for what it matters). Crazy2be (talk) 02:18, 4 March 2016 (UTC)[reply]

Resolution[edit]

I've done some of this in an incremental manner. Congestion window, Taxonomy of congestion control, Fast retransmit and Slow-start have been merged into TCP congestion-avoidance algorithm. I've left Additive increase/multiplicative decrease separate for now since this is used outside TCP. I have included a summary of it in TCP congestion-avoidance algorithm, however.

The article is a bit long at present but I believe this is mainly because each variant is covered two or three times. I will go through and try to reduce redundancy. ~Kvng (talk) 22:12, 13 March 2016 (UTC)[reply]

I merged everything into TCP congestion-avoidance algorithm for convenience and to best maintain revision history. I would support renaming to TCP congestion control over the current redirect there. ~Kvng (talk) 22:39, 13 March 2016 (UTC)[reply]

I'd also support that renaming. — Dsimic (talk | contribs) 22:20, 7 April 2016 (UTC)[reply]
I have submitted this to Wikipedia:Requested_moves/Technical_requests#Uncontroversial_technical_requests. ~Kvng (talk) 14:30, 10 April 2016 (UTC)[reply]
 Done ~Kvng (talk) 14:28, 26 April 2016 (UTC)[reply]

Congestion control vs loss recovery algorithms[edit]

I do not believe that it helps understanding to describe loss recovery algorithms as if they are in the same set as congestion control (CC) algorithms. For instance New Reno and PRR are in the same list as Reno and Cubic, as if they are all CC algorithms and as if they are all mutually exclusive. Whereas you can have Reno CC with or without the New Reno loss recovery algorithm, and you can have Cubic CC with or without PRR.

CC & loss recovery algorithms can (and probably should) be described together on the same page, because loss recovery algorithms also slightly alter the congestion window to compensate for losses. But they should not be all on the same level in the same list.

A useful distinction is to consider whether one of these algorithms responds to ECN echo congestion experienced feedback. If not, it is a loss recovery algorithm, not a CC algorithm (because ECN indicates congestion but no loss).

Also, I notice that Cubic is described as "default in Linux kernels from version 2.6.19 to 3.1", while PRR is "default in Linux kernels since version 3.2". Whereas actually Cubic is still the default CC in the latest Linux kernel (4.6) with no immediate likelihood of not remaining the default in subsequent versions. This makes me wonder whether the authors believed that PRR and Cubic are mutually exclusive.

I also noticed that the most common congestion control algorithm used on the Internet today (Reno) is described by comparing its loss recovery with Tahoe, but the congestion avoidance phase of the Reno CC algorithm is neither described nor referenced. The latest IETF Proposed Standard RFC [RFC5681] is only referenced with respect to its slow start algorithm, not congestion avoidance. Also it is not made clear that most of the listed CC algorithms only differ in their congestion avoidance phases, all using much the same slow start algorithm.


Finally, on a completely separate point, I noticed the article has become dated. It describes a number of CC algos that were never widely deployed. However, for instance, Data Centre TCP is not described[1], despite having been implemented in Linux and deployed in Windows Server 2012 (based on Windows NT 6.2) onwards. Windows Server automatically switch over from Reno to DCTCP if ECN negotiation succeeds and the RTT is <10ms). Also from Windows Server 2012 onwards Compound was no longer default (because it was found to be unstable at low round trip times). BobBriscoe (talk) 23:36, 20 May 2016 (UTC)[reply]

References

  1. ^ Alizadeh, Mohammad; Greenberg, Albert; Maltz, David; Padhye, Jitu; Patel, Parveen; Prabhakar, Balaji; Sengupta, Sudipta; Sridharan, Murari (Oct 2010). "Data Center TCP (DCTCP)". ACM CCR. 40 (4): 63--74. doi:10.1145/1851275.1851192.

Proportional Rate Reduction is not a complete congestion control by itself[edit]

According to the presentation and actual 60-line source code that added to the Linux Kernel, Proportional Rate Reduction is a stand-alone improvement on loss recover, not a complete solution of congestion control, and standard congestion control algorithms are still used. As far as I know, the CUBIC algorithm is left as the default option when configuring the kernel (CONFIG_TCP_CONG_ADVANCED), and RTT is not an option. We have to make a clearer introduction to Proportional Rate Reduction. Bieraaa (talk) 02:20, 11 July 2016 (UTC)[reply]

Google BBR advertisment[edit]

The text on Google BBR states: "As network interface controllers evolve from megabit per second to gigabit per second performance, packet loss should no longer be considered the primary determining factor in identifying congestion, making model-based congestion control algorithms which provide higher throughput and lower latency, such as BBR, a more reliable alternative to more popular algorithms like CUBIC."

This really reads like a sales brochure. I'm not sure that those claims have been proven and even if, where is the reference?

I propose to delete those sentences or add references. Cxxl (talk) 09:12, 27 May 2018 (UTC)[reply]

I have removed these statements and made some other WP:NPOV improvements. ~Kvng (talk) 20:13, 8 June 2023 (UTC)[reply]

Please document which algorithms were used by default for which major operating system releases[edit]

...going back as far as we can. ★NealMcB★ (talk) 05:20, 17 September 2020 (UTC)[reply]

BLVC, BLFC, BLFSC[edit]

What do BLVC, BLFC, BLFSC in comparison table stand for? The online search shows these are not common abbreviations. If its something related to Barrier Lyapunov Function - we need an explanation why its benefitial to be listed in "advantages" 80.249.81.133 (talk) 10:06, 6 May 2021 (UTC)[reply]

There's a key for these in point 3 of the preceding discussion. ~Kvng (talk) 20:03, 8 June 2023 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:TCP_congestion_control&oldid=1205582400"