QoS（3）QoS はなぜ必要? 要件の変化・輻輳の発生

Internet 技術に思うこと

Internet の基幹技術は TCP/IP とイーサネットだが、イーサネット以外の様々な通信網(物理層)とも一体となり発展と変化を遂げてきた。ARPANET のパケット交換、Robert E. Kahn が提唱した「オープンネットワーク」、TCP/IP やイーサネットなどの概念や技術が融合し、現在の Internet 技術がある。この技術が登場した当時は、「到達保証がないのは通信ではない」と多くの批判を浴びた。しかし、到達保証を捨てることで多くの利点を生み出した。ごく小規模なネットワークから世界規模 の Internet までをカバーする柔軟さ、様々な通信網で動作する適応力やコストパフォーマンスの高い通信網などだ。当時実現を危惧された「複雑な機能を端末に持たせる」ことも、パソコンやサーバの高性能/高機能化と価格低下で、懸念は解消された。

一方、多くの課題を生み出すことになった。一つはセキュリティ問題だ。開かれたネットワークは、盗聴やアタックに会う危険なネットワークでもある。セキュリティ問題はいまだ大きな課題ではあるが、暗号や認証技術で徐々に改善している。もう一つの課題は「到達保証」だ。これも、産業用イーサネットの様々な工夫や QoS 技術で克服できる可能性が出てきた。

ネットワーク要件の変化

初期のイーサネットでは、ファイル転送やメールなどの用途が主で、緊急性がなく遅延は大きな問題にならず、パケット損失も再送でカバーできるため気にならなかった。当然、QoS の必要はなく Best Effort で問題はなかった。イーサネットの適用範囲が広がり、Web アクセスの HTTP 、IP 電話の VoIP 、Zoom のような動画配信などの特性の異なる様々なデータが流れるようになり状況が変わった。これらのアプリケーションは、帯域・遅延・ジッタ・バースト・パケット損失などのネットワークに求める要件が異なり、サービスに応じた QoS が必要になった。

VoIP や動画配信は、リアルタイム性が求められる。遅延が大きくなると快適な通話や会議ができない。ジッタが大きくなるとパケット到着間隔が一定せず不安定になり、映像や音声が途切れる。VoIP は遅延やジッタに敏感だが、必要帯域はそれほど大きくはない(100Kbps 程度)。 Zoom などの動画配信は、遅延とジッタに敏感で、更に必要帯域も比較的大きい(600Kbps ~ 1.5Mbps 程度)。しかし、いずれもパケット損失には比較的寛容だ。わずかなパケットロスであれば、一瞬の音声や映像の途切れはあるが、致命的ではない。音声や映像などのアプリケーションでは、軽微なパケット損失を許容し、遅延・ジッタ・帯域を優先した方が得策だ。

HTTP はバースト性があり、一気に大量のパケットを送信する傾向があるが、一時的に大きな帯域が必要になる。しかし、遅延やジッタは問題にはならない。パケット損失が発生すると、TCP は再送によりリカバーするためパケット送受信は問題なくできる。しかし、TCP はパケットロスによる再送時に「スロースタート機能」が働き、通信速度が急速に落ちる。トラフィックが込み合った状態ではパケット損失が発生しやすいが、TCP の再送でさらにトラフィックが増え状況はさらに悪化する傾向がある。HTTP やファイル転送などのアプリケーションでは、遅延やジッタを犠牲にしてでもパケット損失を避ける必要がある。

ネットワーク要件（QoS 評価項目）は図1 を、各アプリケーションのネットワーク要件は表1/2 を参照いただきたい。

また、QoS 評価項目の用語については次回解説する。

パケットの種類	帯域	遅延	ジッタ	損失
音声	小さい	敏感	敏感	影響は少ない
ビデオ	大きい／バースト	敏感	敏感	影響は少ない
HTTP/FTP	大きい／バースト	影響は少ない	影響は少ない	影響は少ない

パケットの種類	帯域	片方向遅延	ジッタ	損失
音声	30～320kbps	150ミリ秒未満	30ミリ秒未満	1%未満
ビデオ	384K～20Mbps	200～400ミリ秒	30～50ミリ秒	0.1～1%未満

輻輳の発生

QoS の必要性に話が及ぶと、「ネットワークの高速化で対応できる」との反論がよく出る。しかし、ネットワークが高速化しても輻輳ポイントは変わらず、 QoS を避けて通ることはできない。パケット交換網は予期しない経路からのトラフィック流入があり、トラフィック量は予測できない。End to End で全てのネットワークの通信速度が同じとは限らない。また、HTTP、FTP や映像のようにバースト性の強いアプリケーションでは、一時的にキューが枯渇しパケット廃棄につながる可能性が常にある。主な輻輳ポイントは次の3点だ。

輻輳ポイント

帯域超過	ネットワーク接続機器で帯域超過／速度変化
中継装置キュー溢れ	ネットワーク接続機器でのキュー溢れ
受信キュー溢れ	受信ノードのキュー溢れ

パケットが溢れ、廃棄が起きるポイントを「輻輳ポイント」と呼ぶ。「輻輳」の定義や語源については、用語解説を参照いただきたい。

帯域超過

図2 の様に、トラフィック集中や速度不一致で、受信帯域（400Mbps/1Gbps）＞送信帯域（100Mbps）となることがある。基本的にすべてのノードは送受信可能なため、いつどこで起きるかは予測できない。

中継装置キュー溢れ

図3 の様に、トラフィック集中や帯域超過によるパケット廃棄を緩和するために、スイッチやルータにはキューが用意されている。しかし、キュー容量は有限なため、収まりきれないパケットは廃棄される。幾つかの廃棄手法があるが、キューが一杯になった段階で無差別に廃棄する「テールドロップ」が一般的だ。

受信キュー溢れ

図4 の様に、送受信ノードが 1対1 接続であれば通信路の帯域超過は起きない。しかし、受信ノードの CPU 処理負荷やメモリ空き状態により、キューを無限に用意できるわけではない。状況によっては受信キューが溢れ廃棄が始まる。TCP/IP では、この受信キュー溢れを防ぐため「Window 制御」と呼ばれる機能がある。受信ノードが受信できるデータ量を送信ノードにあらかじめ伝え、キュー溢れを未然に防いでいる。一方、UDP/IP にはキュー溢れを防ぐ機能がない。