論文「The Design Philosophy of the DARPA Internet Protocols」を読む(4)
7. Other Goals
前の章で説明があった3つの設計目標は最もインターネットアーキテクチャに影響を与えている要素です。 その他の設計目標はあまり達成していないか、もしくは完全には実現していません。 別々の組織が個別に運用を行うという設計目標はある程度実現しています。 例えば、インターネットの全てのゲートウェイを単一の組織が運用しているわけではありません。
分散管理を実現するための良いツールが無いことが今日の課題です。 （1988年の論文なので「無い」というのは当時の話です。）
環境によってはインターネットアーキテクチャはcost effectiveではありません。 インターネットでのパケットヘッダは大きいです。 通常のヘッダは40バイトです。 最悪のケースでは、1バイトを送るのに40バイトのヘッダをつけなければいけません。 ファイル転送などの時には1000バイト毎にパケットを送信すればヘッダのオーバーヘッドは4％にしかなりません。
もう一つの非効率な点は喪失パケットの再送です。 インターネットでは、ネットワークのエンドノードが再送を行うので最悪の場合には何度もネットワーク上を再送パケットが送信されます。 インターネットでは途中ノードが再送を行ってくれないのでこのようになっています。 ただし、ネットワークでのパケット喪失量が十分に小さければこの影響は無視できます。 パケット喪失量が非常に多いネットワークではネットワークに何らかの付加機能があるType of Serviceがあった方が良いかも知れません。
インターネットへの新しいホストを追加するのは他のアーキテクチャよりも大変かもしれません。 インターネットアーキテクチャでは、プロトコルのほどんどがホスト内に実装されています。 そのため、全部のプロトコルをホストに実装するのは非常に大変です。 ただし、色々なプロトコルを実装している間に段々新しいプロトコルを追加することが容易になってきました。 （ここらへんは０から全部プログラムを書かなければいけない時代の発想ですね。。。）
駄目な実装がネットワーク全体に影響を与えるという問題もあります。 最初のうちはコントロール可能な少数のコンピュータだけでやっていたので大丈夫でしたが、インターネットが成長するにつれて行儀の悪いホストに対する耐性は低くなってしまいました。 （現在では迷惑メールやDoSなどが問題になっていますね。）
課金に関しては当初議論されていましたが結局、パケットフローに課金を行うツールはちょっとしかありません。 課金まわりは非軍事利用での研究でのみ行われています。
今日はここまで
続きはまた今度。
最近のエントリ
- 日本のIPv6採用状況が50％を超えている件について
- 「ピアリング戦記」の英訳版EPUBを無料配布します！
- IPv4アドレス移転の売買価格推移および移転組織ランキング100
- 例示用IPv6アドレス 3fff::/20 が新たに追加
- ShowNet 2024のL2L3
- ShowNet 2024 ローカル5G
過去記事
