传输控制协议（TCP）是全球互联网通信可靠性的基石，其核心机制，包括有序交付、拥塞控制和基于重传的错误恢复，构成了现代网络应用的基础 1。尽管TCP协议在设计上具有非凡的鲁棒性，但特定的现代网络架构和应用模式会将其推向性能灾难性崩溃的边缘。网络工程领域中常提及的“TCP熔断”并非单一现象，而是对至少两种截然不同的性能问题的统称，它们的成因、环境和解决方案迥然不同。
本报告旨在对这两种现象进行深入的技术剖析，明确区分其本质差异。第一种现象是TCP-over-TCP熔断（TCP-over-TCP Meltdown），这是一种在广域网（WAN）隧道应用中普遍存在的协议分层冲突问题 3。第二种现象是
TCP Incast，这是一种由特定工作负载诱发的性能崩溃，常见于高性能局域网（LAN）和现代数据中心环境中 5。本报告的目标是通过协议层面的精细解构，阐明这两种现象迥异的根本原因、失效机制和缓解策略，从而为网络架构师和系统工程师在设计和诊断复杂网络系统时提供一个清晰、准确的理论框架。
TCP-over-TCP问题是一种根本性的架构反模式，其核心在于将两个独立的可靠性协议栈进行嵌套，从而引发不可避免的严重性能衰退。本节将从基本原理出发，解构这一问题的成因，并阐述为何这种架构在设计上存在固有缺陷。
“TCP堆叠”（TCP stacking）或“TCP-over-TCP”指的是将一个完整的TCP会话（称为“内层”或“载荷”连接）封装在另一个TCP会话（称为“外层”或“隧道”连接）之内 1。这种架构在现实世界中的典型应用场景包括：以TCP模式运行的虚拟专用网络（VPN）软件（如OpenVPN、VTun），或通过SSH连接隧道化点对点协议（PPP）流量 1。尽管在某些受限网络环境下这是一种权宜之计，但它构成了对TCP协议基本设计假设的根本性违背。
TCP协议的设计初衷是在一个不可靠的数据报服务（如IP协议）之上提供可靠的传输层 9。当其底层承载网络本身是另一个TCP连接时，其内置的可靠性与拥塞控制机制就变得冗余，并产生破坏性的相互干扰 3。这种干扰会导致严重的吞吐量下降，文献报告的性能损失可达55%甚至更高 10。
这种架构问题不仅是效率低下，更是对协议层间语义契约的根本性违背。TCP的整套控制机制，包括拥塞窗口管理、重传计时器和确认机制，都建立在一个核心假设之上：它正在为一个不可靠的下层协议提供纠错和流量控制。当底层实际上是另一个同样在努力提供可靠性的TCP连接时，上层TCP的控制循环所依据的网络状态信息从根本上就是失真的。外层TCP通过自身的重传机制向上层隐藏了真实的物理丢包，这使得隧道对内层TCP而言显得“可靠”。然而，这种“可靠性”是以延迟的剧烈、不可预测的变化为代价的。内层TCP无法感知到真实的丢包事件，只能观察到延迟的增加，并错误地将其解读为网络拥塞，从而不必要地收缩其发送窗口。因此，问题的根源在于外层TCP向上层提供了错误的语义服务——一个具有可变延迟的可靠流，而非预期的不可靠数据报服务。内层TCP的算法本身是正确的，但由于输入了错误的环境信号，最终导致了“垃圾输入，垃圾输出”式的系统性失效。
TCP-over-TCP的核心失效机制源于两个独立且互不协调的TCP拥塞控制算法的同时运作 7。外层TCP连接有效地向内层连接“隐藏”了底层网络的真实状况 11。当外层隧道在广域网链路上遭遇丢包时，它会启动自身的恢复机制，例如重传丢失的报文段。对于内层TCP而言，它并未直接观察到这次丢包；它所经历的仅仅是数据传输延迟的突然增加，因为外层TCP正在忙于数据恢复。
内层TCP的拥塞控制算法，在设计上会将这种非预期的延迟增长误判为网络路径出现拥堵的信号。作为回应，它会采取标准的拥塞规避措施——收缩其拥塞窗口，从而降低发送速率。此时，系统陷入了一个恶性循环：外层TCP因实际的丢包而减速，而内层TCP则因外层恢复行为引发的延迟而减速。两个控制循环基于不同（且相互冲突）的信号，同时对数据流进行节流，导致了吞吐量的急剧且不必要的下降 7。
每个TCP连接都维护着一个独立的重传超时（Retransmission Timeout, RTO）计时器，作为数据未被确认时的最终恢复手段 1。在TCP-over-TCP场景中，两个层级的RTO计时器之间存在巨大的差异和不协调，这是导致性能熔断的关键因素。内层TCP通常运行在客户端的局域网环境中，其RTT较短，因此其RTO值也相对较小。相反，外层TCP需要穿越延迟较高的广域网，其RTO值会大得多且变化范围更广 1。
当广域网链路上发生一次物理丢包时，外层TCP会启动其缓慢的恢复过程，这可能需要等待一个较长的RTO周期。然而，在此期间，内层TCP那个短得多的RTO计时器很可能会首先超时。内层TCP错误地判断其数据段已丢失，于是发起重传。这个重传的数据包随即被送入外层TCP的发送队列，而此时外层TCP可能仍在处理前一次的丢包恢复，导致新的数据包被阻塞。这种机制可能触发一个灾难性的正反馈循环：内层TCP因持续收不到确认而反复进行不必要的重传，形成所谓的“重传风暴” 7。最终，当外层连接速度较慢时，上层排队的重传数据量会超出下层处理能力，导致整个连接性能彻底“熔断” 1。
这种双层恢复机制的交互作用产生了一种“恢复努力放大”的失效模式。一次单一的物理丢包事件，被两个独立且未协同的控制代理（内、外层TCP）视为两次独立的逻辑丢包事件来处理。系统为了一次物理故障，付出了双倍的带宽和处理资源进行恢复。正如研究指出的，“两个流控机制都可能请求重传同一个数据包，导致对同一数据包的多次重传” 7。这种恢复成本的非线性放大，是导致系统“好put”（goodput）迅速崩溃的深层原因。
针对TCP-over-TCP问题，业界已经形成了一套清晰的解决方案和最佳实践，其核心思想是恢复协议栈的正确分层逻辑。
业界共识的首选且最根本的解决方案是完全避免TCP-over-TCP架构，转而使用UDP作为隧道的外部传输协议 1。这种设计恢复了协议分层的正确语义：一个可靠的协议（内层TCP）运行在一个不可靠的数据报服务（外层UDP隧道）之上。这正是现代VPN协议（如WireGuard）仅使用UDP构建的原因 4，也是为何经验丰富的网络管理员会将OpenVPN配置为默认使用UDP模式，仅在需要穿越严格防火墙策略时才不得已使用TCP模式的原因 1。
为解决UDP的不可靠性和安全性问题，数据报传输层安全（Datagram Transport Layer Security, DTLS）协议应运而生。DTLS提供了与TLS相当的加密安全保障，但其设计专为UDP等数据报协议服务，从而在提供安全性的同时，完美地规避了TCP熔断问题 14。
QUIC作为一种基于UDP的现代传输协议，从根本上解决了TCP-over-TCP问题。它在单个连接内提供了多个独立的、可靠的、多路复用的流 9。理论上，如果将TCP隧道化于单个QUIC流之上，当该流因丢包而阻塞时，仍可能出现类似熔断的队头阻塞问题 17。然而，QUIC的真正优势在于其对不可靠数据报的扩展支持。通过QUIC数据报扩展，数据包可以在QUIC层传输而无需等待重传，这完美地模拟了UDP隧道的理想特性，同时保留了QUIC协议固有的加密和认证优势 9。
sshuttle等工具提供了一种巧妙的应用层解决方案 18。它并非在网络层隧道化IP包，而是在更高的应用层进行操作。其工作机制如下：
sshuttle在本地拦截外发的TCP连接，提取出纯粹的应用数据流，然后将这些数据通过一个稳定的SSH（TCP）连接进行多路复用传输。在远程服务器端，数据流被重新组装，并注入一个新的TCP连接，最终发往目标地址 18。
这种模式是“数据-over-TCP”，而非“TCP-over-TCP”。通过在传输前剥离内层TCP的协议头，它完全消除了两个控制循环之间相互干扰的可能性，展示了如何通过智能的应用层设计来规避传输层的架构陷阱。
与WAN环境下的协议分层冲突不同，局域网中的TCP性能崩溃，即TCP Incast问题，并非源于协议设计缺陷，而是TCP协议为广域网设计的特性与现代数据中心独特的硬件和工作负载模式之间不匹配的产物。
TCP Incast被精确定义为一种在高带宽、低延迟网络中，影响“多对一”通信模式的灾难性吞吐量崩溃现象 5。其发生的典型环境具备以下特征：网络带宽高达10 Gbps或更高，往返时间（RTT）低至微秒级别，并且普遍使用缓冲区较浅（shallow buffers）的商用交换机 5。
必须强调的是，Incast与TCP-over-TCP熔断在根本上是不同的。Incast并非由协议的错误分层引起，而是由一种特定的、高度同步化的应用工作负载与网络硬件（特别是交换机缓冲区）的物理限制相互作用而触发的 5。
TCP Incast的直接触发因素是一种被称为“多对一、屏障同步”（many-to-one, barrier-synchronized）的通信模式 21。在这种模式下，一个客户端（或聚合节点）同时向多个服务器（或工作节点）发出请求，并等待所有服务器的响应全部到达后，才能开始下一轮处理。
这种模式在现代数据中心的大规模并行应用中极为常见：
MapReduce： 在“shuffle”阶段，大量的mapper节点几乎同时将其计算出的中间结果发送给同一个reducer节点 6。
分布式文件系统（如pNFS, GFS）： 客户端读取一个跨多个存储服务器条带化的数据块时，所有相关的服务器会同时响应，将各自的数据分片发往客户端 5。
Web搜索与社交网络： 一个聚合器向成百上千个后端服务查询数据（如搜索结果片段、用户资料组件），这些服务几乎在同一时刻返回响应 6。
这种高度同步的响应模式会在极短的时间内（微秒级）形成一股巨大的流量“微突发”（micro-burst），所有流量都汇集到交换机上连接客户端的同一个出端口。交换机有限的出口缓冲区专为统计复用的随机流量设计，无法承受这种确定性的、同步的流量洪峰，导致缓冲区迅速被填满并溢出。其结果是，来自多个不同TCP流的数据包被大量、同时地丢弃 5。
在遭遇大规模同步丢包后，TCP首选的高效恢复机制——快速重传（fast retransmit）——在Incast场景下往往会失效。这是因为参与同步通信的TCP流通常是短流，每个流只传输一小块数据（称为服务器请求单元，Server Request Unit或SRU） 5。当一个数据包被丢弃后，由于后续没有足够的数据包在途，接收端无法生成触发快速重传所需的三个重复确认（ACK） 25。
由于快速重传机制失效，所有遭遇丢包的TCP流被迫退回到最后的恢复手段：等待重传超时（RTO）。问题的核心在于网络实际RTT与TCP默认最小RTO（RTOmin）之间存在着惊人的数量级差异：
数据中心RTT： 通常低于250微秒 26。
Linux默认RTOmin： 200毫秒，即200,000微秒 6。
RTOmin的值比数据中心的RTT高出近三个数量级。当数十个TCP流同时进入RTO恢复状态时，客户端的高速链路将在长达200毫秒的时间内完全空闲，静静地等待重传数据的到来。正是这种大规模的、同步的传输停顿，直接导致了观测到的吞吐量雪崩，一个10Gbps的链路其实际有效吞吐量可能骤降至数Mbps的水平 19。
Incast现象深刻地揭示了一个系统性问题：它是分布式系统高度同步化所产生的负面涌现特性。问题的根源并非某个组件的故障，而是大量组件（服务器、TCP协议栈）在完全相同的时间点上，以完全相同的方式“正确”地执行操作。应用的屏障同步强制所有TCP流同步启停，而交换机的浅缓冲区则强制它们同步经历丢包。这种高度的同步性，使得原本为统计复用设计的TCP拥塞控制机制彻底失效，因为网络流量模式从随机和统计性转变为确定性和脉冲性，超出了TCP协议原始设计的假设范围。
针对Incast问题，研究和实践领域已经发展出一系列解决方案，从早期的参数调整和硬件变通，演进到对数据中心拥塞控制范式的根本性重塑。
早期的研究证明，将TCP的RTOmin从200毫秒大幅降低至微秒级别，可以显著缓解Incast问题 6。然而，这种方法在实践中面临挑战，例如需要操作系统提供高精度的计时器支持，并且在网络延迟稍有波动时可能引发错误的超时重传 20。
在硬件层面，增加交换机缓冲区大小或启用以太网流控（Ethernet Flow Control）是另外两种部分有效的方案。更大的缓冲区能够推迟Incast现象的发生，但成本高昂，且治标不治本 28。以太网流控在单交换机环境下有效，但在跨越多台交换机的复杂拓扑中，可能引发严重的队头阻塞（head-of-line blocking），因此并非一个普适且安全的解决方案 28。
显式拥塞通知（ECN）提供了一种优于依赖丢包来感知拥塞的机制 29。它允许交换机在队列深度超过一个预设阈值时，主动地在IP包头中设置一个标记（“拥塞经历”位），而不是等到缓冲区完全耗尽后才开始丢包。这个标记为发送方提供了一个关键的、主动的早期拥塞预警信号。
数据中心TCP（DCTCP）是微软研究院提出的、业界领先的Incast解决方案，它代表了数据中心拥塞控制思想的一次重大转变 27。DCTCP的核心创新在于，它巧妙地利用ECN的单比特信令，构建出一个多比特的、与拥塞程度成比例的反馈信号 27。
DCTCP的算法机制可以分解为三个部分：
交换机行为： 支持ECN的交换机被配置一个极低的队列标记阈值（K）。当数据包到达且队列长度超过K时，交换机就在该数据包的IP头中设置“拥塞经历”（CE）标志位 32。
接收端行为： DCTCP接收端在收到带有CE标记的数据包后，会在其返回的TCP ACK包中设置“ECN回显”（ECE）标志，其实现方式能够让发送端精确地追踪被标记的数据包序列 32。
发送端行为： DCTCP发送端在一个RTT周期内，持续计算被标记数据包所占的比例（α）。然后，它不再像标准TCP那样在收到拥塞信号后将拥塞窗口减半，而是根据计算出的α值，按比例地、平滑地减小拥塞窗口 31。
这种与拥塞程度成正比的精细化响应机制，使得DCTCP能够进行频繁而微小的速率调整，从而将交换机队列长期维持在非常低的水平（比标准TCP节省90%的缓冲区占用），同时依然能实现链路带宽的最大化利用 26。通过从根本上避免大规模队列积压，DCTCP有效地防止了导致Incast的大规模同步丢包，从而解决了这一难题 27。
本节将综合前述分析，通过一个清晰的对比框架，对TCP-over-TCP熔断和TCP Incast进行系统性总结，并为网络架构师和系统管理员提供可操作的战略性指导。
为了清晰地阐明两种性能崩溃现象的本质区别，下表从多个技术和操作维度对其进行了直接比较，并辅以叙述性解释。
表1：TCP-over-TCP熔断与TCP Incast的对比分析
属性 |
TCP-over-TCP 熔断 |
TCP Incast |
主要环境 |
广域网（WAN），典型场景为隧道应用（VPN、SSH隧道）。 |
高速局域网（LAN），特指数据中心、集群计算环境。 |
根本原因 |
架构性问题： 根本的协议分层逻辑冲突。 |
系统性问题： 应用工作负载、网络拓扑与传输协议假设之间的失配。 |
核心机制 |
两个嵌套的TCP拥塞控制算法和重传计时器之间发生破坏性干扰 7。 |
大量发送端的同步微突发流量压垮了交换机的浅缓冲区，导致大规模同步丢包和超时 5。 |
触发条件 |
将一个TCP流封装在另一个TCP隧道内 3。 |
“多对一、屏障同步”的数据传输模式（如MapReduce shuffle、分布式文件读取） 6。 |
主要症状 |
单个逻辑连接上出现严重的、持续的吞吐量下降和高且不可预测的延迟 10。 |
在同步操作期间，吞吐量发生灾难性的、近乎完全的崩溃（有效吞吐量下降数个数量级） 5。 |
关键TCP失效点 |
因网络状态被遮蔽而导致的伪超时重传和不恰当的拥塞窗口缩减 1。 |
无法触发“快速重传”，被迫回退到灾难性漫长的最小RTO（200ms）恢复机制 25。 |
主要解决方案 |
规避架构： 使用UDP作为外层隧道协议（如UDP模式的OpenVPN、WireGuard、QUIC） 4。 |
适配协议： 部署支持ECN的交换机，并采用DCTCP等先进的传输协议 27。 |
综上所述，TCP-over-TCP熔断是由错误的协议嵌套引发的逻辑层面的冲突，其解决方案在于纠正协议分层。而TCP Incast则是特定应用模式与物理层面（交换机缓冲区）限制交互作用的结果，其解决方案在于使传输协议能够更智能地适应这种极端流量模式。
基于上述技术分析，可以为网络设计者和运维人员提供以下明确的战略建议：
对于广域网和隧道应用：
永远不要使用TCP作为VPN或其他IP隧道的传输协议，除非绝对必要（例如，为了绕过只允许特定TCP端口的严格防火墙）。最佳实践和行业标准是使用基于UDP的协议，如WireGuard或正确配置为UDP模式的OpenVPN，并利用DTLS来确保安全性
4。对于面向未来的设计，应将QUIC视为更优越的隧道平台
9。
对于数据中心网络：
对于任何新建的高性能数据中心，或在现有环境中观察到类似Incast症状（例如，大规模并行任务性能不佳）的情况，强烈建议投资于支持ECN的交换矩阵，并部署如DCTCP这样的先进ECN传输协议。这不应被视为简单的参数调整，而是一项根本性的架构决策，是支持现代高度并行、延迟敏感型应用所必需的
27。单纯采购具有更大缓冲区的交换机是一种昂贵且治标不治本的临时措施，无法从根本上解决问题
28。
本报告的分析表明，“TCP熔断”并非一个单一、孤立的问题，而是对至少两种截然不同的网络性能崩溃现象的统称，它们各自拥有独特的成因、环境和解决方案。
报告的核心结论是：TCP-over-TCP熔断是一个可以、也应该被避免的架构设计错误，其根源在于违反了协议分层的基本原则。相比之下，TCP Incast则是一种在高性能计算环境中，由系统高度同步化所涌现的复杂现象，它的出现要求我们重新思考并设计新一代的、适应数据中心特性的传输协议。
从TCP-over-TCP催生出对UDP隧道和QUIC的需求，到TCP Incast推动了DCTCP等精细化拥塞控制算法的诞生，这些挑战与创新共同展示了TCP/IP生态系统卓越的适应性和演进能力。通过深刻理解这些问题的本质区别，网络专业人员能够做出更明智的架构决策，从而构建出更高效、更稳健的网络系统，以应对未来不断增长的性能需求。
An Investigation of the TCP Meltdown Problem and ... - ResearchGate, accessed on August 29, 2025, https://www.researchgate.net/publication/330024051_An_Investigation_of_the_TCP_Meltdown_Problem_and_Proposing_Raptor_Codes_as_a_Novel_to_Decrease_TCP_Retransmissions_in_VPN_Systems_Proceedings_of_Fifth_International_Conference_INDIA_2018_Volume_1
Performance Comparison between TCP and UDP Protocols in Different Simulation Scenarios - ResearchGate, accessed on August 29, 2025, https://www.researchgate.net/profile/Musatafa-Albadr/publication/329698255_Performance_Comparison_between_TCP_and_UDP_Protocols_in_Different_Simulation_Scenarios/links/5c15d51692851c39ebf08b18/Performance-Comparison-between-TCP-and-UDP-Protocols-in-Different-Simulation-Scenarios.pdf
Tunneling protocol - Wikipedia, accessed on August 29, 2025, https://en.wikipedia.org/wiki/Tunneling_protocol
WireGuard - Wikipedia, accessed on August 29, 2025, https://en.wikipedia.org/wiki/WireGuard
Measurement and Analysis of TCP Throughput Collapse in Cluster-based Storage Systems, accessed on August 29, 2025, https://www.researchgate.net/publication/221353829_Measurement_and_Analysis_of_TCP_Throughput_Collapse_in_Cluster-based_Storage_Systems
Understanding TCP incast throughput collapse in datacenter networks - Web Services, accessed on August 29, 2025, https://people.ucsc.edu/~warner/Bufs/understanding-tcp-incast.pdf
Understanding TCP over TCP: effects of TCP tunneling on end-to-end throughput and latency | Request PDF - ResearchGate, accessed on August 29, 2025, https://www.researchgate.net/publication/238445492_Understanding_TCP_over_TCP_effects_of_TCP_tunneling_on_end-to-end_throughput_and_latency
Experimental performance comparison between TCP vs UDP tunnel using OpenVPN, accessed on August 29, 2025, https://www.researchgate.net/publication/304287577_Experimental_performance_comparison_between_TCP_vs_UDP_tunnel_using_OpenVPN
Trust, 2-Party Relays, and QUIC - Obscura VPN, accessed on August 29, 2025, https://obscura.net/blog/bootstrapping-trust/
How (not) to Build a Transport Layer for Anonymity Overlays - The Free Haven Project, accessed on August 29, 2025, https://www.freehaven.net/anonbib/cache/tschorsch:translayeranon.pdf
What is TCP-over-TCP and how does OpenVPN under TCP mode avoid the issue? - Server Fault, accessed on August 29, 2025, https://serverfault.com/questions/1045786/what-is-tcp-over-tcp-and-how-does-openvpn-under-tcp-mode-avoid-the-issue
A Performance Analysis of VPN Technologies Used in an IoT Environment - Advances in Electrical and Computer Engineering, accessed on August 29, 2025, https://aece.ro/displaypdf.php?year=2025&number=2&article=9
Under what circumstances is TCP-over-TCP performing significantly worse than TCP alone (2014)? - Server Fault, accessed on August 29, 2025, https://serverfault.com/questions/630837/under-what-circumstances-is-tcp-over-tcp-performing-significantly-worse-than-tcp
Transport Layer Security - Wikipedia, accessed on August 29, 2025, https://en.wikipedia.org/wiki/Transport_Layer_Security
Datagram Transport Layer Security - Wikipedia, accessed on August 29, 2025, https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security
It's time to replace TCP in the datacenter (2023) - Hacker News, accessed on August 29, 2025, https://news.ycombinator.com/item?id=42168997
Can TCP meltdown happen for TCP over Quic? - Stack Overflow, accessed on August 29, 2025, https://stackoverflow.com/questions/71049993/can-tcp-meltdown-happen-for-tcp-over-quic
How does sshuttle avoid of TCP-over-TCP curse? - Stack Overflow, accessed on August 29, 2025, https://stackoverflow.com/questions/41427123/how-does-sshuttle-avoid-of-tcp-over-tcp-curse
Understanding TCP Incast and Its Implications for Big ... - USENIX, accessed on August 29, 2025, https://www.usenix.org/system/files/login/articles/chen12-06.pdf
Understanding TCP Incast Throughput Collapse in Datacenter Networks - Events, accessed on August 29, 2025, https://conferences.sigcomm.org/sigcomm/2009/workshops/wren/papers/p73.pdf
Survey on TCP Incast Problem in Datacenter Networks, accessed on August 29, 2025, https://serialsjournals.com/abstract/42414_75-cha-7.pdf
TCP Incast in Data Center Networks: Issue and Existing Solutions - ResearchGate, accessed on August 29, 2025, https://www.researchgate.net/publication/364080861_TCP_Incast_in_Data_Center_Networks_Issue_and_Existing_Solutions
Controlling TCP Incast Congestion in Data Centre Networks - White Rose Research Online, accessed on August 29, 2025, https://eprints.whiterose.ac.uk/id/eprint/89457/1/M21TCPA.pdf
Measurement and Analysis of TCP Throughput Collapse in Cluster-based Storage Systems - Parallel Data Lab, accessed on August 29, 2025, https://www.pdl.cmu.edu/PDL-FTP/Storage/CMU-PDL-07-105.pdf
What is TCP incast? - Quora, accessed on August 29, 2025, https://www.quora.com/What-is-TCP-incast
DCTCP: Efficient Packet Transport for the Commoditized Data Center - ResearchGate, accessed on August 29, 2025, https://www.researchgate.net/publication/238065260_DCTCP_Efficient_Packet_Transport_for_the_Commoditized_Data_Center
Data Center TCP (DCTCP) - Microsoft, accessed on August 29, 2025, https://www.microsoft.com/en-us/research/wp-content/uploads/2017/01/dctcp-sigcomm2010.pdf
TCP Incast - Parallel Data Laboratory - Carnegie Mellon University, accessed on August 29, 2025, https://www.pdl.cmu.edu/Incast/
Explicit Congestion Notification - Wikipedia, accessed on August 29, 2025, https://en.wikipedia.org/wiki/Explicit_Congestion_Notification
RFC 8087 - The Benefits of Using Explicit Congestion Notification (ECN) - IETF Datatracker, accessed on August 29, 2025, https://datatracker.ietf.org/doc/rfc8087/
Data Center TCP (DCTCP) - Stanford University, accessed on August 29, 2025, https://web.stanford.edu/~balaji/papers/10datacenter.pdf
draft-ietf-tcpm-dctcp-10 - Data Center TCP (DCTCP): TCP Congestion Control for Data Centers - IETF Datatracker, accessed on August 29, 2025, https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/10/
RFC 8257 - Data Center TCP (DCTCP): TCP Congestion Control for Data Centers, accessed on August 29, 2025, https://datatracker.ietf.org/doc/rfc8257/
Microsoft's Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters, accessed on August 29, 2025, https://potaroo.net/ietf/all-ids/draft-bensley-tcpm-dctcp-05.html
NSX Administration Guide, accessed on August 29, 2025, https://vdr.one/wp-content/uploads/2015/12/nsx_6_admin.pdf