エンドツーエンド原理
概要
編集
エンドツーエンド原理では、アプリケーション固有の機能がネットワーク終端のホストで﹁完全かつ正しく﹂実装できるなら、ネットワーク内の中間ノードではなく終端のホストで実装されるべきだとする。この考え方はバランが1960年代に行った信頼できない部品で信頼性のあるネットワークを構築する研究にまで遡り、ネットワークに機能を追加しようとしたとき、︵ネットワークでの実装のレベルによらず︶結局は﹁完全かつ正しい﹂実装のために終端のホストにも実装しなければならなくなるという知見に基づく[注3]。下層の通信システムの機能の多くは上位層クライアントのために実装されているものの、クライアントがその機能を必要としないこともあり、クライアントが同等機能をエンドツーエンド的に再実装するような冗長な状況が存在し、性能的に無駄が生じるとした。
もう1つの典型的な例としてファイル転送がある。信頼性のあるファイル転送プロトコルやファイル転送プログラムではチェックサム機能を持ち、転送が完了した時だけチェックサムを検証する。ディスク障害やソフトウェア障害を考慮すると、エンドツーエンドのチェックサムが必要となる。ファイル転送でのキーとなるリソースはファイルシステムである。エンドツーエンド原理に従えば、ファイル転送でファイルシステムにアクセスするソフトウェアが転送の進み具合を制御し、最小の遅延で再転送を開始させることになる。
典型例として、それなりの大きさの分散ネットワークで信頼性のある2点間のファイル転送を行う場合が挙げられる[2]。2つの終端が完全な信頼性のあるファイル転送を行うには、転送先の終端でファイル全体のチェックサムを確認して終端間︵エンドツーエンド︶で肯定応答を行う必要がある。そのようなシステムで下位層がファイルより小さな単位でチェックサムと応答のプロトコルを実装することは性能最適化の手段としてのみ正当化され、ファイル転送アプリケーション自体の高い信頼性要求を達成する手段としては不十分である。
ネットワーク中立性での議論では、エンドツーエンド原理は﹁中立﹂または﹁ダム﹂ネットワークを前提として解釈される。
基本的内容
編集
エンドツーエンド原理の背景にある基本的考え方は、2つのプロセスが何らかの通信手段を用いて互いに通信する際、その通信手段の提供する﹁信頼性﹂だけでプロセスに要求されている信頼性を完全に達成することは期待できないというものである。特にそれなりの大きさのネットワークに隔てられたプロセス間で通信する際に非常に高い信頼性が求められる場合、そのコストは単純な肯定応答と再送︵ARQなど︶で達成できる信頼性要求を満たす場合より高くなる[注4]。ある一定のマージンを超えて信頼性を得るには﹁中間ノード﹂内の機構よりも﹁終端ホスト﹂内の機構の方がずっと容易で扱いやすく[注5]、特に終端ホストの方が中間ノードよりも制御しやすい場合はそうである[注6]。エンドツーエンドで肯定応答と無限に再試行する再送のプロトコル︵PAR、Positive Acknowledgment with Re-transmission プロトコル︶を使うと、データ転送の成功確率がゼロより大きい任意のネットワークで任意の高い信頼性を達成できる[注7]。
エンドツーエンド原理をエンドツーエンドの誤り制御・訂正以外に拡張して適用することは簡単ではない。例えば、レイテンシやスループットといった通信パラメータの向上に直接エンドツーエンド原理で寄与することはできない。Saltzer︵最初のエンドツーエンド原理に関する論文の主著者[2]︶との個人的やりとりに基づき、BlumenthalとClarkは2001年の論文[6]で次のように記している。
当初から、エンドツーエンド論は終端で要求仕様を正しく実装できると仮定してきた。ネットワーク内に実装する以外に要求を達成する手段がないなら、そもそもエンドツーエンド論は不適切である。(p. 80)
歴史
編集エンドツーエンド原理の意味は提唱された当初から継続的に再解釈されてきた。また Saltzer, Reed, Clark の1981年の論文より前に、注目すべきエンドツーエンド原理的な概念の明確な表現も見られる[2]。
信頼できない部品群による信頼性の達成
編集
1960年代、ポール・バランとドナルド・デービスはARPANET以前のネットワークを研究し、信頼性について後のエンドツーエンド原理に通じるコメントを残している。バランの1964年の論文には次のように記している[7]。
信頼性と誤り率低減は二次的である。いずれにしてもネットワークは重大な障害が起きることを想定して構築しなければならない。強力な誤り訂正手段は既に存在している。(p. 5)
同様にデービスはエンドツーエンドの誤り制御について次のように記している[8]。
ネットワークの全てのユーザーは自ら何らかの誤り制御手段を用意でき、それによってパケット消失を検知できるだろう。したがって、パケット消失が十分稀な現象なら、許容される。(p. 2.3)
ARPANETでの体験
編集
ARPANETは世界初の大規模汎用パケット通信ネットワークであり、バランやデービスが指摘した点を考慮し、エンドツーエンド原理の観点から重要な特徴をいくつか備えていた。
パケット交換は、一部の論理機能を通信終端に分担させる。
分散ネットワークがパケット通信を前提とするなら、パケットの順序入れ違えや重複の検出といった機能は必然的に論理的なネットワーク終端の機能となる。結果としてARPANETは機能を2つの階層に分けることを特徴とした。1つは隣接するネットワークノード (IMP) 間でデータパケットを転送することを扱う下層で、もう1つはデータ転送の終端間︵エンドツーエンド︶の側面を扱う上層である[注8]。エンドツーエンド原理の論文の筆者の1人クラークは﹁パケットの発見はエンドツーエンド論の結果ではない。パケットによりエンドツーエンド論が適切なものとなった﹂(slide 31) と結論付けている[11]。
終端間︵エンドツーエンド︶の肯定応答と再送の機構がなければ、高信頼データ転送は不可能である。
ARPANETは、コンピュータが周辺機器と入出力チャネルでやりとりするときのように、ネットワークの任意の2終端間で高信頼なデータ転送を提供するよう設計された[注9]。パケット転送で発生しうる障害に対処するため、通常のARPANETメッセージは隣接ノード間で肯定応答と再送の方式を使って確実に手渡される。手渡しが成功したらそれらが処分され[注10]、パケット喪失の際に発信元から宛先まで再送するということはない。しかし多大な努力にもかかわらず、初期のARPANET仕様で想定していた完全な信頼性は、この方式では提供不可能であることが判明した。ARPANETが初期の4ノード構成から成長するにしたがって、そのことがますます明らかとなっていった[注11]。そこでARPANETは隣接ノード間の信頼性機構の持つ本質的制約に対処し真のエンドツーエンド信頼性を追求しようとした[注12]。
信頼性、レイテンシ、スループットにはトレードオフの関係がある。
完全な信頼性を追求することは、データ転送の他の重要なパラメータ、特にレイテンシとスループットを低下させる可能性がある。予測可能なスループットと低レイテンシは、対話型のリアルタイム音声アプリケーションなどで重要であり、その場合完全な信頼性は全く必要とされない。そのような用途のため、ARPANETでは低レイテンシのデータ転送サービスをホストに提供するため、各種信頼性保証手段を省いたサービスを提供した[注13]。
TCP/IP
編集
インターネットでは、コネクションレスのデータグラムサービスで送達もQoSも保証しないIPプロトコルがほとんど全ての通信に使われている。IP上で任意のプロトコルが動作する。
音声など一部の用途では再送による信頼性は必要とされないので、IPにおける信頼性機構はIPヘッダのチェックサムのみとなっている︵低品質の経路でパケットを送信する際のビット誤り検出に必須である︶。
エンドツーエンドの肯定応答と再送は、IPの上に置かれるコネクション指向のTCPで実装している。IPとTCPで機能的に分割したのは、用途によってエンドツーエンド原理を選択可能にしたためである。
さらにネットワークが適切に機能するためには、輻輳状態となるような負荷を排除するような手段も必要とされる。
インターネットのほとんどのアプリケーションが通信にTCPを使っている。
バン・ジェイコブソンらがTCP向けのエンドツーエンドの輻輳制御アルゴリズムを考案したのは、TCPが標準化されてから7年後のことである。
エンドツーエンド接続性
編集
エンドツーエンド接続性︵End-to-End Connectivity︶は、インターネットの特徴であり、ネットワーク上の全ノードが︵途中のネットワークで変換を加えることなく︶他の任意のノードにパケットを送信できることを意味する。これはTCP/IPの特性である。
しかし、ネットワークを構成する要素や技術︵例えばネットワークアドレス変換︶は、エンドツーエンド接続性を保持していない。この特性がない場合、新たなプロトコルを使用するにはそれをサポートする新たな機器などが必要となる。このことは、TCPのコネクションを使わないでインターネットを利用する新たなアプリケーションの展開を妨げている。例えば、IPsecの普及、IPv6への移行、Peer to Peerアプリケーションの普及、ネットワークゲームの普及などが挙げられる。
エンドツーエンド接続性は時として以下のような実用的理由で意図的に放棄されることがある:
●IPv4 アドレス空間は限りある資源であり、必要と思われるよりIPアドレスが少なくなることは明らかである。
●セキュリティのために一種のアドレス変換を行ってルーティング範囲を制限すること。これはつまり、ネットワークアドレス変換(NAT)を隔てた位置にあるコンピュータは信頼されていない領域から直接アクセスできない。
この傾向により、インターネットユーザーは2種類に分かれつつある。一方は実際にインターネット接続が可能な人々で、もう一方は外向きのTCP接続でしかインターネットを利用できない人々である。
脚注
編集注釈
編集- ^ ピーター・J・デニングの「コンピューティングの大原則」の1つ
- ^ 1981年に発表されたこの論文[1]は、改定後1984年にACMのTOCSにて出版された[2][3]。
- ^ Saltzer, Reed, Clark の論文[2]からの完全な引用は次の通り。通信を含むシステムにおいては、通常通信サブシステムの周囲でモジュラーな境界を設け、あるモジュールとシステムの他の部分との間で堅固なインタフェースを定義する。すると、各モジュールは一連の機能を何らかの方法で実装することになる。各機能について通信サブシステムが実装する場合やクライアント側が実装する場合が考えられ、両方で協調して機能する場合や両方に独立に実装して冗長性を持たせる場合なども考えられる。実装を選択するにあたり、アプリケーションの要求仕様から次のような主張が成り立つ。すなわち、その機能を完全かつ正しく実装するには、通信システムの終端にあるアプリケーションの持つ知識と助力が必須である。したがって、問題の機能を通信システム自体の機能として実装することは不可能であり、さらに言えば通信システムの全クライアントの性能ペナルティを生じる︵時には、性能向上策としてその機能の下位部分を通信システムに実装するのが有効な場合もある︶。下位層に機能を実装する考え方に対して、我々はこのような考え方をエンドツーエンド論 (end-to-end argument) と呼ぶ。(p. 278) ・^ 実際、LANであっても通信に失敗する可能性はゼロではない。﹁より高いレベルの信頼性への配慮はネットワークの制御戦略を問わず必要とされている﹂[4] ・^ 経済学用語で言えば、ネットワークに信頼性を追加するための限界費用は、同レベルの信頼性を終端ホストの改良で得るのに必要となる限界費用を越えている。ネットワーク内での信頼性改良の経済的に効率的なレベルは、具体的な状況に依存するが、ゼロ近辺でないことは確かである。[2] 明らかに、より下位層でネットワーク信頼性を高める努力は、アプリケーション性能に重大な影響を及ぼすといえる。(p. 281) ・^ 契約上の救済策を強制できる可能性があったとしても、非決定的な形で中間のリソースを共有するネットワークでは完全な信頼性を達成するのは不可能である。それはせいぜい統計的な平均的性能を示す程度である。 ・^ より正確には:[5] 無限の再試行を行うPARプロトコルが正しく機能するなら、メッセージを失ったり複製を得たりすることは決してない。したがって、試行回数が有限であっても送信側の設定によって失敗確率を必要なだけ低減させることができる。(p. 3) ・^ ARPANET FRQ[9] (pp. 47 f.) によれば、ARPANETはある機能群を概念的に分離させていた。BBNの1977年の論文[10]に以下の記述がある。 ARPAネットワークの実装は、いくつものノード間で転送を繰り返すために生じる遅延を最小化するために、メッセージをパケットに分割する技法を採用している。また、通信中の2つのホスト間で同時に複数のメッセージを転送可能である。しかし、複数のメッセージやメッセージ内の複数のパケットは転送先IMPに送信時とは異なる順序で到着することがあり、重複して届くこともある。ARPAネットワークの発信元-受信先の転送手続きではパケットやメッセージの元の順序への並べ替えや重複の除去を行い、あるメッセージを構成する全パケットが到着したら宛先ホストにメッセージを渡し、エンドツーエンドの肯定応答を返す。(p. 284) ・^ この要件は ARPANET RFQ にも明確に記されている[9]。 ネットワークユーザーとしてのARPA契約者の観点からすると、通信サブネットはソフトウェアとハードウェアをネットワーク契約者が維持する自己完結型のファシリティである。相互接続ソフトウェアの設計においては、一般的な入出力のようにデータだけをサブネットとやりとりし、サブネット操作の詳細に関与すべきでない。特に誤りチェック、障害検出、メッセージ交換、障害回復、回線切り替え、通信障害、通信品質保証はネットワークの信頼性保証に必要とされ、ネットワーク契約者の唯一の責任となる。 (p. 25) ・^ Waldenの1972年の論文に次の記述がある[12]。 各IMPは隣接するIMPがパケットを受信したことを示す肯定応答を返すまで、パケットを保持する。問題がなければ肯定応答が返される。するとIMPは次のIMPがそのパケットについて責任を持つことになったと認識でき、パケットのコピーを破棄できるようになる。(p. 11) ・^ 1973年には、BBNはARPANETが当初想定していた完全な信頼性を達成できないことを認識している[13]。 当初、ネットワーク設計内で誤りを発生するのは通信回線のみと想定され、IMP内のモデムインタフェースはそのような誤りを﹁ほとんどすべて﹂検出するべくCRCチェックサム機構を備えていた。システムの他の部分、ホストインタフェース、IMPプロセッサ、メモリ、インタフェースはいずれも誤りを発生しないと想定されていた。しかし、我々は我々の経験を考慮してこの立場を再評価する必要がある。(p. 1)実際1973年に Metcalfe は﹁ARPANETでは十分な割合で検出されないビット誤りが発生している﹂と結論付けている[14] (p. 7-28)。 また BBN Report 2816 (pp. 10 ff.)[15] にもARPANETの初期の運用で得られた経験を元に行われた追加の改良が記されている。 ・^ ちなみに、ARPANETはまたエンドツーエンド信頼性機構とそれによるコストのトレードオフのよい例でもある。例えば最大8個のメッセージが2終端間のネットワーク上を転送中だと想定すると、エンドツーエンド信頼性を完全に達成することは当時としては非常にコストがかかった。肯定応答が宛先のIMPから全く届かないことを想定すると、タイムアウトして再送するまで︵そして肯定応答が返ってくるまで︶送信中の全メッセージをメモリ上に保持しておかなければならないが、当時メモリは高価であり現実的ではなかった。ホストベースのエンドツーエンド信頼性機構を実装した場合、ホストレベルのプロトコル (Network Control Program) はかなり複雑になっただろう。ホストレベルの信頼性機構が望ましいということは RFC 1 でも明記されているが、いくらかの議論の後、その方向性は採用しないことになった︵もちろん、上位層プロトコルやアプリケーションがそのような機構を実装するのは自由だった︶。当時の議論は Bärwolff 2010[16]︵pp. 56-58 および脚注、特に 151 と 163︶に詳しい。 ・^ パケット通信による音声データ転送は1971年まで遡り、1972年にはARPAが正式な研究を開始している。RFC 660 (p. 2)[17]にある通り、BBNは1974年に音声向けに信頼性を保証しないメッセージサービス (Raw Message Interface, RMI) をARPANETに導入したが、音声以外のデータ転送にも利用を認めた︵BBN Report 2913[18]pp. 55 f︶。また、Bärwolff 2010,[16] (pp. 80-84) を参照。
出典
編集
(一)^ abSaltzer, J. H.; Reed, D. P.; Clark, D. D. (April 8–10, 1981), “End-to-End Arguments in System Design”, Proceedings of the Second International Conference on Distributed Computing Systems (Paris, France: IEEE Computer Society): 509-512
(二)^ abcdefSaltzer, J. H.; Reed, D. P.; Clark, D. D. (1984), “End-to-End Arguments in System Design”, ACM Transactions on Computer Systems 2.4: 277-288 - SaltzerのMITでのホームページにある版
(三)^ Saltzer, J. H. (1980), End-to-End Arguments in System Design. Request for Comments No. 185, MIT Laboratory for Computer Science, Computer Systems Research Division
(四)^ Clark, D. D.; Pogran, K. T.; Reed, D. P. (1978), “An Introduction to Local Area Networks”, Proceedings of the IEEE 66.11: 1497–1517
(五)^ Sunshine, C. A. (1975), “Issues in Communication Protocol Design – Formal Correctness. Draft”, INWG Protocol Note 5 (IFIP WG 6.1 (INWG))
(六)^ Blumenthal, M. S.; Clark, D. D. (2001), “Rethinking the Design of the Internet: The End-to-End Arguments vs. the Brave New World”, ACM Transactions on Internet Technology 1.1: 70–109
(七)^ Baran, P. (1964), “On Distributed Communications Networks”, IEEE Transactions on Communications 12(1): 1–9
(八)^ Davies, D. W.; Bartlett, K. A.; Scantlebury, R. A.; Wilkinson, P. T. (1967), “A Digital Communication Network for Computers Giving Rapid Response at Remote Terminals”, SOSP '67: Proceedings of the First ACM Symposium on Operating System Principles (New York, NY): 2.1–2.17
(九)^ abScheblik, T. J.; Dawkins, D. B.; Advanced Research Projects Agency (1968), RFQ for ARPA Computer Network. Request for Quotations, Advanced Research Projects Agency (ARPA), Department of Defense (DoD)
(十)^ McQuillan, J. M.; Walden, D. C. (1977), “The ARPA Network Design Decisions”, Computer Networks 1.5: 243–289 - Crowther et al. (1975) に基づいており、その論文は BBN Report 2918 とその元になった BBN Report 2913 に基づいている︵どちらも1974年︶。
(11)^ Clark, D. D. (2007), “Application Design and the End-to-End Arguments”, MIT Communications Futures Program Bi-Annual Meeting (Philadelphia, PA) - 講演のスライド
(12)^ Walden, D. C. (May 25–26, 1972), “The Interface Message Processor, Its Algorithms, and Their Implementation”, AFCET Journées d’Études: Réseaux de Calculateurs (AFCET Workshop on Computer Networks) (Paris, France: Association Française pour la Cybernétique Économique et Technique (AFCET))
(13)^ McQuillan, J. M. (1973), Software Checksumming in the IMP and Network Reliability - RFC 528. Historic. NWG.
(14)^ Metcalfe, R. M. (1973), Packet Communication, Cambridge, MA: Harvard University - 学位論文。改訂版は MIT Laboratory for Computer Science Technical Report 114 に掲載された。大部分は MIT Project MAC は Xerox PARC について。
(15)^ Bolt, Beranek and Newman Inc. (1974), “Interface Message Processors for the Arpa Computer Network”, BBN Report 2816. Quarterly Technical Report No.5 (Bolt, Beranek and Newman Inc. (BBN))
(16)^ abBärwolff, M. (2010), End-to-End Arguments in the Internet: Principles, Practices, and Theory - Createspace/Amazon を通してオンライン自費出版
(17)^ Walden, D. C. (1974), Some Changes to the IMP and the IMP/Host Interface - RFC 660. Historic. NWG.
(18)^ BBN (1 July 1974 to 30 September 1974), “Interface Message Processors for the Arpa Computer Network”, BBN Report 2913. Quarterly Technical Report No. 7 (Bolt, Beranek and Newman Inc. (BBN))