クラウド対応でWAN最適化

国際電気通信連合(ITU)が、クラウドコンピューティングの国際標準規格を、日本の骨子案を基に、2013年末にも固める見通しという報道がありました。

日本が掲げる骨子案は、
  1. サーバー間の通信の品質維持
  2. 通信の際の遅延を少なくする
  3. サーバーの省電力化を進めること-など
そういえば、通信品質改善や遅延対策、WAN高速化、WAN最適化のニュースが目立つ気がします。

Ciscoは、WAN最適化プラットフォーム「Cisco Wide Area Application Services(WAAS)」をクラウド対応の一環として6月12日にアナウンスしています。

クラウドとの接続を「Skeed Silver Bullet Protocol」で高速化するというSKEEDが先週発表しました。
他にもチラホラとあります。

「Skeed Silver Bullet Protocol」のように詳細を公開しない例もありますが、既存のWAN高速化手法を凌駕する画期的な技術が開発されたという話もみあたりません。

既存手法で、なんとかWAN最適化・高速化を実現しようとしているようです。

WAN高速化ツールは多種多様ですが、たいていは以下の4つの手法を使っています。

(1)TCPの最適化/TFO(Transport Flow Optimization)
  • 送受信ウインドウサイズ調整、回線線状況に応じたダイナミック輻輳制御
  • 代理応答(ツールでACKを返す)
  • ツール側でパケット損失を修復する
(2)データの圧縮/DRE(Data Redundancy Elimination)
ツール側でデータ量を減らし、伝送速度向上(暗号化されたデータなどは圧縮率があがらず効果がでにくい)
(3)アプリケーションに応じた最適化・ツールでTCPの終端
ツールでTCPセッションを透過的に終端し、WAN回線区間はツール間で中継
WAFS(wide area file services)はその一例。CIFSの4Kバイトの読出し要求を64Kバイトに束ねるなど、ツールがアプリの内容を理解してツール側で処理。
ツールが、TCPアプリからみて透過的にTCPを終端できるアプリに限定される
(4)ショートパケットを結合・分割する
DFビットがある場合や、パケット改ざん検知に引っかかる場合があるので注意

AndroidoのTCPスループット低下

Androidでも、遅延でスループットが低下します
HT-03で、遅延とスループット関係を実測した表があったので引用。

Android:遅延とスループット

Hardware HT-03a
Model number AOSP on Sapphire(US)
Firmware version 2.1-update1
Baseband version 62.50S.20.17Hpsy"5F2.22.19.26I
Kernel version 2.6.29-00481-ga8089eb-dirty
Build number aosppsy"5Fsapphirepsy"5Fus-eng 2.1-update1 ERE27

iPhone高速化ツール

iPhoneの遅延対策ツール

iPhoneのチューニングツールもあります

このツール画面でBnadwidth Delay Productとあるのは、帯域幅遅延積(BDP)のことです。
BDPは、ネットワーク帯域にラウンドトリップタイムをかけた値

送信側TCPスタックが一度に流せるバッファサイズは、帯域幅遅延積(BDP:Bnadwidth Delay Product) できまるので、BDPに応じてウインドウサイズを調整するのがこのツールです。

バッファーサイズを変更する時は、エンド―エンドでの回線品質、帯域のボトルネックなどを確認してから実施するのが無難。

回線が太くてもネットワークの信頼性が低く、エラー率や損失率が高いなど場合に、送信バッファーが大きいままだと、大量の再送が起こりスループットは低下してしまう場合もあります。
電波状況が変化して帯域が狭くなりパケット破棄が起きた時には、送信バッファーも小さくして、再送を抑止しないとTCPよりもスループットが低下してしまうこともあります。

さまざまなTCP

TCPのスループット低下を改良する試みは、連綿と続いている。
その結果、OSが違えば、TCPの実装が異なっています。

LinuxのTCPは14種類

renoとcubicの違い.png

Linux-2.6.22.6 では14種類のTCPの実装が選択可能

  1. bic
  2. cubic
  3. highspeed
  4. htcp
  5. hybla
  6. reno
  7. scalable
  8. vegas
  9. westwood
  10. veno
  11. lp
  12. yeah
  13. illinois
  14. compound
昔からあるのは、Reno。 LinuxのデフォルトはCUBICです。
Androidもその流れで、CUBICが一般的。

ウインドウ制御方法/輻輳制御が各実装の主な違い。
どれを選ぶかで、スループットが変わりますが、遅延、回線品質、送信データサイズ、連続送信時間などによって適した実装が異なります。
どんな場合も常にこれがベストという方式はありません。

AndroidでCUBICとRENOの違いを実測した値が、右上のグラフです。微妙な差ですね。遅延やパケロスが現実よりかなり小さいせいかもしれません。

各種TCPの実装の比較
送信レートの時間変化のグラフ
各種TCPの実装の比較(送信レートの時間変化のグラフ).PNG

WindowsのTCPはC-TCP

Compound TCPが、Vista以降のWindowsのデフォルト。
Compound TCPは、MSの独自方式で、受信ウィンドウ自動チューニングは、既定で TCP ウィンドウ スケーリングを有効にし、16 MB までの最大受信ウィンドウ サイズを許可します。

モバイル用TCP

モバイルではWAP1.xでTCPをあきらめたが、WAP2.0でTCPに回帰した
WAP2.0が規定したのが、モバイル用TCP、Wireless Profiled TCP(w-TCP)です。
最近、WAPは、iPhoneやAndroidに無視されて、今は影が薄ですが、死んではいません。

WAP

 WAP 1.x UDPを利用
 WAP 2.0 TCPを利用 Wirelss Profiled TCP(w-TCP)

Wirelss Profiled TCP(w-TCP)

  • split-TCPとして利用可能であること(RFC2757: Long Thin Networks)
  • windowスケールオプションの有効化(RFC1323)
  • 輻輳制御の最適化(RFC2414)
  • SACKの対応(RFC2018)
以上必須、以下オプション
  • RTTMのタイムスタンプオプション(RFC1323)
  • MTUサイズの経路上サイズ検出機構のサポート(RFC1191)
  • ECNのサポート(RFC2481)

TCPのスループット向上の歴史

RFCを拾ってみると、TCPスループット向上につながる規格や研究がたくさんのあります。
悪戦苦闘の歴史のような感じです。
  • RFC 793:TRANSMISSION CONTROL PROTOCOL(TCP)
  • RFC1191:Path MTU Discovery
  • RFC1323:TCP Extensions for High Performance 
    • windowスケールオプション
    • タイムスタンプオプション
  • RFC1337: TIME-WAIT Assassination Hazards in TCP
  • RFC2018:SACKS (Selective Acknowledgments)
  • RFC2414:Increasing TCP's Initial Window
  • RFC2415:Simulation Studies of Increased Initial TCP Window Size
  • RFC2416:When TCP Starts Up With Four Packets Into Only Three Buffers
  • RFC2481:A Proposal to add Explicit Congestion Notification (ECN) to IP
  • RFC2582:The NewReno Modification to TCP's Fast Recovery Algorithm
  • RFC2757:Long Thin Networks
  • RFC2883:An Extension to the Selective Acknowledgement (SACK) Option for TCP
  • RFC3168:The Addition of Explicit Congestion Notification (ECN) to IP
  • RFC3517:A Conservative SACK based  Loss Recovery Algorithm for TCP
  • RFC3390: Increasing TCP's Initial Window
  • RFC3649:High Speed TCP for Large Congestion Windows
  • RFC4138:Forward RTO-Recovery (F-RTO)

これらを振り返るまでもなく、WAN最適化は複雑です。
スループットは、通信データサイズ、通信頻度、利用アプリ、暗号化の有無、エラー率などに左右されるので、最適化・高速化がレイヤー3以下に閉じた対応で済まない事が、対応を難しくしているようです。

最近のブログ記事

GoogleがHTC買収を発表
台湾のHTCを買収することをGoogl…
上限突破でも速度制限なし
T-mobileが月間通信量の上限を5…
貼れる,洗える,伸びる太陽電池
h2{ font-size:120%…
カスタム検索

月別 アーカイブ