要約

  • RFC 1077は完成済みのギガビット網を規定した文書ではなく、生の光学容量を利用者のサービスへ変えるための研究課題を整理した情報提供RFCだった。
  • 幹線の速度が交換要素より速く伸びると、希少性は回線から電子処理、パケット単位の仕事、メモリー転送、ホスト側へ移る。最速の部品はシステム全体を代表しない。
  • 後年のRFCは、装置ベンチマーク、サービス上の約束、経路上の観測を別々に定義した。どれも物理回線速度の言い換えではなく、互いの証明にもならない。

未来図より先に、変換問題があった

RFC 1077は、設置済み光ファイバーを根拠に、集約でギガビット、その先にはテラビット毎秒に近い生の帯域まで見通した。だが文書は、その規模を成果として数えなかった。少数の利用者へ数ギガビットを届けながら、多数の利用者には数メガビット級を費用効率よく届けるにはどうするか、と問い直している。

これはDARPAの要請で集まったGigabit Working Groupの研究報告である。ギガビット・バックボーン、相互接続されたネットワーク、管理技術、アクセス構造の研究と実証を提案したが、標準規格でも導入実績でもない。列挙された方式も処方箋ではなく、研究上の論点を具体化する例だった。

言い換えれば、RFC 1077の主題は速度そのものではなく変換である。伝送媒体が持つ可能性を、異なる利用者が継続的に使えるサービスへ変換する。その途中に何があるかを、一つずつ数えた。

交換機が光に追い越される

従来の広域網では、高価で遅い帯域を有効利用することが交換設計の中心だった。RFC 1077は、この前提が反転しつつあると述べた。幹線の速度が交換要素の速度より速く上がり始めたのである。

光は大量のビットを運べる。しかし転送先の選択、バッファー、課金、制御には電子回路と処理が要る。従来型パケット交換は各パケットに仕事を課すため、ビット毎秒だけを増やしても、パケット毎秒の処理能力が追いつかなければ交換機が狭窄部になる。記憶装置も電子技術への依存と大規模時の不安定性を持ち込む。

これは「帯域が無限になる」という予言ではない。制約の住所が変わるという観察だった。媒体を増速すれば、次に遅い部品が結果を決める。

その次の住所がホストである。RFC 1077は、高速網ではホストのパケット処理負荷が重大なボトルネックになると見た。幹線全体では高い集約レートを通せても、一つのアプリケーションへ高レートを渡せない。プロトコル処理、メモリー移動、周辺機器、ネットワーク・フロントエンドまでが配達経路だった。

合計値が同じでも、需要の形は違う

想定された負荷には二つの極があった。スーパーコンピューターなど少数の装置が個別に巨大な流れを要求する場合と、膨大な数の中速利用者が集まって巨大な総量を作る場合である。合計ビット数が同じでも、突発性や同時性、必要な制御は同じではない。

さらに、アプリケーションはスループットだけを求めない。RFC 1077は遅延、遅延のばらつき、信頼性、順序配送を分けた。大量転送は量を優先できる。対話型シミュレーションは応答を失えない。音声と映像は到着間隔を気にする。ネットワーク制御は小容量でも重要度が高い。

文書は、コネクション型、コネクションレス、ストリーム／同期通信を区別し、一定量の帯域を保証する例として予約を置いた。サービス種別、経路ポリシー、公平性、事前予約も研究課題に入れた。

ここで制御権が現れる。アプリケーションが必要なサービスを記述し、ネットワークが資源配分に使う。しかしアプリケーションは、抽象的な「速さ」をレート、遅延、損失許容度、継続時間へ翻訳することに慣れていない。物理容量の所有者だけでは、正しい要求を作れない。

高速化は管理を本体にした

RFC 1077が次世代構造を「第一に管理アーキテクチャ」とした点は重い。リンク、プロセッサー、メモリーが単純な性能問題を解くほど、大規模システムには複雑な性能、信頼性、セキュリティーの問題が現れるからだ。

管理には課金、セキュリティー、性能監視、障害切り分け、構成制御が含まれる。課金は、割り当て帯域、パケット、ポートなど政策上必要な対象を記録する。それは誰に何を配分したかという証拠であり、受信アプリケーションが何を得たかという証拠ではない。

性能監視は、ある観測点と条件でネットワークがどう動いたかを示す。文書は、苦情の後に動く管理から、利用者が気づく前の診断と動的資源配分へ進むことを望んだ。同時に、生の管理データが人を溺れさせるため、しきい値、フィルター、警報と詳細への到達手段が必要だとした。

速いネットワークは、転送するデータだけでなく、説明すべき状態も増やす。

装置の能力は試験条件と一体である

後のRFC 1242は、相互接続装置のスループットを、投入したフレームを一つも落とさずに処理できる最大レートと定義した。媒体に印刷された公称ビットレートではない。

フレーム長、片方向か双方向か、ルーティングかブリッジングか、チェックサムや制御処理を含むかで能力は変わる。同RFCは遅延、フレーム損失、過負荷、オーバーヘッド、バーストも別の項目にした。大きなフレームの定常流に強い装置が、小さなパケットや経路更新にも同じ強さを持つとは限らない。

RFC 2544は、その能力を比較可能にする試験手順を整えた。理論上の媒体レートと実測スループットを並べ、確定したスループットで遅延を測り、投入負荷とフレーム長ごとに損失を報告する。単一の広告値より、条件を含む表が重要だった。

これは隔離された条件下の装置特性である。多段の実ネットワーク、アプリケーションの完了時間、契約上の品質をそのまま証明しない。問いを限定するからこそ、有効な証拠になる。

予約は結果を約束する装置であって、観測ではない

RFC 1633は後に、光ファイバーが豊富なら資源管理はいらない、という議論を退けた。生の帯域が安く見えても、ネットワークサービスとして提供される帯域が、あらゆる場所で十分かつ無競合になるわけではない。

Integrated Servicesは、予測可能な扱いを必要とするフローに予約と受け入れ制御を設けた。分類器、スケジューラー、受け入れ判断が、どの流れをどのキューで扱い、新しい約束を許すかを決める。これはサービスの制御面であり、媒体容量とも事後観測とも違う。

RFC 2212のGuaranteed Serviceは、申告したトラフィック条件を守り、経路上のサービス要素が適合すれば、キューイング遅延を上限内にし、キューあふれによる廃棄を避けるという強い約束を記述した。固定的な経路遅延は別に加える。予約の設定方法もRSVP一択ではなく、手動設定や管理プロトコルでよい。

したがって予約成功が示すのは、モデルに基づく約束が受理されたことだ。経路が変わらず、全要素が適合し続け、受信側が実際に結果を得たことまでは独立に証明しない。

経路の事実は経路で測る

RFC 2679は、一方向遅延を送信元、宛先、パケット種別、時刻を持つ観測として定義した。一回の値、標本、統計量を分け、時計同期、測定誤差、非常に遅いパケットと損失の判別まで条件に含めた。

RFC 3393は、選んだパケット同士の一方向遅延の差を遅延変動とした。再生バッファーの設計やキューの動きに役立つが、容量や平均遅延の別名ではない。観測点と選択方法を外せば、同じ数値でも意味が変わる。

RFC 1077の問いを運用上の四層へ整理すると、こうなる。

  1. 生の容量――媒体が所定の前提で運べる量。
  2. 処理能力――交換機とホストが所定の負荷で転送・消費できる量。
  3. サービス上の扱い――制御系が割り当て、予約し、条件付きで保証するもの。
  4. 提供結果――選ばれた観測者が特定経路・時間帯で測ったもの。

下の層は上の層を制約するが、証拠は自動的に上へ昇らない。回線速度は装置試験ではない。装置試験は予約ではない。予約は到着の記録ではない。

ラベルのない「帯域」が最も危ない

RFC 1077はギガビット・インターネットを完成させなかった。その代わり、最速部品をサービス全体の代理にしない思考法を残した。ある技術の豊富さは、別の場所の不足を露出させる。

速度の数字を見るときは、どの層の誰が、どの方向、パケット形状、負荷、経路、時間窓で作った数字かを確認する必要がある。容量なのか、能力なのか、約束なのか、結果なのか。

光ファイバーは確かに速かった。だが利用者へ届くまで、サービスはシステムであり続けた。

出典と証拠の限界

RFC 1077は1988年の研究課題、RFC 1242とRFC 2544は装置能力、RFC 1633とRFC 2212はサービスモデルと約束、RFC 2679とRFC 3393は経路観測の境界を示す。これらは公表された設計と要件の証拠であり、普遍的な導入、現在の製品性能、RFC 1077から後続文書への直接系譜を証明しない。