Le principe de bout en bout peut-il être formalisé?

À la fin des années 1990, lorsque j'étais à l’université, le journal

JH Saltzer; DP Reed; DD Clark: arguments de bout en bout dans la conception du système . ACM Trans. Comput. Syst. 2 (4): 277-288, 1984. DOI = 10.1145 / 357401.357402

était à peu près une lecture obligatoire dans chaque classe de systèmes d'exploitation dans chaque université, et il semble toujours être l'un des principaux principes directeurs sous-jacents à la conception d'Internet. (Voir par exemple: J Kempf, R Austein (eds), et l'IAB, " The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture ", RFC 3724, mars 2004. )

Le principe de bout en bout énonce (Saltzer et al., 1984):

[Si] la fonction en question ne peut être complètement et correctement mise en œuvre qu'avec la connaissance et l'aide de l'application se trouvant aux extrémités du système de communication, ..., à condition que cette fonction mise en cause en tant que caractéristique du système de communication lui-même ne soit pas possible. [Bien que] parfois une version incomplète de la fonction fournie par le système de communication peut être utile pour améliorer les performances.

Ou plus brièvement (à partir du résumé):

L'argument de bout en bout suggère que les fonctions placées à de bas niveaux d'un système peuvent être redondantes ou de peu de valeur par rapport au coût de leur fourniture à ce bas niveau.

Mais j'ai eu peu de succès à appliquer le principe de bout en bout dans ma propre expérience (qui est dans l'architecture informatique, pas l'architecture Internet). Comme le principe est énoncé comme un «poème» (c'est-à-dire en prose anglaise avec un tas de termes qui ne sont pas définis mathématiquement), il est assez facile de se faire croire que «la fonction en question ne peut être complètement et correctement mise en œuvre qu'avec la connaissance et l'aide de l'application. " Mais qu'est-ce que "la fonction en question", encore moins "la connaissance et l'aide" d'une application?

Exemple: les réseaux sur puce (contrairement à Internet) ne sont pas autorisés à supprimer des paquets, mais ont une mise en mémoire tampon assez limitée, vous devez donc avoir un moyen d'éviter ou de récupérer après un blocage. D'un autre côté, l'application doit également se libérer de l'impasse, non? Je pourrais donc penser que je devrais rendre le cas commun (pas de blocage) rapide et repousser l'évitement des blocages sur l'application. C'est en fait ce que nous avons essayé sur Alewife et Fugu (Mackenzie, et al., Exploiting Two-Case Delivery for Fast Protected Messaging , Int'l Symp High-Perf Comp Arch, (HPCA-4): 231-242, 1998. Ou la thèse de John Kubiatowicz.) Cela a "fonctionné" (en faisant interrompre l'interconnexion du processeur lorsque les tampons ont été remplis et en augmentant le système d'exploitation avec la mise en mémoire tampon des logiciels), mais je n'ai vu personne dans le monde universitaire ou dans l'industrie (y compris ceux d'entre nous qui étaient des auteurs à ce sujet). Papier HPCA) essayant de reproduire l'idée. Ainsi, l'évitement d'impasse dans un réseau n'est apparemment pas la même "fonction en question" que l'évitement d'impasse au niveau de l'application, ou le principe de bout en bout est erroné.

Est-il possible de transformer le principe de bout en bout d'un "poème" en théorème? Ou du moins, peut-on le dire en termes compréhensibles pour un architecte informatique?

Je pense qu'il peut y avoir deux lacunes dans votre application du principe de bout en bout (e2e):

Tout d'abord, dans le sens où vous l'appliquez à la performance. Le bout en bout est un principe de conception permettant d'assurer l'orthogonalité, la composabilité, la régularité de l'architecture, une ou toutes, de fournir des primitives, etc. Ces principes ont été décrits dans des manuels connexes. La performance n'en fait pas partie. En fait, Clark et al., Implique qu'un bout à bout strict peut entraîner une baisse des performances, il l'utilise donc, à titre d'exception à ce principe.

Donc, si vous voulez toujours formaliser:

"L'argument de bout en bout fait appel aux exigences de l'application et fournit une justification pour déplacer la fonction vers le haut dans un système en couches", vous aurez donc besoin d'exigences d'application formalisées et d'un système en couches formalisé. Voici une tentative qui pourrait aider à aller plus loin:

Supposons que vous ayez des exigences pour la couche (i) (la couche (0) est pour l'ensemble d'applications que vous prévoyez de prendre en charge maintenant ou à l'avenir, la couche application) et les interfaces fermes Interface (i, i + 1) et Interface (i + 1 , i) (de la couche i à i + 1, présumez qu'il n'y a pas de superposition ici, facile à modifier et à en faire une exigence) et fonctions Fonction (i, j) (couche i, indice de fonction j, supposez que les données font partie de la fonction pour avoir plus simple)

Entrée: exigences de la couche (0) (comme nous l'avons dit, elles doivent être formalisées)

Sortie: tout le reste

La sortie de bout en bout est une sortie telle que: Pour chaque L, la couche (L) remplit ses exigences uniquement par les fonctions Fonction (L, j) (c'est-à-dire les fonctions au sein de la couche) et Interface (L, L + 1), Interface (L + 1, L)

Pour chaque couche L et fonction Function (L, F), il n'y a pas de jeu de fonctions S dans la sortie de sorte que Function (L, F) = S (= signifie une sortie équivalente et des effets secondaires)

Donc, en arrivant à la deuxième lacune possible pour l'application spécifique du principe e2e (et si je lis correctement ce qui est tenté), on peut affirmer qu'elle ne suit pas du tout le principe e2e, bien au contraire. Vous avez vos puces fournir "une certaine évitement de blocage" et vous avez une interface qui est hors de l'ordinaire non ferme et spécifique pour déclencher (interrompre) plus d'aide des couches supérieures. Il s'agit sans doute d'une approche multicouche et non d'une approche de bout en bout. En d'autres termes, vous avez une fonction (1, x) qui n'accomplit pas sa tâche complètement et correctement avec des interfaces définies - si vous souhaitez utiliser le projet de formalisation fourni ci-dessus (qui bien sûr n'est qu'un début utile à une extension pour répondre pleinement à votre question mais probablement pas complet en soi).