Tag: bbr

Amazon EC2 的網路效能

前一篇「在 AWS 上面的 OpenVPN Server 效能」最後的問題就是 EC2 instance 本身的網路效能，畢竟是公司要用的，還是實際測一下數字，之後有人接手的時候也比較清楚是怎麼選這個大小的...

這邊拿的是 AWS 的 ap-southeast-1 (Singapore) 的 EC2 測試，直接在同一個 subnet 裡面開兩台一樣的機器跑 iperf 測試。

機器開機後會先跑這串指令 (除了安裝 iperf 的指令，其他的是出自我自己 wiki 上的 Ubuntu 這頁)，然後再重開機：

sudo fallocate -l 512M /swapfile; sudo chmod 600 /swapfile; sudo mkswap /swapfile; sudo swapon /swapfile; echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab; echo -e "net.core.default_qdisc=fq\nnet.ipv4.tcp_congestion_control=bbr" | sudo tee /etc/sysctl.d/99-tcp.conf; sudo sysctl -p /etc/sysctl.d/99-tcp.conf; sudo apt update; sudo apt dist-upgrade -y; sudo apt install -y apache2-utils apt-transport-https build-essential curl dnsutils dstat git jq locales moreutils most mtr-tiny net-tools p7zip-full pigz prometheus-node-exporter rsync sharutils software-properties-common sysstat unrar unzip vim-nox wget zsh zsh-syntax-highlighting zstd; sudo apt install -y iperf; sudo apt clean

接下來就是一台跑 iperf -s，另外一台跑 iperf -c 10.x.x.x -i 1 -t 3600 讓他跑一個小時看結果了。

我都有跑 tmux 再連到這些機器上，這樣可以捲回去看每一秒的傳輸速度，就可以看出來變化了，不過這邊還是簡單的只列出最高速度 (burstable) 與穩定輸出的速度 (baseline)：

EC2 instance Baseline Burstable vCPU RAM Pricing (USD$)
c6g.medium 500Mbps 10Gbps 1 2GB 0.0392
c6g.large 750Mbps 5Gbps (claimed 10Gbps) 2 4GB 0.0784
c6g.xlarge 1.25Gbps 10Gbps 4 8GB 0.1568
t4g.small 125Mbps 5Gbps 2 2GB 0.0212
t4g.medium 255Mbps 5Gbps 2 4GB 0.0424
t4g.large 510Mbps 5Gbps 2 8GB 0.0848
t4g.xlarge 1Gbps 5Gbps 4 16GB 0.1696

這邊沒列出來的是 burstable 可以持續的時間，但這跟你機器吃的網路資源有關，我就決定只用 baseline 來做決策了，這樣可能會多花一點錢，但會少很多麻煩。

另外這次在處理的過程有被同事提醒各種 bandwidth overhead，所以就順便查了一下資料：

  • OpenVPN 本身的 overhead 大約是 5% (跑 UDP 的時候)：「OpenVPN performance」。
  • SSH 也有些 overhead，大約是 6% (把來回的封包都算進去)：「What is the overhead of SSH compared to telnet?」。
  • rsync 的部份鐵定也有 overhead，但這邊就沒找到現成的文章有統計過了。
  • 另外我自己之前做實驗發現 TCP BBR 的 retransmission algorithm 還蠻激進的，會有 10% packet loss，改用預設的 CUBIC 會好很多，大約 1% 到 2% 左右。

綜合這些測試，我自己抓了 35% 的 overhead 來推估，最後是用 c6g.large 來養 VPN server。750Mbps 的實際流量大約可以包進 550Mbps 的原始流量，大約是 68MB/sec。

不過新加坡與印尼之間的 internet bandwidth 好像還是不太夠，有時候深夜跑也跑不滿... 不過之後 VPN 上的 client 會愈來愈多，應該是不需要降...

TCP Congestion Control Algorithm 的選擇

先前 Ubuntu 桌機用 BBR 跑了一陣子，但有遇到一些問題 (可以參考「Dropbox 測試 BBRv2 的結果」這篇)，所以暫時換成 Westwood，但還是陸陸續續會看一下各種研究。

剛剛在「[tor-relays] TCP CCA for Tor Relays (and especially Bridges)」這邊看到一個經驗談：

Here are my completely unscientific scribbles of how all the various algorithms behaved. The scenario is uploading for a minute or so, observing the speed in MB/sec visually, then recording how it appeared to change during that minute (and then repeating this a couple of times to be certain).

tcp_bic.ko       -- 6...5...4
tcp_highspeed.ko -- 2
tcp_htcp.ko      -- 1.5...3...2
tcp_hybla.ko     -- 3...2...1
tcp_illinois.ko  -- 6...7...10
tcp_lp.ko        -- 2...1
tcp_scalable.ko  -- 5...4...3
tcp_vegas.ko     -- 2.5
tcp_veno.ko      -- 2.5
tcp_westwood.ko  -- <1
tcp_yeah.ko      -- 2...5...6

上面是「目視法」觀察到的速度 (MB/sec)，看了一下維基百科上 TCP-Illinois 的說明，看起來設計的目的是提供給頻寬大、latency 高的情境下：

It is especially targeted at high-speed, long-distance networks.

來跑跑看好了...

Dropbox 測試 BBRv2 的結果

BBRv1 有不少問題，在 BBRv2 有一些改善 (目前還在測試階段，在「TCP BBR v2 Alpha/Preview Release」這邊可以看到一些說明)，而 Dropbox 則是跳下去測試，並且公佈結果：「Evaluating BBRv2 on the Dropbox Edge Network」。

Spoiler alert: BBRv2 is slower than BBRv1 but that’s a good thing.

在文章開頭的這張圖就說明了 BBRv2 的速度比較慢，但是說明這是朝好的方向改善。

BBRv1 的問題其實我自己都有遇到：我自己的 Ubuntu 桌機跑 BBRv1，在我上傳大量資料的時候 (只開一條連線)，會導致 PPPoE 的 health check 失敗，於是就斷線了，另外 VM 裡面的 Windows 7 因為也是 bridge mode 跑 PPPoE，也可以看到斷線嘗試重連的訊息，於是只好改掉...

上面提到的問題就是 BBRv1 造成 packet loss 過高，除了我遇到的問題外，這對於其他 loss-based 的 TCP congestion algorithm 來說會有很大的傷害 (i.e. 不公平)：

Other tradeoffs were quite conceptual: BBRv1’s unfairness towards loss-based congestion controls (e.g. CUBIC, Compound), RTT-unfairness between BBRv1 flows, and (almost) total disregard for the packet loss:

另外一個改善是 BBRv2 加入了 ECN 機制，可以更清楚知道塞住的情況。

整體上來說應該會好不少，不知道之後正式釋出後會不會直接換掉 Linux Kernel 裡的 BBRv1，或是不換，讓 BBRv1 與 BBRv2 共存？

CloudFront 的 BBR 效能提昇

這是在找一些 TCP congestion algorithm 相關的資訊時發現的，看起來 Amazon CloudFront 導入 BBR 一陣子了：「TCP BBR Congestion Control with Amazon CloudFront」。

不過 BBR 被研究的愈來愈多，大家開始發現這個演算法的霸道，跟其他的 TCP congestion algorithm 並不太能和平共存，但這就跟軍事武器一樣，隔壁升級了你就得跟著升級，抱怨沒有用，只會被消滅...

又一個 TCP BBR 的測試結果

TCP BBR 是 Google 發表的 TCP congestion control 演算法，是一個純伺服器端就能夠改善 TCP 壅塞處理的機制。在 Linux Kernel 4.9 之後被納入了。

而 Spotify 有大量資料要傳到使用者端 (像是音檔)，剛好是 TCP BBR 改善的對象之一，實際測試後得到了很不錯的改善數據：「Smoother Streaming with BBR」。

Spotify 公佈的資料沒有提到平台，所以先稍微了解一下他的音質，也就是「Audio settings」這篇。

在 Desktop 是 160kbps/320kbps Ogg (Standard/HQ)。在 Web Player 則是 128kbps/256kbps AAC (Standard/HQ)。

行動平台部份比較複雜，在 iOS 上是 96kbps/160kbps/256kbps Ogg (Normal/High/Extreme)，另外有 Automatic 自動調整的設定。在 Android 平台則是 24kbps HE-AACv2 (Low) 與 96kbps/160kbps/320kbps Ogg (Normal/High/Very high) 以及 Automatic。

而最後 Chromecast 則是 128kbps/256kbps (Standard/Premium)。

測試時可以發現 shutter (指跟不上播放速度) 的情況降低了 6%～10%，而且下載速度增加了 5%～7% (對於慢速的裝置改善更多，10%～15%)：

Taking daily averages, stutter decreased 6-10% for the BBR group. Bandwidth increased by 10-15% for the slower download cohorts, and by 5-7% for the median. There was no difference in latency between groups.

而各地區的差異也可以看出來改善很多：

另外他們在測試時，剛好遇到秘魯的機房連外發生問題，結果意外發現 BBR 還是可以穩定在這種網路環境下運作：

In Peru, the non-BBR group saw a 400-500% increase in stutter. In the BBR group, stutter only increased 30-50%.

In this scenario, the BBR group had 4x bandwidth for slower downloads (the 10th percentile), 2x higher median bandwidth, and 5x less stutter!

在 Ubuntu 18.04 上可以直接設定 BBR，在 Ubuntu 16.04 則可以參考「Ubuntu 16.04 用 speedtest-cli 測試 TCP BBR 效能」這篇的方式升級 kernel 後設定 BBR。

Google 研發出的 BBR: Congestion-Based Congestion Control

Google 針對 TCP 的 congestion control 研究出了新的方法，是個純 sender-side 的演匴法，可以讓現有的 internet 直接換上去使用：「[net-next,14/14] tcp_bbr: add BBR congestion control」。

在 long-lived TCP connection 愈來愈普及後 (像是 HTTP/2)，TCP 連線的最佳化可以用統計模型來計算，這也就是 BBR 的想法：

In a nutshell, BBR creates an explicit model of the network pipe by sequentially probing the bottleneck bandwidth and RTT. On the arrival of each ACK, BBR derives the current delivery rate of the last round trip, and feeds it through a windowed max-filter to estimate the bottleneck bandwidth. Conversely it uses a windowed min-filter to estimate the round trip propagation delay. The max-filtered bandwidth and min-filtered RTT estimates form BBR's model of the network pipe.

不過 QUIC 不是也開始有進展了嗎？(參考「Google Chrome 52 預設開啟了更快的 QUIC (被戲稱為 TCP/2)」這篇)

感覺 QUIC 解決的比較徹底，不過 443/udp 的 firewall 問題的確也是個需要時間解決的課題...