<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Congestion Control on Mi&amp;Bee Blog</title><link>/en/tags/congestion-control/</link><description>Recent content in Congestion Control on Mi&amp;Bee Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>蓝宝石的傻话</managingEditor><lastBuildDate>Sun, 10 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="/en/tags/congestion-control/rss.xml" rel="self" type="application/rss+xml"/><item><title>TCP Congestion Control Evolution: From Reno to BBR</title><link>/en/posts/network/tcp-congestion-control-evolution/</link><pubDate>Fri, 15 Aug 2025 00:00:00 +0000</pubDate><guid>/en/posts/network/tcp-congestion-control-evolution/</guid><description>&lt;p&gt;The previous articles in this series focused on the architecture and implementation of P2P networks, but the performance bottleneck of P2P applications often lies not in the protocol layer itself, but in the underlying transport protocol — TCP congestion control. A single BitTorrent node may maintain hundreds of concurrent TCP connections, each independently performing congestion control. Choosing the wrong congestion control algorithm can severely degrade bandwidth utilization, especially on high-latency links or links with random packet loss. Understanding the evolution of congestion control not only helps P2P developers optimize transport performance but is also essential for gaining a deep understanding of how the internet transport layer operates.&lt;/p&gt;</description></item><item><title>BBR Congestion Control Algorithm Deep Dive</title><link>/en/posts/network/bbr-algorithm-deep-dive/</link><pubDate>Sun, 10 May 2026 00:00:00 +0000</pubDate><guid>/en/posts/network/bbr-algorithm-deep-dive/</guid><description>&lt;p&gt;BBR (Bottleneck Bandwidth and Round-trip propagation time), developed by Neal Cardwell, Yuchung Cheng, and others at Google, is one of the most advanced model-based congestion control algorithms available today. Unlike traditional loss-based algorithms (Reno, CUBIC), BBR explicitly models the network path by directly measuring bottleneck bandwidth and propagation delay, sending data at the BDP (Bandwidth-Delay Product) rate at the bottleneck point.&lt;/p&gt;
&lt;p&gt;BBR&amp;rsquo;s core insight is that &lt;strong&gt;packet loss does not equal congestion&lt;/strong&gt;. On deep-buffered (Bufferbloat) or wireless links, packet loss can be caused by channel noise or excessive buffer queuing rather than genuine link saturation. BBR actively measures bandwidth and latency to precisely control the sending rate, rather than passively waiting for loss signals.&lt;/p&gt;</description></item></channel></rss>