QoS(7)優先制御の限界

現在の QoS(Quality of Service)は、優先制御と帯域制御で実現している。QoS 登場以前は Best Effort で、パケットは到着順にキューに格納され、キューが溢れると廃棄される。この問題を解消するために「優先制御」が登場した。「重要なデータ」を優先的に送り出し、廃棄されにくくする手法だ。かつての QoS は優先制御のみだったが、現在は優先制御と帯域制御の両方を持つことを QoS と 呼ぶのが一般的になった。帯域制御登場の背景には、従来のファイル転送とは異なる特性を持つ「音声」や「映像」サービスの登場がある。

帯域制御は、アプリケーション等の使用帯域をコントロールすることで、「帯域保証」と「帯域制限」がある。帯域保証は優先度を高くすることで使用帯域の下限値、帯域制御で上限値を設定することが多い。帯域制限は、帯域制御で上限帯域を設定する。しかし、優先制御だけでも、ある程度「帯域保証」と「帯域制限」は実現できる。優先制御では実現できないのが「バースト抑制」だ。バーストは、ごく短い時間にトラフィックが集中し輻輳を起こす現象で、「マイクロバースト」とも呼ばれる。平均帯域は十分余裕があるにも関わらず、音声や映像が途切れる現象がある。この原因の大半が「バースト」の仕業だ。帯域制御にはいくつかの実現方法があるが、平均帯域を制御することでは大差はないが、違いは「バースト抑制」にある。

帯域制御の説明に入る前に、バースト動作概要と、バーストの観点から音声」「映像」「ファイル転送のトラフィック特性、優先制御の限界を確認したい。

バースト動作概要

図1 のモデルで、バースト動作を説明する。このモデルは、FIFO 型のスイッチ経由で、3台の送信ノードと1台の受信ノードが接続されている。回線は全て 100Mbps イーサネットだ。

図1 FIFO バーストモデル
図1 FIFO バーストモデル

3台の送信ノードから一定間隔でパケットを送信した場合と、バースト状に一括送信した場合の「送信キュー」の様子が図2 になる。何れの場合も、送信ノードの送信帯域は 20Mbps で、受信ノードは全ての送信ノードのパケットを受信するため、受信帯域は 60Mbps になる。ネットワーク帯域の 60% を消費しているが、負荷率としては適正な範囲だ。説明を簡略化するため、全てのパケットは同じ大きさを想定している。

一定間隔でパケットを受信した場合はキューに滞留するパケット数は少ないが、バースト状に受信するとキューに大量のパケットが滞留する。同じ平均帯域でも、キューの状態には差がある。キューの長さには限度があるため、バーストはパケット廃棄の危険性を高くする。

図2 スイッチでの一定間隔(コンスタント)とバースト送信の違い
図2 スイッチでの一定間隔(コンスタント)とバースト送信の違い

音声の特性

主な音声通信は IP 電話と VoIP だ。IP 電話ではG.711、VoIP ではG.729 のコーデック(符号化)を使用する。G.711 は ISDN でも使用されるコーデックで音質は良いが、情報量が多い。 G.729 は圧縮率が高く情報量が少ない。G.711 の音声帯域は 64kbps 、G.729 は 8kbps だ。これらの音声データは、RTP/UDP/IP/Ethernet と順次カプセル化され伝送される。RTP ヘッダ には、コーデック種別、音声パケットの順序、音声パケットの送信間隔などの情報があり、受信側で元の音声に戻す情報が入っている。 UDP 以降は送信元と宛先情報だ。

何れのコーデックも 20 ミリ秒間隔でコンスタントにパケットを送信する。バースト状にパケットを送信することはない(図3)。音声通信には、遅延対策は必要だがバースト対策は必要ない。

図3 IP電話とVoIP パケット送信間隔
図3 IP電話とVoIP パケット送信間隔

IP 電話(G.711)と VoIP(G.729)のイーサネット上での帯域を見てみよう。G.711 の音声帯域 は 64Kbps で1回あたりの送信データ量は 160 Byte 、G.729 の音声帯域は 8Kbps で1回あたりの送信データ量は 20 Byte になる(計算式は、図4 参照)。

音声データはイーサネット上を伝送するため、RTP/UDP/IP/Ethernet と順次カプセル化しヘッダが付加される。ヘッダと最後に付加される FCS を加えると、いずれのコーデックも音声データに 74 Byte のヘッダ情報が必要になる(図4)。

イーサネット(VLAN 付き)の総フレーム長は、G.711 は 234 Byte、G.729 は 86 Byte になる。

音声データは 20 ミリ秒間隔で定期的に送信するため、1秒間に 50 個のパケットが双方向に送られる。1秒間の送信データ量(帯域)は、G.711 では 93.6Kbps、G.729 は 34.4Kbps となる。 100本の同時通話でも 10Mbps を下回り、100M イーサネットの10%、ギガビットイーサネットであれば 1% に過ぎず、通信帯域を圧迫するような事態は起きない。

音声通信には、最高優先度を与え特別な帯域制御を施さない場合が多い。これは、優先度を高くすることで遅延を抑え、必然的に必要帯域も確保できるためだ。また、データ量も少ないため、優先度を高くしても全体への影響は少ない。

音声の課題

音声は遅延には厳しいが、一定間隔でパケットを送信し帯域も小さい

優先制御による遅延保証のみ必要、帯域制御は不要

図4 IP電話とVoIP パケット構造
図4 IP電話とVoIP パケット構造

映像の特性

非圧縮映像は大きな帯域を必要とし、ネットワークを圧迫する。例えば、横 640×縦 480 でグレースケールが 8ビット(256段階)の映像を、1秒間に 30 フレーム送ると約 74M ビットになる(640×480×8×30÷106 )。さらにデータ量の多いハイビジョンのカラー画像は、とても非圧縮では伝送できない。一般的には、MPEG2 や H.264 などの圧縮映像を監視カメラやビデオ会議で使用する。しかし、圧縮映像でもある程度の解像度を求めると、1秒間に 1Mbps~8 Mbps の伝送帯域が必要になる。

例えば、1秒間に 6Mbps の圧縮映像を 1秒間 30 フレームで送信すると、1回あたりの伝送量は 200K ビットになる(6Mbps÷30=200K ビット)。200K ビットは 25K バイトになり、RTP の ペイロードに 1000 バイトずつ分割搭載すると、25個のイーサネットフレームになる(図5)。もちろん、圧縮方法やペーロードへの搭載量によってパケット数は若干変動するが、おおむねこの辺りのパケット数になる。

図5 圧縮映像のヘッダ構成
図5 圧縮映像のヘッダ構成

1画面分の映像データは、 RTP/UDP/IP/Ethernet と順次カプセル化され送信される。この時、映像送信デバイスは、次フレームの処理を行うため送信キューを早く空にしたい。結果、25個のイーサネットフレームは連続してバースト状に送信されることになる(図6)。

図6 映像データのバースト送信
図6 映像データのバースト送信

映像のバーストが、ネットワーク上の様々な問題を引き起こす一番の要因だ。テレビ会議の様な双方向コミュニケーションでは、できるだけ遅延時間を抑えたい。しかし、遅延時間を抑えるため優先度を高くすると、映像データがネットワークを占有し、他のパケットは伝送できなくなる。100M イーサネットで、最大長フレームを25個連続送信する時間は約3ミリ秒だ。映像1本であればこの程度で済むが、10本の映像データのバーストが運悪く重なると30ミリ秒の間、映像以外の通信が途絶えることになる(図3-7)。

図7 映像のバーストが重なる
図7 映像のバーストが重なる

映像は遅延に厳しく、帯域も確保しなけらばならない。また、ファイル転送などの他のトラフィックへの悪影響を少なくするためバーストも抑える必要がある。これらを実現するためには、優先制御と帯域制御を組み合わせて使用する必要がある。

映像の抱える3重苦

遅延に厳しい・帯域が大きい・バーストが発生する

映像の抱える3つの課題の解決手段として、「帯域制御」と「優先制御」の組み合わせが登場した

ファイルの特性

ファイルや Web サイトアクセスには TCP を使用する。TCP は受信ノードが受信できるデータ量を送信側に事前に伝える「Window 制御」の仕組みがある。Window の最大サイズは 64K バ イトだ。送信ノードは受信ノードが指定した Window サイズまでのデータを一括して送ることができる。Window サイズは、セッション確立時とデータ受信後に ACK パケットと共に送られるため、Window サイズを超えるデータが一括送信される事態は起きない(図8)。

図8 TCP 送信手順
図8 TCP 送信手順

しかし、TCP の「Window 制御」にも問題はある。1つは、受信ノードは間違いなく受け取れるデータ量だが、途中経路のスイッチやルータが問題なく中継できるとは限らない。もう1つの問題は、Window の最大サイズが 64K バイトとかなり大きいことだ。仮に、TCP のペイロードに 1K バイトのデータを格納すると、64個のパケットがバースト送信されることになる。1本の映像よりもバースト長が大きい。ファイル転送やWeb サイトアクセスのバーストでは、バーストの長さ(データ量)やバースト間隔は変化し一定ではない(図9)。

図9 ファイル/Web サイトアクセスのバースト送信
図9 ファイル/Web サイトアクセスのバースト送信

TCP を使用するファイル送信やWeb サイトアクセスは、一般的に「帯域保証」ではなく「帯域制限」をかけることが多い。しかし、ユーザとのインタラクティブな操作が必要な用途では、パケットロスによるタイムアウトを避けるために、優先度を高くし帯域保証を行うことがある。例えば、ATM(現金自動預け払い機)や券売機などだ。

優先制御の限界

優先制御の限界確認のため、図10 のモデルケースを設定する。このモデルでは、全ての通信 路は 100Mbps イーサネットで、入力トラフィックは IP 電話が50本、6Mbps の圧縮映像が4本、ファイル転送や Web アクセスの平均帯域が 30Mbps とする。合計で 60Mbps 程度だ。比較する優先制御方式は、FIFO/RR/WRR/SPQ の4種類だ。

図10 優先制御限界確認モデル
図10 優先制御限界確認モデル

表1 の様に、いずれの優先制御も問題を抱えている。SPQ と RR/WRR を組み合わせた優先制御もあるが、根本的な解決にはならない。優先制御で不具合を引き起こす1番の要因は「映像のバースト」で2番目が「ファイル等のバースト」だ。

FIFORRWRRSPQ
音声×先行パケットが多いと遅延時間を守れない。パケット廃棄の可能性もある。4個のキューであれば、巡回遅延は0.5ミリ秒以下。遅延時間は許容範囲内で、パケット廃棄は起きない。4個のキューであれば、巡回遅延は0.5ミリ秒以下。遅延時間は許容範囲内で、パケット廃棄は起きない。最高優先度であれば、遅延時間は最小に抑えられ、パケット廃棄も起きない。
映像×映像またはファイル等のバーストによるパケット廃棄の可能性がある。×映像のバーストによるパケット廃棄の可能性がある。映像のバーストによるパケット廃棄の可能性があるが、重み付けで改善。音声に次ぐ2番目の優先度であれば、パケット廃棄は起き難い。
ファイル等バーストによるパケット廃棄の可能性はあるが、再送で回復可能。バーストによるパケット廃棄の可能性はあるが、再送で回復可能。バーストによるパケット廃棄の可能性はあるが、再送で回復可能。×映像のバーストにより、極端に性能が劣化する可能性がある。
(最適← ◎ 〇 △ × →不適)
表1 優先制御方式に挙動の違い

QoS

この記事を書いた人

岩崎 有平

早稲田大学 理工学部 電子通信学科にて通信工学を専攻。
安立電気(現 アンリツ)に入社後、コンピュータ周辺機器の開発を経てネットワーク機器の開発やプロモーションに従事する。
おもにEthernetを利用したリアルタイム監視映像配信サービスの実現や、重要データの優先配信、映像ストリームの安定配信に向けた機器の開発行い、Video On Demandや金融機関のネットワークシステム安定化に注力した。
現在は、Ethernetにおけるリアルタイム機能の強化・開発と普及に向けて、Ethernet TSNの普及活動を行っている。