El principio de extremo a extremo es un marco de diseño en redes informáticas . En las redes diseñadas de acuerdo con este principio, las características específicas de la aplicación residen en los nodos finales comunicantes de la red, en lugar de en los nodos intermediarios, como puertas de enlace y enrutadores , que existen para establecer la red.
La esencia de lo que más tarde se llamaría el principio de extremo a extremo estaba contenida en el trabajo de Paul Baran y Donald Davies sobre redes de conmutación de paquetes en la década de 1960. Louis Pouzin fue pionero en el uso de la estrategia de extremo a extremo en la red CYCLADES en la década de 1970. [1] El principio fue articulado explícitamente por primera vez en 1981 por Saltzer , Reed y Clark . [2] [nb 1]El significado del principio de extremo a extremo se ha reinterpretado continuamente desde su articulación inicial. Además, se pueden encontrar formulaciones notables del principio de extremo a extremo antes del artículo seminal de 1981 de Saltzer, Reed y Clark. [3]
Una premisa básica del principio es que los beneficios de agregar características a una red simple disminuyen rápidamente, especialmente en los casos en los que los hosts finales tienen que implementar esas funciones solo por razones de conformidad, es decir, integridad y corrección basadas en una especificación. [nb 2] La implementación de una función específica incurre en algunas penalizaciones de recursos independientemente de si la función se utiliza o no, y la implementación de una función específica en la red distribuye estas penalizaciones entre todos los clientes.
Concepto
La noción fundamental detrás del principio de extremo a extremo es que para dos procesos que se comunican entre sí a través de algún medio de comunicación, no se puede esperar que la confiabilidad obtenida de ese medio esté perfectamente alineada con los requisitos de confiabilidad de los procesos. En particular, cumplir o superar los requisitos de muy alta confiabilidad de los procesos de comunicación separados por redes de tamaño no trivial es más costoso que obtener el grado requerido de confiabilidad mediante reconocimientos y retransmisiones positivos de extremo a extremo (denominados PAR o ARQ ). [nb 3] Dicho de otra manera, es mucho más fácil obtener confiabilidad más allá de un cierto margen mediante mecanismos en los hosts finales de una red que en los nodos intermediarios , [nb 4] especialmente cuando estos últimos están fuera del control de, y no responsable ante el primero. [nb 5] Los reconocimientos positivos de extremo a extremo con reintentos infinitos pueden obtener una confiabilidad arbitrariamente alta de cualquier red con una probabilidad superior a cero de transmitir datos con éxito de un extremo a otro. [nb 6]
El principio de extremo a extremo no se extiende trivialmente a funciones más allá del control y la corrección de errores de extremo a extremo. Por ejemplo, no se pueden hacer argumentos sencillos de un extremo a otro para los parámetros de comunicación como la latencia y el rendimiento . En un artículo de 2001, Blumenthal y Clark señalan: "[Desde el principio, los argumentos de un extremo a otro giraban en torno a requisitos que podrían implementarse correctamente en los puntos finales; si la implementación dentro de la red es la única forma de cumplir con el requisito , entonces un argumento de extremo a extremo no es apropiado en primer lugar ". [7] : 80
El principio de extremo a extremo está estrechamente relacionado y, a veces, se considera un precursor directo del principio de neutralidad de la red . [8]
Historia
En la década de 1960, Paul Baran y Donald Davies , en sus elaboraciones de redes previas a ARPANET , hicieron breves comentarios sobre la confiabilidad que capturan la esencia del principio de extremo a extremo posterior. Para citar un artículo de Baran de 1964, "la confiabilidad y las tasas de error en bruto son secundarias. La red debe construirse con la expectativa de daños importantes de todos modos. Existen métodos poderosos de eliminación de errores". [9] : 5 De manera similar, Davies señala sobre el control de errores de un extremo a otro: "Se cree que todos los usuarios de la red se proporcionarán algún tipo de control de errores y que sin dificultad se podría hacer que esto muestre una falta paquete. Debido a esto, la pérdida de paquetes, si es lo suficientemente rara, puede tolerarse ". [10] : 2,3
ARPANET fue la primera red de conmutación de paquetes de propósito general a gran escala, que implementó varias de las nociones básicas mencionadas anteriormente por Baran y Davies.
Davies había trabajado en la simulación de redes de datagramas . [11] [12] Sobre la base de esta idea, la red CYCLADES de Louis Pouzin fue la primera en hacer que los hosts fueran responsables de la entrega confiable de datos, en lugar de ser un servicio centralizado de la propia red. [1] Los conceptos de esta red influyeron en la arquitectura ARPANET posterior.
Aplicaciones
ARPANET
ARPANET demostró varios aspectos importantes del principio de extremo a extremo.
- La conmutación de paquetes empuja algunas funciones lógicas hacia los puntos finales de comunicación
- Si la premisa básica de una red distribuida es la conmutación de paquetes, entonces funciones como el reordenamiento y la detección de duplicados deben implementarse inevitablemente en los puntos finales lógicos de dicha red. En consecuencia, ARPANET presentaba dos niveles distintos de funcionalidad:
- un nivel inferior relacionado con el transporte de paquetes de datos entre los nodos de red vecinos (llamados procesadores de mensajes de interfaz o IMP), y
- un nivel superior relacionado con varios aspectos de un extremo a otro de la transmisión de datos. [nb 7]
- Dave Clark, uno de los autores del artículo del principio de extremo a extremo, concluye: "El descubrimiento de paquetes no es una consecuencia del argumento de extremo a extremo. Es el éxito de los paquetes lo que hace que el final del argumento relevante ". [15] : diapositiva 31
- Sin transferencia de datos arbitrariamente confiable sin mecanismos de reconocimiento y retransmisión de extremo a extremo
- ARPANET fue diseñado para proporcionar un transporte de datos confiable entre dos puntos finales de la red, como un simple canal de E / S entre una computadora y un dispositivo periférico cercano. [nb 8] Con el fin de remediar cualquier falla potencial en la transmisión de paquetes, los mensajes ARPANET normales fueron entregados de un nodo al siguiente nodo con un esquema de reconocimiento y retransmisión positivo; después de un traspaso exitoso, fueron descartados, [nb 9] no se atendió ninguna retransmisión de origen a destino en caso de pérdida de paquetes. Sin embargo, a pesar de los esfuerzos significativos, resultó imposible proporcionar una confiabilidad perfecta como se preveía en la especificación inicial de ARPANET, una realidad que se hizo cada vez más obvia una vez que ARPANET creció mucho más allá de su topología inicial de cuatro nodos. [nb 10] ARPANET proporcionó un caso sólido para los límites inherentes de los mecanismos de confiabilidad salto a salto basados en la red en busca de una verdadera confiabilidad de extremo a extremo. [nb 11]
- Compensación entre confiabilidad, latencia y rendimiento
- La búsqueda de una confiabilidad perfecta puede dañar otros parámetros relevantes de una transmisión de datos, principalmente la latencia y el rendimiento. Esto es particularmente importante para las aplicaciones que valoran el rendimiento predecible y la baja latencia sobre la confiabilidad; el ejemplo clásico son las aplicaciones de voz interactivas en tiempo real. Este caso de uso fue atendido en ARPANET al proporcionar un servicio de mensajes sin procesar que prescindió de varias medidas de confiabilidad para brindar un servicio de transmisión de datos de latencia más rápida y baja a los hosts finales. [nb 12]
TCP / IP
El Protocolo de Internet (IP) es un servicio de datagramas sin conexión sin garantías de entrega . En Internet, la IP se utiliza para casi todas las comunicaciones. El acuse de recibo y la retransmisión de extremo a extremo son responsabilidad del Protocolo de control de transmisión (TCP) orientado a la conexión, que se encuentra en la parte superior de IP. La división funcional entre IP y TCP ejemplifica la aplicación adecuada del principio de extremo a extremo al diseño del protocolo de transporte.
Transferencia de archivos
Un ejemplo del principio de extremo a extremo es el de una transferencia de archivos arbitrariamente confiable entre dos puntos finales en una red distribuida de un tamaño variable y no trivial: [3] La única forma en que dos puntos finales pueden obtener una transferencia completamente confiable es transmitiendo y reconocer una suma de comprobación para todo el flujo de datos; en tal configuración, los protocolos de suma de comprobación y reconocimiento ( ACK / NACK) menores se justifican solo con el propósito de optimizar el rendimiento; son útiles para la gran mayoría de los clientes, pero no son suficientes para cumplir con el requisito de confiabilidad de esta aplicación en particular. Por lo tanto, es mejor realizar una suma de comprobación exhaustiva en los puntos finales, y la red mantiene un nivel relativamente bajo de complejidad y un rendimiento razonable para todos los clientes. [3]
Limitaciones
La limitación más importante del principio de extremo a extremo es que su premisa básica, colocar funciones en los puntos finales de la aplicación en lugar de en los nodos intermediarios, no es trivial de implementar.
Un ejemplo de las limitaciones del principio de extremo a extremo existe en los dispositivos móviles, por ejemplo, con IPv6 móvil . [23] Llevar la complejidad específica del servicio a los puntos finales puede causar problemas con los dispositivos móviles si el dispositivo tiene un acceso no confiable a los canales de la red. [24]
Se pueden ver más problemas con una disminución en la transparencia de la red debido a la adición de la traducción de direcciones de red (NAT), en la que se basa IPv4 para combatir el agotamiento de las direcciones . [25] Con la introducción de IPv6 , los usuarios vuelven a tener identificadores únicos, lo que permite una verdadera conectividad de extremo a extremo. Los identificadores únicos pueden basarse en una dirección física o pueden ser generados aleatoriamente por el anfitrión. [26]
Ver también
- De igual a igual
Notas
- ^ El artículo de 1981 [2] se publicó en el TOCS de ACM en una versión actualizada en 1984. [3] [4]
- ^ La cita completa del artículo de Saltzer, Reed, Clark dice: [3] "En un sistema que incluye comunicaciones, generalmente se dibuja un límite modular alrededor del subsistema de comunicación y se define una interfaz firme entre este y el resto del sistema. Cuando Al hacerlo, se hace evidente que hay una lista de funciones, cada una de las cuales podría implementarse de varias formas: por el subsistema de comunicaciones, por su cliente, como una empresa conjunta, o quizás de forma redundante, cada una haciendo su propia versión. Al razonar sobre esta elección, los requisitos de la aplicación proporcionan la base para la siguiente clase de argumentos: La función en cuestión puede implementarse 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. Por lo tanto, proporcionar esa función cuestionada como una característica del sistema de comunicación en sí no es posible y, además, produce una penalización de rendimiento para todos los clientes del sistema de comunicación (Som 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. A esta línea de razonamiento contra la implementación de funciones de bajo nivel la llamamos argumento de extremo a extremo ". (pág.278).
- ^ De hecho, incluso en las redes de área local existe una probabilidad distinta de cero de falla de comunicación: "se requiere atención a la confiabilidad en niveles más altos independientemente de la estrategia de control de la red". [5]
- ^ Dicho en términos económicos, el costo marginal de la confiabilidad adicional en la red excede el costo marginal de obtener la misma confiabilidad adicional por medidas en los hosts finales. El nivel económicamente eficiente de mejora de la confiabilidad dentro de la red depende de las circunstancias específicas; sin embargo, ciertamente no se acerca a cero: [3] "Claramente, algún esfuerzo en los niveles más bajos para mejorar la confiabilidad de la red puede tener un efecto significativo en el rendimiento de la aplicación (p. 281)".
- ^ No obstante la posibilidad de recursos contractuales exigibles, es imposible que cualquier red en la que se compartan recursos intermediarios de forma no determinista garantice una fiabilidad perfecta. A lo sumo, puede citar promedios estadísticos de desempeño.
- ^ Más precisamente: [6] "THM 1: Un protocolo PAR que funciona correctamente con un número de reintentos infinito nunca deja de entregar, pierde o duplica mensajes. COR 1A: Un protocolo PAR que funciona correctamente con un número de reintentos finito nunca pierde ni duplica mensajes, y el remitente puede reducir arbitrariamente la probabilidad de no entregar un mensaje ". (pág. 3).
- ^ De acuerdo con ARPANET RFQ [13] (págs. 47 y sig.), ARPANET separó conceptualmente ciertas funciones. Como señala BBN en un artículo de 1977: [14] "[L] a implementación de la red ARPA utiliza la técnica de dividir los mensajes en paquetes para minimizar el retraso visto en las transmisiones largas en muchos saltos. La implementación de la red ARPA también permite que varios mensajes sean en tránsito simultáneamente entre un par dado de hosts. Sin embargo, los varios mensajes y los paquetes dentro de los mensajes pueden llegar al IMP de destino fuera de servicio, y en el caso de un IMP o línea rota, puede haber duplicados. El procedimiento de transmisión de origen a destino de la red ARPA consiste en reordenar los paquetes y mensajes en su destino, eliminar los duplicados y, una vez que hayan llegado todos los paquetes de un mensaje, pasar el mensaje al host de destino y devolver un finalice el reconocimiento (pág. 284) ".
- ^ Este requisito se detalla en la RFQ de ARPANET, "Desde el punto de vista de los contratistas de ARPA como usuarios de la red, la subred de comunicación es una instalación autónoma cuyo software y hardware es mantenido por el contratista de la red. En el diseño de la interconexión Software que solo deberíamos necesitar utilizar las convenciones de E / 0 para mover datos dentro y fuera de la subred y no estar involucrados en los detalles de la operación de la subred. Específicamente, verificación de errores, detección de fallas, conmutación de mensajes, recuperación de fallas, conmutación de línea, las fallas del operador y la evaluación de la calidad del operador, según se requiera para garantizar un rendimiento confiable de la red, son responsabilidad exclusiva del contratista de la red ". [13] : 25
- ^ Señala Walden en un artículo de 1972, "Cada IMP retiene un paquete hasta que recibe un reconocimiento positivo del siguiente IMP en la línea de que el paquete se ha recibido correctamente. Si recibe el reconocimiento, todo está bien; el IMP sabe que el próximo IMP ahora tiene la responsabilidad del paquete y el IMP transmisor puede descartar su copia del paquete ". [16] : 11
- ^ En 1973, BBN reconoció que el objetivo inicial de una confiabilidad perfecta dentro de ARPANET no era alcanzable. "Inicialmente, se pensó que los únicos componentes en el diseño de la red que eran propensos a errores eran los circuitos de comunicaciones y las interfaces del módem en el Los IMP están equipados con una suma de comprobación CRC para detectar "casi todos" esos errores. El resto del sistema, incluidas las interfaces de host, los procesadores de IMP, las memorias y las interfaces, se consideraron libres de errores. Hemos tenido que volver a evaluar esta posición a la luz de nuestra experiencia. [17] : 1 De hecho, como resume Metcalfe en 1973, "ha habido suficientes bits en error en ARPANET para llenar esta cuota [un error de transmisión no detectado por año] durante siglos. " [18] : 7–28 Ver también Informe BBN 2816 [19] : 10 y siguientes para una elaboración adicional sobre las experiencias adquiridas en los primeros años de funcionamiento de ARPANET.
- ^ Incidentalmente, ARPANET también proporciona un buen caso para las compensaciones entre el costo de los mecanismos de confiabilidad de un extremo a otro y los beneficios que se obtienen así. Tenga en cuenta que los verdaderos mecanismos de confiabilidad de extremo a extremo habrían sido prohibitivamente costosos en ese momento, dado que la especificación sostenía que podría haber hasta 8 mensajes a nivel de host en vuelo al mismo tiempo entre dos puntos extremos, cada uno con un máximo de más de 8000 bits. La cantidad de memoria que se habría requerido para guardar copias de todos esos datos para una posible retransmisión en caso de que no llegara un acuse de recibo del IMP de destino era demasiado cara para que valiera la pena. En cuanto a los mecanismos de confiabilidad de extremo a extremo basados en host, estos habrían agregado una complejidad considerable al protocolo de nivel de host común (Protocolo de host-host ). Si bien la conveniencia de los mecanismos de confiabilidad host-host se articuló en RFC 1 , después de alguna discusión se prescindió de ellos (aunque los protocolos o aplicaciones de nivel superior eran, por supuesto, libres de implementar dichos mecanismos por sí mismos). Para un recuento del debate en ese momento, véase Bärwolff 2010, [20] págs. 56-58 y las notas allíincluidas, especialmente las notas 151 y 163.
- ↑ Los primeros experimentos con paquetes de voz se remontan a 1971, y en 1972 se inició una investigación más formal de ARPA sobre el tema. Como se documenta en RFC 660 (p. 2), [21] en 1974 BBN introdujo el servicio de mensajes en bruto (Raw Message Interface, RMI) en ARPANET, principalmente para permitir que los hosts experimenten con aplicaciones de voz en paquetes, pero también reconociendo el uso de tales facilidad en vista de una posible comunicación entre redes (véase un Informe BBN 2913 [22] en las págs. 55 y sig.). Véase también Bärwolff 2010, [20] págs. 80-84 y las abundantes notas que contiene.
Referencias
- ^ a b Bennett, Richard (septiembre de 2009). "Diseñado para el cambio: argumentos de extremo a extremo, innovación en Internet y el debate sobre la neutralidad de la red" (PDF) . Fundación Tecnología de la Información e Innovación. págs. 7, 11 . Consultado el 11 de septiembre de 2017 .
- ^ a b Saltzer, JH, DP Reed y DD Clark (1981) "Argumentos de extremo a extremo en el diseño de sistemas". En: Actas de la Segunda Conferencia Internacional sobre Sistemas de Computación Distribuida. París, Francia. 8-10 de abril de 1981. IEEE Computer Society, págs. 509-512.
- ^ a b c d e f Saltzer, JH, DP Reed y DD Clark (1984) "Argumentos de extremo a extremo en el diseño de sistemas". En: ACM Transactions on Computer Systems 2.4, págs. 277-288. (Consulte también aquí para obtener una versión de la página de inicio del MIT de Saltzer).
- ^ Saltzer, JH (1980). Argumentos de extremo a extremo en el diseño de sistemas. Solicitud de comentarios No. 185, Laboratorio de Ciencias de la Computación del MIT, División de Investigación de Sistemas Computacionales. ( Copia en línea ).
- ^ Clark, DD, KT Pogran y DP Reed (1978). “Introducción a las redes de área local”. En: Proceedings of the IEEE 66.11, págs. 1497-1517.
- ^ Sol, CA (1975). Problemas en el diseño de protocolos de comunicación: corrección formal. Sequía. Protocolo INWG Nota 5. IFIP WG 6.1 (INWG). ( Copia de CBI ).
- ^ Blumenthal, MS y DD Clark (2001). "Repensar el diseño de Internet: los argumentos de un extremo a otro frente al mundo valiente". En: ACM Transactions on Internet Technology 1.1, págs. 70–109. ( Versión de prepublicación online ).
- ^ Alexis C. Madrigal y Adrienne LaFrance (25 de abril de 2014). "Neutralidad de la red: una guía (y la historia) de una idea impugnada" . El Atlántico . Consultado el 5 de junio de 2014 .
Esta idea de neutralidad de la red ... [Lawrence Lessig] solía llamar al principio e2e, de extremo a extremo
- ^ Baran, P. (1964). "Sobre redes de comunicaciones distribuidas". En: IEEE Transactions on Communications 12.1, págs. 1–9.
- ^ Davies, DW, KA Bartlett, RA Scantlebury y PT Wilkinson (1967). "Una red de comunicación digital para computadoras que brindan una respuesta rápida en terminales remotos". En: SOSP '67: Actas del primer simposio de ACM sobre principios de sistemas operativos. Gatlinburg, TN. 1 al 4 de octubre de 1967. Nueva York, NY: ACM, págs. 2.1–2.17.
- ^ C. Hempstead; W. Worthington (2005). Enciclopedia de la tecnología del siglo XX . Routledge . ISBN 9781135455514.
El grupo NPL también realizó trabajos de simulación en redes de paquetes.
- ^ Pelkey, James. "6.3 CYCLADES Network y Louis Pouzin 1971-1972". Capitalismo e innovación empresarial: una historia de las comunicaciones por computadora 1968-1988 .
Había hecho alguna simulación de redes de datagramas, aunque no había construido ninguna, y parecía técnicamente viable.
- ^ a b Scheblik, TJ, DB Dawkins y Agencia de proyectos de investigación avanzada (1968). RFQ para ARPA Computer Network. Solicitud de cotizaciones. Agencia de Proyectos de Investigación Avanzada (ARPA), Departamento de Defensa (DoD). ( Copia en línea archivada el 15 de agosto de 2011 en Wayback Machine ).
- ^ McQuillan, JM y DC Walden (1977). "Las decisiones de diseño de la red ARPA". En: Computer Networks 1.5, págs. 243–289. ( Copia en línea ). Basado en Crowther et al. (1975), que se basa en el Informe BBN 2918, que a su vez es un extracto del Informe BBN 2913, ambos de 1974.
- ^ Clark, DD (2007). Diseño de aplicaciones y argumentos de principio a fin. Reunión semestral del Programa de Futuros de Comunicaciones del MIT. Filadelfia, PA. 30 al 31 de mayo de 2007. Diapositivas de presentación. ( Copia en línea ).
- ^ Walden, DC (1972). "El procesador de mensajes de la interfaz, sus algoritmos y su implementación". En: AFCET Journées d'Études: Réseaux de Calculateurs (Taller AFCET sobre redes informáticas). París, Francia. 25-26 de mayo de 1972. Association Française pour la Cybernétique Économique et Technique (AFCET). ( Copia en línea ).
- ^ McQuillan, JM (1973). Suma de verificación de software en el IMP y la confiabilidad de la red. RFC 528 . Histórico. NWG.
- ^ Metcalfe, RM (1973). "Comunicación por paquetes". Tesis doctoral. Cambridge, MA: Universidad de Harvard. Copia en línea (edición revisada, publicada como MIT Laboratory for Computer Science Technical Report 114). Principalmente escrito en MIT Project MAC y Xerox PARC.
- ^ Bolt, Beranek y Newman Inc. (1974). Procesadores de mensajes de interfaz para Arpa Computer Network. Informe BBN 2816. Informe técnico trimestral n. ° 5, 1 de enero de 1974 al 31 de marzo de 1974. Bolt, Beranek y Newman Inc. (BBN). ( Copia privada, cortesía de BBN ).
- ↑ a b Bärwolff, M. (2010). "Argumentos de extremo a extremo en Internet: principios, prácticas y teoría". Publicación propia en línea y a través de Createspace / Amazon ( PDF, erratas, etc. )
- ^ Walden, DC (1974) Algunos cambios en el IMP y la interfaz IMP / Host. RFC 660 . Histórico. NWG.
- ^ BBN (1974). Procesadores de mensajes de interfaz para Arpa Computer Network. Informe BBN 2913. Informe técnico trimestral núm. 7, del 1 de julio de 1974 al 30 de septiembre de 1974. Bolt, Beranek y Newman Inc. (BBN).
- ^ J. Kempf; R. Austein (marzo de 2004). El auge del medio y el futuro de un extremo a otro: reflexiones sobre la evolución de la arquitectura de Internet . Grupo de trabajo en red, IETF . doi : 10.17487 / RFC3724 . RFC 3724 .
- ^ "Arquitectura del Protocolo CNF" . Proyectos de enfoque . Winlab, Universidad de Rutgers . Consultado el 23 de mayo de 2016 .
- ^ Ward, Mark (14 de septiembre de 2012). "Europa alcanza los viejos límites de direcciones de Internet" . BBC News . Consultado el 28 de febrero de 2017 .
- ^ Steve Deering y Bob Hinden, Copresidentes del Grupo de Trabajo de IP Next Generation del IETF (6 de noviembre de 1999). "Declaración sobre la privacidad de la dirección IPv6" . Consultado el 28 de febrero de 2017 .