A Pure HTTP/3 Alternative to MQTT-over-QUIC in Resource-Constrained IoT の備忘録

HTTP3 でpub-subとMQTT-over-QUICの比較をIoTの観点から行った論文の備忘録です。

IoTという文脈で、ネットワークエミュレータに遅延と帯域を設定して、性能（最初のデータが到達するまでの時間、通信終了までの時間やスループット）、ネットワークへのオーバーヘッド（バイト量とパケット数）、リソースの使用状況（CPU使用率、RAM使用量）、の3つを比較しています。

性能面では、H3 pub-subのほうが優れた結果が得られていますが、ネットワークのオーバーヘッドやリソースの使用状況はHTTP3 pub-subのほうが MQTT-over-QUICよりも多くのリソースを使用する結果となったようです。

これらの結果から、IoTという文脈を考えた場合、トレードオフが存在しているということを示唆しています。

元論文は下で読めます。

arxiv.org

実装について

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に対応させたものが使われています。

github.com

brokerは、VolantMQ というブローカーをQUICに対応させたものが使われています。

github.com

H3 pub-sub

H3 pub-sub は、DriftというHTTP/2を使ってPub/Subを行うOSSにH3を適用したものが使用されています。

github.com

Driftでは以下のテーブルのように、HTTPのメソッドをpub/subにマッピングしています。トピック名はURLにエンコードされます。

HTTPメソッドとpub/sub のマッピング

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

実験の結果から、

1. ネットワークオーバーヘッドの観点では比較可能

2. H3はパイプライン化された認証により、最初のデータが到達するまでの時間を1RTT節約できる

3. 受信はH3のほうが数秒早い

4. 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のバイト数の差が影響しているように思えます。