> [!abstract] 概要(Abstract の日本語訳) > 我々は、あらゆる主要ハイパーバイザプラットフォーム向けのマルチレイヤ・オープンソース仮想スイッチである Open vSwitch の設計と実装について記述する。Open vSwitch は仮想環境におけるネットワーキングのために新規に(de novo)設計されており、その結果、従来のソフトウェアスイッチングアーキテクチャからの大きな設計上の逸脱が生じている。我々は、Open vSwitch がその動作を最適化しハイパーバイザのリソースを節約するために用いる高度なフロー分類とキャッシングの技術について詳述する。我々は、Open vSwitch を7年間にわたって利用し改善してきた我々のデプロイ経験を踏まえて、その性能を評価する。 ## 論文情報 - タイトル: The Design and Implementation of Open vSwitch - 著者: [[Ben Pfaff]]・[[Justin Pettit]]・[[Teemu Koponen]]・[[Ethan Jackson]]・[[Andy Zhou]]・[[Jarno Rajahalme]]・[[Jesse Gross]]・[[Alex Wang]]・[[Joe Stringer]]・[[Pravin Shelar]](以上 [[VMware]])、[[Keith Amidon]]([[Awake Networks]])、[[Martin Casado]]([[VMware]]) - 媒体: 第12回 USENIX Symposium on Networked Systems Design and Implementation(NSDI '15)、Operational Systems Track。2015年5月4〜6日、米国カリフォルニア州オークランド開催。**Best Paper 受賞** - URL: https://www.usenix.org/conference/nsdi15/technical-sessions/presentation/pfaff - PDF: https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-pfaff.pdf > [!note] 著者名の表記ゆれ > USENIX 会議ページの著者一覧(HTML)は "Joe Stringer" と表記するが、PDF 本文の著者欄は "Jonathan Stringer" と表記する(いずれも VMware, Inc. 所属)。本ページでは会議ページの表記を採用し、entity のエイリアスに両方を記録する。 ## 概要 Open vSwitch(OVS)は、あらゆる主要ハイパーバイザ向けに動作するマルチレイヤのオープンソース仮想スイッチである。本論文は、OVS が汎用プロセッサ上で高性能な OpenFlow スイッチングを実現するために採用してきた設計、とりわけカーネル空間のフローキャッシュとユーザ空間のタプル空間探索パケット分類器がどのように協調するかを、7年間にわたる実運用経験に基づいて記述する。中心的な緊張関係は「専用ハードウェアの助けなしに、汎用性を犠牲にせず高性能を達成する」ことであり、本論文はこの緊張関係にどう応えてきたかの設計史として書かれている。 ## 問題設定 仮想スイッチの動作環境は、伝統的なネットワークアプライアンスの動作環境とは大きく異なる。論文はこの違いを3つの制約として整理する。 - **リソース共有**: 伝統的なネットワークアプライアンスは最悪ケースのライン速度を専用ハードウェアで達成する設計を favor するが、仮想スイッチにとってはリソースの節約こそが重要であり、ハイパーバイザの主機能(ユーザワークロードの実行)に多くのリソースを残すことが優先される。したがって、仮想スイッチは「最悪ケースではなく典型ケース」を最適化対象とする。この原則がフローキャッシングをはじめとする各種キャッシング技法の重視につながった。 - **配置(placement)**: 仮想スイッチはネットワークのエッジ(leaf)に位置し、ハイパーバイザや VM と運命を共にする。この配置は多くの単純化をもたらす一方、スケーリングを複雑にする——単一の仮想スイッチが、ハイパーバイザ間の IP トンネルのポイントツーポイントメッシュにおいて数千の仮想スイッチをピアに持つことも珍しくない。VM の起動・マイグレーション・シャットダウンに応じてフォワーディング状態は絶えず変化しうる。この特性が、O(1) 更新を実現するタプル空間探索分類アルゴリズムの採用を動機づけた。 - **SDN・ユースケース・エコシステム**: OVS はその起源から [[OpenFlow]] スイッチであり、単一目的の垂直統合されたネットワーク制御スタックに縛られず OpenFlow で再プログラム可能である。この柔軟性は、ネットワーク仮想化のような高度なユースケースが要求する長いパケット処理パイプライン(例: VMware の NVP コントローラは最低でも約15回のテーブルルックアップを要求)による高い分類負荷を招き、これがフローキャッシングの実装を必要とした。さらに、OVS は他の主要な仮想スイッチと異なりオープンソース・マルチプラットフォームであり、動作環境(OS・ハイパーバイザ)をユーザが選べるため、設計は高度にモジュラー・可搬でなければならない。 ## 提案手法 ### アーキテクチャ OVS は2つの主要コンポーネントからなる。1つはユーザ空間デーモン `ovs-vswitchd`(OS・実行環境間でほぼ共通の実装)、もう1つはカーネルデータパスモジュール(性能のためホスト OS ごとに専用実装される)である。物理 NIC や VM の仮想 NIC から届く各フローの最初のパケットはカーネルモジュールでミス(miss)となり、ユーザ空間コンポーネントに転送される。`ovs-vswitchd` はパケットの扱いを決定してカーネルに送り返すとともに、以降の類似パケット向けにこのフォワーディング決定をカーネルにキャッシュさせる。制御は [[OpenFlow]] を通じて行われ、OpenFlow コントローラの視点では各パケットは一連の OpenFlow フローテーブルを通過し、条件を満たす最高優先度のフローが見つかりそのアクションが実行される、という単純なモデルに見える——キャッシングやユーザ/カーネル分割は OpenFlow コントローラからは不可視の実装詳細である。 **Figure 1: Open vSwitch のコンポーネントとインターフェース** ![[_attachments/nsdi15-paper-pfaff/fig01-architecture.png]] (Figure 1. あるフローの最初のパケットはミスとなりカーネルモジュールからユーザ空間コンポーネントへ転送され、ユーザ空間はフォワーディング決定を以降のパケット向けにカーネルへキャッシュする。Off-box には OpenFlow コントローラ、userspace には `ovsdb-server`(OVSDB 経由で構成データベースを提供)と `ovs-vswitchd`(OpenFlow 経由でフローテーブルを受け取る)、kernel には Kernel Datapath が置かれる。Source: Figure 1.) 構成に関わる情報(OpenFlow スイッチの生成・破棄、ポートの追加・削除、QoS キューの設定、コントローラとの関連付け、STP の有効/無効化など)は OpenFlow の対象外であり、別コンポーネントである構成データベース(`ovsdb-server`)が OVSDB プロトコルで扱う。OpenFlow は高速に変化しうる一時的なデータ(フローテーブル)を、構成データベースはより永続的な状態を、それぞれ制御する。 ### アルゴリズム/手法の詳細 **タプル空間探索によるパケット分類**。OVS はカーネル・ユーザ空間の両方で、全てのパケット分類にタプル空間探索分類器(Srinivasan, Suri, and Varghese, "Packet Classification Using Tuple Space Search", SIGCOMM 1999)を用いる。同じフィールドの組み合わせにマッチするフロー群は1つのハッシュテーブル(=タプル)にまとめられ、異なるマッチ形式が追加されるたびに新しいハッシュテーブルが生成される。探索は全タプルに対するハッシュルックアップとなり、複数タプルにマッチがあれば優先度の高い方が採用される。この方式は決定木分類アルゴリズムに劣らない3つの利点を持つ——(1) 効率的な定数時間更新(1回のハッシュテーブル操作で済む)、(2) 任意個数のフィールドへの一般化が容易、(3) フロー数に対して線形なメモリ使用量。 **2層のフローキャッシュ**。OVS の初期実装(2007年開始)はカーネル空間にすべての OpenFlow 処理を実装するマイクロフローキャッシュだったが、単一トランスポート接続単位でしか一致しない極めて細粒度なキャッシュだったため、大量の短命接続に直面すると性能が大きく劣化した。これに対処するため、より粗いトラフィック集約に対応するメガフローキャッシュを第2層として導入した。メガフローは、ユーザ空間がパケットを OpenFlow テーブル群で分類する際に「実際に参照されたパケットフィールドのビット」を追跡し、その集合だけにマッチするフローエントリとして反応的(reactive)かつインクリメンタルに生成される。マイクロフローキャッシュはこのメガフローキャッシュへのヒントとして第1層に残され、同一マイクロフローの2パケット目以降をメガフロー探索なしに直接転送できるようにすることで、メガフロー探索のコストをパケット単位からマイクロフロー単位に低減する。 **キャッシュを意識したパケット分類器の最適化**。素朴なタプル空間探索は、生成されるメガフローの条件を必要以上に厳しくしてしまい、キャッシュヒット率を悪化させる。論文は4つの最適化を導入する。 1. **タプル優先度ソート(§5.2)**: 各タプル $T$ の最大優先度 $T.pri\_max$ を追跡し、優先度の高いタプルから探索する。既に見つかったマッチ $F$ の優先度が次のタプルの $T.pri\_max$ 以上であれば探索を打ち切れる。 **Figure 2: タプル優先度ソート付きタプル空間探索の擬似コード** ![[_attachments/nsdi15-paper-pfaff/fig02-tuple-search-pseudocode.png]] (Figure 2. `PrioritySortedTupleSearch(H)` は、対象パケットヘッダ $H$ に対し、$T.pri\_max$ の降順にタプルを走査し、既知の最良マッチ $B$ の優先度が次のタプルの最大優先度以上になった時点で早期終了する。実運用の NVP コントローラが設定するフローテーブル(29 タプル)の分析では、26 タプルが単一優先度のフローのみを含み、優先度ソートによって多くのケースで即座に打ち切れることを確認した。Source: Figure 2.) 2. **ステージドルックアップ(§5.3)**: 各タプルを単一ハッシュテーブルではなく、メタデータ・L2・L3・L4 の4段階(ステージ)に分けたハッシュテーブル配列として実装する。ある段階の探索が不一致であれば、それ以降の段階を探索せずタプル探索全体を打ち切れ、メガフローはその段階までに含まれるフィールドだけにマッチすればよい。この最適化により、L4 ポートに基づく ACL を持つ論理データパスとそうでない論理データパスが混在する VMware NVP の実運用構成で、L4 ACL の無いトラフィックのメガフローが不要に L4 ポートへマッチする問題を解消した。 3. **プレフィックストラッキング(§5.4)**: IPv4/IPv6 アドレスに対して、トライ構造を用いた最長プレフィックスマッチ(LPM)探索をタプル空間探索の前に行い、必要な最大メガフロープレフィックス長を決定するとともに、影響を与えないタプルの探索をスキップする。これにより、特定ホストへの高優先度 ACL が全メガフローを完全な IP アドレス(/32)にマッチさせてしまう問題を防ぐ。 **Figure 3: プレフィックストラッキングの擬似コード** ![[_attachments/nsdi15-paper-pfaff/fig03-prefix-tracking-pseudocode.png]] (Figure 3. `TrieSearch(value, root)` は IP アドレス等の値をトライで探索し、マッチするノードを一意に確定するために調べるべき先頭ビット数と、可能なマッチ長のビット配列(`plens`)を返す。この結果を使い、メガフローに含めるべきビット数を最小化しつつ、スキップ可能なタプルを特定する。Source: Figure 3.) 4. **分類器パーティショニング(§5.5)**: OpenFlow のメタデータフィールド(例: パイプラインステージ番号)でタプルをパーティション分割し、現在のメタデータ値がタプル中に存在しなければそのタプルの探索を丸ごとスキップする。NVP はパイプラインの各ステージをこのメタデータで示すことで、無関係なタプルの探索を避けるヒントを分類器に与えている。 **キャッシュ無効化(§6)**。制御プレーンの変化(コントローラによるフローテーブル変更、MAC 学習、STP、CFM/BFD 等の接続性検出プロトコルなど)に応じてキャッシュを更新する必要がある。OVS は影響範囲を正確に特定できない変更(例: 新規フローの追加は、それより低優先度の既存メガフロー全てに影響しうる)と、影響範囲を絞り込める変更(例: MAC 学習テーブルの変化)を区別する。前者への対応として、初期の OVS はデータパスの最大キャッシュフロー数を約1,000(のち2,500)に制限して定期的な全数再検証のコストを抑えていたが、これは単一スレッド実装のもとで新規フロー設定のレイテンシを悪化させていた。後者は Bloom フィルタベースの「タグ」機構で最適化されていたが、コントローラとフローテーブルが高度化するにつれタグ当たりの偽陽性が増え、OVS 2.0 でタグ機構は放棄され常に全データパスフローテーブルを再検証する方式に単純化された。かわりに OVS 2.0 でユーザ空間を複数スレッドに分割してフロー設定処理を再検証から分離し、OVS 2.1 で再検証専用の複数スレッドを追加してカーネルキャッシュの最大サイズを約200,000エントリまで拡大した(合計再検証時間が1秒以内に収まるよう動的調整される)。 ### 実装上の工夫 - マイクロフローキャッシュの実装には CuckooSwitch(Zhou, Fan, Lim, Kaminsky, and Andersen, CoNEXT 2013)に着想を得た楽観的並行 cuckoo ハッシュと RCU 技術を採用し、ノンブロッキングなマルチリーダー・シングルライタのフローテーブルを実現した。 - フロー設定のバッチ化により、システムコール回数を減らしフロー設定性能を約24%改善した。 - OpenFlow の cross-product 問題(フィールド A の $n_1$ 値とフィールド B の $n_2$ 値の組み合わせごとにフローが必要になる問題)を、`resubmit` アクションによる複数テーブル参照で解消した。これはのちの OpenFlow 1.1 のマルチテーブル対応の先駆けとなったが、OVS は後方互換性のため `resubmit` を今も保持している。 - レジスタ(register)というメタデータフィールドを OpenFlow 拡張として追加し、パイプライン途中の一時状態(例: 物理宛先の早期決定)をフロー間で受け渡せるようにした。VMware の NVP コントローラはこれを用いて論理 L2/L3 トポロジ上のパケットの進捗を追跡する。 ## 新規性 既存の仮想スイッチの多くは固定機能パイプライン(feature datapath model)を持ち、あらかじめ用意された機能の構成のみが可能である(例: Hyper-V 仮想スイッチはバイナリモジュール追加で拡張できるが、各モジュールは単一目的機能を追加するにとどまる)。これに対し OVS は最初期から OpenFlow スイッチとして再プログラム可能であり、単一目的・垂直統合の制御スタックに縛られない。また、他の主要な仮想スイッチがクローズドソースで単一環境向けであるのに対し、OVS はオープンソース・マルチプラットフォームであり、OS・ハイパーバイザの組み合わせをユーザが選択できる。この柔軟性が、モジュラーで可搬な設計と、汎用性を保ったまま性能を確保する必要性(=フローキャッシングの高度化)を同時に要求した点が本研究の核心的な新規性である。関連研究との対比では、CacheFlow(Katta, Alipourfard, Rexford, and Walker, "Infinite CacheFlow in Software-Defined Networks", HotSDN 2014)が OpenFlow フローの高速パスキャッシュという点で類似するが、高速パスに全 OpenFlow アクションを実装しフロー依存グラフを事前構築する必要がある点で OVS と異なる。また多くの分類アルゴリズムは静的なフロー集合を前提とするか更新コストが高く、動的な OpenFlow フローテーブルに適さない。 ## 実験設定 - **実運用データ**: Rackspace が運用する大規模マルチテナントデータセンターの、1,000台超のハイパーバイザから10分間隔で収集した24時間分の統計。 - **マイクロベンチマーク環境**: 8コア・2.0GHz Xeon プロセッサ2基、10Gb NIC 2枚を搭載した Linux サーバ。 - **ベンチマークツール**: Netperf の TCP CRR(Connect/Request/Response)テスト。TCP コネクションの確立・1バイト送受信・切断を繰り返し、400並列セッションの合計トランザクション/秒(tps)で評価する。レイテンシに敏感なテストである。 - **比較対象**: Linux bridge(カーネル内蔵の Ethernet スイッチ実装)。 ## 実験結果 **Figure 4: メガフローのフロー数分布(実運用)** ![[_attachments/nsdi15-paper-pfaff/fig04-megaflow-counts-cdf.png]] (Figure 4. 観測期間中の最小・平均・最大メガフロー数の CDF。ハイパーバイザの50%は平均フロー数107以下であり、最大フロー数の99パーセンタイルでも7,033フローにとどまる。小さなメガフローキャッシュで実用上十分であることを示す。Source: Figure 4.) **Figure 5: キャッシュヒット率の分布** ![[_attachments/nsdi15-paper-pfaff/fig05-hit-rates-cdf.png]] (Figure 5. 全期間(実線)・トラフィック最多の25%期間(破線)・最少の25%期間(点線)それぞれにおけるキャッシュヒット率の CDF。全体のキャッシュヒット率は97.7%。トラフィックが少ない期間ではヒット率が74.7%まで低下する一方、トラフィックが多い期間ではヒット率がわずかに上昇し98.0%に達する——キャッシュすべき対象が多いときほどキャッシュが有効に働くという直観と整合する。Source: Figure 5.) **Figure 6: キャッシュヒット/ミスのパケット数分布** ![[_attachments/nsdi15-paper-pfaff/fig06-hit-miss-packet-counts.png]] (Figure 6. ハイパーバイザの99%は、キャッシュにヒットするパケットが秒間79,000未満、ユーザ空間でのミスによるフロー設定が秒間1,500未満である。データセンターの大多数のハイパーバイザは高トラフィックワークロードを経験していないことを示す。Source: Figure 6.) **Figure 7: ユーザ空間デーモンの CPU 負荷とミス率の関係** ![[_attachments/nsdi15-paper-pfaff/fig07-cpu-load-vs-misses.png]] (Figure 7. ユーザ空間 CPU 負荷はカーネルでのミス数にほぼ比例する。ハイパーバイザの80%は `ovs-vswitchd` の CPU 使用率5%以下、50%超は2%以下にとどまる(マルチスレッド化のためCPU負荷は100%を超えうる)。24時間平均で100%超のCPU負荷を示した外れ値6台を個別に調査したところ、いずれもプレフィックストラッキング実装の未知のバグ(ICMP type/code にマッチするフローが、全 TCP フローに TCP 送信元/宛先ポート全体をマッチさせてしまう)が原因であることが判明した。OVS 2.3 で修正済みと考えられるが、当該データセンターがアップグレードされていなかったため本番環境での修正確認はできていない。Source: Figure 7.) 分類器最適化のマイクロベンチマークでは、次の単純な OpenFlow フローテーブル(優先度降順)を用いた。 ``` arp (1) ip ip_dst=11.1.1.1/16 (2) tcp ip_dst=9.1.1.1 tcp_src=10 tcp_dst=10 (3) ip ip_dst=9.1.1.1/24 (4) ``` 最適化なしでは、あらゆる TCP パケットが(フロー(3)が TCP ポートにマッチするために)TCP 送信元・宛先ポートにマッチするメガフローを生成してしまう。タプル優先度ソートにより、フロー(2)にマッチするパケットはフロー(3)を考慮せずに済むため TCP ポートへのマッチを省略できる。ステージドルックアップにより、フロー(3)が宛先 IP 9.1.1.1 だけを見た時点で不一致と判定できる IP パケットは TCP ポートに一切マッチしなくなる。プレフィックストラッキングは、フロー(3)がアドレス全体にマッチしているにもかかわらず、宛先 IP アドレスの一部ビットをメガフローが無視できるようにする。 **Table 1: 分類器最適化ごとの性能測定結果** | Optimizations | ktps | Flows | Masks | CPU%(user/kernel) | |---|---:|---:|---:|---| | Megaflows disabled | 37 | 1,051,884 | 1 | 45/40 | | No optimizations | 56 | 905,758 | 3 | 37/40 | | Priority sorting only | 57 | 794,124 | 4 | 39/45 | | Prefix tracking only | 95 | 13 | 10 | 0/15 | | Staged lookup only | 115 | 14 | 13 | 0/15 | | All optimizations | 117 | 15 | 14 | 0/20 | (Table 1. 各行は Netperf TCP CRR トランザクション/秒(千単位)、カーネルフロー数、カーネルマスク(タプル)数、ユーザ/カーネル CPU 使用率を示す。全最適化併用でメガフロー無効時の約3.2倍のスループット(37→117 ktps)を、カーネルフロー数を1,051,884から15まで削減しながら達成している。Source: Table 1.) **Table 2: マイクロフローキャッシュの効果** | Microflows | Optimizations | ktps | Tuples/pkt | CPU%(user/kernel) | |---|---|---:|---:|---| | Enabled | Enabled | 120 | 1.68 | 0/20 | | Disabled | Enabled | 92 | 3.21 | 0/18 | | Enabled | Disabled | 56 | 1.29 | 38/40 | | Disabled | Disabled | 56 | 2.45 | 40/42 | (Table 2. 分類器最適化が有効な場合、マイクロフローキャッシュの無効化はスループットを120から92 ktpsへ低下させる。最適化が無効な場合はユーザ空間往復コストが支配的なためマイクロフローキャッシュの効果はほぼ現れない(56 ktps のまま)。Source: Table 2.) **Figure 8: 平均探索タプル数とフォワーディング性能の関係** ![[_attachments/nsdi15-paper-pfaff/fig08-forwarding-rate-vs-tuples.png]] (Figure 8. マイクロフローキャッシュを無効化した状態での、カーネルクラシファイアが平均で探索するタプル数に対するフォワーディングレート(長寿命フロー)。1タプルの探索で約10.6Mppsから、30タプルの探索で約4.5Mppsまで単調に低下する。同一シナリオでマイクロフローキャッシュを有効にすると、探索タプル数によらずおよそ10.6Mppsで一定になり、5タプル探索という条件下でもマイクロフローキャッシュが1.5Mppsの性能改善をもたらすことを確認した。Source: Figure 8.) **カーネル内スイッチとの比較**: 単純な構成では OVS と Linux bridge はほぼ同一のスループット(18.8Gbps)と近い TCP CRR コネクションレート(OVS 696ktps 対 Linux bridge 688ktps)を達成したが、OVS の CPU 使用率は高かった(161% 対 48%)。STP BPDU パケットをドロップする単一フローを OVS に、同等の iptables ルールを Linux bridge に追加すると、OVS の性能と CPU 使用率は変わらなかった一方、Linux bridge のコネクションレートは512ktpsに低下し CPU 使用率は26倍以上(1,279%)に跳ね上がった。これは、Linux bridge のカーネル内蔵機能がパケット単位のオーバーヘッドを持つのに対し、OVS のオーバーヘッドは概ねメガフロー単位で固定であるためだと論文は説明する。 ## 考察 論文は、OVS の性能がマルチテナントデータセンターワークロードの要求に応じて段階的に最適化されてきた歴史であり、その結果として設計が複雑化してきたと総括する。今後もこの傾向——専用ハードウェアに近づくのではなく、伝統的なネットワークアプライアンスからますます乖離する方向——が続くと予想している。また、OpenFlow はステートフルなパケット処理を扱えないため、ハイパーバイザ上でローカルコントローラ(例: NVP の L3 デーモン)を走らせる、あるいはコネクショントラッキングのようなカーネルネットワーキング機能に依存するという2つの回避策が使われている。将来の方向性として、DPDK/netmap によるユーザスペースネットワーキング、NIC ハードウェアオフロード(特に Flow Director のようなフィーチャの活用によるカーネル分類の高速化)を挙げている。 ## 強み / 弱点・課題 **強み** - タプル空間探索の4つの最適化(優先度ソート・ステージドルックアップ・プレフィックストラッキング・分類器パーティショニング)はいずれも正当性を犠牲にせず(必要なフィールドへのマッチを削らず)、生成されるメガフローをより一般化することでキャッシュヒット率を改善する、という一貫した設計原理を持つ。 - 7年間・1,000台超のハイパーバイザという大規模かつ長期の実運用データに基づく評価であり、マイクロベンチマークだけでなく実運用の分布(Figure 4-7)を提示している点で説得力が高い。 - Linux bridge との比較実験(STP BPDU ドロップの追加)は、固定機能カーネル実装とプログラム可能な OVS の性能特性の違い(パケット単位オーバーヘッド対メガフロー単位オーバーヘッド)を具体的に示している。 **弱点・課題(論文が自ら述べるもの)** - プレフィックストラッキング実装のバグにより、ICMP type/code にマッチするフローが存在すると全 TCP フローが TCP ポート全体にマッチしてしまい、CPU負荷が異常に高くなる事例が実運用データに6件観測された。修正は OVS 2.3 で行われたとされるが、当該データセンターでの本番検証はできていない。 - OpenFlow の一般性ゆえに、あるフロー追加がどのメガフローに影響するかを正確に(時間・空間効率よく)特定する方法が知られておらず、初期実装は影響範囲が不明な変更を全数再検証で扱わざるを得なかった。Header Space Analysis がこの問題に理論的な道具立てを提供しうるとしつつ、オンライン解析としての実用性は未解決の問題として残されている(脚注2)。 - Bloom フィルタベースのタグ機構は、タグ数の増加とともに偽陽性が増大し、最終的に OVS 2.0 で放棄された——キャッシュ無効化の「精密な影響範囲特定」というアプローチ自体が長期的にスケールしなかった事例である。