端到端原则可以形式化吗？

在1990年代后期，当我还在读研究生时，

JH Saltzer；DP芦苇; DD Clark：系统设计中的端到端参数。ACM Trans。计算 Syst。2（4）：277-288，1984.DOI = 10.1145 / 357401.357402

在每所大学的每个操作系统课程中，几乎都需要阅读该书，而且它似乎仍然是互联网设计的主要指导原则之一。（例如：参见J Kempf，R Austein编辑）和IAB，“ 中间的兴起和端对端的未来：对Internet体系结构演进的思考 ”，RFC 3724，2004年3月。 ）

端到端原理说明（Saltzer等人，1984）：

[如果]仅在站在通信系统端点的应用程序的知识和帮助下，才能完全正确地实现所讨论的功能，...，前提是所质疑的功能不是通信系统本身的功能可能。[尽管]有时，通信系统提供的功能的不完整版本可能有助于提高性能。

或更简单地（摘自摘要）：

端到端的论点表明，与以较低级别提供功能相比，放置在系统较低级别上的功能可能是多余的或价值很小。

但是以我自己的经验（在计算机体系结构中，而不是在互联网体系结构中）应用端到端原理并没有取得什么成功。由于该原则被说成是“诗”（即，英语散文中有许多数学上没有定义的术语），因此很容易自欺欺人地认为：“所讨论的功能只有通过以下方式才能完全正确地实现：应用程序的知识和帮助。” 但是什么是“所讨论的功能”，更不用说应用程序的“知识和帮助”了？

示例：片上网络（与Internet不同）不允许丢弃数据包，但是缓冲非常有限，因此您需要采取某种措施来避免死锁或从死锁中恢复。另一方面，应用程序也需要使其自身无死锁，对吗？因此，我可能会以为我应该使常见情况（无死锁）变快，并在应用程序上避免死锁。实际上，这就是我们在Alewife和Fugu上尝试过的方法（Mackenzie等人，“ 利用两箱式邮件传递以进行快速保护的消息传递”，《国际Symp高性能复合拱门》（HPCA-4）：231-242， 1998年。或约翰·库比亚托维奇（John Kubiatowicz）的论文。“它”有效“（通过在缓冲区已满时使互连中断处理器，并通过软件缓冲使OS扩展），但我在学术界或行业中都没有见过任何人（包括我们中的任何人） HPCA论文）竞相尝试复制该想法。因此，显然，避免网络中的死锁与避免应用程序级死锁是不同的“问题功能”，否则端到端原理是错误的。

可以将端到端原理从“诗”转变为定理吗？或者至少可以用计算机架构师可以理解的术语来表述？

我相信端到端（e2e）原则的应用可能存在两个缺点：

首先，从某种意义上说，您将其应用于性能。端到端是一种设计原则，例如确保体系结构正交性，可组合性，规则性，一个或全部，提供原语等。此类原则已在相关教科书中进行了概述。性能不是其中之一。实际上，克拉克（Clark）等人暗示严格的端到端可能会导致性能变差，因此将其用作此原则的例外。

因此，如果您仍然想形式化：

“端到端参数吸引了应用程序需求，并提供了在分层系统中向上移动功能的理由”，因此您将需要正式的应用程序需求和正式的分层系统。这是一种尝试，可能有助于进一步采取措施：

假设您具有Layer（i）要求（Layer（0）是您现在或将来希望支持的应用程序集，即应用程序层）和牢固的接口Interface（i，i + 1）和Interface（i + 1） ，i）（从第i层到i + 1的层在这里假设没有交叉层，易于更改并使其成为必需）和函数Function（i，j）（第i层，函数索引j，假定函数的数据部分使它更简单）

输入：第（0）层要求（正如我们所说的，这些需要形式化）

输出：其他一切

END-TO-END输出是这样的输出：对于每个L，Layer（L）仅通过功能Function（L，j）（即层内的功能）和Interface（L，L + 1），Interface实现其要求（L + 1，L）

对于每个L层和函数Function（L，F），输出中没有一组Function S，因此Function（L，F）= S（=表示等效的输出和副作用）

因此，对于特定的e2e原则应用（如果我正确阅读了所尝试的内容），第二个可能的缺点是可以声称它根本不遵循e2e原则，恰恰相反。您的芯片提供了“避免死锁”的功能，并且您有一个非常规的非公司接口，专用于从上层触发（中断）更多帮助。可以说这是一种跨层方法，而不是端到端方法。换句话说，您有一个Function（1，x）不能使用设置的接口完全正确地完成其任务-如果您想使用上面提供的草稿形式化（当然，这只是一个扩展，可以帮助您完全回答问题）但本身可能并不完整）。