⚙️

Juniper Trio を用いた In-Network Application

2022/08/29に公開

innetworkcomputing

ACM SIGCOMM 2022 で Juniper Trio ネットワークプロセッサを用いた In-Network Application に関する論文が発表されました。論文は以下リンクからダウンロード可能です。

Using trio: juniper networks' programmable chipset - for emerging in-network applications (dl.acm.org)

トピックは以下３つ

Juniper Trio のアーキテクチャ解説
Trio のプログラミング言語である Microcode の解説
機械学習系のワークロードの In-Network 処理実装の事例（aggregation, straggler）
上記事例の実機評価結果、及び Tofino ASICでの結果との比較

以下、内容サマリと感想です。

Trio アーキテクチャとプログラム言語の解説

アプリケーションに特化した Instruction Set (VLIW) を有するマルチコアプロセッサである Juniper Trio のアーキテクチャを解説し、Tofino や Trident 等の "reconfigurable match-action tables" (RMT) パイプラインモデルを利用した Ethernet ASIC と比較して In-Network なアプリケーションをより高性能・効率的に実行可能であることを主張しています。

ネットワークプロセッサのアーキテクチャ解説は貴重である事に加えて、C言語ライクな Trio プログラミング言語である Microcode についても解説しサンプルコードを示しているので、この２つを知るためだけに読む価値がある論文でした。

また、特長として run-to-completion であり複雑な処理にも対応可能な事、タイマーベースの処理が可能な事から Tofino/Trident 等 RMT パイプラインモデルを利用した Ethernet ASIC よりも多くの In-Network アプリケーションを実現可能な事は分かりやすい比較であり、ここ数年 Tofino ばかりであった In-Network 系のターゲットプラットフォームに選択肢が増えるのは嬉しい主張と思います。

Trio Microcode について

Trio Microcode は C言語ライクなプログラミング言語であり、Figure 4 のように Trio Compiler (TC) を用いてコンパイルし、Junosの１部として利用します。

Section 3.2 provides a packet filtering example programmed in Trio Microcode を参照すると Trio Microcode を利用したプログラミングのイメージを掴むことが可能です。

3.2 Microcode Program Example からサンプルコードを抜粋

process_ether:
begin
    ir0 = 0;
    if (ether_ptr ->etype == 0x0800) {
        goto process_ip;
    }
    goto count_dropped;
end

process_ip:
begin
    const ipv4_t *ipv4_addr = ether_ptr + sizeof(ether_t);
    ir0 = 1;
    if (ipv4_addr ->ver == 4 && ipv4_addr ->ihl == 5) {
        goto forward_packet;
    }
    goto count_dropped;
end

CPUで実行するC言語のように自由に記述できるわけではなく、メモリの場所（on-chip, shared, etc)の指定や instruction delineation と呼ばれる１つのインストラクションで実行する範囲を指定するなど、チップのアーキテクチャを理解した記述が必要になります。
サンプルコードでも、レジスタを指定して変数を利用する(ir0)、goto を多様して処理の流れを記述している事から、C言語を用いたアプリケーションプログラミングというよりは、ハードウェアを意識した手順をC言語ライクに記述する必要があるという印象です。（P4でもある程度複雑な処理を記述しようとすると必要になるのは同様です）

同時に、サンプルコードが豊富に提供されれば Trio Microcode 自体を習得するのは特別困難ではなく、学習時間の多くはハードウェアアーキテクチャと制約の理解に費やすと想像されるのはP4言語と同様と感じました。

ちなみにこのような制約が大きなC言語ライクなプログラミング言語を利用するネットワークプロセッサとしては、SmartNICタイプで有名な Netronome Agilio があります。（なお、Netronomeに関しては開発が停まっているように見えるため利用可否については要確認となります）

Trio Microcode のエコシステムやオープン化について

Trio を活用した In-Network アプリケーションのユースケースが今後増えていくか？という点に関しては、プログラミング言語である Trio Microcode や開発環境のオープン化についての主張と実際に公開している内容のギャップが大きく、疑問が残りました。

例えば We invite the networking community to identify novel use cases that will leverage Trio’s programmable architecture. とまで記載しているのであれば、Trio の言語仕様を公開して（少なくともvMX等のハードウェアを購入した人なら）誰でも Trio Microcode を利用して自分でプログラムできるようにして欲しいところです。

例えば As a first step to enable third-party access to Trio’s functionalities の取り組み例として記載されている First, we plan to add comprehensive support for P4 programming for Trio. Juniper engineering has made an initial effort to achieve this goal [6] "TrioでP4言語をサポートする最初の取り組み" として参照している GitHubにてオープンソース公開された [6] Juniper P4 Agent (JP4Agent) は Last Commit が4年前の2018年9月24日であり、メンテナンスされていません。なお、README.md 記載のコンタクト先である Sandesh Kumar Sodhi は（LinkedIn のこの人であると想定すると）既にJuniperを退職しているようです。

但し、2022年4月15日更新の Junos Document に P4Runtime サポートに関する記述があるため、オープンソースでは無いもののJP4Agent自体のサポートは継続している可能性がありますので、ぜひこの論文を契機にオープン化が進む事に期待したいところです。

Junos OS > Monitoring, Sampling, and Collection Services Interfaces User Guide

ご参考までに、2018年の以下記事では Juniper P4 Agent (JP4Agent) に関し詳しく解説しています。
Juniper Advancing Disaggregation Through P4 Runtime Integration

In-Network アプリケーション事例と評価結果

論文で実装・評価されている In-Network アプリケーション事例は以下２つです。

in-network aggregation for distributed machine learning
in-network straggler mitigation

in-network aggregation for distributed machine learning

１つ目の事例は機械学習のアグリゲーションに関するワークロードで、各JobのUnicastパケットのペイロードに格納された Gradients を BLOCK_ID 毎に保存（Aggregate）し、BLOCKの最終パケットを受信したら Multicast パケットとして送信する、という処理になります。
処理内容はシンプルで図（Figure 9, Figure 10）を見るとが理解しやすいと思います。（既存のML Aggregation実装と類似の処理です）

in-network straggler mitigation

２つ目の事例は straggler problem ストラグラー問題（落伍者問題）と呼ばれる、 "最も遅いJOBが完了するまで全体が待機するため全体の性能が低下する" という課題を緩和する手法です。
現在のストラグラー問題の緩和技術は全てサーバを利用するため、緩和のために利用した他のサーバが落伍者になる循環依存を作りだす課題を抱えているため、ストラグラー問題の緩和機能をサーバから切り離し Juniper vMX （Trio搭載ネットワーク機器）で実装しています。

ストラグラー問題の緩和機能には "ストラグラー（処理が遅いサーバ）を検知してから緩和処理を実行" する必要があるため、タイマーベースの処理が実装可能な Trio ならではの In-Network アプリケーションの良い事例となっています。

なお、Tofinoではタイマーベースの処理ができないため実装は不可能に近い困難なのは主張通りだと思います。しかし、 "検知は Control Plane で実施 ⇒ 緩和処理を Data Plane (Tofino) で実行する" 等の検討は議論されていないため、コスト次第では Tofino + CPU での処理が現実的な可能性もあるため（研究ではなく）実運用上最適なプラットフォームを選定する際にはコストやユースケースにより優先される制約を含めた検討が必要と思われます。

評価結果

Figure 11 のように、以下ハードウェア構成で評価を実施し、結果を解説しています。

Juniper MX480
64×100 Gbps Tofino switch
サーバ６台：ASUS ESC4000AE10
- 各サーバに A100 Nvidia GPU と 100Gbps Mellanox ConnectX5 NIC を搭載

利用した DNNモデルは３種です。

ResNet50 [41]
DenseNet161 [42]
VGG11 [68]

性能評価としては Figure 13 のグラフの通り、Tofinoを利用したソリューションと比較し ~1.8倍程度の性能向上となったようです。

まとめ

Trio のアーキテクチャ解説に加え、（おそらく初の？） Trio Microcode 解説＆サンプルコードがあり非常に興味深い論文でした。
また、P4以外の言語や Tofino/旧Mellanox 以外のチップを用いた In-Network アプリケーションに対する取り組みが出て来たことは大きな意義があると感じました。

半面、Trio Microcode 言語仕様がオープンで無い事や、その開発環境をどう利用可能かが不明なため、現時点で Trio Microcode の利用は難しいと感じました。

将来的な Trio Microcode のオープン化やエコシステム構築に向けて Juniper が情報発信してくれることを大いに期待したいと思います。

また、1.8倍の性能向上がどういう意味を持つのかについては、評価で使用した Trio と Tofino 搭載ネットワーク機器それぞれの価格と共に提示してくれないと何とも評価が難しいと感じました。
ただし、プロダクションでの実績が圧倒的に大きな vMX 上で In-Network アプリケーションを開発可能になるのであれば、In-Network アプリケーションの進展に大きな意義があり、仮にハードウェアコストが多少高くても採用に向けての大きなメリットになると思われます。