スイッチは機械学習を夢見ているのでしょうか? ネットワーク内指向の分類

スイッチは機械学習を夢見ているのでしょうか? ネットワーク内指向の分類

まとめ

機械学習は現在、技術革命と社会革命を推進しています。プログラマブル スイッチはネットワーク内のコンピューティングに有用であることが証明されていますが、プログラマブル スイッチ内の機械学習はこれまでのところほとんど成功していません。ネットワーク内で処理を行うとエネルギー効率とパフォーマンスに利点があることが知られているため、ネットワーク機器を使用せずに機械学習を実行すると、コストが高くなります。この論文では、トレーニングされた機械学習モデルを一致アクション パイプラインにマッピングすることにより、ネットワーク内の分類に汎用プログラマブル スイッチを使用する可能性を探ります。ソフトウェアベースおよびハードウェアベースのプロトタイプ IIsy を紹介し、さまざまなターゲットへのマッピングの適用可能性について説明します。この論文で紹介したアプローチを使用すると、私たちのソリューションは他の機械学習アルゴリズムに一般化できます。

ACM 参照フォーマット: Zhaoqi Xiong および Noa Zilberman。2019年。Do Switches Dream of Machine Learning? Toward In-Network Classification (スイッチは機械学習を夢見ていますか? ネットワーク内分類に向けて) ネットワークのホット トピックに関する ACM ワークショップ (HotNets '19)、2019 年 11 月 13 ～ 15 日、米国ニュージャージー州プリンストン。ACM、ニューヨーク、米国、9 pp. https://doi.org/10.1145/3365609.3365864

1 はじめに

機械学習 (ML) は、オンライン ショッピングのパーソナライズからソーシャル ネットワーキング、金融、取引に至るまで、私たちの日常生活のデジタル側面をますます支配しています。システム コミュニティは、ムーアの法則 [33、39] の終焉やデナード スケーリング [19] からメモリとコストの制約 [42] まで、増大するハードルに直面しながら、ML の要求を満たすのに苦労しています。これらの課題は、CPU 最適化 (例 [6, 53])、GPU (例 [14])、FPGA (例 [18, 21, 51]) ソリューションや専用処理 ASIC など、ML ハードウェア設計の革新を推進します。 12、26]。あらゆる形式の ML アクセラレーションが大きな注目を集めています。

ネットワークは、最適化と意思決定に使用される ML から逃れる傾向もありません (例 [13、23、52])。プログラマブル ネットワーク デバイスの台頭により、ネットワーク内の ML が広く使用されることが期待されました。ネットワーク内コンピューティングは、優れたパフォーマンスを発揮するだけでなく [24、25]、エネルギー効率も優れています [50]。ただし、ネットワーク内 ML はオンライン コミュニティではまだ広く採用されていません。実際、ネットワーク内アグリゲーション [45] などを通じて、ネットワーク デバイスを使用して分散 ML を改善できることが示されていますが、これはネットワーク デバイス内で ML が実装される方法ではありません。ネットワーク内での推論に向けた考えられる最初のステップは、プログラマブル ネットワーク デバイス内にニューラル ネットワークを実装する方法を議論した N2Net [47] と BaNaNa Split [43] でした。

このペーパーでは、次の質問に焦点を当てます: ML トレーニングがすでに進行しているときに、トレーニングされたモデルをプログラマブル ネットワーク デバイスに展開できますか? これにより、ML の特定の側面、つまり分類に焦点を当てます。私たちは、非ニューラル ネットワーク ベースの ML 推論分類に焦点を当て、トレーニングされたパケット分類モデルがプログラム可能なデータ プレーンにシームレスにマッピングされることを示します。このマッピングは、流量でのトラフィック分類を実現し、限られたリソース、流量、分類精度の間のバランスを見つけます。さらに、特徴セットが静的である限り、分類モデルの更新は、データ プレーンを変更する必要がなく、コントロール プレーンを通じてのみ展開できることを示します。

この文書における私たちの貢献は次のとおりです。

• 4 つの異なるトレーニング済み機械学習アルゴリズムを match-action パイプラインにマッピングする例を示します。

• トレーニングされたモデルを一致アクション パイプラインに自動的にマッピングする、ソフトウェアおよびハードウェア ベースのプロトタイピング フレームワークを導入します。

• ハードウェア ターゲットのネットワーク内分類を実証し、リソース要件を定量化します。

私たちの仕事の範囲は限られています。すべての ML アルゴリズムを調査したわけではありません。ニューラル ネットワークなどの最も一般的なアルゴリズムでさえ、この記事の範囲を超えています。当社は、ML アルゴリズムに関していかなる貢献も主張しません。さらに、私たちの方法には、精度と抽出される特徴の種類の点で設計上の制限があります。私たちの分類学的貢献は、ネットワーク デバイス内でのより複雑で特殊な推論への第一歩であると信じています。私たちのコードは [57] で入手できます。

1.1 動機

機械学習 (ML) の実行、つまりネットワーク機器内で ML を実行することは、いくつかの理由から裏付けられる興味深い見通しです。まず、スイッチのパフォーマンスが非常に高いです。スイッチを通過するレイテンシはパケットあたり数百ナノ秒程度 [3] ですが、ハイエンド ML アクセラレータの推論レイテンシは数十マイクロ秒からミリ秒の範囲です [26、36]。同じアクセラレータは 10 ～ 90 TOPS/秒 [26] を達成しますが、16 Tb/秒のスイッチは 1 秒あたり約 150 億パケットをサポートします [31]。ただし、OPS/秒はパケット レートに直接マッピングされません。たとえば、NVidia Tesla V100 は 1 秒あたり 10,000 枚の画像を推論できますが [36]、同じ画像データセットは 1 秒あたり 10,000,000 画像を超える速度でスイッチを介して送信できます。ネットワーク スイッチの電力効率により、ほとんどのアクセラレータよりも優れたワットあたり数万のパケットの処理が可能 [50] であり、プログラマブル スイッチ [3] は今日の代替品 [26] よりも絶対的な電力消費が少なくなります。

スイッチには別の利点もあります。それは、特定の ML ユースケースにとって理想的な位置にあるということです。分散 ML のパフォーマンスは、ノードとの間でデータを転送するのにかかる時間によって制限されます。スイッチが分散システム内のノードにパケットを送信するのと同じ速度でパケットを分類できれば、単一ノードのパフォーマンスに匹敵するか、それを超えることさえできます。データセンターの外では、スイッチにはさらに利点があります。データを早期に終了し、ネットワーク負荷を軽減し、長期的なスケーラビリティを可能にすることができます。エッジ近くでデータを終端すると、電力が節約され、インフラストラクチャの負荷が軽減され、待ち時間が短縮されてユーザー エクスペリエンスが向上します。何よりも、スイッチはすでにネットワークに導入されているため、追加のハードウェアをインストールする必要はありません。単一のスイッチが ML とネットワーク操作の両方をサポートできる限り、ML アクセラレータで強化されたシステムよりも安価なソリューションが提供され、ML アプリケーションを実行する CPU のサイクルが解放されます。

この作業では、分類タスクのみに焦点を当てます。ユーザー生成データの量が増加し続けるにつれて、ネットワークは年間 10 ZB を超える膨大なサイズのデータ​​に対する防御の第一線となります [15]。モノのインターネット（IoT）の普及により、データのサイズはさらに拡大し、その多くは機密化が必要になることが予想されます。ミドルボックスは現在でもエッジで必要な処理量を処理できますが、データ需要の増大に応じて拡張し続ける可能性は低いです。しかし、データが処理先に到達する前にネットワーク内で分類を実行できたらどうなるでしょうか? 処理をオフロードできるだけでなく、イベントに早期に応答して、エッジ付近でトラフィックを終了することもできます。自動運転車や自動化された工場などのアプリケーションは、この利点が得られる遅延に敏感なアプリケーションの一部です [46]。

おそらく、ネットワーク内部分類の最も単純な例は、組み込みデバイスと IoT デバイスを使用して、選択されたターゲットに対してサービス拒否攻撃を開始する Mirai ボットネットです [2]。エッジ デバイスが「標準」アクセス コントロール リストを使用する代わりに、ML ベースの推論の結果に基づいてすべての Mirai 関連トラフィックをドロップした場合、攻撃を早期に阻止することは可能でしょうか? ユースケースについてはセクション 6.3 と 7 でさらに説明します。

2. 分類機としてのスイッチ

商品取引所は当然選別機として機能します。標準的なレイヤ 2 イーサネット スイッチを例に挙げると、どのようなスイッチ アーキテクチャも適用可能ですが、P4 [8] や NPL [35] で使用されているようなプログラム可能なデータ プレーンのメンタル モデルを維持しています。

新しいオブジェクト (パケット) が到着すると、最初のステップはそこから関連する特徴を抽出することです。スイッチでは、これはパケットのヘッダーを解析することに似ています。各ヘッダー フィールドは実際には特徴であり、ヘッダー パーサーは特徴抽出器です。

分類プロセスの次のステップは、オブジェクトの特徴をトレーニングされた機械学習モデルに適用することです。レイヤ 2 イーサネット スイッチの場合、モデルは 1 つのレイヤのみを持つ非バイナリ デシジョン ツリーの形式をとります。ルートの分割特性は宛先 MAC アドレスです。スイッチ内の MAC アドレス テーブルにアクセスすることで、オブジェクト (パケット) の特性 (宛先 MAC アドレス) に対応する正しい分岐を見つけることができます。適切なブランチが見つかると、オブジェクトがクラスに割り当てられます。これは、パケットが出力ポートに割り当てられることを意味します。この類似性を図 1 に示します。

レイヤ 2 イーサネット スイッチは、より複雑なデシジョン ツリーで表すこともできます。たとえば、送信元ポートが宛先ポートと同じかどうかを確認し、値が同じ場合はパケットをドロップします。デシジョン ツリーでは、これにより、別のレイヤーと追加のクラスが追加 (削除) されます。

スイッチは機械学習を夢見ているのでしょうか?

図1: デシジョン ツリーと単純なスイッチ パイプラインの類似点。同様のコンポーネントは丸で囲まれています。M/Aとはマッチングオペレーションを意味します。パイプの出力は、単なるポートの割り当て以上のものになる可能性があります。

3. 重要なポイント

これまで機械学習アルゴリズムがネットワーク機器に実装されていない理由の 1 つは、必要な数学的演算の実装が複雑であることです。加算、XOR、ビット シフトなどの演算はスイッチ ハードウェアで簡単に実装できますが、乗算、多項式、対数などの演算は適切にパイプライン化されていないため、遅延が増加したり、スループットに影響を与える可能性があります。ただし、スイッチは loд(x) や loд(y) などの演算をサポートしていませんが、loд(x) と loд(y) がわかれば、loд(x × y) などの演算を簡単に実行できます。

スイッチ内に数学演算を実装しようとはしません。代わりに、プログラマブル ハードウェア (FPGA など) とハイ パフォーマンス コンピューティングの一般的な慣行を借用し、ルックアップ テーブルを使用して計算結果または同等の結果を保存します。ルックアップ テーブルは、プログラマブル スイッチで使用される一致アクション パラダイムに完全に適合します。

実際には、実装は思ったほど簡単ではありません。ハードウェア スイッチのリソースは限られており、すべての可能な値をサポートするための無限サイズのテーブルを格納することはできません。この作業で採用した解決策は、テーブルに基礎となる値を一切保存せず、実現可能性を犠牲にしてある程度の精度を失うことを許容することです。計算結果の代わりに分類結果またはコード (§5) を保存することでメモリをさらに節約し、結果として 3 値テーブルと最長前置一致 (LPM) テーブルをより効率的に使用できるようになります。

すでに述べた 2 番目の点は、スイッチが分類マシンとして設定され、パーサーが特徴抽出モジュールとして機能し、分類を行うために一致アクション パイプラインが使用されることです。

多くのスイッチ アーキテクチャでは、パケットの一部だけがプログラマブル データ プレーンを通過し、残りはバッファリングされます [8]。パケット全体を処理するための 1 つの解決策は、パケット (および機能) をヘッダー サイズのデータ​​ ユニットに分割し、パイプラインをステップ実行するパケット ループ処理です。このアプローチではスループットが低下し、メタデータを維持するための調整が必要になりますが、ネットワーク使用率が低いか、速度が十分に改善されていれば、依然として良好なパフォーマンスを発揮できます。

4. 実際のリソース割り当て

これまで、分類アルゴリズムを一致アクション パイプラインにマッピングするための重要なアイデアについて説明してきました。このセクションでは、より現実的なアプローチを使用して、ネットワーク内でのソートにおける汎用スイッチの制限を検討します。

まず、スイッチは分類を実行するだけでなく、重要なスイッチング機能も含む場合があることに注意してください。したがって、スイッチングやその他のスイッチ機能を機械学習動作として検討する前に、基本的なネットワーク機能によって大量のリソースが消費されることが予想されます。

第 2 に、上で紹介したすべてのネットワーク内分類ソリューションは重要な特性を共有しています。それは、外部依存関係を必要としない、つまり、ターゲット固有の機能を必要としないということです。この純粋な一致アクションの実装により、異なるターゲット間での移植性が可能になり、ソリューションが単一のプラットフォームに固定されないことを意味します。

現在のプログラマブル スイッチは、デバイスごとに複数 (たとえば 4 つ) のパイプラインを備え、パイプラインごとに 12 ～ 20 のステージをサポートしているため、サポートされる機能が制限されていることがわかります。テーブル メモリは数百メガビット [9] のオーダーであり、複数のパイプラインに分散される場合があります。また、パーサーはパイプラインの深さに匹敵する限られた数のヘッドしか抽出できません。そのため、一部の分類実装では、特徴の数がカテゴリの数に匹敵します。一方、特性の幅は非常に大きくなる可能性があり、たとえば IPv6 アドレスは 128 ビット幅です。テーブルの深さがキーの幅に比例すると期待するのは非現実的であり、むしろネットワークのサイズ (スイッチの場合) または分類問題 (ネットワーク内の分類の場合) に比例します。

実際には、テーブル キーとして複数の機能を使用することは実装が簡単ではありません。シリコン ベンダーは IPv6 の 128 ビット アドレスのルックアップ テーブルの実装に苦労しており、現在の最先端のメモリ深さは 300K ～ 400K エントリに達するだけです [ 4, 5] であるため、この量より大幅に大きいもの (たとえば、10 倍を超えるもの) は非現実的であると考えられます。ただし、128 ビットが実現可能なキー幅であると仮定すると、大きな可能性が広がります。TCP の送信元ポートと宛先ポートがそれぞれ 16 ビットを占有するため、フラグは通常数ビットにすぎず、ethertype も 16 ビットであるため、複数の特性を 1 つのキーに連結できます。 IPv6 アドレスの幅に達することはありません。

さまざまなアルゴリズムの実装に必要なリソースの量に制限を設定することは避けます。そのような制限は現実とほとんど似ていないためです。たとえば、テーブルのキー幅が w の場合、テーブルの深さはわずか 2^w になり、テーブルがダイレクト マップされている場合にのみ、単純なメモリとして実装でき、アクションを保存するだけで済みます。完全一致、最長接頭辞一致、および範囲タイプのテーブルを使用することは、テーブルの深さの要件を回避することを目的としていますが、テーブル幅 (キー幅とアクション幅) が増加します。これについてはセクション 6.3 で詳しく説明します。

分類に使用される特徴 (またはカテゴリ) の数を増やす 1 つの方法は、複数のパイプラインをチェーンすることです。この場合、1 つのパイプラインの出力が次のパイプラインの入力として使用されます。このアプローチには 2 つの課題があります。まず、デバイスの最大スループットが、接続されているパイプラインの数の係数で減少します。次に、ステージ間で使用するメタデータはパイプライン間で共有されないため [3]、情報を中間ヘッダーに埋め込む必要がある場合があります。

5. 機械学習からマッチアクションまで

この研究では、一般的な PISA または RMT [9] パイプライン モデルを想定して、プログラマブル データ プレーンの P4 アプローチ [8] を採用します。教師あり学習と教師なし学習を含む、パケット分類のための 4 つのアルゴリズム (デシジョン ツリー、K 平均法、サポート ベクター マシン (SVM)、ナイーブ ベイズ) の使用を検討します。これらのアルゴリズムは、その違いと結果の一般化可能性を考慮して選択されました。ニューラル ネットワークはこの作業の範囲外です。表 1 に私たちのアプローチをまとめます。

5.1 デシジョンツリー

デシジョン ツリーは、マッチアクション パイプラインに直感的にマッピングできます。各段階で、一連の条件がフィーチャに適用され、その結果がツリーのさまざまな分岐につながります。条件は単純な演算なのでP4でも実装可能です。ただし、ツリーの深さと状態によってパイプラインのステージ数が決まるため、このアプローチは無駄です。私たちは、マッチアクション パイプラインにより適した別のアプローチを提案します。つまり、パイプラインに実装されるステージの数は、使用される機能の数に 1 を加えたものに等しくなります。各段階で、特徴とその可能なすべての値が照合されます。結果 (アクション) はメタデータ フィールドにエンコードされ、ツリー内で選択されたブランチを示します。パイプラインの最後のステージでは、メタデータ バスからすべての機能のエンコードされたフィールドをフェッチし、その値を結果のリーフ ノードにマッピング (照合) します。

デシジョン ツリーは範囲タイプのテーブル [37] を使用して実装できますが、これらのテーブルは多くのハードウェア ターゲットでは利用できません。固有値の数が既知で制限されている場合は、代わりに完全一致テーブルを使用できます。あるいは、トリプル値の最長プレフィックス一致 (LPM) テーブルを使用して範囲を複数のエントリに分割し、(範囲タイプのテーブルと比較して) リソースの消費量が増加しますが、実行可能な使用パスを提供できます。

5.2 サポート ベクター マシン (SVM)

2 番目の教師あり学習アルゴリズムは、超平面を使用して異なるクラスを分離するサポート ベクター マシン (SVM) です。トレーニング プロセスの出力は複数の方程式の形式をとり、各方程式は超平面 ^ 5 を表します。

ここで、n は特徴の数、k はカテゴリの数、m = k * (k - 1) / 2 です。

SVM (表 1.2) を実装する 1 つの方法は、m 個のテーブルを実装することです。各テーブルは超平面専用であり、指定された入力が超平面のどちら側にあるかを示します。マッチアクションテーブルにアクセスするために使用されるキーは特徴コレクションであり、複雑な操作を避けるためにアクションは「投票」です。「投票」は、入力が超平面の内側に属するか外側に属するかを示す、メタデータ バスにマッピングされた 1 ビットの値です。入力が m 個のすべてのテーブルと照合されると、すべての「投票」(カテゴリ間のメタデータ バスの合計) がカウントされ、最も多くの「投票」を持つカテゴリが分類結果となります。

2 番目のアプローチ (表 1.3) は、特徴ごとにテーブルを専用にすることであり、テーブルの出力は a1x1、a2x1、...amx1 という形式のベクトルになります。マッチアクションパイプラインの最後で、各超平面の値、つまりすべてのベクトルの合計が計算され、決定が行われます。このアプローチにはより小さなテーブルが必要ですが、いくつかの制限があります。結果として得られるベクトルの値の精度は限られており (浮動小数点数を表現できないなど)、多くのビットが必要になる場合があります。さらに、一致アクション パイプラインの最後で重要な論理演算 (合計演算) が必要になる場合があります。

表1: マッチ アクション パイプラインでネットワーク内分類を実装するさまざまな方法。ロジックは加算演算と条件のみを指します。

5.3 単純ベイズ

特徴間の独立したガウス分布 [20] を仮定して、教師ありナイーブ ベイジアン分類器 [30] を探索します。カーネル推定 [32] など、より正確である可能性があるネットワーク トラフィック分類への関連アプローチは、同様の実装概念に従います。この仮定の下では、特徴 xi の尤度は次のように表されます。

分類ルールは次のようになります。

k クラスの問題では、n 個の特徴を使用すると、k × n (µy, σy) のペアが存在します。単純な実装 (表 1.4) では、k クラスの n 個の確率と、そのクラスで計算されたすべての n 個の確率の積を計算するために、k × (n + 1) のマッチアクション テーブルを使用します。このプロセスはリソースを無駄にするだけでなく、確率値が小さい場合にはハードウェアで近似することが困難になります。

2 番目のアプローチ (表 1.5) は、すべての特徴をキーとしてカテゴリごとに 1 つのテーブルを使用します。分類の確率として浮動小数点値の代わりに、確率を表す整数値が返されます。このアプローチでは、確率を表すためにテーブル (異なる分類) で同様の値が使用されている限り、正確な結果が得られます。欠点は、必要なテーブルのサイズです。テーブルでは、この幅に比例した深さを持つ非常に幅の広いキー (すべての入力特徴値を接続する) が使用されます。

5.4 K 平均法

K 平均法クラスタリングは教師なし学習の一例です。k 個のカテゴリに対して、k 個のクラスター中心が提供され、各クラスター中心は n 個の座標値で構成され、各座標値はフィーチャに対応します。指定された入力 x からクラスター i の中心までの距離は、次のように計算されます。

ここで、x1 から xn は特徴の値です。入力は距離が最も小さいクラスターに分類されます。

最短距離に基づいてクラスターを選択するには、二乗距離のみが考慮されます。1 つのオプションは、キーがすべての機能であるクラスターごとのテーブル アプローチ (表 1.7) を使用することです。このアプローチでは、座標ごとに 1 つのテーブルを使用するアプローチ (表 1.6) よりも必要なテーブルが少なくなりますが、より深く幅広いテーブルが使用されます。もう 1 つのアプローチ (表 1.8) は、アクションによって距離値のセットをメタデータ バスの 1 つの軸 (クラスターごとに 1 つの値) に割り当てる特徴ごとのテーブルを使用することです。このアプローチでは、最後のステージで距離ベクトルを同時に累積し、距離が最小のクラスターに分類します。

実現可能性: セクション 4 と表 1 に基づいて、実際のスイッチについて理解すると、各実装方法の実現可能性と制限が示されます。4 6 4^6を達成する$4^6$ (単純ベイズ) と 6 (K 平均法) はどちらも非常に限定的です。分類専用のデータ プレーンであっても、4 ～ 5 個を超える特徴量と 4 ～ 5 個のクラスを使用することは現実的ではなく、利用可能なステージ数を超えてしまいます。逆に、2 つのクラスと 10 個の特徴量を使用することになります (逆も同様)。他の方法では、より柔軟性が高く、最大 20 のカテゴリまたは機能がサポートされます。分類子 1 (デシジョン ツリー)、3 (サポート ベクター マシン)、および 8 (K 平均法) は最高のスケーラビリティを備えており、テーブルの数、キーの幅、およびアクションの幅の組み合わせによって実現できます。

6 試作と評価

観察の検証として、IIsy (Inference in Networks Simplified) という名前のプロトタイプを実装しました。当社のフレームワークには、分類アルゴリズムをネットワーク デバイスに自動的にマッピングする機能を実証するソフトウェア ベースの実装と、リソース要件とパフォーマンスを調査するハードウェア ベースの実装が含まれています。

IIsy は 3 つのコンポーネントで構成されます。1 つ目は、機械学習のトレーニング環境です。2 つ目は、ネットワーク機器内のプログラム可能なデータ プレーンです。3 つ目は、トレーニングされたアルゴリズムをネットワーク デバイスにマッピングするために使用されるコントロール プレーンです。フレームワークを図 2 に示します。

トレーニング環境として Scikit-learn [40] を使用します。トレーニングの入力には任意のデータセットを使用できますが、現実的なトラフィック シナリオを示すためにラベル付きパケット トレースを入力として使用します。Scikit-learn は使いやすさを考慮して選択されており、出力をコントロール プレーンに一致するテキスト形式に変換できる限り、他のトレーニング環境で置き換えることができます。

図2: IIsy の高レベルのアーキテクチャ。IIsy コンポーネントは白色です。外装パーツはグレーです

6.1 ソフトウェアベースのプロトタイピング

ソフトウェアベースのプロトタイプは、P4 を使用して v1model アーキテクチャにデータ プレーンを実装します。コントロール プレーンは P4Runtime [38] を使用します。テストには bmv2 と mininet を使用します。ユースケースごとに P4 プログラムを作成します。ユース ケースは、使用される機械学習アルゴリズムと予想されるネットワーク トラフィックという 1 組のパラメーターを指します。ネットワーク トラフィックはデータ プレーン パーサーの設計 (つまり、どのヘッダーを解析する必要があるか) を決定しますが、機械学習アルゴリズムは実装する必要がある一致アクションの設計を定義します。

Python スクリプトを使用してコントロール プレーンを生成します。P4runtime を使用して、機械学習トレーニング フェーズの出力を、マッチ アクション パイプラインへのテーブル書き込みに変換します。この段階は単純ですが、最も重要な段階です。機械学習モデルの種類と使用する機能セットが同じであれば、P4 プログラムを変更することなく、ネットワーク デバイスの動作を変更し、さまざまな分類ルールを実装できます。それは変わらない。

6.2 ハードウェアベースのプロトタイピング

IIsy のハードウェア プロトタイプは、P4→NetFPGA ワークフロー [22] を使用して NetFPGA SUME [59] 上に実装されました。現在、P4→NetFPGA は P4runtime をサポートしていません。P4→NetFPGA コントロール プレーン インターフェイスを使用してコントロール プレーン構成を実装します。私たちのハードウェア実装では、主にハードウェア ターゲットへの移植の実現可能性と分類率を調査します。私たちが使用した P4 プログラムはソフトウェア ベースのプロトタイプと非常によく似ていましたが、ハードウェア ターゲットに合わせてわずかに変更が加えられています。範囲タイプのテーブルが完全一致テーブルまたはトリプル値テーブルに置き換えられ、構文が P4 の要件に合わせて調整されました。 →NetFPGAのワークフロー。私たちのソフトウェア実装とのもう 1 つの違いは、P4→NetFPGA で使用されるアーキテクチャが SimpleSumeSwitch [22] であることです。

パフォーマンス評価には、トラフィックを生成し、ワイヤ スピード (4 × 10G) での遅延を測定するためのオープン ソース ネットワーク テスト ツールである OSNT を使用します [1]。OSNT は制限されたサイズのパケット トレースを再生できるため、大きなトレース ファイルに対して tcpreplay を使用して標準 X520 ネットワーク カードで機能テストを実行しました。

6.3 例: IoT トラフィック

セクション 1 で説明したように、モノのインターネットは、ネットワーク内での分類のアプリケーション シナリオを推進します。私たちは、Sivanathan et al. によって公開された IoT デバイスの pcap トレースをデータセットとして使用します [48]。私たちの目標は、IIsy を使用して、デバイス タイプに基づいて受信トラフィックを分類することです。当社では、監視対象デバイスを 5 つのカテゴリにグループ化しています: 静的スマート ホーム デバイス (例: コンセント)、センサー (例: 気象センサー)、オーディオ (例: スマート アシスタント)、ビデオ (例: セキュリティ カメラ)、および「その他」。高帯域幅 (ビデオ) からベストエフォート (「その他」カテゴリ) まで、さまざまな QoS グループにマッピングできるカテゴリを選択しました。EtherType、IP プロトコルとフラグ、TCP ポートなど、評価用に 11 の特性を選択しました。すべての特徴はパケットのヘッダーから直接抽出されます。MAC アドレスや IP アドレスなどの識別情報は使用しませんでした。これは、偏った結果を回避するため (デバイスのアドレスが固定されているため)、アドレス ベースの一致アクションの実践を超えて展開を分類できることを実証するためです。

表 2 は、データセットの属性をまとめたものです。これらの特徴のうち 6 つは、データセット内に少数の値しか存在しないため、計算された値を保持するには非常に小さなテーブルやレジスターでも十分である可能性があります。パケット サイズを保持するテーブルは、標準のルックアップ テーブル [56] に収まります。TCP および UDP ポート番号の場合、完全一致テーブルの使用は実現可能ですが、FPGA ターゲットでのコストが高くなります。そのような各テーブルは 2Mb 近くのメモリを消費し [56]、タイミング制約を満たせない可能性があります。したがって、値の範囲内での照合を可能にする 3 つの値のテーブルを使用します。

Barefoot Tofino のようなデバイスに適した 11 個の機能を選択しました。各機能はテーブルを使用し、パイプラインのステージ数に等しいデシジョン テーブルを持ちます [3、34]。今後の研究では、より多くの機能 (セクション 7 を参照) を含むより複雑な機能、および NetFPGA プラットフォームでの実装の実現可能性を検討することが期待されます。最適化ルールとテーブルのマッチングはこの文書の範囲外であり、広範囲に研究されています (例: [10, 11, 27])。

Scikit-learn を使用してモデルをトレーニングし、モデルの統計を取得します。ポート マッピングに対して分類を検証します。私たちの目標は、スイッチの分類出力がモデルの分類結果と一致することです。

モデルごとに 1 つのアプローチを採用して、4 つのモデルすべてを IIsy に実装し、機能とリソース消費を評価しました。当社のパフォーマンス テストはスループットとレイテンシを測定し、デシジョン ツリーの実装に対してのみテストされます。

表 3 は、NetFPGA プラットフォームでこれらのモデルを実装するために必要なリソースの概要を示しています [59]。使用率の数値は、このボードで使用されている Virtex-7 690T FPGA を使用した場合の相対比較を示しています。最後の (決定) テーブルを除き、64 エントリの小さなテーブルを使用します。このテーブルは完全一致を使用し、可能なオプションの数に設定されます。512 エントリのテーブルは FPGA には問題ありませんが、200MHz でのタイミングを満たすことができません。

小さなテーブルを研究すると、興味深い洞察が得られます。たとえば、デシジョン ツリーの場合、各機能には 2 ～ 7 の一致範囲が必要ですが、これらの範囲は 47 エントリ以下のテーブルに収まります。これは、64K の潜在的な値 (TCP ポートなど) と比較すると大きな違いです。貯蓄。逆に、複数の特徴をテーブル キーとして使用するモデルは、テーブル エントリにマッピングするのがより難しく、範囲間の一致を実現するには、特徴間のビットの並べ替え (最初に最上位ビット、次に最下位ビットをインターリーブする) が必要です。予想のとおり、負けのない試合をするには 64 個のエントリーでは十分ではありません。

最も正確な実装では、デシジョン ツリーを使用します。深さ 11 でトレーニングされたモデルは、同様の精度、再現率、および F1 スコアで 0.94 の精度を達成します。デシジョン ツリーの深さを減らすと、予測の精度がレベルごとに 1% ～ 2% 低下します。NetFPGA では、わずか 5 レベルのパイプラインを実装し、精度と F1 スコアは約 0.85 でした。したがって、必要な機能は 5 つだけです。私たちの目標は最適なトラフィック分類モデルを見つけることではなく、トレーニングされたモデルと同じくらい正確な分類を実行することであることに注意してください。データセットの pcap トレースを再生し、分類で予期されたポートにパケットが到着することを確認することで、実装の精度を評価します。私たちの分類結果は、トレーニングされたモデルの予測と正確に一致しています。また、OSNT を使用して実装のパフォーマンスを評価し、完全なワイヤスピード要件を達成していることを確認します。私たちのデザインのレイテンシ (ツールチェーンのバージョンに応じて) は 2.62 µs (±30 ns) で、これは同様のステージ数を持つリファレンス (非機械学習) P4→NetFPGA デザインに匹敵します。

表2: IoT トレーニング データセットの選択されたプロパティ

表3: NetFPGA-SUME でのネットワーク内分類実装のリソース使用率。

7 ディスカッション

イントラネットワーク コンピューティング: イントラネットワーク分類は、イントラネットワーク コンピューティングの一種です。この研究では、いくつかのよく知られた研究 ([24, 25, 44] など) に従って、ネットワーク内計算を当然のことと考えていますが、この研究領域はまだ物議を醸しており、未熟であると考えられています [7, 41]。重要な課題は、ネットワーク内の計算が他のネットワーク目的に必要なリソースを消費することです。スイッチをネットワーク接続アクセラレータとして使用すると、リソースを共有せずにスループットの利点が維持されますが、消費電力とスペースはほぼゼロに近く、パケットのネットワーク トラバースの一部として計算すると実質的に無料になります。

特徴抽出: 私たちのプロトタイプでは、主にパケット ヘッダーから抽出された特徴を使用しました。同様に、キャッシュ クエリ [50] や DNS リクエスト [55] などの機能も抽出できます。キュー サイズなどの特性は、パイプラインのメタデータ バスを通じて利用できる場合がありますが、これらの特性はアーキテクチャに依存します。フロー サイズなどの状態を必要とする特徴を抽出することは可能ですが [29、49]、カウンターまたは外部コンポーネントの使用が必要であり、ターゲット固有の場合もあります。多くの機械学習モデルは複雑な特徴を必要とするため、スイッチでは抽出できない場合があります。

パフォーマンスとスケーラビリティ: 私たちの実装では、複雑な操作を行わずに match-action テーブルのみを使用します。したがって、ハードウェア ターゲットでは、IIsy のパフォーマンスはプラットフォームのパケット処理速度と同等になります。IIsy はスループットに合わせて拡張しますが、機能の数や各機能の値には拡張できない場合があります。これは、ハードウェア ターゲット間で異なるプロパティです (§4)。私たちが提供するソリューションは、[54] と同様に、リソースの観点から分類の精度を犠牲にして、精度の低いクラスにはホストによるさらなる処理のためにフラグが立てられることが予想されます。

スイッチ ASIC: IIsy を汎用スイッチに移植することは今後の課題です。スイッチ ベンダーとの協議により、これが可能であり、ワイヤスピードのパフォーマンスが可能であることがわかりました。

アプリケーション シナリオ: IIsy で最も期待されるアプリケーション シナリオは、トラフィック分類 [32] などのネットワーク トラフィックに関連するシナリオです。これは、IIsy がトラフィック容量のスケーラビリティの課題に対処する手段を提供するためです [16]。関連するアプリケーション シナリオには、トラフィック フィルタリングと分散型サービス拒否攻撃の軽減が含まれます。輻輳制御は、キュー サイズなどの特定のハードウェア ターゲットで利用可能な機能を輻輳制御に使用できる、別の可能なアプリケーション シナリオです。

8 関連研究と結論

近年、機械学習 (ML) とネットワーキングの分野の研究が急速に成長しています。これらの研究は、ネットワーク トラフィック分類 [17、32、58]、ML を使用したスケジューリングおよび輻輳制御などの側面に取り組んでいます [23、52]。ML フレームワークは、高速化 [18、44] のためにネットワーク デバイスを使用しており、パラメータ サーバーとして、または集約およびマルチキャスト トラフィックとして機能することができます [28、45]。

ネットワーク デバイス内での推論の実装はまだ初期段階にあります。N2Net [47] と BaNaNa Split [43] は、ネットワーク デバイス内でのバイナリ ニューラル ネットワークの実装を実証し、処理と通信のオーバーヘッドを分析しました。Li [28] は、カスタム アクセラレーション モジュールを使用して、スイッチ内で強化学習を実装する方法を提案しました。この論文はこれらの研究を補完するもので、非ニューラル ネットワークの ML アルゴリズムについて説明します。

このペーパーでは、IIsy という名前のネットワーク内分類フレームワークを紹介します。教師あり学習と教師なし学習のアルゴリズムをアクション パイプラインにマッピングし、これらの実装の適用可能性について説明します。私たちのプロトタイプはソフトウェアとハ​​ードウェアの両方のバージョンを実装しており、フルラインレートで現実世界のパケットを分類できます。これは、ネットワーク デバイス内で ML を実装するための最初のステップにすぎません。次の重要な課題は、ネットワーク内トレーニングを達成することです。