5-1 QoS の必要性と 3 モデル — なぜ優先順位が要るのか

1. 前節の振り返りと本節の内容

前章 第 4 章 セキュリティ編 では、通信を 通すか・守るか で制御する仕組みを扱いました。4-1 ACL の in/out、4-5 ZBF の zone-pair、4-6 NAT の inside/outside は、パケットを通す・遮断する・書き換える制御でした。4-7 IPsec・4-8 Site-to-Site VPN は、通る中身を暗号で守る制御でした。いずれも「この通信を通すか、通すならどう守るか」という問いに答えるものでした。

その 4-8 の締めで、視点を変える問いを予告しました。帯域が有限なとき、通すと決めた通信の「どれを先に通すか」は別の問題 です。音声やビデオ会議のような遅延に敏感な通信を、大量のファイル転送に埋もれさせないためには、通信に優先順位をつける仕組みが要ります。それを扱うのが QoS (Quality of Service、サービス品質) です。第 4 章が「通すか・守るか」なら、第 5 章 QoS 編は「通すと決めたものを、どの順で通すか」を扱います。

本節では、QoS の実機設定に入る前の土台として、次の 3 点を概念として整理します。第一に、なぜ QoS が要るのか = リンクの帯域が有限であるという出発点です。第二に、QoS が制御・改善しようとする 4 つの指標 = 帯域・遅延・ジッタ・損失です。第三に、QoS の全体像を分ける 3 つのモデル = Best Effort・IntServ・DiffServ です。本節は概念に徹し、実機の config や show 出力は次節以降で扱います。マーキングやキューイングの具体的な設定は、この 3 モデルの位置づけを掴んでから見ていくのが理解の近道になります。

2. なぜ QoS が要るのか — 帯域は有限である

QoS の出発点は、リンクの帯域は有限 という単純な事実です。1 本のリンクが単位時間に送れるデータ量には上限があり、そこに流し込める通信の総量は物理的に決まっています。この上限を超える量の通信が同時に流れようとしたとき、リンクは処理しきれなくなります。この状態を 輻輳 (congestion、ふくそう) と呼びます。

輻輳は、複数の性質の異なる通信が 1 本のリンクを共有するときに起きやすくなります。たとえば、音声通話 (VoIP)・ビデオ会議・大容量のファイル転送 (バックアップなど) が同じ WAN 回線を同時に流れる状況を考えます。ファイル転送はリンクの帯域を可能な限り使い切ろうとするため、リンクが埋まり、ほかの通信の入る余地が狭くなります。この状況は以下のとおりです。

輻輳が起きたとき、何もしていないルータは すべての通信を区別せず、到着順に公平に扱います。その結果、リンクが混むと全通信が一様に遅くなり、キューが溢れれば区別なくパケットが落ちます。一見すると公平ですが、ここに問題があります。通信の種類によって、遅延や損失をどれだけ許せるか がまったく違うからです。

音声通話は、片道の遅延が大きくなると会話が噛み合わなくなり、パケットが少し落ちるだけで音が途切れます。一方、ファイル転送は数秒遅れても最終的にファイルが届けばよく、途中でパケットが落ちても再送で回復できます。通信ごとに要求する品質が違う のに、既定のルータはそれを一切区別しません。遅延に敏感な音声と、遅延を許せるファイル転送を同じ扱いにすることが、実際には不公平を生みます。

この不公平を正すのが QoS です。QoS は、限られた帯域の中で どの通信を優先し、どの通信を後回しにするか を機器に指示します。輻輳が起きたときに、音声のような遅延に敏感な通信を先に送り出し、ファイル転送のような遅延を許せる通信を待たせることで、それぞれの通信に適した品質を割り当てます。輻輳が起きない限り QoS は目立って働きませんが、帯域が足りなくなった瞬間に、通信の優先順位が品質を左右します。

3. QoS が扱う 4 つの指標 — 帯域・遅延・ジッタ・損失

QoS が制御・改善しようとする通信品質は、4 つの指標で表されます。帯域・遅延・ジッタ・損失 です。この 4 つは、通信の種類ごとに「どこまで許容できるか」が異なり、QoS 設計の目標値になります。

帯域 (bandwidth) は、単位時間に送れるデータ量です。ビット毎秒 (bps) で表し、リンクの容量そのものを指すことも、ある通信に割り当てる量を指すこともあります。帯域が不足すると通信が詰まり、輻輳の直接の原因になります。QoS では、重要な通信に必要な帯域を優先的に確保する制御が中心になります。

遅延 (delay / latency) は、パケットが送信元から宛先に届くまでにかかる時間です。伝送距離による伝搬遅延、機器で処理する時間、キューで順番を待つ時間などが積み重なります。音声通話では、片道の遅延が 150 ミリ秒程度以内 であれば自然な会話が成立するとされ、これは ITU-T (国際電気通信連合) の勧告 G.114 が示す目安です。これを大きく超えると、相手の返事を待つ間が不自然に空き、会話が噛み合わなくなります。ファイル転送のように遅延を許せる通信と違い、音声・映像は遅延に厳しい通信です。

ジッタ (jitter) は、遅延の ばらつき です。個々のパケットの遅延が一定でなく、あるパケットは早く、次のパケットは遅れて届くと、パケットの到着間隔が揺れます。音声や映像はパケットが等間隔で届くことを前提に再生するため、到着間隔が揺れると音が途切れたり映像が乱れたりします。受信側は ジッタバッファ で一定量のパケットをためてから再生することで、ある程度のばらつきを吸収しますが、吸収できる量には限度があり、大きなジッタは吸収しきれません。

損失 (loss / packet loss) は、パケットが宛先に届かず途中で捨てられる割合です。輻輳したルータの出力キューが溢れると、後から到着したパケットが入りきらずに捨てられます。この、キューの末尾から溢れて落とす動作を テールドロップ (tail drop) と呼びます。音声通話では、1 パーセント程度 の損失でも聞き取りにくくなるとされ、ファイル転送のように再送で回復できる通信と違い、リアルタイムの音声はいったん落ちた音を取り戻せません。

この 4 指標が、1 本のパケット列のどこに現れるかは以下のとおりです。

QoS は、この 4 指標を通信の種類ごとに満たすように帯域と順番を配分する技術です。音声のように遅延・ジッタ・損失に厳しい通信には、優先的に短い遅延で送り出す扱いを与え、ファイル転送のように帯域を欲しがるが遅延を許せる通信には、余った帯域を割り当てて後回しにします。次の 3 モデルは、この配分を どの範囲・どの粒度で行うか の設計思想の違いです。

4. モデル 1: Best Effort — 何もしない既定の世界

最初のモデルは Best Effort (ベストエフォート、最善努力型) です。これは「QoS を何もしていない」既定の状態を指します。ネットワーク機器は、すべてのパケットを 到着順に区別なく 扱い、届けられる範囲で最善を尽くしますが、特定の通信を優先することはしません。

Best Effort の動作は単純です。パケットは到着した順に出力キューに並び、先に入ったものから順に送り出されます。この、先に入ったものが先に出る方式を FIFO (First In First Out、先入れ先出し) と呼びます。輻輳してキューが溢れれば、前節のテールドロップで後から来たパケットが落ちます。音声もファイル転送も、この同じ列に並び、同じ規則で送られ、同じ規則で落とされます。なお、ここでは Best Effort を「単一の FIFO キュー」という概念モデルとして扱います。実機の既定のキュー挙動は、機種やインタフェースの種別、ハードウェアキューの構成によって異なる場合があり、その詳細は以降の実機を扱う節で確認します。

Best Effort は、インターネットの基本設計です。機器は通信の種類を意識せず、ただパケットを転送するだけでよいため、シンプルで拡張性が高い という利点があります。世界規模のネットワークが成立しているのは、各機器が個々の通信を区別せず単純に転送する Best Effort を土台にしているからです。その反面、特定の通信を優先できないため、輻輳時には遅延に敏感な通信も一様に劣化します。

QoS を設計するとは、この Best Effort から出発して優先制御を足していく作業だと位置づけられます。何もしなければ通信は Best Effort で流れ、そこに「この通信を優先する」という指示を加えることで、はじめて優先順位が生まれます。以降に扱う 2 つのモデルは、いずれも Best Effort に優先制御を足す方式であり、その 足し方 が異なります。

5. モデル 2: IntServ (RSVP) — 経路上の全ルータに帯域を予約させる

2 つ目のモデルは IntServ (Integrated Services、統合サービス) です。IntServ は、通信を始める前に、送信元から宛先までの経路上のすべてのルータに、必要な帯域をあらかじめ予約させる 方式です。予約がすべてのルータで成立して初めて通信を始め、予約した帯域の中で品質を保証します。

予約の手続きを担うのが RSVP (Resource Reservation Protocol、資源予約プロトコル) です。RSVP では、送信元がまず通信の特性を知らせる情報 (PATH メッセージ) をデータと同じ方向に流して経路を伝え、それを受け取った 受信側 が「この通信のためにこれだけの帯域を確保してほしい」という予約要求 (RESV メッセージ) を 逆方向 (受信側から送信元へ) に返します。この予約要求が通る経路上の各ルータが、それぞれ帯域を確保できるかを判断し、確保できれば自分のところに予約状態を作ります。すべてのルータが確保に応じれば予約が成立し、応じられないルータが 1 つでもあれば予約は失敗します。RSVP が受信側から予約を組み立てる方式であることは、RFC 2205 で receiver-oriented (受信者主導) と定義されています。いずれにせよ、通話を始める前に経路を確保する電話回線の予約に近い発想であり、Best Effort が予約なしで送り出すのとは対照的です。

IntServ は、予約した帯域の中で通信品質を厳密に保証できるという強みを持ちます。しかし、この方式には根本的な弱点があります。経路上の各ルータが、通過するすべての通信の流れ (フロー) ごとに、予約の状態を個別に保持しなければならない ことです。ここでいうフローとは、送信元・宛先・ポートなどで区別される 1 本 1 本の通信の流れを指します。

この「フローごとに状態を持つ」性質が、IntServ の限界になります。フローの数が数本であれば問題ありませんが、数万・数十万のフローが通過する大規模なルータでは、フローの数だけ予約状態を覚え、維持し続けなければならず、メモリと処理の負担がフロー数に比例して増大します。フローが増えるほど負担が爆発するため、IntServ は スケールしない (規模に耐えない) のです。世界中の膨大な通信が集まるインターネットのコア (中核) には、この方式は向きません。

この「フローごとに状態を持つからスケールしない」という限界こそが、次に扱う DiffServ が生まれた動機です。IntServ が品質保証と引き換えに規模を犠牲にしたのに対し、DiffServ は状態の持ち方を変えることで、この限界を解こうとします。

6. モデル 3: DiffServ — パケットに印をつけてホップごとに扱う

3 つ目のモデルは DiffServ (Differentiated Services、差別化サービス) です。DiffServ は、IntServ のスケール問題を解くために設計された方式で、今日の実運用 QoS のほぼすべてがこの DiffServ を土台にしています。

DiffServ は、IntServ と違い、通信を始める前の予約を 一切しません。その代わりに、各パケットのヘッダに 優先度を表す印 をつけます。この印を DSCP (Differentiated Services Code Point、DiffServ コードポイント) と呼びます。経路上の各ルータは、フローごとの状態を覚える必要はなく、通過するパケットの DSCP の印を見て、そのルータ 1 台の中で (ホップ単位で) 転送の扱いを決めます。このホップ単位の扱いを PHB (Per-Hop Behavior、ホップごとの動作) と呼びます。

IntServ との違いは、ルータが覚えておくべき情報の粒度にあります。IntServ の各ルータは、通過する フローの数だけ 状態を持つ必要がありました。DiffServ の各ルータは、フローを区別せず、印の種類 (数クラス) ごとの扱い だけを知っていればよく、何本のフローが通過しようと持つべき情報の量は変わりません。フロー数が増えても負担が増えないため、DiffServ は スケールします。この、状態をフローごとからクラスごとに減らした点が、DiffServ が大規模ネットワークで使える理由です。

3 つのモデルを、スケーラビリティ (規模への耐性) の軸で並べると、その関係が見えます。この対比は以下のとおりです。

DiffServ は、品質の保証という点では IntServ に劣ります。経路上のどこか 1 台が印を無視したり、輻輳がクラスの想定を超えたりすれば、品質は保証されません。それでも DiffServ が主流になったのは、スケールする という一点が大規模ネットワークで決定的だからです。厳密な保証をあきらめる代わりに、印をつけてクラス単位で扱うという単純さで、膨大なフローを捌けるようにしました。

実運用の QoS で扱う印のつけ方 (マーキング)、印に応じた送り出しの制御 (キューイング)、帯域を超えた通信の抑制 (ポリシング・シェーピング) は、いずれも DiffServ の枠組みの中で動く技術です。3 モデルのうち DiffServ が実運用の主役であり、具体的な QoS 設計はこの DiffServ を前提に組み立てられます。

7. 落とし穴・補足

QoS は、輻輳が起きて初めて効果が見える技術であり、その位置づけを誤解しやすい点がいくつかあります。本節の概念に関わる注意点をまとめます。

QoS は帯域を増やさない。 QoS が行うのは、限られた帯域を通信ごとにどう配分するか、どの通信を先に通すか、超過した通信をどう抑えるか、といった 有限の帯域の使い方の制御 であって、帯域そのものを魔法のように生み出すわけではありません。したがって、そもそも帯域が慢性的に足りていない環境では、QoS で優先順位をつけても、優先されなかった通信の品質は改善しません。根本的に帯域が不足しているなら、必要なのは回線の増設です。QoS は「輻輳が瞬間的に起きたときに、重要な通信を守る」ための手段であって、恒常的な帯域不足の解決策ではありません。

DiffServ の印は、信頼できる境界でつけ直す必要がある。 DiffServ は、パケットの DSCP の印を見て扱いを決めます。ということは、末端の端末が自分のパケットに勝手に高い優先度の印をつければ、その通信を不当に優先させられることになります。これを防ぐため、実運用ではネットワークの入口 (信頼境界、trust boundary) で、外から入ってきた印を信用せず、あらためて正しい印をつけ直します。この印のつけ直しをマーキングと呼びます。DiffServ が印を信頼して動く以上、その印を誰が・どこでつけるかが品質の前提になります。

Best Effort・IntServ・DiffServ は排他的ではない。 この 3 モデルは、どれか 1 つを選ぶ択一の関係ではありません。実際には、DiffServ の枠組みの中に、優先度をつけていない通常の通信を扱う 既定クラス (default class) が用意されており、これは実質的に Best Effort です。優先すると決めた通信だけに高い印をつけ、それ以外はまとめて Best Effort 相当で流す、という形で共存します。「DiffServ を導入する」とは、すべての通信を厳密に分類することではなく、Best Effort を土台に、守りたい通信だけを優先クラスに引き上げることを意味します。

8. 次節

本節では、QoS の必要性と全体像を概念として整理しました。QoS の出発点が「帯域は有限であり、輻輳時には通信ごとの品質要求の違いが無視される」という問題にあること (§2)、QoS が制御する 4 指標が帯域・遅延・ジッタ・損失であること (§3)、そして QoS の全体像が Best Effort (何もしない)・IntServ (経路上の全ルータに予約させるがスケールしない)・DiffServ (印を見てホップごとに扱いスケールする) の 3 モデルに分かれ、実運用の主役が DiffServ であること (§4〜§6) を扱いました。

次節 5-2 マーキング体系 では、その DiffServ の要である「印」の中身に踏み込みます。パケットのどこに、どのような値で優先度を書き込むのか。L2 で使う CoS (Class of Service)、L3 の古い印である IP Precedence、そして現在の標準である DSCP と、その値が表す PHB (EF・AF・CS・BE) の体系を整理し、DiffServ が実際にどの印でクラスを区別しているのかを見ていきます。