5Gでのトランスポートプロトコルの評価

f:id:aptpod_tech-writer:20201211185209j:plain

研究開発グループのエンジニアの酒井 (@neko_suki)です。

aptpod Advent Calendar 2020 の14日目を担当します。

研究開発グループでは、TCP/QUIC/UDP などのトランスポートプロトコルの製品適用に向けた検証を行っています。

今回の記事は前回の「5Gのネットワークを計測してみた」の続きになります。

tech.aptpod.co.jp

今回の記事では、以下の2つを紹介します。

  • モバイルルーターをWi-Fi STATION SH-52A に固定して行った4G/5G のping/iperf3 の計測結果
  • 4G/5G でのTCP/QUIC/UDP の計測結果

計測機材の紹介

計測機材は前回と同じ機材を使用しています。

計測用のクライアントは組み込み製品を想定しRaspberry Pi4を使用しました。計測用のサーバは、AWS上でEC2のm5.xlargeのUbuntuインスタンスを使用しました。Raspberry Pi側はUbuntu 20.04、サーバ側はUbuntu 18.04 を使用しています。

また、5G/4Gの接続にはDocomoから販売されているモバイルルーター Wi-Fi STATION SH-52A を使用しています。SH-52Aは「5G/4G/3G」で接続するモードと「4G/3G」で接続するモードを選択可能です。「5G/4G/3G」モードでは5Gの接続に固定されるわけではありませんが、今回計測を行った場所では安定して5Gに接続が可能でした。

以下のような構成で計測をします。

f:id:aptpod_tech-writer:20201209175648p:plain:w200

前回の記事の再掲になりますが、計測に使った機器は以下のように接続しています。

f:id:aptpod_tech-writer:20201209175705j:plain

計測場所の紹介

前回の記事で計測を行った場所と同じ日産スタジアム東ゲート付近の広場で、12/4に計測を行いました。

f:id:aptpod_tech-writer:20201202094656j:plain

ネットワーク計測の結果

pingの計測

pingの計測では、pingコマンドを使って1秒間隔で60秒間RTT (Round Trip Time)を計測しました。

比較のために、12/4 に計測した結果と前回の記事の計測結果の両方を載せます。前回の記事では4Gの計測はモバイルWi-FiルーターL-01G というモバイルルーターを使っていました。

以下の表には、前回の結果と今回の計測結果の、平均値、10パーセンタイル値、50パーセンタイル値、90パーセンタイル値を載せています。

4G(2020/12/4計測) 5G(2020/12/4計測) 4G(2020/12/2掲載) 5G(2020/12/2掲載)
平均値 40.3msec 43.3msec 74.5msec 38.5msec
10パーセンタイル値 31.7msec 32.9msec 65.2msec 30.4msec
50パーセンタイル値 40.5msec 44.0msec 75.6msec 39.15msec
90パーセンタイル値 47.9msec 52.12msec 83.9msec 46.09msec

前回の記事では、5Gの方が4GよりもRTTが小さいと紹介しましたが、モバイルルーターをSH-52Aに統一した結果を見ると、4Gと5GのどちらもRTTには差分がなさそうです。

L-01G を使用した場合のみ大きく違う値が出ていますが、この原因は今後調査を行い機会があればお伝えしたいと思います。

iperf3の計測

iperf3の計測では、UDPとTCP(輻輳制御はBBRを使用)のそれぞれについて、クライアントからサーバに20秒間データを送信する計測を3回行いました。

UDPの結果

UDPの計測は律速するまで帯域を上げています。4Gは25Mbps、5Gは50Mbpsを設定しています。

4G(2020/12/4計測) 5G (2020/12/4計測) 4G(2020/12/2掲載) 5G (2020/12/2掲載
1回目 20.9 Mbps 45.2 Mbps 17.4Mbps 45.2Mbps
2回目 21.2 Mbps 18.4 Mbps 24.6Mbps 47.0Mbps
3回目 20.7 Mbps 39.4 Mbps 25.0 Mbps 47.0 Mbps

このように、おおむね5Gの方が高いスループットを得られています。 UDPの2回目の時は、未到達のパケットがかなり多かったため4G側より低い値になっていますが、ネットワークの変動によるものではないかと思います。

TCPの結果

TCPの場合はビットレートを指定しなくても流せる上限まで流そうとするのでビットレートの指定はしません。 計測結果は以下のようになりました。

4G(2020/12/4計測) 5G (2020/12/4計測) 4G(2020/12/2掲載) 5G (2020/12/2掲載
1回目 10.3 Mbps 40.3 Mbps 9.33Mbps 15.9Mbps
2回目 13.6 Mbps 43.4 Mbps 11.1Mbps 17.8Mbps
3回目 16.2 Mbpbs 34.2 Mbps 12.3 Mbps 34.4 Mbps

おおむね5Gの方が高いスループットが出ています。ただし、5Gの結果は前回の記事の結果と今回の結果で大きく差が出ています。したがって、変動の影響はありうると考えるのがよさそうです。

トランスポートプロトコルの評価

ここからは、トランスポートプロトコルの評価についてお伝えします。 実験では、

  • TCP(輻輳制御はCUBICを使用)
  • QUIC(輻輳制御はCUBICを使用)
  • UDP

をそれぞれ4G/5Gで評価しています。

計測は4G/5Gに対してそれぞれ5回ずつ行いました。

実験内容

実験は、高頻度なデータの塊をクライアントからサーバに伝送するユースケースを設定します。

送信するデータは1unit (データの単位)を8byteとします。これを1000 unit/secで送信します。そのために1msec毎に1unitのデータをクライアント側で生成します。

弊社製品のintdashでは、IPやTCPヘッダのオーバーヘッドを低減するために、一定期間のユニットをバッファリングして送信する仕組みを導入しています。

なので、それに倣って10個の連続したデータを一つの塊として送信します。このバッファリングしたデータ単位はflush*1と呼ばれています。

以下の図のように、送信時刻までの10msec分のデータが1つのflushとしてまとめて送信されます。

f:id:aptpod_tech-writer:20201210163852p:plain
flush

クライアント-サーバ間の送信遅延を評価するために、データがクライアントで生成された時刻とサーバ側で受信した時刻の差分を遅延時間として定義します。 サーバでは1flush分のデータをまとめて受信します。そのため、flushの先頭のunitは、ネットワークの上りの遅延+10msec程度の遅延が発生します。

f:id:aptpod_tech-writer:20201210164238p:plain
クライアントとサーバ間のデータのやり取り

この場合、遅延時間は以下のようになります。

生成時刻 受信時刻
1unit 0msec ネットワークの上りの遅延 + 10msec
2unit 1msec ネットワークの上りの遅延 + 9msec
3unit 2sec ネットワークの上りの遅延 + 8msec
... ... ...
10unit 9msec ネットワークの上りの遅延+1msec

ここから、理想的な状態では「ネットワークの上りの遅延+10msec」の範囲に、遅延時間が収まることが期待されます。

評価結果

それでは実際に結果を見ていきます。

TCPの結果

ここでは5回の計測結果の中から一つの結果を取り上げていますが、他の結果も同様の傾向になっています。

まずはヒストグラムです。横軸は、遅延時間、縦軸は頻度になっています。

f:id:aptpod_tech-writer:20201211150016p:plain
TCP ヒストグラム

理想的には10msec以内に収まってほしいのですが、5Gの場合は20msec、4Gの場合は40msec の範囲にデータが収まっていることがわかります。pingの結果が4G/5Gで差異がなかったことを考えると、4G/5Gの回線のみを変えて結果に差分が出た点は疑問が残ります。

原因は、クライアントからサーバの間のどこかで想定外のバッファリングが行われたのではないかと予想しています。

ヒストグラムだけだと理解が難しいので、時系列でのプロットも見てみます。

まずは、5Gの結果です。以下のグラフは横軸が10秒間に送信される10000unitのデータの番号で、縦軸がそれぞれの遅延時間になります。5Gの場合は19msec~36msec 辺りに収まっていることがわかります。

f:id:aptpod_tech-writer:20201211144734p:plain
TCP(5G)の結果

次に4Gの結果です。4Gの場合は多くの値が、10msec~50msecの間にあることがわかります。

f:id:aptpod_tech-writer:20201211144751p:plain
TCP(4G)の結果

原因は調査が必要ですが、ヒストグラムの違いの理由は明らかになりました。

QUICの結果

QUICの結果のヒストグラムは以下のようになります。

f:id:aptpod_tech-writer:20201211150035p:plain
QUIC ヒストグラム

ここでも、理想的には10msec以内に収まっていてほしいものが、5Gの場合は20msec、4Gの場合は40msec の範囲に収まっていることがわかります。

5Gの場合はTCPと同じような結果になっています。一方で4Gの場合は2つの山が見える結果になっています。

TCPの時と同様に、時系列のプロットを見てみます。

5Gの結果は以下のようになります。ヒストグラムで見たように、18msec~38msecの間にデータが収まっていることがわかります。

f:id:aptpod_tech-writer:20201211144900p:plain
QUIC(5G)の結果

次に、4Gの結果です。4Gの場合は、18msec~34msecの範囲と、15msec~45msecの二つのパターンがあることがわかります。これはネットワーク上で別の経路を通った結果が反映されている可能性がありそうです。この結果、ヒストグラムには二つの山ができていると考えられます。

f:id:aptpod_tech-writer:20201211144918p:plain
QUIC(4G)の結果

UDPの結果

UDPの結果のヒストグラムは以下のようになります。

f:id:aptpod_tech-writer:20201211150059p:plain
UDP ヒストグラム

TCP/QUICの結果と異なり、5Gの方が遅延時間のとる範囲が大きくなっています。

ここでも時系列のデータを見てみます。

5Gの結果はこれまでと異なり、値のとる範囲が安定していないことがわかります。その結果がヒストグラムにも反映されていたようです。

f:id:aptpod_tech-writer:20201211144954p:plain
5G(UDP)の結果

逆に4Gの結果は、最初の2秒(2000unit)の振れ幅は大きいですが、それ以降は 19msec~29msec 辺りに落ち着いているデータが多いように見えます。

f:id:aptpod_tech-writer:20201211145011p:plain
4G(UDP)の結果

考察

疑問が多く残る結果になりましたが、少なくとも以下の3点は言えそうです。

  • 10unit以上のデータがまとまって届いているため、経路上のどこかで予期していないキューイングが発生している可能性が考えられる
  • ネットワーク上の経路の違いが遅延時間に影響を与えている
  • TCP/QUIC/UDPすべての結果を踏まえると、4G/5Gの違いがあると言い切れる根拠は今回の実験では得られなかった

疑問が多く残っているため、今後も調査・検証を続けていこうと思います。

まとめ

今回の記事では「5Gでのトランスポートプロトコルの評価」について紹介しました。

ネットワークの再計測の結果やトランスポートプロトコルの評価結果は疑問が多く残る結果となりました。今後も調査・検証を継続、新しい事実が判明したらお届けしたいと思います。

最後までご覧いただきありがとうございました。