A fines de la década de 1990, cuando estaba en la escuela de posgrado, el periódico
JH Saltzer; DP Reed; DD Clark: argumentos de extremo a extremo en el diseño del sistema . ACM Trans. Comput Syst. 2 (4): 277-288, 1984. DOI = 10.1145 / 357401.357402
era bastante necesario leer en todas las clases de sistemas operativos en todas las universidades, y todavía parece ser uno de los principios rectores principales que subyacen en el diseño de Internet. (Véase, por ejemplo: J Kempf, R Austein (eds), y el IAB, " The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture ", RFC 3724, marzo de 2004. )
El principio de principio a fin establece (Saltzer et al., 1984):
[Si] la función en cuestión se puede implementar completa y correctamente solo con el conocimiento y la ayuda de la aplicación que se encuentra en los puntos finales del sistema de comunicación, ..., siempre que esa función cuestionada como una característica del sistema de comunicación en sí no posible. [Aunque] a veces una versión incompleta de la función proporcionada por el sistema de comunicación puede ser útil como una mejora del rendimiento.
O más brevemente (del resumen):
El argumento de extremo a extremo sugiere que las funciones ubicadas en niveles bajos de un sistema pueden ser redundantes o de poco valor en comparación con el costo de proporcionarlas en ese nivel bajo.
Pero he tenido poco éxito aplicando el principio de principio a fin en mi propia experiencia (que es en la arquitectura de computadoras, no en la arquitectura de Internet). Dado que el principio se declara como un "poema" (es decir, en prosa en inglés con un montón de términos que no están matemáticamente definidos) es bastante fácil engañarse a sí mismo al pensar que "la función en cuestión solo se puede implementar completa y correctamente con el conocimiento y la ayuda de la aplicación ". Pero, ¿cuál es "la función en cuestión", y mucho menos "el conocimiento y la ayuda" de una aplicación?
Ejemplo: las redes en chip (a diferencia de Internet) no pueden soltar paquetes, pero tienen un almacenamiento en búfer bastante limitado, por lo que debe tener alguna forma de evitar o recuperarse del punto muerto. Por otro lado, la aplicación también necesita liberarse del punto muerto, ¿verdad? Por lo tanto, podría razonar que debería hacer que el caso común (sin punto muerto) sea rápido y alejar la evitación del punto muerto en la aplicación. Esto es, de hecho, lo que probamos en Alewife y Fugu (Mackenzie, et al., Explotación de la entrega en dos casos para mensajería rápida protegida , Int'l Symp High-Perf Comp Arch, (HPCA-4): 231-242, 1998. O la disertación de John Kubiatowicz.) "Funcionó" (al hacer que la interconexión interrumpa el procesador cuando se llenaron los búferes y que el sistema operativo aumente con el almacenamiento en búfer de software) pero no he visto a nadie en la academia o la industria (incluidos ninguno de nosotros que fuimos autores en ese Papel HPCA) corriendo tratando de replicar la idea. Así que, aparentemente, evitar el punto muerto en una red no es la misma "función en cuestión" que evitar el punto muerto a nivel de aplicación, o el principio de principio a fin es incorrecto.
¿Es posible convertir el principio de principio a fin de un "poema" en un teorema? O al menos, ¿puede expresarse en términos comprensibles para un arquitecto informático?
Respuestas:
Creo que puede haber dos deficiencias en su aplicación del principio de extremo a extremo (e2e):
En primer lugar, en el sentido de que lo aplicas para el rendimiento. El principio a fin es un principio de diseño que garantiza la ortogonalidad de la arquitectura, la compostibilidad, la regularidad, una o todas, proporciona primitivas, etc. Tales principios se han esbozado en libros de texto relacionados. El rendimiento no es uno de ellos. De hecho, Clark et al, implica que un estricto extremo a extremo puede dar lugar a un peor rendimiento, por lo que utiliza tal, como una excepción a este principio.
Entonces, si aún quieres formalizar:
"El argumento de extremo a extremo apela a los requisitos de la aplicación y proporciona una justificación para mover la función hacia arriba en un sistema en capas", por lo que necesitará requisitos de aplicación formalizados y un sistema en capas formalizado. Aquí hay un intento que podría ayudar a llevarlo un paso más allá:
Supongamos que tiene requisitos de Capa (i) (La capa (0) es para el conjunto de aplicaciones que espera admitir ahora o en el futuro, la capa de aplicación) y las interfaces firmes Interfaz (i, i + 1) e Interfaz (i + 1 , i) (de la Capa i a i + 1, supongamos que no hay capas cruzadas aquí, fácil de cambiar y que sea un requisito) y funciones Función (i, j) (Capa i, Índice de función j, asume que los datos son parte de la función para que sea más simple)
Entrada: Requisitos de capa (0) (como dijimos, estos deben formalizarse)
Salida: todo lo demás
La salida END-TO-END es una salida tal que: para cada L, la capa (L) cumple sus requisitos solo mediante las funciones Función (L, j) (es decir, funciones dentro de la capa) e Interfaz (L, L + 1), Interfaz (L + 1, L)
Para cada Capa L y Función Función (L, F) no hay un conjunto de Funciones S en la salida de manera que la Función (L, F) = S (= significa salida equivalente y efectos secundarios)
Entonces, llegando a la segunda posible deficiencia para la aplicación específica del principio e2e (y si estoy leyendo correctamente lo que se está intentando), uno puede afirmar que no sigue el principio e2e, sino todo lo contrario. Tiene sus chips que proporcionan "un poco de evitación de punto muerto" y tiene una interfaz que es fuera de lo común, no firme y específica para activar (interrumpir) más ayuda de las capas superiores. Este es posiblemente un enfoque de capa cruzada, no un enfoque de extremo a extremo. En otras palabras, tiene una función (1, x) que no cumple su tarea completa y correctamente con las interfaces configuradas, si desea utilizar el borrador de formalización proporcionado anteriormente (que por supuesto es solo un comienzo útil para una extensión para responder completamente a su pregunta pero probablemente no completo en sí mismo).
fuente