Introduction to QoS
- 例えばWAN edgeのrouterは、WAN側は遅く、LAN側は速い
- ので、LAN側に数百数千のパケットが渋滞しうる
- どうする? — QoS
QoS: Managing Bandwidth, Delay, Jitter, and Loss
-
ネットワークのトラフィックの特性
- Bandwidth
- bps
-
速度と捉えることもできるし、キャパシティと捉えることもできる
- 10%をvoice、50%をmission-critial、残りを普通のトラフィックに充てる、など
- Delay
- one-way delay: 送信して届くまで
- round-trip delay: パケットを1つ送信して1つ返ってくるまで
- Jitter
- delayのばらつき
- Loss
- sentを分母とする百分率
-
要因
- faulty cabling
- WANサービス側の問題
- LAN側のキューあふれ
- など
Types of Traffic
Data Applications
- ユーザが求めているのは良いQoE (Quality of Experience)
-
アプリケーションによって求められるQoS特性は異なるという話
- 例: バッチ
- delayやjitterは大した問題にならない
- bandwidthが大きいことやlossが少ないことが重要
Voice and Video Applications
-
例: VoIP
- bandwidthは小さくてよい
- delayやjitterの小さきことが重要
- Ciscoガイドラインの推奨値:
voice | video | |
---|---|---|
bandwidth | ? | 384kbpbs - 20+Mbps |
delay | < 150ms | 200-400ms |
jitter | < 30ms | < 30-50ms |
loss | < 1% | 0.1% - 1% |
QoS on Switches and Routers
-
本章では便宜上packet/frameの区別をしないこととする
- 重要でないので
Classification and Marking
Classification Basics
- 他のQoSツールの前段
- パケットを分類する
Matching (Classification) Basics
-
パケットが通過する全デバイスで複雑なマッチングをするのは得策でない
- パフォーマンスに悪影響がある
-
早期に複雑なマッチングを済ませてマーキングし、以降はマーキングに基づいて簡単なマッチングで済ませるのが得策
- Cisco/RFC推奨
-
DSCP: Differentiated Services Code Point
- マーキング用のフィールド
Classification on Routers with ACLs and NBAR
- QoS実現のためにはパケットの分類が必要
- ACLでパケットを分類できる
- ACLでうまく分類できない場合はNBARという選択肢もある
-
NBAR: Network Based Application Recognition
- 一般的にNBAR2 — next-generation NBAR のこと
- アプリケーション層の情報まで利用してパケットを分類する
Marking IP DSCP and Ethernet CoS
- CoS: L2のQoS用フィールド
- DSCP: L3のQoS用フィールド
CoS | DSCP | |
---|---|---|
voice | 5 | EF |
video | 4 | AF41 |
business-critical | 2 | AF21 |
Marking the IP Header
-
送信元ホストから宛先ホストまでずっと残る
- ルータホップ時、L2フレームは剥がすがL3ヘッダは破棄しない
-
ToSフィールド(8ビット)
- 昔: IPP: IP Precedence フィールドとして3ビットだけ使われていた
- 今: DSCPフィールドに6ビット使っている
Marking the Ethernet 802.1Q Header
-
CoS (3ビット)
- 802.1Qタグに含まれる
- ので、利用できるのはトランクリンクに限られる
- VLAN越えられない
Other Marking Fields
- Wi-FiのTID
- MPLSのEXP
Defining Trust Boundaries
- ホストは好き勝手にDSCPやCoSを設定してパケットを送信できる
- voice packetじゃないのにEF (Expedited Forwarding)を設定したりできる
- ので、DSCPやCoSを無条件に信じるわけにはいかない
-
Trust Boundaries
- ここからのパケットのDSCPやCoSは信じますよ、という境界
- 典型的にはfirst ingress switchやIP phone
DiffServ Suggested Marking Values
- DSCP値の標準化みたいな話
- RFC2475
Expedited Forwarding (EF)
- 10進数の46番
-
音声データ用
- cf. voice signaling packetはCS3
Assured Forwarding (AF)
Best Drop | Worst Drop | ||
---|---|---|---|
Best Queue | AF41 (34) | AF42 (36) | AF43 (38) |
AF31 (26) | AF32 (28) | AF33 (30) | |
AF21 (18) | AF22 (20) | AF23 (22) | |
Worst Queue | AF11 (10) | AF12 (12) | AF13 (14) |
- 4種のキュー
-
各キューの中でのdrop優先度
- 輻輳回避用
- 8の倍数がないのは後述のCSに割り当てられているため
Class Selector (CS)
-
IPP互換
- 3ビットのIPP (
000
~111
)が6ビットのDSCP(000000
~111000
)になったので、8の倍数
- 3ビットのIPP (
IPP | CS | DSCP |
---|---|---|
0 | CS0 | 0 |
1 | CS1 | 8 |
2 | CS2 | 16 |
3 | CS3 | 24 |
4 | CS4 | 32 |
5 | CS5 | 40 |
6 | CS6 | 48 |
7 | CS7 | 56 |
Guidelines for DSCP Marking Values
-
結局どういうときにどれ使えばいいの
- DSCP EF: Voice payload
- AF4x: Interactive video
- ビデオ会議とか
- AF3x: Streaming video
- AF2x: High priority (low latency) data
- CS0: Standard data
Queuing
-
出力インタフェースがbusyなときにパケットを溜めておくやつ
- 受信したパケットをclassifierで分類し
- 分類ごとにqueueに積み
- schedulerで優先度づけして送信する
Round-Robin Scheduling (Prioritization)
-
CBWFQ: Class-Based Weighted Fair Queuing
- 重みづけラウンドロビン
- 分類ごとに最低帯域幅・重みを設定
Low Latency Queuing
- 対話的な音声(電話など)や映像(ビデオ会議など)では、重み付けラウンドロビンでは十分なlow latency/jitter/loss特性を得られない
-
スケジューラにLLQ: Low Latency Queuingを追加することで解決する
- 最優先なキュー
-
新たに生じる問題: queue starvation
- interfaceの処理能力以上のトラフィックがLLQに入ってきたら、他のキューが処理されなくなる
-
解決法: policing
- LLQに最大帯域幅を設定し、あふれたパケットを破棄する
- 新たに生じる問題: 音声パケットのロスが生じる
-
解決法: CAC: Call Admission Control
- 詳細は割愛
Shaping and Policing
-
このまま送受信したらトラフィックがあふれてしまう、という時
- shaping: queueに積んで送信を遅延する
- policing: 破棄するか、優先度の低い値で再マーキングする
- 低トラフィックからのスパイクは許可する
Policing
Where to Use Policing
-
SPのネットワーク機器(受信側)でトラフィック制限
- 顧客から過剰のトラフィックを送りつけられたら破棄する or 優先度の低い値で再マーキングする
Shaping
- 送信側で設定
- トラフィックが設定値をあふれないようにqueueに積んで送信を遅延する
Setting a Good Shaping Time Interval for Voice and Video
- 送信を遅延するので、当然delayとjitterが増大する
- 例: 1000Mbpsのinterfaceのegress trafficを200MbpsにShapingする場合
- shaperのtime intervalが1000msだと、
200ms送信・800ms待機・200ms送信・800ms待機…という挙動になる -
800msのdelayが生じるということ
- voice packetには耐えない
-
解決法: shaperのtime intervalを短く設定する
- 対話的音声や映像には10ms程度
- 2ms送信・8ms待機…となる
Congestion Avoidance
TCP Windowing Basics
-
windowing
- window
- TCPコネクションにおいて、senderが一度に送信してよいバイト数
- windowに達したら、receiverからackを受け取るまで送信を待機する
- 待機時間は無駄なので、これを無くすために、receiverはackするたびにwindowを倍々にしていく
- 輻輳によるパケットロスが検出されたらwindowを狭める
-
tail drop
- ネットワーク機器のqueueが一杯になり、新たなパケットが破棄される状態
Congestion Avoidance Tools
-
tail dropを未然に防ぐために、TCPセグメントを破棄する
- TCPコネクションはパケットロスを検出してwindowを狭める
- tail dropよりも長い目で見てマシ