Kann das End-to-End-Prinzip formalisiert werden?

In den späten neunziger Jahren, als ich in der Graduiertenschule war, die Zeitung

JH Saltzer; DP Reed; DD Clark: End-to-End-Argumente im Systemdesign . ACM Trans. Comput. Syst. 2 (4): 277-288, 1984. DOI = 10.1145 / 357401.357402

Es war ziemlich wichtig, in jeder Betriebssystemklasse an jeder Universität zu lesen, und es scheint immer noch eines der wichtigsten Leitprinzipien zu sein, die dem Design des Internets zugrunde liegen. (Siehe zum Beispiel: J Kempf, R Austein (Hrsg.) Und das IAB, " Der Aufstieg der Mitte und die Zukunft von Ende zu Ende: Reflexionen über die Entwicklung der Internetarchitektur ", RFC 3724, März 2004. )

Das End-to-End-Prinzip besagt (Saltzer et al., 1984):

[Wenn] die betreffende Funktion nur mit dem Wissen und der Hilfe der Anwendung, die an den Endpunkten des Kommunikationssystems steht, vollständig und korrekt implementiert werden kann, ... sofern diese fragliche Funktion als Merkmal des Kommunikationssystems selbst nicht vorhanden ist möglich. [Obwohl] manchmal eine unvollständige Version der vom Kommunikationssystem bereitgestellten Funktion als Leistungssteigerung nützlich sein kann.

Oder kurz (aus der Zusammenfassung):

Das End-to-End-Argument legt nahe, dass Funktionen, die auf niedrigen Ebenen eines Systems platziert werden, redundant oder von geringem Wert sein können, verglichen mit den Kosten für deren Bereitstellung auf dieser niedrigen Ebene.

Aber ich hatte wenig Erfolg damit, das End-to-End-Prinzip aus eigener Erfahrung anzuwenden (in der Computerarchitektur, nicht in der Internetarchitektur). Da das Prinzip als "Gedicht" bezeichnet wird (dh in der englischen Prosa mit einer Reihe von Begriffen, die nicht mathematisch definiert sind), ist es ziemlich einfach, sich zu täuschen, dass "die fragliche Funktion nur mit vollständig und korrekt implementiert werden kann das Wissen und die Hilfe der Anwendung. " Aber was ist "die fragliche Funktion", geschweige denn "das Wissen und die Hilfe" einer Anwendung?

Beispiel: On-Chip-Netzwerke (im Gegensatz zum Internet) dürfen keine Pakete verwerfen, haben jedoch eine recht begrenzte Pufferung. Sie müssen also eine Möglichkeit haben, Deadlocks zu vermeiden oder zu beheben. Andererseits muss sich die Anwendung auch frei von Deadlocks machen, oder? Daher könnte ich argumentieren, dass ich den allgemeinen Fall (kein Deadlock) schnell lösen und die Vermeidung von Deadlocks in der App deaktivieren sollte. Dies ist in der Tat das, was wir bei Alewife und Fugu versucht haben (Mackenzie et al., Exploiting Two-Case Delivery für schnelles geschütztes Messaging , Int'l Symp High-Perf Comp Arch, (HPCA-4): 231-242, 1998. Oder John Kubiatowicz 'Dissertation.) Es "funktionierte" (indem die Verbindung den Prozessor unterbrach, als die Puffer gefüllt wurden, und das Betriebssystem mit Software-Pufferung erweitert wurde), aber ich habe niemanden in der Wissenschaft oder Industrie gesehen (einschließlich eines von uns, der Autoren dafür war HPCA-Papier) rast herum und versucht, die Idee zu wiederholen. Offensichtlich ist die Vermeidung von Deadlocks in einem Netzwerk nicht dieselbe "fragliche Funktion" wie die Vermeidung von Deadlocks auf Anwendungsebene, oder das End-to-End-Prinzip ist falsch.

Ist es möglich, das End-to-End-Prinzip von einem "Gedicht" in einen Satz zu verwandeln? Oder kann es zumindest in Begriffen angegeben werden, die für einen Computerarchitekten verständlich sind?

Ich glaube, dass Ihre Anwendung des End-to-End-Prinzips (e2e) zwei Mängel aufweisen kann:

Erstens in dem Sinne, dass Sie es für die Leistung anwenden. Das Ende-zu-Ende ist ein Entwurfsprinzip, um die Orthogonalität, Zusammensetzbarkeit, Regelmäßigkeit der Architektur, eine oder alle, Grundelemente usw. sicherzustellen. Solche Prinzipien wurden in verwandten Lehrbüchern beschrieben. Leistung gehört nicht dazu. Tatsächlich implizieren Clark et al., Dass striktes Ende-zu-Ende zu einer schlechteren Leistung führen kann, weshalb es als Ausnahme von diesem Prinzip solche verwendet.

Wenn Sie also noch formalisieren möchten:

"Das End-to-End-Argument spricht die Anwendungsanforderungen an und liefert eine Begründung für die Aufwärtsbewegung der Funktion in einem Schichtsystem", sodass Sie formalisierte Anwendungsanforderungen und ein formalisiertes Schichtsystem benötigen. Hier ist ein Versuch, der helfen könnte, noch einen Schritt weiter zu gehen:

Angenommen, Sie haben Anforderungen an Schicht (i) (Schicht (0) gilt für die Gruppe von Anwendungen, die Sie jetzt oder in Zukunft unterstützen möchten, die Anwendungsschicht) und feste Schnittstellen Schnittstelle (i, i + 1) und Schnittstelle (i + 1) , i) (von Schicht i bis i + 1 setzen hier keine Überlagerung voraus, einfach zu ändern und erforderlich) und Funktionen Funktion (i, j) (Schicht i, Funktionsindex j, nehmen Datenteil der Funktion an um es einfacher zu haben)

Eingabe: Layer (0) -Anforderungen (wie gesagt, diese müssen formalisiert werden)

Ausgabe: alles andere

END-TO-END-Ausgabe ist eine Ausgabe, bei der: Für jedes L erfüllt die Schicht (L) ihre Anforderungen nur durch die Funktionen Funktion (L, j) (dh Funktionen innerhalb der Schicht) und Schnittstelle (L, L + 1), Schnittstelle (L + 1, L)

Für jede Schicht L und Funktion Funktion (L, F) gibt es keinen Satz von Funktionen S in der Ausgabe, so dass Funktion (L, F) = S (= bedeutet äquivalente Ausgabe und Nebenwirkungen)

Wenn man also zum zweiten möglichen Mangel für die spezifische Anwendung des e2e-Prinzips kommt (und wenn ich richtig lese, was versucht wird), kann man behaupten, dass es überhaupt nicht dem e2e-Prinzip folgt, ganz im Gegenteil. Sie haben Ihre Chips "eine gewisse Deadlock-Vermeidung" und Sie haben eine Schnittstelle, die ungewöhnlich, nicht fest und spezifisch ist, um mehr Hilfe von den oberen Schichten auszulösen (zu unterbrechen). Dies ist wohl ein Cross-Layer-Ansatz, kein End-to-End-Ansatz. Mit anderen Worten, Sie haben eine Funktion (1, x), die ihre Aufgabe mit festgelegten Schnittstellen nicht vollständig und korrekt erfüllt - wenn Sie den oben bereitgestellten Formalisierungsentwurf verwenden möchten (was natürlich nur ein Anfang ist, um Ihre Frage vollständig zu beantworten aber wahrscheinlich nicht voll an sich).