QoS: 全体的なTIPS

  • RoCEv2ではPFCより先にECNをトリガすることが必要になる
  • ECNはRoCEv2のための成功要因の1つ。ここで、バッファが溢れ切ってからECNするだけでなく、確率的にエレファントをうまく判別するWRED ECNなどの利用は重要になる。
  • エレファントフローの識別は重要で、このためにDPP/AFDといった拡張がある。
  • PFCのデッドロックはNIC故障などで必ず発生しうる。ここで、PFC Watchdog(PFCWD)はこれを検出する仕組みである。
  • RDMAトラフィックはカーネルをバイパスするので、tcpdumpできないことに注意する。

注意事項

QoS: End-to-End QoS Implementation and Operation with Nexus

主に、NexusにおけるQoSの話。

QoS Basic

QoSというのは、トラフィックを色分けし、輻輳を制御し、帯域を最大化することである。

QoSは大まかに以下のフェイズに分けられる。Classification -> Policing -> Marking -> Quere/Scheduling -> Shaping。

Classificaionというのは、トラフィックをClassに分けるもので、ACL/CoS/DSCPなどが用いられる。

Policingは指定した帯域にトラフィックを削る。

  • 2 colorのPolicerはConfirm(Permit)とExceed(drop)
  • 3 colorのPolicerはConfirm(Permit)は同じだが、Exceed(Markdown) と Violate(drop)となる。
    • Markdownとは弱い優先度にトラフィックを色付けし直し、再度刈り取るかを判定する。ものだ。

Bufferingが必要になる理由はいくつかある。帯域溢れと異速度接続。Inからの通信を即座に転送できない場合は何らかのバッファが使われる。

  • 帯域溢れは分かりやすく、out側が溢れている時に送れるようになるまで待つ。
  • 異速度は早い速度(例:100G)から遅い速度(例:10G)に送る時には通信のクロックが異なるため、絶対に発生する。

QueueingにはQueueの理解が必要。Queueは論理的に分けられたメモリバッファである。それぞれのQueueは異なる優先度を持つことができる。

SchedulingはOut側のQueueに送る優先度・順序のことである。スケジューリングを処理する際にはPriorityが存在することに注意。

  • Priorityフラグがついている場合、その転送は最優先される。このフラグはOn/Offの２値の場合もあれば、レベルが分かれている場合もある。レベルが分かれている場合、高い優先度が存在すればそれは低い優先度の処理を止めてまで優先される。
  • Priorityなしの通信はPriorityありのパケットがない場合のみに処理される。

Scheduringの一般的なアルゴリズムは次の4つがある。Queueの処理はそれぞれが独立したアルゴリズムで処理することができる。

  • Round Robin
  • Weighted Round Robin
  • Deficit Round Robin
  • Shaped Round Robin

Shapingはゆるい転送帯域の制限で、バッファリングを活用する。マイクロバーストなどが起きても平滑化した転送を行う。

Markingは具体的な優先度に色付けをするものである。

Congestion(輻輳)が発生した際の処理には大きく２つの方法がある。

  • TailDropはキューにある閾値を決めておき、それを溢れたら捨てる。
  • WRED(Weighted Random Early Drop)はもう一段下に閾値を決めておく。その段階からランダムにパケットを落とし始める。厳しい閾値を超えたらすべて捨てる。 WREDは端末側がパケットロス度合いなどを元に賢く帯域の制限をすることを期待している。

NexusのQoS

NexusのQoSは3つの段階に分かれる。ClassMap -> PolicyMap -> ServicePolicy。通常のネットワークは複数台の装置で構成されるため、QoSルールのポリシはいくつかあり得る。ネットワーク全体ですべて同じポリシをばら撒く場合もあれば、単一のスイッチ毎に設計することもある。

QoSポリシはいくつかの段階で設定を行う。

  • System Based Policy はグローバルレベルの設定である。
  • VLAN Based PolicyはVLANに割り当てられるルールであるが、これにはルーティングインタフェースであることが求められる。(多分)
  • Interface Based Type Queuing Policyはインタフェースポートに指定するもので、これはL2にも指定可能である。また、LAGにも指定できる。

一般的なQoSの問題点を話す。あるIn側のQueueにModuke 1,2,3宛のトラフィックがあったとする。1が溢れた時、2,3が空いていたとしても、すべてのキューが影響を受けてしまう。

VOQ(Virtual Output Queuing)は一部のNexus(9500R, 3600-R)で利用可能なQueueの実装でIn側のモジュールでは、Out側のモジュールごとにキューを持つ。こうすると輻輳した宛先のトラフィックはOutのモジュールに対してのキューイングが行われる。 実装としては、Nポートがあると、NxNのバッファが必要で重い実装である。

Output Queingは9000系、3000系で用いられるOut側のキューのことである。Outモジュール内のポートごとのバッファリングによって適当な配送が行われる。 実装としては、Nポートがあると各モジュール内でそのモジュール内のポートだけのバッファを用意するのでシステムとしてはNのバッファがあれば良い。

Queueの種類は設定によって異なる。

  • 4 colorのclass queuingは最も使われているであろう色付け。
  • 8 colorの色付けもある。DSCP 24-30はRoCEv2に使われる。

データセンタQoS / Lossless Ethernet

データセンターでは、ストレージトラフィックなど欠損にシビアなものが用いられる。これに対応するため、ロスレスのネットワークが必要になってくる。このポイントとなる技術がいくつかあり、PFC, ECN, ETC, DCBXである。

RoCEv2ではPFC, ECN, ETSが要求される。RoCEv1の場合はPFCとETSで要求される。

PFC(Priority Flow Control)は802.1Qbbとして知られるフロー制御である。これは、優先度付きの状態で使われる(Prioがついたパケット)。これによって、あるシステムでLosslessとLossyなトラフィックを一緒に扱うことができ、Losslessトラフィックは優先される。これによって落とされたLossyなトラフィックは上位層の再送制御で補完される。

ETS(Enhanced Transmission Selection)は802.1Qazとして知られる帯域制御の仕組みである。あるクラスだけがすべての帯域をHogging(占有)することを防ぐ。あるクラスの帯域分の予約が余っている場合、他のクラスがそれを使える。これはバースト的なトラフィックに効果的に動作する。 具体例は図の通りでその他を3Gbpsと予約していても、他のトラフィックが5Gbpsなら、5Gbpsまでを許す。などである。

DCBX(Data Center Bridging Exchange Protocol)は802.1Qazとして知られるLosslessへの対応を隣接ノードに知らせるLLDPの拡張(TLV値)である。PFC, ETS, CoS値などが送られる。（これによる具体的な利用方法はこのスライドでは述べられていない）

ECN(Explicit Congestion Notification)は輻輳を通達する仕組みである。ToSフィールドの2bitが使われる。End-End間での輻輳を知らせる仕組みで、経路上のIPデバイスから通知される。これにはPAUSEフレームは用いられず、送信元は送信トラフィック量を減らすことで輻輳の解消を狙う。 なお、ECNフィールドは00の時対応しておらず、輻輳が起こったら11となる。

Overlay QoS

(MPLSに関する説明はこの記事では省略する。スライドを参照すること)

VXLAN EVPNにおいてQoSが行われるための仕組みが必要である。送信側では、L3パケットを処理する際、元のDSCP値はOuterのVXLANのパケットにコピーされる。L2フレームを処理する場合、CoS値は適当なDSCP値にマップする。 受信側では、2つのモードがある。

  • UniformモードはOuterヘッダのものを付与します
  • PipeモードはInnerのDCSP値を付与します

Nexus9000におけるQoS実装

Nexus9000シリーズはLSシリーズのASICが用いられている。Sこれらは複数のSliceに分割されているものもある。Sliceはポートを束ねる単位であり、例えば、9300-GXのLS6400GXは1.6TのSliceが4つに分けれたものである。Sliceはポートを集約する単位である。ただし、Sliceの間はノンブロッキングで転送するのに十分な帯域が確保されている。スライスはそれぞれのポートに向けた共有のバッファメモリを持っている。ここで、Intelligent bufferは必要なサイズを適切に最大化する。8 colorのQoSがoutput portごとに設定できる。ここで、CPUの通信は最優先され、そのポート向けのSPANの通信はBest EffortのマーキングでQoSされる。

Intelligent bufferの仕組みはDBP, AFD, DPPによって成り立っている。

DBP(Dynamic Buffer Protection)はあるout queueのバッファ占有が不公平にならないようにするための仕組みである。つまり、バッファの容量である。このためには各キューに最大の閾値が決め、それを超えたら破棄する。この閾値はAlphaというパラメータに関連して決まる。これによって今のバッファサイズによって次にバッファがどの程度予約されるかが決まる。

AFD(Approximate Fair Drop)の話の前にバッファの理想と現実を考える。理想的にはバッファを食い潰す前に各TCPなどはうまく帯域を調整し、バッファは埋まらない。現実問題は、各バッファは先に溢れて、その結果として各TCPなどは帯域を狭くする。 AFDでは、エレファントとマウスのトラフィックを主にバイトカウントから判定し、バッファが溢れそうになる時に、エレファントなトラフィックからdropするようにします。 WREDとの違いは、WREDは各クラスの中のフローを識別しないのに対して、AFDは各クラス内のフローを意識しながらDropします。

Dynamic Packet Prioritization（DPP)はAFDと似たようなものですが、パケット数で区別を行います。例えば、1024以上はエレファント側のフローとし落としやすくします。対して、1024未満なら、優先します。これにより、マウストラフィックを落とされにくくします。

QoS: RoCE Storage Implementation over NX-OS VXLAN Fabrics

マルチサイトのRoCE over VXLANについて述べられた文章。

RoCEはRDMAをover Ether, over IPで実現する技術である。RDMAの特徴はゼロコピー、カーネルバイパス、CPU割り込みなしである。RoCE(UDP 4791)の実現に使われる技術はPFC, ECNがあり、両方が用いられることが望ましい。ただし、片方でも良い。RoCEv2を用いるとパケット欠損と遅延を抑えることができ、つまり、ゼロロス、低遅延、高いスループットを目指す。これによって、ストレージNWを持たなくてよくなる。

PFCはPAUSE(802.3x)に似た仕組みを持つが、CoS毎に動作する点が大きく異なる。PAUSEの時代は輻輳が発生するとtimeフィールドに入れた適当な時間のPAUSEを要求することで輻輳を緩和しようとした。一方でPFCはCoS毎にPAUSEを要求し、ここでも時間を設定できる。この時間は512bitを送るための時間で表現される。このタイマーを0とすることで再開される。このポーズフレームはTTL1で送られて隣接ノードのみに配られる。 PFCストームという異常な状態が起こることがある。ある機器が故障してパケットを受け取れなくなるとPFCフレームを対向のSWに送る。これによってその対向のバッファが溢れ、そのSWはさらに対向にPFCが送られる。このようにもう全体にPFCが伝搬し、機能しなくなることがある。

ECNはある程度の値を超えたときに、パケットに輻輳制御のマーキングをする。WREDがパケットを落とすのに比べ、ECNは落とさない。ECNはDestination側に届き、Source側に対して帯域を下げるように要求する。これにはCNPが使われる。まず、送信者から送られたパケットがあるSWに届く。そのSWが輻輳していれば、ECNがONになったパケットがDestに届く。DestではECNがONになったパケットを受け取るとRoCEのCNP(Congestion Notification Packets)をSrcに対して送る。SrcはCNPを受信すると、アプリケーション側で適当に帯域制限をする。

マルチサイトのPFCの実装にはいくつかのポイントがある。まずはPFCがEnable(priority-flow-control mode on)であること。また、RoCE over VXLANを有効にし、RoCEの識別フラグがVTEPで適切にencap/decapされること。また、PFCのポーズの時間を合わせるためにMTUが一致すること。PFCの状況を見るにはshow interface priority-flow-controlが利用できる。

ECNについて考える。ECNに対応している送信者はECNフラグを00ではなく01などとする。SWは輻輳があれば11にする。さて、encapされたVXLAN区間の輻輳があった場合、ECNは外側にマーキングされ、decapする際にコピーされ、destまで届く。もちろん、decap状態で付けられたECNフラグはそのまま適切にdestまで届く。この結果、dest側で生成されたCNPは最高の優先度でSrcまで届くだろう。尚、ECNのCNPがSrcに届くまでの間、ECNで特に何かが制御されることはない。

WRED ECN extensionという仕組みがある。WREDはある程度のバッファとなるとランダムにパケットを落とすがこの拡張ではマーキングのみを行う。これによって場合により適切な動作となる。これには次に説明するAFDを使うこともできる。AFDはフローを識別し、WREDはフローの識別をしない。適切な方を使うのが良い。

AFDはETRAP(エレファントトラップ)を使った制御でバイト数によりエレファントなフローを識別する。ここでのフローとは5 Tupleである。これは一般的なフロー管理がされ、タイムアウトもする。show hardware flow etrap により、ETRAPのステータスを確認できる。

WREDかAFDはシステムでどちらかを排他に選択できる。policy-map内のclassでbandwidthの設定と一緒にAFDを書ける。

QoS（概要）: RDMA向けのパケットロスレスネットワークの構築方法について

PFC, ECNの仕組みを図付きで詳細に説明している。読みやすいので最初の読むのに良いだろう。 CiscoのConfigベースのサマリがある。

RDMAは従来のIP通信にない特性を持つ。ただし、パケロスによるペナルティは非常に大きく、アプリケーション層における再送などが発生するため、RDMAの伝送効率は著しく落ちる。

輻輳が発生する理由はいくつかある。 1: オーバーサブスクリプション。通常のCLOSはコストの観点からオーバーサブする。これにより、帯域を上回った通信が発生する。 2: ECMP。ハッシュは偏りが発生する。 3: TCP incast。Many-to-Oneの通信パターン。Hadoopなどの分散ストレージ、あるいはHPC関係で発生する。

服装のコントロールはバッファのコントロールと言える。マイクロバーストを考慮した制御をしなければならない。

PFCのデッドロックはノードの故障などで特に起こりえる。そしてデッドロックはPFCを用いるネットワークで最も気をつけなければならないことの１つ。そこで、RuijieのノードはPFCデッドロックの検知機能を有する。これはPFCのPAUSE状態が連続して起こる場合に転送を開始する機能である。

RoCEv2を動作させるコツはPFCよりも先にECNがトリガされるようにすることだ。これによって、網の制御の前に個々の制御を先にトリガできる。

QoS（概要）: RDMA over Converged Ethernet (RoCE) on Cisco Nexus 9300

PFC, ECNの仕組みを図付きで詳細に説明している。読みやすいので最初の読むのに良いだろう２。

PFC Watchdog (PFCWD) はNexus9000で使える仕組みである。これはPFCデッドロックが発生した際に、キューをフラッシュすることでデッドロック状態を防ぐ仕組みである。以下のようなコマンドを用いることができる。

priority-flow-control watch-dog-internal on

また、RDMAはカーネルをバイパスするのでtcpdumpできないことに注意する必要がある。これはNICにフラグを立てることで回避することができる。

QoS(Mellanox側の設定について)

全体的な説明はLOSSLESS ROCE CONFIGURATION FOR LINUX DRIVERS IN DSCP-BASED QOS MODEを見ること。

ECNの設定はHOWTO CONFIGURE DCQCN (ROCE CC) VALUES FOR CONNECTX-4 (LINUX)で述べられている。 この記事はRoCE congestion control(RoCE CC)について、つまり、DCQCNについてのもの。 4.1以降は比較的簡単。マニュアルを見ること。4.0以前なら、ECNの有効化や確認は次のようにできる。

echo 1 > /sys/class/net/ens785f1/ecn/roce_np/enable/3
echo 48 > /sys/class/net/ens785f1/ecn/roce_np/cnp_dscp
echo 6 > /sys/class/net/ens785f1/ecn/roce_np/cnp_802p_prio

QoS: Intelligent Buffer Management on Cisco Nexus 9000 Series Switches White Paper

難しい、というかディープ。Nexus9000系のインテリジェントバッファに関する記事。

Data Center Traffic Forwarding and Buffer Management

まず、データセンタートラフィックはMiceとElephantの識別が重要になる。ほとんどのフローはマウスである。ある調査によれば、フロー数は9:1だが、トラフィック量は逆に1:9となる。まず、この両者はトラフィック要件が全く異なることに注意する。帯域、欠損、レイテンシである。

一般的なエレファントフローは大容量の通信で広帯域を求めたがる。一方で、マウスのフローはアプリケーション層のクエリ・制御などに関するもので、レイテンシにシビアである。一般にこれらはTCPで通信されるため、TCPで制御される再送制御を考えるとパケットロスは大きな性能への影響が起きる。

ここでの問題最大の問題は、一般のQoSにおいて、エレファントとマウスが１つのキューに存在することである。主に、マウスフローをパケット損失から守り、長いキューに並ばないようにする必要がある。ただし、エレファントなフローも適切に広帯域な通信ができなければならない。帯域が食い潰されることを抑制するために、エレファントフローに少量のパケットドロップを意図的に引き起こすことでSrc側に速度を遅くしてもらう調整を行うことが一般的である。多くのエレファントフローに対して、TCP再送信などが機能するため、これは有効に動く。

エレファントとマウスを適切に認識して処理することが重要になる。しかし、一般的なQoSの世界ではこれらを区別すること、また、区別して処理することはできない。なぜなら、キューはシンプルなFIFOにしかすぎず、（残念ながら）公平にパケットを間引く。つまり、マウスのフローを選択的にバッファリングできないのだ。これにより、ドロップされたパケットはTCPレイヤで適当に帯域制御され、網全体で最適になることを期待する。 この問題のため、一部のメーカでは、Deep Bufferによりうまく処理することをアピールする。しかし、ディープバッファはパケットの遅延を大きくし、根本的な問題は解決しない。つまり、遅延が長くなり、パケットロスは変わらず発生しうる。言い換えれば、ディープバッファは単にコストを増大させるだけのソリューションかもしれず、結局、マウストラフィックに対する問題は変わらない。TCPは設計的に貪欲なプロトコルであり、リンク・バッファを埋めるように制御されるためです。

Nexus9000シリーズのASICはインテリジェンスなバッファを提供し、この問題に対応する。特に、エレファントとマウスを識別するために、ETAP, DPP, AFDなどがある。これらによって識別されたものはマウスのみをLLQ(低遅延キュー)に入れるなど賢い制御が可能となる。これらについて説明していく

Approximate Fair Dropping (AFD) with Elephant Trap

AFDはキュー管理のための仕組みであり、エレファントフローテーブルを持つ。Sharedなoutput queueの公平な割り当てをする。ここでの特徴は２つがある。 1: エレファントとマウスを適切に区別し、マウスをパケットドロップから除去すること 2: エレファントフローを識別して、その中で適切な制御を行うこと

エレファントテーブルはエレファントフローを追跡するもので、アクティブなフローであるかとどのようなレートを持つかを保持する。このテーブルにはタイムアウトおよび、エレファントと識別するための帯域幅を持ちます。一度エレファントと識別されたフローでも単位時間あたりの帯域幅が大きくないのであればエレファントとならない。

AFDを構成する要素は大きく次の2つからなる。 1: ETRAPはフローテーブルそのものに近く、入力ポートのエレファントを適切にエレファントテーブルとして管理して出力側のバッファに公平に渡す。 2: 公平帯域制御。AFDはout queueの状態をフィードバックして、適切な帯域制御を行います。各フローごとに最適なレートが求められ、その帯域以下ならば通過し、帯域以上ならランダムなドロップを行います。この際に、どの程度帯域を超えるかによってドロップレートを変更します。

AFDとWRED(や、RED)を比較する。　WREDは従来使われてきたパケット破棄のアルゴリズムでクラスごとに重みをつけた破棄を行う。しかし、クラス内でのフロー識別は行わないため、エレファントとマウスの識別なくパケットフォロップがおこなります。この結果、マウスフローもエレファントと同じように落とされる。また、一度帯域幅が落ちたフローは再度広帯域な帯域を取ろうとするため、再度フローでの衝突が起こる。AFDでは各フローがエレファントかを識別することでこのような衝突が起こらないようにする。

ECNをAFDと組み合わせることができる。ここまで、AFDの動作はパケットドロップとして扱ったが、代わりにECNで通知することができる。つまり、AFDによって特定の閾値を超えたもの（おそらくエレファント）に対してECNフラグを立てることができる。

AFDの設定について述べる。 1: ETRAPのパラメータ値を宣言する 2: Policy mapでバッファの深さと共にAFDを有効にする。 3: 出力インタフェースに設定する

ETRAPのパラメータについて見ていく。また、NX-OS 7.0での標準値を紹介する。 バイトカウント。そのフローの転送する量がこの閾値を超えるとエレファントフローとしてみなされる。NX-OS7.0では1MBが閾値。 Age Time: フローのタイムアウト。NX-OS7.0では 500us。 Bandwidth閾値: 現在もエレファントなフローかを識別するためのもの。ウィンドウ的になっており、そのウィンドウ内の転送量がBandwidth閾値を下回ればエレファントから消える。NX-OS7.0では500byte。 また、バッファの深さも指定する必要があり、afd queue-definedで指定をする。ここで、Ciscoの推奨値がある。（おそらく、NX-OS7.0時点での）推奨値は100Gbpsで1.5MBのキューの深さである。さらに、show queuing interfaceでAFDの状況は確認できる。

Dynamic Packet Prioritization (DPP)

つぎにDPPを見ていく。DPPは動的なパケットの優先制御で１つのキューの中でマウスとその他のフローを分けたキューで管理する。DPPの仕組みは一見AFDと似るところもあるため注意深く確認すること。 AFDとDPPは排他な関係ではなくて、両立できる。DPPでマウスフローのための優先キューを用意し、DPPはエレファントフロー内での適切な公平帯域制御を提供する。

DPPでは入力されたトラフィックは5 tupleでフローとして解釈される。ここでパケット数のカウンタを数え、閾値Nを超えていないフローはマウスと区別される。必要なパケットだけがマウスと判断されるように注意する必要がある。

マウスフローは優先キュー(Priority Queue)で処理される。ここでの優先キューはQoSの優先キューと同意義である。この利点を述べる。(TODOここは2nd reasonがよく理解できない)

DPPの動作は２つのパラメータで構成される。 age timer: フローの生存時間。 max-num-pkts: 閾値となるパケット数。これを超えない限りはマウスとして優先される。 処理されたフローは閾値を超えている限りはdefaultで指定されたグループにマップされる。一方で、閾値を超えないフローはdpp set-qos-groupで指定されたキューに分類される。これはincommingのキューで設定されることに注意する。さて、エレファントなフローは出力インタフェースのin queueに到達する。ここでAFDを追加で適応することができる。これにより、エレファントなフローを公平に扱うことができる。

Application Benefits of AFD and DPP

ここでは、CiscoとAristaのスイッチを実際に比較した例を見ていく。CiscoのスイッチではAFDとDPPを有効にしている。対してAristaではシンプルな構成（注意: PFCのEnableなどは語られていない、と思う）である。結論はCiscoのスイッチの方が良い結果となった。

従来のスイッチはすべてのフローを公平に制御してしまう。このためマウスフローもエレファントなフローと一緒にキューに並んでしまう。Ciscoのスイッチはマウスフローを優先的に処理できる。また、CiscoはAFDによって適当に溢れそうなエレファントフローを抑制した。ここでの興味深いことはAFDを使用した方が、ディープバッファよりドロップ数は多いもののアプリケーションとしての性能はAFDの方が早いことである。これはマウスフローによるコントロールがタイムリーに行われることだろう。

バッファの使用量も約10倍異なる。バッファメモリは効果であるため、これはコストに大きく影響する。QoSの項で述べた通り、キューイングの仕組みによってN*Nのバッファを持つ必要があるからだ。

本文にはもう少し詳細に記載がある。ただ、これはアプリケーションによって異なりすぎるだろうから、必要な部分を適切に読むこと。

Conclusion

昨今のフローはロングテールなトラフィック分布となっており、フロー数が9:1でもトラフィック量は1:9という状態である。加えて、マウスのフローはマイクロバースト的な特性を持っており、これらをどのように賢く処理するかでデータセンタ全体のアプリケーションに対するパフォーマンスに影響を与える。

従来型のディープバッファなデータセンタースイッチはすべてのトラフィックを公平に扱う。一方でNexusはCloud Scale ASICに実装されたETRAP, DPP, AFDを用いたインテリジェントバッファを持つことで賢くマウスとエレファントのフロー管理できる。マウスなフローはパケット損失を回避するだけでなく低遅延にマイクロバーストを許容されて処理される。エレファントフローも適切な帯域制御が行われる。

以上のことよりCiscoのスイッチは、スイッチに過度な深いバッファスペースを必要とせずにトラフィックの増大という現在のデータセンタの課題にアプローチできる。