Il principio end-to-end può essere formalizzato?

Alla fine degli anni '90, quando ero alla scuola di specializzazione, il giornale

JH Saltzer; DP Reed; DD Clark: argomenti end-to-end nella progettazione del sistema . ACM Trans. Comput. Syst. 2 (4): 277-288, 1984. DOI = 10.1145 / 357401.357402

era praticamente necessario leggere in ogni classe di sistemi operativi in ​​ogni università, e sembra ancora essere uno dei principi guida primari alla base della progettazione di Internet. (Vedi ad esempio: J Kempf, R Austein (a cura di) e IAB, " L'ascesa del medio e il futuro dell'end-to-end: riflessioni sull'evoluzione dell'architettura di Internet ", RFC 3724, marzo 2004. )

Il principio end-to-end afferma (Saltzer et al., 1984):

[Se] la funzione in questione può essere implementata completamente e correttamente solo con la conoscenza e l'aiuto dell'applicazione che si trova agli estremi del sistema di comunicazione, ..., a condizione che la funzione in questione come caratteristica del sistema di comunicazione stesso non sia possibile. [Sebbene] a volte una versione incompleta della funzione fornita dal sistema di comunicazione può essere utile come miglioramento delle prestazioni.

O più brevemente (dall'abstract):

L'argomentazione end-to-end suggerisce che le funzioni poste a livelli bassi di un sistema possono essere ridondanti o di scarso valore se confrontate con il costo di fornirle a quel livello basso.

Ma ho avuto scarso successo nell'applicazione del principio end-to-end nella mia esperienza (che è nell'architettura del computer, non nell'architettura di Internet). Dal momento che il principio è definito come "poesia" (cioè, in prosa inglese con un mucchio di termini che non sono definiti matematicamente), è abbastanza facile ingannarsi nel pensare che "la funzione in questione può essere implementata completamente e correttamente solo con la conoscenza e l'aiuto dell'applicazione ". Ma qual è "la funzione in questione", figuriamoci "la conoscenza e l'aiuto" di un'applicazione?

Esempio: le reti su chip (a differenza di Internet) non possono rilasciare pacchetti, ma hanno un buffering piuttosto limitato, quindi è necessario avere un modo per evitare o ripristinare il deadlock. D'altra parte, l'applicazione deve liberarsi anche del deadlock, giusto? Quindi potrei pensare che dovrei velocizzare il caso comune (senza deadlock) e spingere via l'evitamento di deadlock sull'app. Questo è, in effetti, ciò che abbiamo provato su Alewife e Fugu (Mackenzie, et al., Sfruttando la consegna in due casi per la messaggistica protetta veloce , Int'l Symp High-Perf Comp Arch, (HPCA-4): 231-242, 1998. O tesi di John Kubiatowicz.) "Ha funzionato" (facendo in modo che l'interconnessione interrompesse il processore quando i buffer si riempivano e il sistema operativo aumentasse con il buffering del software), ma non ho visto nessuno nel mondo accademico o industriale (incluso nessuno di noi che ne fosse autore Carta HPCA) correndo in giro cercando di replicare l'idea. Quindi l'evitamento di deadlock apparentemente in una rete non è la stessa "funzione in questione" dell'evitamento di deadlock a livello di applicazione, oppure il principio end-to-end è sbagliato.

È possibile trasformare il principio end-to-end da un "poema" in un teorema? O almeno, può essere dichiarato in termini comprensibili per un architetto informatico?

Credo che potrebbero esserci due carenze nell'applicazione del principio end-to-end (e2e):

Innanzitutto, nel senso che lo applichi per le prestazioni. L'end-to-end è un principio di progettazione tale da garantire l'ortogonalità dell'architettura, la componibilità, la regolarità, una o tutte, fornire primitivi ecc. Tali principi sono stati delineati nei libri di testo correlati. Le prestazioni non sono tra queste. In effetti, Clark et al., Implica che un rigoroso end-to-end può comportare prestazioni peggiori, quindi usa tali, come un'eccezione a questo principio.

Quindi, se vuoi ancora formalizzare:

"L'argomento end-to-end fa appello ai requisiti dell'applicazione e fornisce una logica per spostare la funzione verso l'alto in un sistema a strati", quindi avrai bisogno di requisiti di applicazione formalizzati e di un sistema a strati formalizzato. Ecco un tentativo che potrebbe aiutare a fare un ulteriore passo avanti:

Supponiamo che tu abbia i requisiti del Livello (i) (Il Livello (0) è per il set di applicazioni che ti aspetti di supportare ora o in futuro, il livello dell'applicazione) e le interfacce aziendali Interface (i, i + 1) e Interface (i + 1 , i) (dal Livello i a i + 1 non presuppone la sovrapposizione qui, facile da modificare e rende un requisito) e funzioni Funzione (i, j) (Livello i, Indice di funzione j, assume i dati parte della funzione per semplificarlo)

Input: Requisiti del livello (0) (come abbiamo detto, questi devono essere formalizzati)

Uscita: tutto il resto

L'uscita END-TO-END è un'uscita in modo tale che: per ogni L, il livello (L) soddisfa i suoi requisiti solo dalle funzioni Funzione (L, j) (ovvero funzioni all'interno del livello) e Interfaccia (L, L + 1), Interfaccia (L + 1, L)

Per ogni strato L e funzione Funzione (L, F) non esiste un insieme di funzioni S nell'uscita in modo tale che Funzione (L, F) = S (= significa uscita equivalente ed effetti collaterali)

Quindi, arrivando al secondo possibile difetto per l'applicazione specifica del principio e2e (e se sto leggendo correttamente cosa si sta tentando) si può affermare che non segue affatto il principio e2e, al contrario. Hai i tuoi chip che forniscono "un po 'di evitamento del deadlock" e hai un'interfaccia fuori dal comune non solida e specifica per innescare (interrompere) un maggiore aiuto dai livelli superiori. Questo è probabilmente un approccio a più livelli non un approccio end-to-end. In altre parole, hai una funzione (1, x) che non svolge il suo compito in modo completo e corretto con le interfacce impostate - se vuoi usare la bozza di formalizzazione fornita sopra (che ovviamente è solo un inizio utile in misura per rispondere pienamente alla tua domanda ma probabilmente non è pieno in sé).