それぞれのトラフィック管理技術には，当然，利点と欠点があります。例えばsFlowを推奨するWebサイトでは，RMON/sFlow/NetFlowの技術比較表を公開しています。しかし，開発者の視点から見ると少々偏った感じを受けます。そこで，ここではできるだけ公平に比較してみたいと思います。比較にあたって，RMONは実際に導入可能な（一般的な）RMONの実装，仕様として定義されているRMONの2つのレベルについて考えます。また，比較は対応プロトコル階層別の比較と仕様に関する比較の2つの面から行います。
トラフィック管理技術のプロトコル階層別の対応比較を示したものが表4です。RMONは主にデータリンク層のみに対応し，NetFlowは主にネットワーク層とトランスポート層に対応しており，最新のVer.9ではデータリンク層などにも対応が拡張されています。sFlowは，管理ステーション（コレクタ）側の機能に依存しますが，すべての階層に対応可能です。
| |
| 表4●トラフィック管理対応プロトコルの階層別の比較 |
各トラフィック管理技術の仕様に関して比較をしたものが表5です。パケット・キャプチャ機能は，LANアナライザのように指定した条件にあるパケットをネットワークから採取する機能です。NetFlowではできませんが，sFlowでは，全パケットをサンプルするような設定をして，管理ステーション（コレクタ）側でフィルタすれば理論的には可能です。
|
ただし，全パケットのキャプチャは転送データ量が大きくなり現実的ではありません。RMONにもこの機能はありますが，設定が複雑であり，プローブのリソースを多く消費するので，これも実用的ではありません。エージェント・リソースについては，機能を実現するためにエージェント上で必要とするCPUの処理量やメモリ量を示しています。この必要量が少なければ，ハードウエアによる実装が可能となりコストを下げられます。この点では，sFlowが最も良く，RMONが最も悪いと言えます。
対応するプロトコルに関しては，NetFlowはTCP/IPのみですが，RMONとsFlowではTCP/IP以外のプロトコルにも対応できます。リアルタイム表示対応は，測定しているトラフィック情報をリアルタイムで管理ステーション上に表示できるかという問題です。sFlowでは，サンプル・データが即座に管理ステーションに送られて処理可能になるので，リアルタイム表示が可能です。NetFlowについても，エージェント側で集計後に送信する部分があるため若干の遅れはありますが可能です。一方RMONは，プローブ（エージェント）から管理ステーションに転送するデータ量が多い場合，リアルタイム表示は難しくなります。
