stringtranslate.com

Principio de extremo a extremo

El principio de extremo a extremo es un marco de diseño en redes informáticas . En redes diseñadas según este principio, garantizar ciertas características específicas de la aplicación, como la confiabilidad y la seguridad, requiere que residan en los nodos finales comunicantes de la red. Los nodos intermediarios, como las puertas de enlace y los enrutadores , que existen para establecer la red, pueden implementarlas para mejorar la eficiencia, pero no pueden garantizar la corrección de extremo a extremo.

La esencia de lo que más tarde se llamaría el principio de extremo a extremo estaba contenida en el trabajo de 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] [a] El significado del principio de extremo a extremo ha sido 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 Saltzer, Reed y Clark de 1981. [3]

Una premisa básica del principio es que los beneficios de agregar ciertas características requeridas por la aplicación final al subsistema de comunicación disminuyen rápidamente. Los hosts finales tienen que implementar estas funciones para que funcionen correctamente. [b] La implementación de una función específica implica 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 agrega estas penalizaciones a todos los clientes, ya sea que necesiten la función o no.

Concepto

Según el principio de extremo a extremo, la red solo es responsable de proporcionar a los terminales conexiones de máximo esfuerzo. Las características como la confiabilidad y la seguridad deben ser proporcionadas por mecanismos y protocolos ubicados en los terminales.

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 a partir de ese medio esté perfectamente alineada con los requisitos de confiabilidad de los procesos. En particular, cumplir o superar los requisitos de confiabilidad muy altos de los procesos que se comunican 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 ). [c] 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 en lugar de en los nodos intermedios , [d] especialmente cuando estos últimos están fuera del control de los primeros y no son responsables ante ellos. [e] Los reconocimientos positivos de extremo a extremo con reintentos infinitos pueden obtener una confiabilidad arbitrariamente alta de cualquier red con una probabilidad mayor que cero de transmitir datos exitosamente de un extremo a otro. [f]

El principio de extremo a extremo no se extiende a funciones que van más allá del control y la corrección de errores de extremo a extremo y la seguridad. Por ejemplo, no se pueden hacer argumentos de extremo a extremo directos para 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 extremo a extremo giraban en torno a requisitos que se podían implementar correctamente en los puntos finales; si la implementación dentro de la red es la única forma de cumplir 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 los años 60, Paul Baran y Donald Davies , en sus elaboraciones de redes previas a ARPANET , hicieron comentarios sobre la confiabilidad. El artículo de Baran de 1964 afirma: "La confiabilidad y las tasas de error bruto son secundarias. La red debe construirse con la expectativa de que se produzcan daños importantes de todos modos. Existen métodos poderosos de eliminación de errores". [9] : 5  Yendo más allá, Davies captó la esencia del principio de extremo a extremo; en su artículo de 1967, afirmó que los usuarios de la red se proporcionarán a sí mismos un control de errores: "Se cree que todos los usuarios de la red se proporcionarán a sí mismos algún tipo de control de errores y que sin dificultad se podría hacer que esto muestre un paquete faltante. Debido a esto, la pérdida de paquetes, si es lo suficientemente rara, se puede tolerar". [10] : 2.3 

ARPANET fue la primera red de conmutación de paquetes de propósito general a gran escala, que implementó varios de los conceptos articulados previamente por Baran y Davies. [11] [12]

Davies construyó una red de área local con un único conmutador de paquetes y trabajó en la simulación de redes de datagramas de área amplia . [13] [14] [15] Basándose en estas ideas y buscando mejorar la implementación en ARPANET, [15] la red CYCLADES de Louis Pouzin fue la primera en implementar datagramas en una red de área amplia y hacer que los hosts fueran responsables de la entrega confiable de datos, en lugar de que este sea un servicio centralizado de la red en sí. [1] Los conceptos implementados en esta red se incluyen en la arquitectura TCP/IP . [16]

Aplicaciones

ARPANET

ARPANET demostró varios aspectos importantes del principio de extremo a extremo.

La conmutación de paquetes impulsa 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 la reordenación y la detección de duplicados inevitablemente deben implementarse en los puntos finales lógicos de dicha red. En consecuencia, ARPANET presentaba dos niveles distintos de funcionalidad:
  1. un nivel inferior encargado de transportar paquetes de datos entre nodos de red vecinos (llamados procesadores de mensajes de interfaz o IMP), y
  2. un nivel superior que se ocupa de diversos aspectos de extremo a extremo de la transmisión de datos. [g]
Dave Clark, uno de los autores del artículo sobre el 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 argumento de extremo a extremo sea relevante". [19] : diapositiva 31 
No es posible una transferencia de datos arbitrariamente confiable sin mecanismos de reconocimiento y retransmisión de extremo a extremo
ARPANET fue diseñada para proporcionar un transporte de datos confiable entre dos puntos finales de la red, de manera muy similar a un simple canal de E/S entre una computadora y un dispositivo periférico cercano. [h] Para remediar cualquier falla potencial en la transmisión de paquetes, los mensajes normales de ARPANET se enviaban de un nodo al siguiente con un esquema de reconocimiento y retransmisión positivo; luego de una transferencia exitosa, se descartaban. [i] No se preveía una retransmisión de origen a destino en caso de pérdida de paquetes. Sin embargo, a pesar de los esfuerzos significativos, la confiabilidad perfecta prevista en la especificación inicial de ARPANET resultó imposible de proporcionar, 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. [j] ARPANET proporcionó así un argumento sólido para los límites inherentes de los mecanismos de confiabilidad salto a salto basados ​​en la red en la búsqueda de una verdadera confiabilidad de extremo a extremo. [k]
Compensación entre confiabilidad, latencia y rendimiento
La búsqueda de una fiabilidad perfecta puede perjudicar otros parámetros relevantes de una transmisión de datos, sobre todo la latencia y el rendimiento. Esto es particularmente importante para aplicaciones que valoran el rendimiento predecible y la baja latencia por encima de la fiabilidad; el ejemplo clásico son las aplicaciones de voz interactivas en tiempo real. Este caso de uso se atendió en ARPANET proporcionando un servicio de mensajes sin procesar que prescindía de varias medidas de fiabilidad para proporcionar un servicio de transmisión de datos más rápido y con menor latencia a los hosts finales. [l]

Protocolo TCP/IP

El Protocolo de Internet (IP) es un servicio de datagramas sin conexión y sin garantías de entrega . En Internet, el IP se utiliza para casi todas las comunicaciones. El reconocimiento 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 sobre el IP. La división funcional entre IP y TCP ejemplifica la aplicación adecuada del principio de extremo a extremo al diseño de protocolos 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 reconociendo una suma de comprobación para todo el flujo de datos; en tal situación, los protocolos de suma de comprobación y reconocimiento menores ( ACK /NACK) 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 completa 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 intermedios, no es fácil 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 . [27] Llevar la complejidad específica del servicio a los puntos finales puede causar problemas con los dispositivos móviles si el dispositivo tiene acceso no confiable a los canales de red. [28]

Se pueden observar más problemas con una disminución en la transparencia de la red debido a la incorporación de la traducción de direcciones de red (NAT), en la que se basa IPv4 para combatir el agotamiento de direcciones . [29] 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 host. [30]

El principio de extremo a extremo aboga por llevar la funcionalidad relacionada con la coordinación cada vez más arriba, en última instancia, a la capa de aplicación. La premisa es que la información a nivel de aplicación permite una coordinación flexible entre los puntos finales de la aplicación y produce un mejor rendimiento porque la coordinación sería exactamente la que se necesita. Esto conduce a la idea de modelar cada aplicación a través de su propio protocolo específico de aplicación que admita la coordinación deseada entre sus puntos finales mientras se supone solo un servicio de comunicación de capa inferior simple. En términos generales, esta idea se conoce como semántica de aplicación (significado).

Los sistemas multiagente ofrecen enfoques basados ​​en la semántica de aplicaciones que permiten implementar cómodamente aplicaciones distribuidas sin requerir garantías de ordenación y entrega de mensajes de los servicios de comunicación subyacentes. Una idea básica de estos enfoques es modelar la coordinación entre los puntos finales de la aplicación a través de un protocolo de información [31] y luego implementar los puntos finales (agentes) en función del protocolo. Los protocolos de información se pueden implementar sobre servicios de comunicación desordenados y con pérdidas. Un middleware basado en protocolos de información y el modelo de programación asociado abstrae las recepciones de mensajes de la red subyacente y permite a los programadores de puntos finales centrarse en la lógica empresarial para enviar mensajes.

Véase también

Notas

  1. ^ El artículo de 1981 [2] se publicó en el TOCS de ACM en una versión actualizada en 1984. [3] [4]
  2. ^ La cita completa del artículo de Saltzer, Reed y Clark dice: [3] "En un sistema que incluye comunicaciones, normalmente se traza un límite modular alrededor del subsistema de comunicación y se define una interfaz firme entre éste y el resto del sistema. Al hacerlo, resulta evidente que existe una lista de funciones, cada una de las cuales podría implementarse de varias maneras: por el subsistema de comunicación, por su cliente, como una empresa conjunta o quizás de manera 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 solo puede implementarse completa y correctamente 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 propio sistema de comunicación no es posible y, además, produce una penalización en el rendimiento para todos los clientes del sistema de comunicación. (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). Llamamos a esta línea de razonamiento contra la implementación de funciones de bajo nivel el argumento de extremo a extremo". (pág. 278).
  3. ^ De hecho, incluso en redes de área local existe una probabilidad distinta de cero de fallo de comunicación: "se requiere atención a la confiabilidad en niveles superiores independientemente de la estrategia de control de la red". [5]
  4. ^ Expresado en términos económicos, el costo marginal de una confiabilidad adicional en la red excede el costo marginal de obtener la misma confiabilidad adicional mediante 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 está cerca de cero: [3] "Claramente, algún esfuerzo en los niveles inferiores para mejorar la confiabilidad de la red puede tener un efecto significativo en el rendimiento de la aplicación (p. 281)".
  5. ^ A pesar de la posibilidad de recurrir a medidas contractuales exigibles, es imposible que una red en la que los recursos intermediarios se compartan de manera no determinista garantice una fiabilidad perfecta. A lo sumo, puede citar promedios estadísticos de rendimiento.
  6. ^ Más precisamente: [6] "THM 1: Un protocolo PAR que funciona correctamente con un número infinito de reintentos nunca falla en la entrega, pierde o duplica mensajes. COR 1A: Un protocolo PAR que funciona correctamente con un número finito de reintentos nunca pierde o duplica mensajes, y la probabilidad de fallar en la entrega de un mensaje puede ser hecha arbitrariamente pequeña por el remitente." (p. 3).
  7. ^ De acuerdo con la RFQ de ARPANET [17] (pp. 47 y siguientes), ARPANET separó conceptualmente ciertas funciones. Como señala BBN en un artículo de 1977: [18] "[L]a implementación de la Red ARPA utiliza la técnica de dividir los mensajes en paquetes para minimizar el retraso que se produce en transmisiones largas a lo largo de muchos saltos. La implementación de la Red ARPA también permite que varios mensajes estén en tránsito simultáneamente entre un par dado de Hosts. Sin embargo, los diversos mensajes y los paquetes dentro de los mensajes pueden llegar al IMP de destino fuera de orden y, en caso de que un IMP o una línea se interrumpa, puede haber duplicados. La tarea del procedimiento de transmisión de origen a destino de la Red ARPA es reordenar los paquetes y mensajes en su destino, eliminar los duplicados y, una vez que han llegado todos los paquetes de un mensaje, pasar el mensaje al Host de destino y devolver un acuse de recibo de extremo a extremo (p. 284)".
  8. ^ Este requisito se explicó en detalle en la RFQ de ARPANET : "Desde el punto de vista de los contratistas de ARPA como usuarios de la red, la subred de comunicaciones es una instalación autónoma cuyo software y hardware es mantenido por el contratista de la red. Al diseñar el software de interconexión, solo deberíamos necesitar usar las convenciones de E/S para mover datos dentro y fuera de la subred y no involucrarnos de otra manera en los detalles de la operación de la subred. Específicamente, la verificación de errores, la detección de fallas, la conmutación de mensajes, la recuperación de fallas, la conmutación de líneas, las fallas de la portadora y la evaluación de la calidad de la portadora, según se requiera para garantizar un rendimiento confiable de la red, son responsabilidad exclusiva del contratista de la red". [17] : 25 
  9. ^ Walden señala en un artículo de 1972: "Cada IMP retiene un paquete hasta que recibe un acuse de recibo positivo del siguiente IMP en la línea de que el paquete ha sido recibido correctamente. Si recibe el acuse de recibo, todo está bien; el IMP sabe que el siguiente IMP ahora es responsable del paquete y el IMP transmisor puede descartar su copia del paquete". [20] : 11 
  10. ^ En 1973, BBN reconoció que el objetivo inicial de una fiabilidad perfecta dentro de ARPANET no era alcanzable: "Inicialmente, se pensaba que los únicos componentes del diseño de la red que eran propensos a errores eran los circuitos de comunicaciones, y las interfaces de módem en los IMP están equipadas con una suma de comprobación CRC para detectar 'casi todos' esos errores. El resto del sistema, incluidas las interfaces del host, los procesadores IMP, las memorias y las interfaces, se consideraban libres de errores. Hemos tenido que reevaluar esta posición a la luz de nuestra experiencia". [21] : 1  De hecho, como resume Metcalfe en 1973, "ha habido suficientes bits erróneos en ARPANET para llenar esta cuota [un error de bit de transmisión no detectado por año] durante siglos". [22] : 7–28  Véase también BBN Report 2816 [23] : 10 ff  para una elaboración adicional sobre las experiencias adquiridas en los primeros años de funcionamiento de ARPANET.
  11. ^ Por cierto, ARPANET también es un buen ejemplo de la compensación entre el coste de los mecanismos de fiabilidad de extremo a extremo y los beneficios que se obtendrían de ese modo. Cabe señalar que los verdaderos mecanismos de fiabilidad de extremo a extremo habrían sido prohibitivamente costosos en su momento, dado que la especificación establecía que podía haber hasta 8 mensajes de nivel de host en circulación al mismo tiempo entre dos puntos finales, cada uno con un máximo de más de 8000 bits. La cantidad de memoria que se habría requerido para mantener copias de todos esos datos para una posible retransmisión en caso de que no viniera ningún acuse de recibo del IMP de destino era demasiado cara para que valiera la pena. En cuanto a los mecanismos de fiabilidad de extremo a extremo basados ​​en host, habrían añadido una complejidad considerable al protocolo de nivel de host común ( Protocolo Host-Host ). Si bien la conveniencia de los mecanismos de fiabilidad host-host se articuló en la RFC  1, después de algunas discusiones 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 de ese momento, véase Bärwolff 2010, [24] pp. 56-58 y las notas allí incluidas, especialmente las notas 151 y 163.
  12. ^ Los primeros experimentos con paquetes de voz datan de 1971, y en 1972 ARPA comenzó a realizar investigaciones más formales sobre el tema. Como se documenta en RFC  660 (p. 2), [25] en 1974 BBN introdujo el servicio de mensajes en bruto (Raw Message Interface, RMI) en ARPANET, principalmente para permitir que los hosts experimentaran con aplicaciones de paquetes de voz, pero también reconociendo el uso de dicha facilidad en vista de una posible comunicación entre redes (cf. un Informe BBN 2913 [26] en las pp. 55 y siguientes). Véase también Bärwolff 2010, [24] pp. 80-84 y las abundantes notas que allí se incluyen.

Referencias

  1. ^ ab Bennett, Richard (septiembre de 2009). "Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate" (PDF) . Fundación para la Tecnología de la Información y la Innovación. pp. 7, 11. Consultado el 11 de septiembre de 2017 .
  2. ^ ab 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.
  3. ^ abcdef JH Saltzer ; DP Reed ; DD Clark (1 de noviembre de 1984). "Argumentos de extremo a extremo en el diseño de sistemas" (PDF) . ACM Transactions on Computer Systems . 2 (4): 277–288. doi :10.1145/357401.357402. ISSN  0734-2071. S2CID  215746877. Wikidata  Q56503280 . Consultado el 5 de abril de 2022 .
  4. ^ Saltzer, JH (1980). Argumentos de extremo a extremo en el diseño de sistemas. Solicitud de comentarios n.º 185, Laboratorio de Ciencias de la Computación del MIT, División de Investigación de Sistemas Informáticos. (Copia en línea).
  5. ^ Clark, DD, KT Pogran y DP Reed (1978). “Introducción a las redes de área local”. En: Actas del IEEE 66.11, págs. 1497–1517.
  6. ^ Sunshine, CA (1975). Problemas en el diseño de protocolos de comunicación: corrección formal. Borrador. Nota de protocolo 5 del INWG. IFIP WG 6.1 (INWG). (Copia de CBI).
  7. ^ Blumenthal, MS y DD Clark (2001). "Replanteamiento del diseño de Internet: los argumentos de extremo a extremo frente a la teoría del mundo valiente". En: ACM Transactions on Internet Technology 1.1, págs. 70-109. (Versión previa a la publicación en línea).
  8. ^ Alexis C. Madrigal y Adrienne LaFrance (25 de abril de 2014). "Net Neutrality: A Guide to (and History of) a Contested Idea" (Neutralidad de la red: una guía para (y la historia de) una idea controvertida). The Atlantic . Consultado el 5 de junio de 2014. Esta idea de neutralidad de la red... [Lawrence Lessig] solía llamar al principio e2e, por end to end (de extremo a extremo).
  9. ^ Baran, P. (1964). "Sobre redes de comunicaciones distribuidas". En: IEEE Transactions on Communications 12.1, págs. 1–9.
  10. ^ Davies, DW, KA Bartlett, RA Scantlebury y PT Wilkinson (1967). "Una red de comunicación digital para computadoras que ofrece una respuesta rápida en terminales remotas". En: SOSP '67: Actas del primer simposio de la ACM sobre principios de sistemas operativos. Gatlinburg, TN. 1–4 de octubre de 1967. Nueva York, NY: ACM, págs. 2.1–2.17.
  11. ^ "La verdadera historia de cómo Internet se volvió tan vulnerable". Washington Post . Archivado desde el original el 30 de mayo de 2015 . Consultado el 18 de febrero de 2020 . Los historiadores atribuyen ideas fundamentales al científico galés Donald W. Davies y al ingeniero estadounidense Paul Baran
  12. ^ Una historia de ARPANET: la primera década (PDF) (Informe). Bolt, Beranek & Newman Inc. 1 de abril de 1981. pp. 13, 53 de 183. Archivado desde el original el 1 de diciembre de 2012. Aparte de los problemas técnicos de interconectar computadoras con circuitos de comunicaciones, la noción de redes de computadoras se había considerado en varios lugares desde un punto de vista teórico. De particular interés fue el trabajo realizado por Paul Baran y otros en la Rand Corporation en un estudio "On Distributed Communications" a principios de la década de 1960. También es de destacar el trabajo realizado por Donald Davies y otros en el Laboratorio Nacional de Física en Inglaterra a mediados de la década de 1960. ... Otro desarrollo de red importante temprano que afectó al desarrollo de ARPANET se llevó a cabo en el Laboratorio Nacional de Física en Middlesex, Inglaterra, bajo el liderazgo de DW Davies.
  13. ^ C. Hempstead; W. Worthington (2005). Enciclopedia de tecnología del siglo XX. Routledge . ISBN 9781135455514El grupo NPL también realizó trabajos de simulación en redes de paquetes .
  14. ^ Clarke, Peter (1982). Redes de datos conmutadas por paquetes y circuitos (PDF) (tesis doctoral). Departamento de Ingeniería Eléctrica, Imperial College of Science and Technology, Universidad de Londres."Además de la red de conmutación de paquetes que se construyó en NPL para la comunicación entre sus instalaciones informáticas locales, se han realizado algunos experimentos de simulación en redes más grandes. En [69] se presenta un resumen de este trabajo. El trabajo se llevó a cabo para investigar redes de un tamaño capaz de proporcionar instalaciones de comunicación de datos a la mayor parte del Reino Unido... Luego se llevaron a cabo experimentos utilizando un método de control de flujo ideado por Davies [70] llamado control de flujo "isarítmico". ... El trabajo de simulación realizado en NPL ha sido, en muchos aspectos, más realista que la mayoría de los estudios teóricos de redes de ARPA".
  15. ^ ab Pelkey, James. "8.3 CYCLADES Network y Louis Pouzin 1971-1972". Capitalismo emprendedor e innovación: una historia de las comunicaciones informáticas 1968-1988. Archivado desde el original el 17 de junio de 2021. Consultado el 21 de noviembre de 2021. Pouzin volvió a su tarea de diseñar una red de conmutación de paquetes más sencilla que Arpanet. ... [Davies] había realizado algunas simulaciones de redes de datagramas [de área amplia], aunque no había construido ninguna, y parecía técnicamente viable.
  16. ^ "El quinto hombre de Internet". The Economist . 13 de diciembre de 2013. Consultado el 11 de septiembre de 2017. A principios de la década de 1970 , Pouzin creó una innovadora red de datos que conectaba lugares de Francia, Italia y Gran Bretaña. Su simplicidad y eficiencia indicaron el camino hacia una red que podría conectar no solo docenas de máquinas, sino millones de ellas. Captó la imaginación del Dr. Cerf y el Dr. Kahn, quienes incluyeron aspectos de su diseño en los protocolos que ahora impulsan Internet.
  17. ^ ab Scheblik, TJ, DB Dawkins y Advanced Research Projects Agency (1968). RFQ para la red informática ARPA. Solicitud de cotizaciones. Advanced Research Projects Agency (ARPA), Departamento de Defensa (DoD). (Copia en línea archivada el 15 de agosto de 2011 en Wayback Machine ).
  18. ^ McQuillan, JM y DC Walden (1977). "Las decisiones de diseño de redes de ARPA". En: Computer Networks 1.5, págs. 243–289. (Copia en línea). Basado en un artículo de 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.
  19. ^ Clark, DD (2007). Diseño de aplicaciones y argumentos de extremo a extremo. Reunión bianual del programa Communications Futures del MIT. Filadelfia, Pensilvania. 30 y 31 de mayo de 2007. Diapositivas de la presentación. (Copia en línea).
  20. ^ Walden, CC (1972). "El procesador de mensajes de 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 y 26 de mayo de 1972. Association Française pour la Cybernétique Économique et Technique (AFCET). (Copia en línea).
  21. ^ McQuillan, JM (1973). Suma de comprobación de software en el IMP y confiabilidad de la red. RFC  528. Histórico. NWG.
  22. ^ Metcalfe, RM (1973). "Packet Communication". Tesis doctoral. Cambridge, MA: Harvard University. Copia en línea (edición revisada, publicada como MIT Laboratory for Computer Science Technical Report 114). Escrito principalmente en el Proyecto MAC del MIT y en Xerox PARC.
  23. ^ Bolt, Beranek y Newman Inc. (1974). Interface Message Processors for the Arpa Computer Network. BBN Report 2816. Informe técnico trimestral n.º 5, del 1 de enero de 1974 al 31 de marzo de 1974. Bolt, Beranek y Newman Inc. (BBN). (Copia privada, cortesía de BBN).
  24. ^ ab Bärwolff, M. (2010). "Argumentos de extremo a extremo en Internet: principios, prácticas y teoría". Autopublicado en línea y a través de Createspace/Amazon (PDF, erratas, etc.)
  25. ^ Walden, DC (1974) Algunos cambios en el IMP y la interfaz IMP/Host. RFC  660. Histórico. NWG.
  26. ^ BBN (1974). Procesadores de mensajes de interfaz para la red informática Arpa. BBN Report 2913. Informe técnico trimestral n.º 7, del 1 de julio de 1974 al 30 de septiembre de 1974. Bolt, Beranek and Newman Inc. (BBN).
  27. ^ J. Kempf; R. Austein (marzo de 2004). El auge del medio y el futuro del extremo a extremo: reflexiones sobre la evolución de la arquitectura de Internet. Grupo de trabajo de redes, IETF . doi : 10.17487/RFC3724 . RFC 3724.
  28. ^ "Arquitectura del protocolo CNF". Focus Projects . Winlab, Universidad Rutgers. Archivado desde el original el 23 de junio de 2016. Consultado el 23 de mayo de 2016 .
  29. ^ Ward, Mark (14 de septiembre de 2012). «Europa alcanza los límites de direcciones de Internet». BBC News . Consultado el 28 de febrero de 2017 .
  30. ^ Steve Deering y Bob Hinden, copresidentes del grupo de trabajo IP Next Generation Working Group del IETF (6 de noviembre de 1999). "Declaración sobre la privacidad de direcciones IPv6" . Consultado el 28 de febrero de 2017 .
  31. ^ "Programación orientada a la interacción basada en información: BSPL, el lenguaje de protocolo increíblemente simple" (PDF) . Consultado el 24 de abril de 2013 .