> [!abstract] 概要(原文 Abstract の日本語訳) > 本論文は、分散コンピュータシステムのモジュール間に機能をどう配置するかを導く設計原則を示す。エンドツーエンド論(the end-to-end argument)と呼ばれるこの原則は、システムの低レベルに置かれた機能は、その低レベルで機能を提供するコストと比較すると、冗長であるか価値が乏しい場合があることを示唆する。本論文で論じる例には、ビット誤り回復、暗号化によるセキュリティ、重複メッセージの抑制、システムクラッシュからの回復、配送確認が含まれる。これらの機能を支える低レベルの機構は、性能向上策としてのみ正当化される。 ## 論文情報 - タイトル: End-To-End Arguments in System Design - 著者・所属: J. H. Saltzer, D. P. Reed, D. D. Clark(いずれも M.I.T. Laboratory for Computer Science。D. P. Reed のみ執筆当時 Software Arts, Inc. 在籍) - 媒体・発表年: *ACM Transactions on Computer Systems*, Vol. 2, No. 4, November 1984, pp. 277-288 - 前身版: 1981年の2nd International Conference on Distributed Systems(パリ)で発表された版(IEEE 1981)を改訂したもの - Received February 1983; accepted June 1983 - DOI: 明記なし(PDF本文に記載なし)。本ページの `url` は著者 J. H. Saltzer 本人が MIT で公開している PDF を採用(ACM Digital Library のページは検証時に403で確認不可だった) ## 概要 本論文は、分散コンピュータシステムの設計において、ある機能をどのモジュール(通信サブシステムか、アプリケーションか)に置くべきかを判断するための原則「エンドツーエンド論」を提示する。核心は、完全性を要する機能は通信システムの末端にあるアプリケーションでしか正しく実装できず、低レベルの通信サブシステムがその機能を完全な形で提供しようとする努力は、性能向上策としてのみ正当化されるというものである。論文は「ケアフルファイル転送」という具体的な事例分析から出発し、配送確認・暗号化・重複メッセージ抑制・FIFO配送保証・トランザクション管理という複数の機能に同じ論法を適用してみせたうえで、エンドツーエンド論が絶対的な規則ではなくガイドラインであることを、音声パケット通信の事例で示す。 ## 問題設定 分散コンピュータシステムの設計者にとって、「機能の境界をどこに引くか」は最も基本的な作業の一つである。特に、通信ネットワークをシステムの一部品として組み込む場合、ある機能(信頼性のある伝送、暗号化、重複排除、配送確認など)は、通信サブシステム自身が実装することも、そのクライアント(アプリケーション)が実装することも、あるいは両者が共同で実装することもできる。論文はこの機能配置の選択に対して、アプリケーション要求に基づく判断基準を与えることを目的とする。対象読者はレイヤ化された通信プロトコルの設計者であり、前提として「通信サブシステムとその周辺の残りの部分との間にモジュラーな境界とインタフェースが引かれている」システムを想定する。 ## 提案手法 ### エンドツーエンド論の定式化 論文はエンドツーエンド論を次のように定式化する。「問題となっている機能は、通信システムの末端に立つアプリケーションの知識と協力があってはじめて完全かつ正しく実装できる。したがって、その機能を通信システム自体の機能として提供することはできない(通信システムが提供する不完全な版の機能が、性能向上策として有用な場合はある)。」 ### ケーススタディ: ケアフルファイル転送 エンドツーエンド論の中心的な事例分析として、計算機Aから計算機Bへファイルを損傷なく転送する「ケアフルファイル転送」問題を用いる。転送の過程では次の5つの脅威が想定される。(1) ディスクのハードウェア障害による読み出し時の誤り、(2) ファイルシステム・転送プログラム・通信システムのソフトウェアバグ、(3) プロセッサやメモリの一過性エラー、(4) 通信システムによるパケットの欠落・改変・重複配送、(5) 転送の途中でのホストのクラッシュ。 これらの脅威に対し、各ステップを個別に冗長化・タイムアウト再送・エラー検出で強化する「力任せ」の対策は、脅威(2)への系統的対処が正しいプログラムを書くことを要求する点で困難であり、経済的でもない。論文はこれに対して「エンドツーエンドのチェックと再試行」を提案する。ファイル転送先のホストBが受信したファイルをディスクから読み戻してチェックサムを再計算し、送信元ホストAの元のチェックサムと比較する。両者が一致した場合にのみ転送を「コミット」したと宣言し、不一致ならば最初からの再試行を行う。 この分析から得られる結論は、通信システムが内部でどれほど信頼性の高いデータ伝送を保証しても(パケットチェックサム・シーケンス番号チェック・内部再送機構など)、脅威(4)は解消されても残り4つの脅威は解消されないため、ケアフルファイル転送アプリケーションは依然としてエンドツーエンドのチェックサムと再試行を自前で用意する必要がある、という点である。通信システムの高信頼化は、アプリケーション側の再試行頻度を減らす効果しか持たず、転送の正しさそのものには寄与しない。 論文はこれを裏付ける実例として、MITで実際に起きた事故を挙げる。あるゲートウェイ経由の複数ネットワークシステムでは、各ホップでパケットチェックサムを取っていたが、ゲートウェイ内部でバッファ間コピー中に一過性エラーが発生し、約100万バイトに1回の頻度でバイトペアが入れ替わるバグがあった。アプリケーションプログラマはネットワークが信頼できる伝送を提供していると誤解しており、ゲートウェイ内部でデータが無防備であることに気づいていなかった。このバグにより一部のOSソースファイルが破損し、所有者は最終手段として古いリスト印刷物との手作業比較・修正を強いられた。 ### 性能面の考慮 低レベル層が信頼性向上に一切関与すべきでない、と結論するのは単純化しすぎである。100メッセージに1つを落とす程度の不信頼なネットワークでは、単純な「送って後で確認する」戦略はファイル長が伸びるほど性能が劣化する——全パケットが正しく届く確率はファイル長に対して指数関数的に減少し、期待転送時間も指数関数的に増大するためである。したがって低レベルでの信頼性向上には性能上の意味がある。しかし低レベル層が「完璧な」信頼性を提供する必要はなく、通信サブシステムへの信頼性対策への投資量は、正しさの要件ではなく性能に基づく工学的トレードオフとして決めるべきである、というのが論文の立場である。低レベルでの機能実装が有利になるのは、既存の低レベル機構への追加負担が最小で済む場合であり、逆に不利になるのは、(a) 低レベルサブシステムが多くのアプリケーションに共有されているため、機能を必要としないアプリケーションもそのコストを負担させられる場合、(b) 低レベルサブシステムが高レベルほどの情報を持たないため効率的に処理できない場合、の2通りがあると整理する。 ## 新規性 論文自身が明記するとおり、エンドツーエンド論に含まれる個々の事例は目新しいものではなく、何年も前から明確な認識や確信を伴わずに使われてきた実務知であった。本論文の新規性は、データ通信ネットワークが計算機システムの構成要素として登場したことでこの種の機能配置論法がより鮮明になった状況を捉え、その論法を明示的に定式化し、どこまで一般化できるかを検討した点にある。具体的には、信頼性のあるデータ伝送という典型例の詳細なケーススタディから出発し、暗号化・重複メッセージ検知・メッセージ順序保証・配送保証・ホストクラッシュ検知・配送確認という通信ネットワーク文脈の複数機能に適用範囲を広げ、さらにファイルシステムを含むオペレーティングシステムのより広い文脈にも同じ論法が適用可能であることを示した。 ## 実験設定・実験結果について 本論文は定量評価を伴う実験を行わない設計原則論文であり、実証は事例分析(ケーススタディ)と歴史的先行事例の参照によって行われる。中心となる事例分析は上記「提案手法」節のケアフルファイル転送であり、加えて以下の適用事例が論じられる。 ### 他の適用事例 - **配送確認(Delivery Guarantees)**: ARPANETのRFNM(Request For Next Message)のような通信システムレベルの配送確認は、アプリケーションが本当に必要とする「対象アプリケーションがメッセージに基づく処理を実行したか」を保証しない。真に必要な確認はエンドツーエンドの確認(「私はやった」「私はやらなかった」)であり、複数ホストにまたがる処理を要する場合は2相コミットプロトコルという高度なエンドツーエンド確認が必要になる。 - **データの安全な伝送(暗号化)**: 通信システム自身が暗号化・復号を行う場合、(1) 鍵管理への信頼、(2) 対象ノードでの平文露出、(3) メッセージの真正性検証を依然アプリケーションが行う必要がある、という3つの理由から、通信サブシステムによる暗号化はアプリケーション要件を満たさない。ただし不正なアプリケーションによる情報漏洩を防ぐファイアウォールとしての全トラフィック自動暗号化には別の意義がある(ユーザーごとの鍵管理を要しない単純な鍵で足りる)。 - **重複メッセージ抑制**: 通信ネットワークが重複メッセージを抑制しても、アプリケーション自身の失敗・再試行手続きが生成する重複はネットワークからは区別できず、アプリケーション自身が検知・抑制するしかない。したがって低レベルでの重複抑制機構は省略できる。 - **FIFOメッセージ配送の保証**: 同一の仮想回線上ではFIFO順序が保証されても、独立した仮想回線や通信サブシステム外の中間プロセスを経由するメッセージは順序が保証されない。複数サイトにまたがる要求を発行する分散アプリケーションは、通信サブシステムより上位の独立した機構で順序制御を行う必要がある。 - **トランザクション管理(SWALLOWでの適用)**: 著者らが構築した分散データストレージシステムSWALLOWでは、エンドツーエンド論の適用によりオーバーヘッドを大きく削減した。基盤の通信プロトコルは重複メッセージを抑制しない(オブジェクト識別子とバージョン情報で重複書き込みを検知でき、重複読み出し要求は単に重複応答を生むだけで送信元が容易に破棄できるため)。また配送確認も基盤層では提供せず、書き込み要求が本当に必要とする確認(データが安全に格納されたこと)はSWALLOWの上位層でしか提供できない。配送確認の省略によりメッセージ数が半減し、ホスト負荷・ネットワーク負荷の双方に有意な性能改善をもたらした。同様の発想はリモートディスクレコードアクセスの実験的プロトコルにも適用され、下位プロトコルのパスレングス短縮によりリモートディスクアクセスの性能維持に寄与した。 ### エンドポイントの識別(Identifying the Ends) エンドツーエンド論の適用には、アプリケーション要件の分析における繊細さが要求される事例として、パケット音声通信が挙げられる。リアルタイム音声会話では、低レベル層がビット完全な通信を追求すると再送によって配送遅延が生じ、一定レートでのデータ供給を必要とする音声アプリケーションを損なう。むしろ多少破損したパケットをそのまま受け入れる、無音や直前パケットの複製で置き換える方が望ましく、音声自体の冗長性と「もう一度言ってもらえますか」という高レベルの誤り訂正手続きがこれを補う。 一方、同じ音声パケットでも、後で聴取するために保存する音声メッセージシステムでは事情が逆転する。配送の短い遅延は許容でき、むしろ録音時点でできる限り正確なデータを得ることが重要になる(受信者は再生時に送信者へ聞き返せないため)。この対比から、論文はエンドツーエンド論が絶対的な規則ではなく、アプリケーションごとにエンドポイントをどこに識別するかを見極めるためのガイドラインであると結論づける。 ## 考察(歴史的先行事例と他分野への応用) 論文の第5節は、エンドツーエンド論の個々の事例が独自の発見ではなく、長年にわたり蓄積されてきたものであることを歴史的に跡づける。 - MITのCompatible Time-Sharing System(CTSS)の"wait"メッセージが、疑わしい中間配送確認の最初期の例として挙げられる。 - 暗号化に関するエンドツーエンド論は、Branstadの1973年論文で初めて公に論じられ、Diffie and Hellman、Kentがより深く発展させ、Needham and Schroederが改良プロトコルを考案した。 - Gray、Lampson and Sturgis、Reedによる2相コミットのデータ更新プロトコルはいずれもエンドツーエンド論の一形態であり、通信システム内部の信頼性・FIFO順序・重複抑制に正しさを依存しない。Reedは自身の博士論文の第2章でこの論法を明示的に展開している。 - 銀行システムの高レベル監査手続き、航空券予約システムでの担当者によるクラッシュ越しの再試行、電話交換機での単一通話損失への無回復方針など、業務システムにおける自動回復への応用が複数挙げられる。 - データグラム対仮想回線というネットワークプロトコルコミュニティの論争は、本質的にエンドツーエンド論をめぐる論争であるとされる。 - 1950年代の磁気テープサブシステムをめぐる実務でも、独立にエンドツーエンド論に相当する実務知が形成され、Multicsのファイルバックアップシステムはテープサブシステム自体の強力な誤り検出・訂正機能に加えて独自のレコードラベルと複数コピーによる誤り制御を持つ。 - RISCアーキテクチャを支持する議論はエンドツーエンド論に類似する(計算機設計者が推測する高度な機能は的を外しやすく、クライアントは結局自前で再実装することになる)。 - Lampsonのオープンオペレーティングシステム論も類似の論法を用いており、低レベルモジュールのどの機能も置換可能であるべきだと主張する。カーネル化プロジェクトの多くも、異なる正しさの論法に触発されつつ、結果として低システムレベルから機能を追い出す方向に動いている。 ## 強み・弱点/課題 **Strengths** - 信頼性・暗号化・重複抑制・順序保証・確認応答という異質に見える複数の機能を、単一の統一的な論法で貫いて説明できる汎用性。 - 「性能向上策としての低レベル実装は正当化されうる」という留保を最初から組み込んでおり、原則を教条的に適用させない設計になっている。 - 音声通信の事例により、原則の適用にはエンドポイントの識別という文脈依存の判断が必要であることを自ら明示し、絶対視を戒めている。 **Weaknesses/Limitations** - 論文自身が「エンドポイントをどこに置くべきかの判断には注意深い考察が必要」「性能トレードオフはしばしば複雑である」と繰り返し述べるとおり、原則の適用そのものに定量的な基準を与えておらず、最終的な判断は設計者の経験則に委ねられる。 - 実証はケーススタディと歴史的先行事例の参照にとどまり、性能面のトレードオフについても定性的な議論の域を出ない(例えば低レベル層での早期再送を導入すべきか否かの判断について、論文自身「どちらの層でもこの性能向上策を実行できるため、エンドツーエンド論はどこに早期チェックを置くべきかを教えてくれない」と認めている)。