On Paravirualizing TCP: Congestion Control on Xen VMs
summary
Shows that Xen VM scheduling quanta (30 ms slots) inject tens of milliseconds into RTTs so TCP mistakes scheduling delay for network congestion, causing incast collapse with >20 senders; builds pvtcp that detects VM wakeups via jiffies-based wakeup detection and tweaks behavior: extend RTO by 1 ms on sender-side to let delayed ACKs arrive, selectively disable ACK coalescing on receiver-side. Tests with 3 VMs/core, 20 senders show throughput restored and only ~7.4% CPU overhead.
AI-written summary · about
chapters (17)
- 0:00Intro
- 0:35Physical datacenter Virtualized datacenter
- 0:59Virtualization brings "delays"
- 1:40Virtualization brings "delays."
- 2:20Network delays in public clouds
- 2:39Incast network congestion
- 5:12Pseudo-congestion NO network congestion, still RTT spikes.
- 6:38Pseudo-congestion (cont'd)
- 7:07Sender-side vs. Receiver-side
- 7:57A micro-view with tcpdump
- 9:33The sender-side problem: OS reasons
- 11:03Delayed ACK vs. CPU overhead
- 13:39Detect the VM's wakeup moment
- 15:58PVTCP- the receiver VM is preempted
- 17:18PVTCP evaluation: throughput
- 18:42PVTCP evaluation: CPU overhead
- 19:26The buffer of the netback
related talks
34mDeterministic Networking for Real-Time Systems (Using TSN)
22mAdapting TCP for Reconfigurable Datacenter Networks
44mTCP memory isolation on multi-tenant servers
17mRearchitecting the TCP Stack for I/O-Offloaded Content Delivery
23mACK to the Future: TCP in 2025
16mPowerTCP: Pushing the Performance Limits of Datacenter Networks
31mTuning Linux TCP for data-center networks
28mRock around the clock (synchronization