要約

  • RFC 1272は、IPアドレスの両端だけでは、どの隣接管理ドメインが境界を越えてトラフィックを運んだか分からないと指摘した。
  • 境界での計測は照合に役立つが、有用な詳細度はトポロジー、粒度、保存、収集コスト、安全性に左右される。
  • 同文書は利用量報告と課金・ポリシー執行を分け、ルーターの入口と出口のどちらで数えるかを未決のまま残した。

欠けていたのは宛先ではなく隣接網の名前

IPパケットには送信元と宛先のアドレスがある。それによって端点間のトラフィックを数えられるが、ある事業者の管理ドメインにどの隣接ネットワークから入ったのかまでは、それだけでは分からない。同じ端末の通信が複数の隣接ドメインから到達し得るなら、両端の記録が完全でも、事業者が知りたい問い――このトラフィックはどの隣接網を通って自分の境界を越えたのか――には答えられない。

RFC 1272は、すべてのネットワークがインターネット上の全利用者について会計する構想ではなかった。各管理主体の関心を、自分のドメインと直接接続された隣接ドメインに絞った。事業者は隣接網との境界を越えるトラフィックを測り、その相手と記録を交換できる。隣接網が自らの費用をさらに下流へ配分するなら、それは隣接網の責任となる。会計は再帰的であり、各管理主体は観測できる関係を扱う。最終利用者まで見通す世界規模の視点があるふりはしない。

この区別によって、計測点の意味も変わる。ホストが観測するのは端点のトラフィックだ。管理境界のルーターはローカルドメインへ入る、またはそこから出る通信を見て、隣接接続に関する情報を得られる。RFC 1272は、中間システムの識別情報はIPヘッダーだけには含まれず、下位層の情報や境界装置の設定が必要になり得るとした。端点アドレスと会計境界は、異なる問いに答える。

計測そのものにも費用がかかる

設置場所は選択肢の一つにすぎない。RFC 1272は専用モニター、回線モニター、ルーター内のソフトウェア計測器、複数の回線モニターを協調させる「router spiders」を挙げた。適切な場所はトポロジーと測定対象によって異なる。境界なら提供者と利用者の照合に役立つが、すべてのルーターを必ず計測対象にせよという指示ではなかった。

文書は詳細度を技術と経済の選択として扱った。ポート、ネットワーク、ホストの単位で数えること、パケット属性を加えること、カウンターや時刻を保存すること、報告間隔を決めることができる。エンティティと属性の組み合わせが増えるたびに、別のフロー記録が必要になることもある。細かい粒度はメモリーと処理を使い、頻繁な報告は帯域とコレクターの容量を消費する。完全な正確性と信頼性を求めるなら、全パケットを調べなければならない。挙動の理解、ネットワーク調整、費用割合の概算が目的なら、サンプリングでより安く十分な場合もある。両者は同じ証拠基準ではない。

収集プロセス自体も保護が必要だった。著者らは利用量データを機微情報と捉え、機密性、完全性、収集制御を課題に挙げた。確認応答と再送、複数コレクター、または計測器側のバックアップ保存を候補として論じている。境界ルーターから取った数値だからといって、自動的に完全で信頼できる会計記録になるわけではない。

報告は請求書でも規則でもない

RFC 1272は目的を明確に限定した。これは利用量報告アーキテクチャの背景資料であり、インターネット標準ではない。報告は加入者の挙動理解、提供者によるポリシー遵守の測定、費用配分の参考に使える。しかし報告だけではポリシーを執行できず、課金方法も推奨していない。再送パケットの費用を誰が負担するかも解決していない。

意図的に未決とした問いもあった。ルーターがパケットを受信したときに数えるべきか、それとも転送したときだけ数えるべきか。輻輳中、ルーターはパケットを破棄することがある。入口で数えれば提示された通信が使った資源を捉え、出口で数えれば転送されなかった通信を課金対象から外せる。RFC 1272は両方を選べる構造を求めた。答えは普遍的な技術則ではなく、状況とポリシーに左右されるからだ。

後年のRFC 2722はトラフィックフロー測定アーキテクチャを規定した。これは測定技術の後史であり、特定の課金制度や1991年の会計構想全体が運用された証拠ではない。RFC 1272が残した問いはもっと限定的だ。管理主体は自分の境界で何を知り得て、どこまで測る費用を負担する価値があるのか。観測したフロー、特定した隣接網、報告、その後の価格や制御の判断まで、証拠の連鎖を保つ必要がある。パケット両端のIPアドレスだけから、そのどれも自動的には導けない。

出典：RFC 1272、RFC 2722、RFC 2990。