HTTP3 でpub-subとMQTT-over-QUICの比較をIoTの観点から行った論文の備忘録です。
IoTという文脈で、ネットワークエミュレータに遅延と帯域を設定して、性能（最初のデータが到達するまでの時間、通信終了までの時間やスループット）、ネットワークへのオーバーヘッド（バイト量とパケット数）、リソースの使用状況（CPU使用率、RAM使用量）、の3つを比較しています。
性能面では、H3 pub-subのほうが優れた結果が得られていますが、ネットワークのオーバーヘッドやリソースの使用状況はHTTP3 pub-subのほうが MQTT-over-QUICよりも多くのリソースを使用する結果となったようです。
これらの結果から、IoTという文脈を考えた場合、トレードオフが存在しているということを示唆しています。
元論文は下で読めます。
実装について
H3 pub-sub、MQTT-over-QUICともに既存の実装の下回りをQUICに変更したものが使用されています。 またQUICの実装は、公平な比較のために両者ともquic-goを使用しています。これにより、QUICの実装差ではなく、H3 pub-subとMQTTの比較が可能になります。
MQTT-over-QUIC
クライアント(publisher/subscriber) は [Eclipse Paho](https://github.com/eclipse/paho.mqtt.golang というクライアントをQUICに対応させたものが使われています。
brokerは、VolantMQ というブローカーをQUICに対応させたものが使われています。
H3 pub-sub
H3 pub-sub は、DriftというHTTP/2を使ってPub/Subを行うOSSにH3を適用したものが使用されています。
Driftでは以下のテーブルのように、HTTPのメソッドをpub/subにマッピングしています。トピック名はURLにエンコードされます。
Network Modeling
NetEmを使用して、遅延と帯域のスロットリングを実現しています。
Narrowband-IoT (NB-IoT) ネットワークパラメーターというのがあり、それをパラメータとして使っているようです。
具体的な値は以下の値です。RTTがかなり大きい印象を受けます。
Experimental Setup
VirtualBox上のOSはUbuntu 18.04.4 (kernel 4.15.0-77)で、publisher, subscriber, brokerをそれぞれ実行しているようです。 quic-goは、v0.20.1を使用しています。H3はdraft29 です。
Results
結果は、性能指標での評価、ネットワークのオーバーヘッドの評価、リソース使用量の評価の3つで評価されています。
Performance Indicator
性能指標の評価の1つ目は、publisherの最初のリクエスト（下回りのQUICの接続は差が出ないのでおそらく接続確立後）から、フレームの最初のデータが届くまでの時間です。（おそらく、publisher→broker→subscriberのことを指していると思われます）
Fig 2は横軸が送信するデータサイズ、縦軸がフレームの最初のデータが届くまでにかかった時間です。 Fig 2 から見てわかるように、MQTT-over-QUICはRTT2回分、H3 pub-subはRTT 1回分になっています。
この原因は、認証プロセスの違い実装の違いから来ているようです。 MQTT-over-QUICの場合は、最初にユーザーのcredentialを送り、ブローカーからのacknowledgementを待ちます。なので、publisherはbrokerからのレスポンスを待ってから実際のデータを送ることになります。その結果、1-RTT分余分な遅延時間が発生します。
一方で、H3 pub-subの実装では、一つのパケットに、ユーザーのcredentialを含むheader frameとパブリッシュするメッセージを含むdata frame が含まれます。 なので、MQTT-over-QUICと異なり、レスポンスは待たないので1-RTT分の遅延のみでsubscriberまでデータが到達します。
性能指標での評価の2つ目は、接続が閉じるまでの時間とスループットです。
この実験では、5つのpublisherを1秒毎に立ち上げて1KBのメッセージをbrokerに送信します。そして、brokerは2%のパケットをランダムにドロップさせます。
Fig 3 は横軸が、時間、縦軸がスループットになっているようです。サンプリングは200msecで行っています。
H3 pub-subの接続は8秒で終了していますが、MQTT-over-QUIC はH3 pub-subより約1.4秒時間がかかっています。
コネクションレベルで見ると、H3 pub-subのピークのスループットは24%高いですが、合計した場合は、2.88% MQTT-over-QUICのほうが高いようです。
同じデータ量を送っているため、H3 pub-sub のほうが早く終わるからスループットが高いようです。
Network Overhead
ネットワークのオーバーヘッドの評価では、brokerとpublisherの間で交換されたバイト数と実際のメッセージサイズを比較しています。
FIg 4の横軸はメッセージサイズを1KBから10KBまで増やした値で、縦軸は実際にやり取りがあったトランザクションのサイズ（Kbyte)です。
軸を見るとわかるのですが、メッセージサイズよりもトランザクションのサイズのほうが3～20倍程度大きいことが分かります。
H3 pub-subのほうが、MQTT-over-QUICより多くのデータが好感されているためネットワーク負荷が高いと考えられます。ただしこれは平均で3.23%と競争可能なレベルではと主張されています。
送信されたデータサイズのみでなく、送信されたパケット数も同様にH3 pub-subのほうが平均で11% 多いようです。
このような結果になった理由の考察として、NB-IoTはRTTが大きいことが挙げられています。 RTTが2秒と大きいので、チューニングされていないQUICはアグレッシブになります。 例えば、publisherの最初の接続を確立するリクエストに対してbrokerのレスポンスが来るまでに、6回の追加のretry Client Hello パケットが送信されているようです。 これによって更に追加のレスポンスが誘発されます。その結果、Fig4のように、送信したいデータサイズの数十倍のデータが送られる結果となったようです。
C. Device Overhead
デバイスのオーバーヘッドとして、psコマンドによってCPU使用率とRAMの使用量を取得して評価しています。
Fig5はCPU使用率です。横軸がメッセージサイズ、縦軸が使用率になっています。
ここでは、H3 pub-subのほうがMQTT-over-QUICよりも大きい値になっています。プロファイラでこの原因を見ると、H3の実装に使われているTLSのx509の証明書の解析が原因との記述があります。
Fig 6はRAMの使用量です。RAMの使用量はテストに対して安定していたので、ピークのものだけが載っています。
グラフから見てわかるようにH3 pub-sub のほうが、63.6% 使用量が多いようです。
VII. DISCUSSION
実験の結果から、
ネットワークオーバーヘッドの観点では比較可能
H3はパイプライン化された認証により、最初のデータが到達するまでの時間を1RTT節約できる
受信はH3のほうが数秒早い
H3はリソースの制約がある環境ではデバイスへの負担が大きい
ということが分かりました。
ここから、H3 pub-sub は、MQTT-over-QUICと比べると、エンドデバイスへの負担が大きく、リソースに制約のあるIoTにおいてトレードオフの関係があると主張されています。
また、論文では、HTTPはMQTTよりも複雑なため、コードフットプリントの面での影響が起こりえると主張されています。
そして、コーディング方法や最適化によってもリソース消費量が大きく左右されることがあります。 実際、DriftはIoT向けには開発されておらず、また、アクティブなメンテナンスはされておらず、そのことは評価結果から認められると主張しています。
所感
個人的に気になったのは以下の2点です。
1点目は、1-RTT 分節約できるという結果です。MQTTの仕様には詳しくないのですが、プロトコルとしての問題なのか、実装の問題なのかどちらなのかが気になりました。
2点目は、ネットワークのオーバーヘッドの部分です。H3とMQTT-over-QUICのどういうところの差から来るものなのかが気になりました。1パケットあたりのMQTTとHTTP3のバイト数の差が影響しているように思えます。
