エンドツーエンドの原則を形式化できますか？

1990年代後半、私が大学院にいたとき、

JHサルツァー; DPリード; DDクラーク：システム設計におけるエンドツーエンドの議論。ACM Trans。計算。システム。2（4）：277-288、1984。DOI= 10.1145 / 357401.357402

すべての大学のすべてのオペレーティングシステムクラスで読む必要があり、インターネットの設計の基礎となる主要な指針の1つであるように思われます。（例：J Kempf、R Austein（eds）、およびIAB、「Rise of the Middle and the Future of End-to-End：Reflections on the Evolution of the Internet Architecture」、RFC 3724、2004年3月。 ）

エンドツーエンドの原則は次のように述べています（Saltzer et al。、1984）：

[if]問題の機能が完全かつ正確に実装できるのは、通信システムのエンドポイントにあるアプリケーションの知識と助けを借りた場合のみです。...問題のある機能を通信システム自体の機能として提供することは、可能。[ただし]通信システムによって提供される機能の不完全なバージョンは、パフォーマンスの向上に役立つ場合があります。

またはもっと簡単に（要約から）：

エンドツーエンドの議論は、システムの低レベルに配置された機能は、その低レベルで提供するコストと比較した場合、冗長であるか、またはほとんど価値がない可能性があることを示唆しています。

しかし、私は自分の経験（インターネットアーキテクチャではなくコンピュータアーキテクチャ）でエンドツーエンドの原則を適用することにほとんど成功していません。原理は「詩」（つまり、数学的に定義されていない一連の用語を含む英語の散文では）として記述されているので、「問題の機能は、アプリケーションの知識と助け。」しかし、アプリケーションの「知識とヘルプ」はもちろんのこと、「問題の機能」とは何でしょうか。

例：（インターネットとは異なり）オンチップネットワークではパケットをドロップできませんが、バッファリングは非常に制限されているため、デッドロックを回避または回復する方法が必要です。一方で、アプリケーションもデッドロックを解消する必要がありますよね？ですから、私は一般的なケース（デッドロックなし）を高速にして、アプリでデッドロック回避をオフにするべきだと考えるかもしれません。これは、実際、私たちがAlewifeとFuguで試したものです（Mackenzie et al。、Exploiting Two-Case Delivery for Fast Protected Messaging、Int'l Symp High-Perf Comp Arch、（HPCA-4）：231-242、 1998.またはJohn Kubiatowiczの論文。）それは「機能しました」（バッファーがいっぱいになったときにインターコネクトにプロセッサーを中断させ、OSにソフトウェアバッファリングを追加させることによって）が、私は学界や業界（その作成者である私たちを含む）で誰も見たことがないHPCAペーパー）アイデアを再現しようと競争している。したがって、ネットワークでのデッドロックの回避は、アプリケーションレベルのデッドロックの回避と同じ「問題の機能」ではないか、エンドツーエンドの原則が間違っています。

エンドツーエンドの原則を「詩」から定理に変えることは可能ですか？あるいは、少なくとも、コンピューターアーキテクトが理解できる言葉でそれを述べることはできますか？

エンドツーエンド（e2e）の原則の適用には2つの欠点があると思います。

まず、パフォーマンスに適用するという意味で。エンドツーエンドは、アーキテクチャの直交性、構成可能性、規則性、1つまたはすべてを保証する、プリミティブを提供するなどの設計原則です。このような原則は、関連する教科書で概説されています。パフォーマンスはそれらの1つではありません。実際、Clark et alは、厳密なエンドツーエンドはパフォーマンスの低下につながる可能性があることを示唆しているため、この原則の例外として使用しています。

したがって、まだ形式化したい場合は、次のようにします。

「エンドツーエンドの議論はアプリケーション要件に魅力的であり、階層化システムで機能を上に移動するための理論的根拠を提供する」ため、正式なアプリケーション要件と正式な階層化システムが必要になります。これをさらに一歩進めるのに役立つ可能性のある試みを次に示します。

Layer（i）要件（Layer（0）は、現在または将来サポートする予定の一連のアプリケーション、アプリケーションレイヤー用）と確定インターフェイスInterface（i、i + 1）およびInterface（i + 1）があるとします。 、i）（レイヤーiからi + 1までは、ここではクロスレイヤーを想定していないため、簡単に変更して要件にすることができます）および関数Function（i、j）（レイヤーi、関数インデックスj、関数のデータ部分を想定より簡単にする）

入力：Layer（0）要件（これらは正式化する必要があると私たちが述べたように）

出力：その他すべて

END-TO-END出力は、次のような出力です。Lごとに、Layer（L）は関数Function（L、j）（つまり、レイヤー内の関数）およびInterface（L、L + 1）、インターフェイスによってのみ要件を達成します（L + 1、L）

レイヤーLと関数Function（L、F）ごとに、出力にFunction Sのセットがありません。そのため、Function（L、F）= S（=は、同等の出力と副作用を意味します）

したがって、特定のe2e原則アプリケーションの2番目の考えられる欠点（および、私が試みていることを正しく読んでいる場合）になると、e2e原則にまったく従わないと主張できます。チップに「いくつかのデッドロック回避」を提供し、上位層からより多くのヘルプをトリガー（割り込み）するために特定された、通常ではない非特定のインターフェイスを使用します。これは間違いなくクロスレイヤーアプローチであり、エンドツーエンドのアプローチではありません。言い換えれば、あなたはFunction（1、x）がset Interfacesで完全にそして正しくタスクを達成していないことを持っています-上で提供されたドラフト形式化を使用したい場合（もちろんこれはあなたの質問に完全に答えるための拡張に役立つ開始にすぎません）おそらくそれ自体で完全ではありません）。