論文 Toward Just-in-Time Data Communications over Shared Networks and Computational Resources on Massive Client Environmentを読んだ。

不急なデータを送ることが原因で緊急のデータのレイテンシーが増えるのは嬉しくないので、さまざまなアプリケーションを総括したフロー制御を提供するプロトコルスタックを提案する論文。

実用例として、自動運転などで用いる通信を例に挙げている。
just-in-time という単語について
関連技術
プロトコル内容
Data Flow Multiplexing Protocol (DFMP) and Data Flow Control Protocol (DFCP)
実験
Overhead of DFMP/DFCP and effect of short packet multiplexing

論文リンク:

https://journals.sagepub.com/doi/full/10.1177/03611981211006731

実用例として、自動運転などで用いる通信を例に挙げている。

車が送受信するデータには、ハンドルやブレーキなどのセンサ情報や危険検知通知情報など安全な運転を行うのに必要なデータと、高度な地図データを作成するための画像データなど緊急ではないデータがある。この緊急でない地図作成データを送るせいで、安全/自動運転を行うのに必要なデータの到着が遅れてない様にしたいという。

just-in-time という単語について

論文中で以下の様に説明している

this paper refers to the data communication that completes the content delivery, at the time that content is actually required by an application, as just-in-time data communication.

つまりアプリケーションが実際にデータが必要な時点までにデータの配信を完了させるデータ通信　のことである。

車の例だとセンサ情報などはすぐに届ける必要があるが、地図作成データは数時間先でも良いという話。

プロトコル内容

RFC1122 ではプロトコルスタックを link layer, IP layer, transport layer, application layer と定義している。

しかしこのIP層で疎通性を確保し、トランスポート層で再送などを実装する方法は最近の技術には合わない場合がある。モバイルエッジコンピューティング（MEC）でデータが前処理されたりする場合など。

下の図の様に chaining layer と data flow layerとそれらを実装するプロトコルDFMPとDFCPを提案する。

chaining layerはIPネットワーク上にオーバーレイネットワークを構築し、データフローはこのchaining layerを介して配信される。chaining layerは、モバイルエッジコンピューティング（MEC）ノードなどのミドルボックスを意識して、データ通信経路を考慮する。

DTLSとUDPを使用した Data Flow Multiplexing Protocol (DFMP) が使用される。

data flow layerはデータフローがアプリケーションで処理可能なデータ形式を保つことを保証する。フロー制御メカニズムを通じて、コンピューティングリソースを含むリソースのアービトレーションを実装する。

Data Flow Control Protocol (DFCP) が使われる。

Data Flow Multiplexing Protocol (DFMP) and Data Flow Control Protocol (DFCP)

DFMPは、異なるjust-in-time要件を持つデータフローを多重化するためのチェーニング層プロトコルです。DFMPは DTLS/UDP上に実装され、データグラムとストリームの両方のデータフローを伝送するように設計されています。

The DFMP common header includes the version of DFMP, protocol flags for extension, the type of the DFMP header, the length of this header including the following DFMP multiplexing header, the flow count representing the number of flows multiplexed in the DFMP packet, the sequence number, and the timestamp for congestion control and data communication quality monitoring.

DFCPは、受信機の計算資源やネットワークの帯域幅などの様々な能力に応じてデータフローを制御するためのデータフローレイヤープロトコルである。このプロトコルの目的は、データフローに優先順位をつけ、just-in-timeの要求を満たすように制御することである。そのため、DFCP では、受信機の計算資源の過負荷などの外部（帯域外）資源不足情報と、パケットロスなどの内部（帯域内）輻輳指標によるフロー制御を行う。この仕組みにより、緩やかなjust-in-time要件のデータフローの帯域やパケット転送の一時停止を制限することができる。DFCPの各フローは、DFMPで多重化される。

DFCP は、ストリームとデータグラムの両方のデータフローをサポートする。DFCPの一般ヘッダは、ストリームとデータグラムのデータフローを運ぶための必須情報を定義している。しかし、ヘッダのオーバーヘッドを最小にし、データグラムデータフローとストリームデータフローの両方をサポートするために、追加のDFCPヘッダはデータフロータイプによって異なるものである。DFCP 一般ヘッダは、DFCP パケットのタイプ、タイプ固有の追加ヘッダを含むヘッダ長、ヘッダとペイロードを含む DFCP パケットのチェックサム、ペイロード長、次のデータフロー層のプロトコルである Next Header を含む。Next Header属性は、1つのDFMPパケットに複数のDFCPフローを多重化するために使用される。

TCPのフロー制御機構は、ウィンドウサイズフィールドを使用して受信者のメモリ量を考慮していた。DFMP/DFCPのリソースアービトレーションの考え方は、TCPのウィンドウサイズと類似しています。しかし、TCPのウィンドウサイズは、一度通知されたウィンドウサイズの縮小を許さないため、動的なリソースの変化に対する配慮を欠いています。また、TCPのウィンドウサイズは、他のフローとのリソースの調整を目的としたものではありません。その結果、TCPのフロー制御はjust-in-timeのデータ通信を実現することができなかった。

DFMPとDFCPのフロー制御は、他のデータフローとの資源調整の仕組みにより、just-in-timeのデータ通信を実現するように設計されています。

-- discussion の章より

実験

二つの車がサーバにデータを送るシナリオを考える。車はそれぞれ just-in-time 要件が 1s の継続的に送るデータ(遠隔運転監視やセンサ情報) と just-in-time 要件が無限のHD map 作成のための大容量画像データの二種類のデータを送ることを想定する。

実験はvm上に4つのdockerコンテナを用いて以下のトポロジーを作成して、実験シナリオの状態を作った。

実験では旧来のTCPとUDPを使用した場合と提案手法のDFMPとDFCPを使った時で比較した。

緊急なデータ(遠隔運転監視やセンサ情報) は再送を行わない UDP と DFCP stateful datagram を使用し、不急なデータ(HD mapのための画像データ)はストリームで送信するため TCP と DFCP stateful stream を使用した。

TCPとUDPを使用した場合、即座に必要な遠隔運転監視のためのデータの受信が数回乱れることが確認されました。サーバ側で受信したUDPパケットとクライアント側で送信したUDPパケットを比較したところ、パケット8,491個中8個（0.094%）の遠隔運転監視トラフィックが、HD map (不急のデータ) を送るTCPのベストエフォート処理による輻輳のためよりドロップされた。このパケットドロップにより遠隔運転監視映像の出力に支障をきたした。

一方、DFMPとDFCPを使用した場合、DFCPの優先送信制御の結果、遠隔運転監視用のデータ受信は乱れることなかった（すなわち、パケットロス0％）。これは、DFMPとDFCPのデータフロー優先制御機構の有効性を示しています。