[論文レビュー] Fitting Square Pegs Through Round Pipes: Unordered Delivery Wire-Compatible with TCP and TLS

Michael F. Nowlan, Nabin Tiwari+3 more|arXiv (Cornell University)|Mar 2, 2011

Network Traffic and Congestion Control参考文献 34被引用数 35

ひとこと要約

Minionは、uTCPを導入することで、ネットワークプロトコルを変更せずに後方互換性のある順序入れ替え可能なセグメント送受信を可能にする最小限のカーネル拡張を提供する。これにより、アプリケーションは順序を入れ替えても送受信が可能となり、uCOBSおよびuTLSを介して安全で順序のないデータグラム送信が実現され、VoIP、VPN、Webブラウジングのパフォーマンスが向上する。CPU使用率は7%未満で、帯域幅コストは一切かからない。

ABSTRACT

Internet applications increasingly employ TCP not as a stream abstraction, but as a substrate for application-level transports, a use that converts TCP's in-order semantics from a convenience blessing to a performance curse. As Internet evolution makes TCP's use as a substrate likely to grow, we offer Minion, an architecture for backward-compatible out-of-order delivery atop TCP and TLS. Small OS API extensions allow applications to manage TCP's send buffer and to receive TCP segments out-of-order. Atop these extensions, Minion builds application-level protocols offering true unordered datagram delivery, within streams preserving strict wire-compatibility with unsecured or TLS-secured TCP connections. Minion's protocols can run on unmodified TCP stacks, but benefit incrementally when either endpoint is upgraded, for a backward-compatible deployment path. Experiments suggest that Minion can noticeably improve performance of applications such as conferencing, virtual private networking, and web browsing, while incurring minimal CPU or bandwidth costs.

研究の動機と目的

• アプリケーションレベルのトランスポートを基盤とするTCPの順序保証によるパフォーマンスボトルネックを解消すること。
• SCTP や DCCP のような新規トランスポートの導入障壁を克服し、既存のTCPインfraストラクチャ上で順序入れ替え可能な送信を可能にすること。
• 変更のないTCPおよびTLSスタックとの互換性を保ちつつ、ワイヤプロトコルに準拠したソリューションを提供すること。
• アプリケーションが重要なデータを優先し、レイテンシに敏感なワークロードの遅延を低減できるように、下位のトランスポートスタックを変更せずに実現すること。
• Webブラウジング、VoIP、仮想プライベートネットワーキングなどの実世界のシナリオで、実用的なパフォーマンス向上を実証すること。

提案手法

• アプリケーションが送信バッファに順序を入れ替えたデータを挿入できるように、uTCP（600行のカーネル変更）をLinux TCPスタックに拡張する。
• アプリケーションが再送信遅延を回避して、即座に順序を入れ替えたTCPセグメントを受信できるようにする。
• 一貫性のあるオーバーヘッドバイトスターミング（COBS）を用いて、自己区切り境界を持つデータグラムを符号化し、TCPストリーム上での信頼性のある順序入れ替え可能なフレーミングを実現する。
• uTLSを設計し、順序入れ替え可能なストリーム断片におけるTLSレコード境界をヒューリスティックに推定し、暗号的MACを用いて検証することで、TLSとのワイヤプロトコル互換性を維持する。
• uCOBSおよびuTLSを、uTCPおよび変更なしのTCP上で動作するアプリケーションレベルプロトコルとして実装し、後方互換性を確保する。
• Linuxにプロトタイプをデプロイし、実世界のトラフィックパターンを用いたVoIP、Webブラウジング、VPNワークロードでパフォーマンスを評価する。

実験結果

リサーチクエスチョン

• RQ1 ワイヤプロトコルを変更せず、新しいトランスポートプロトコルを導入せずに、TCP上で順序入れ替え可能な送信を実現できるか？
• RQ2 アプリケーションレベルプロトコルは、TLSとの互換性を保ちながら、TCPストリーム上に信頼性があり順序のないデータグラム送信をどのように実現できるか？
• RQ3 既存のTCPスタックに順序入れ替え送信を有効化した場合、レイテンシに敏感なアプリケーションに与えるパフォーマンスへの影響は何か？
• RQ4 最小限のカーネル変更で、互換性を損なわず実世界のワークロードで顕著なパフォーマンス向上を達成できるか？
• RQ5 既存のアプリケーションフレームワークは、下位のトランスポートスタックを変更せずに、順序のない送信からどれほど恩恵を受けることができるか？

主な発見

• uTCPにより、VoIPストリームのアプリケーションが認識するジャイタが低減され、聴取品質指標が向上する。
• uTCPを用いたVPNでは、uTCPの送信バッファ制御によりACKを優先・高速化することで、トンネル化されたTCP接続のスループットを倍増できる。
• uTCPを用いたWebブラウジングでは、1つの永続接続内で複数のオブジェクトのチャンクをインターリーブして送信できるため、最初のバイト到着までの時間が最大50%短縮される。
• uCOBSはCOBS符号化のため、最大5倍のCPU負荷が生じるが、uTLSは標準のTLS 1.1と比較してCPU負荷は7%未満、帯域幅コストは一切ない。
• uTCPのカーネルパッチは600行にとどまり、uTLSはユーザー空間で600行未満のコードで実装され、DCCP や DTLS のようなネイティブな順序入れ替えトランスポートに比べてはるかに軽量である。
• uTLSは標準TLSとワイヤプロトコル互換性を達成しており、ネットワークトラフィックにおいてHTTPSと区別がつかないため、ファイアウォールやプロキシの問題なくデプロイ可能である。