ネットワーク輻輳のないQoSの無益の神話

職場では、IPTVやVoIPなどのサービスを正常に動作させるために、輻輳のないイーサネットネットワークでQoSを構成する必要がないという意見に何度か遭遇しました。 この意見は私と同僚に幻の問題を診断するのに多くの神経細胞と時間を費やしたので、この意見が間違っている理由についてできるだけ簡単に話そうと思います。



私の名前はウラジミールで、サンクトペテルブルクの小さなISPの1つでネットワークエンジニアとして働いています。



当社が提供するサービスの1つは、IPTVストリームを転送するためのL2VPNです。 このサービスの例では、私が物語をリードします。



それはすべて、IPTVの品質に関する苦情を伴うクライアントオペレーターからのテクニカルサポートへの呼び出しから始まります。画像はストリーミングされ(「アーティファクト」)、一般に、標準セットの音は消えます。 ネットワーク内のIPTVは、保証された転送キューに分類されるため、診断はルート上の腺を通過し、出力用のAFキューに損失がないこと、および入力キューに物理的なエラーがないことを確認することです。 その後、私たちは責任を負っていないことをクライアントに快く報告します。クライアントが自分自身またはIPTVプロバイダーに問題があるかどうかを調べることをお勧めします。



しかし、クライアントは私たちが非難することを押し続け、主張し続け、すべては彼と一緒です。 すべてを再度チェックし、クラシファイアの正確性を確認し、クライアントからのパケットをマークし、ダイアログが確立され、ある段階で「ネットワークでQoSをどのように設定しますか?」という質問をします。 %はロードされていないため、QoSは不要です "。 重いため息をついて走り去った。



通常、全員が見ているダウンロードスケジュールの間隔は5分です。 「リアルタイム」が1から始まる数秒の場合、残念ながら幸運なことに、最新のネットワーク機器は5分でも1秒でもピコ秒ではありません。 インターフェースが1秒以内に100%ロードされなかったという事実は、数ミリ秒間同じ方法でロードされなかったことを意味しません。



ここで、概念的な概念であるマイクロバーストに到達します。 これは、デバイスが受信するデータの量が、インターフェースが送信できる量よりも大きくなる、非常に短い時間です。



通常、最初の反応はどうですか?! 私たちは高速インターフェースの時代に生きています! 10Gb / sはすでに一般的であり、40および100Gb / sはどこでも実装されており、1Tb / sのインターフェースをすでに待っています。



実際、インターフェイスの速度が速いほど、マイクロバーストとネットワークへの影響が強くなります。



発生メカニズムは非常に簡単です。2つのトラフィックが3つ目のトラフィックを通過する3つの1Gb / sインターフェイスの例として考えます。



画像



これは、マイクロバーストが発生するための唯一の前提条件です。したがって、着信(入力)インターフェースの速度が発信(出力)インターフェースの速度を超えます。 何にも似ていませんか? これは、イーサネットネットワークの集約レベルの従来のスキームです。多くのポート(入力)は、トラフィックを1つのアップリンク(出力)にマージします。 これが、通信事業者からデータセンターに至るまで、ネットワークですべてが絶対に構築される方法です。



各出力インターフェイスには、リングバッファであるtx-ring送信キューがあります。 ネットワークに送信されるパケットが追加され、もちろんこのバッファのサイズは有限です。 ただし、送信側の入力インターフェイスにも、同じラインレートを提供する同じリングバッファがあります。 同時にトラフィックの送信を開始するとどうなりますか? 出力インターフェイスは、パケットを送信できる速度の2倍の速度でいっぱいになるため、txリングに十分なスペースがありません。 残りのパッケージはどこかに保存する必要があります。 一般に、これはキューと呼ばれる別のバッファーです。 tx-ringにスペースがない限り、パケットはキューに入れられ、tx-ringの空きスペースを待ちます。 しかし問題は、キューのメモリが有限であることです。 入力インターフェースが長時間ラインレートで動作する場合はどうなりますか? キュー内のメモリも終了します。 この場合、新しいパッケージには格納する場所がなく、破棄されます-この状況はテールドロップと呼ばれます。



そのようなシナリオが現実になるにはどれくらい時間がかかりますか? 数えましょう。



最も難しいのは、インターフェイスバッファの容量を見つけることです。 ベンダーはそのような情報をあまり積極的に公開しません。 しかし、たとえば、200ミリ秒の時間を取りましょう。通常、パケットをキューに保持することは意味がありません。これはすでにたくさんあります。



1Gb / sインターフェースの場合、(1,000,000,000 * 0.2)/ 8 = 25MBのメモリが必要です。 2つの1Gb / sインターフェイスのラインレートでバッファが完全に一杯になるまでどれくらいかかりますか? 200ms。 これは、25MBが1Gb / sの速度で送信される時間です。 はい、2つの入力インターフェイスがありますが、出力インターフェイスもアイドル状態であり、同じ速度でデータを送信するため、200ミリ秒です。



これは比較的大きな数字です。 そして、10Gb / sの入力インターフェース、1Gb / sのインターフェースの200msのバッファをリロードするのにどれくらい時間がかかりますか? 〜22ミリ秒。 これはすでにかなり少なくなっています。



そして、10Gb / sインターフェースで200msを保存するのにどれくらいのメモリが必要ですか? すでに250MB。 現代の基準ではそれほどではありませんが、この方向に風が吹いています-速度が増加し、バッファの深さを維持するために、より多くのメモリが必要になります。これにより、エンジニアリングおよび経済的な問題が発生します。バッファが小さいほど、マイクロバーストが速く詰まります。



ベンダーエンジニアにとって永遠の疑問であることがわかりました。ハードウェアのインターフェイスにどのくらいのメモリを提供するのでしょうか。 多くは高価であり、1ミリ秒ごとに意味がなくなり、意味がなくなります。 少数-マイクロバーストは、大きなパケット損失と顧客からの苦情につながります。



他のシナリオでは、自分で計算できますが、結果は常に同じです-キューとテールドロップは完全に詰まっており、グラフではインターフェイスシェルフが近くで臭いがすることはなく、どのような期間でも5分1秒です。



パケットネットワークでのこの状況は避けられません-インターフェイスは1秒未満のラインレートで動作し、すでに損失があります。 これを回避する唯一の方法は、ネットワークを構築して、入力速度が出力速度を超えないようにすることです。これは非現実的で非現実的です。



さらなるロジックはすでに追跡可能であり、かなり明白です。 パケット損失はありますが、QoSは設定されていません-優先トラフィックはいかなる方法でも分類されず、他のトラフィックと違いはありません。1つの一般キューに落ち、そこでドロップされる可能性が等しくなります。



どうする QoSを構成します。 優先トラフィックを分類し、大量のメモリを割り当てる別のキューに入れてください。 優先パケットが他のパケットよりも早くtx-ringに到達するようにパケット送信アルゴリズムを設定します-そのため、キューはより速くクリアされます。



たとえば、私たちの実践では、キューに対して次のアプローチを使用します。



アシュアードフォワーディング(AF)-「保留するが配信する」。 AFキューでは、保証された配信を必要とするトラフィックが分類されますが、遅延の影響を受けません。 このキューには大量のメモリが割り当てられますが、tx-ringには比較的小さなスペースが割り当てられ、パケットは他のパケットよりも遅く到着します。 このようなトラフィックの顕著な例はIPTVです。クライアント(VLCまたはSTB)でバッファリングされるため、遅延させることができますが、損失は画像のアーチファクトに変わります。

優先転送(EF)-「即時配信または破棄」。 このキューにはキューの最小割り当て(またはメモリなし)が割り当てられますが、パケットができるだけ早く送信されるように、txリングに入るための最高の優先順位が設定されます。 トラフィックの例はVoIPです。 音声を遅く配信することはできません。そうしないと、テレフォニーコーデックは音声を正しく収集できなくなります。サブスクライバーには、クローキングが聞こえます。 同時に、全体的な音声品質に対する個々のパケットの損失はあまり影響しません-それは人々にとって理想的ではありません。

また、それぞれネットワーク管理およびその他すべてのネットワーク制御(NC)およびベストエフォート(BE)があり、トラフィックは、たとえば、VoIPとIPTVのハイブリッドである電話会議でもありますが、これは完全に別のトピックです。それらのQoSは、トポロジおよびその他の要因に応じて、各ネットワークで個別に実行されます。 全体として、一般に、次のようになります(Cisco Webサイトの写真)。



画像



ネットワークでQoSを構成することを望みますか?



All Articles