LA FILOSOFA DE DISEO DE INTERNET DARPA

PROTOCOLOS
David D. Clark
Massachusetts Institute of Technology
Laboratorio de Ciencias de la Computacin
Cambridge, MA. 02139
RESUMEN
La suite del protocolo Internet, TCP / IP, se propuso por primera vez hace quince aos. Fue
desarrollado por la Agencia de Investigacin de Proyectos Avanzados de Defensa (DARPA), y se ha
utilizado ampliamente en los sistemas militares y comerciales. Aunque ha habido papeles y
especificaciones que describen cmo los protocolos de trabajo, a veces es difcil deducir de estos
por qu el protocolo es como es. Por ejemplo, el protocolo de Internet se basa en un modo de
conexin o datagrama de servicio. El motivo de esto ha sido muy mal entendido. En este trabajo se
intenta captar algunos de los razonamientos que dio forma a principios de los protocolos de
Internet.
I. Introduccin
Durante los ltimos 15 aos que, la Advanced Research Projects Agency del Departamento de
Defensa de EE.UU. ha estado desarrollando un conjunto de protocolos para redes de paquetes
conmutados. Estos protocolos, que incluyen el Protocolo de Internet (IP) y el Transmission Control
Protocol (TCP), son ahora EE.UU. Departamento de Defensa de las normas para la interconexin, y
son de uso generalizado en el entorno de red comercial. Las ideas desarrolladas en este esfuerzo
tambin han influido en otras suites de protocolo, lo ms importante de la configuracin de
conexin de los IS0 protocolos.
Mientras que la informacin especfica sobre los protocolos del Departamento de Defensa es
bastante generalizada, a veces es difcil determinar la motivacin y el razonamiento que llev al
diseo.
De hecho, la filosofa de diseo ha evolucionado considerablemente desde la primera propuesta a
las normas vigentes. Por ejemplo, la idea de los datagramas, o servicio de conexin, no recibe
especial atencin en el primer documento, pero ha llegado a ser la caracterstica que define el
protocolo. Otro ejemplo es la estratificacin de la arquitectura en la IP y las capas de TCP. Esto
parece bsico para el diseo, pero no era tambin una parte de la propuesta original. Estos
cambios en el diseo de Internet surgieron a travs del patrn repetido de implementacin y las
pruebas que se produjo antes de que las normas se establecieron.
La arquitectura de Internet sigue evolucionando. A veces una nueva extensin desafa uno de los
principios de diseo, pero en cualquier caso una comprensin de la historia del diseo
proporciona un contexto necesario para las extensiones de diseo actuales. La configuracin de
conexin de la IS0 protocolos tambin ha sido matizada por la historia de la suite de Internet, por
lo que una comprensin "de la filosofa de diseo de Internet puede ser til para aquellos que
trabajan con la norma ISO.

En este trabajo se catlogos una visin de los objetivos originales de la arquitectura de Internet, y
analiza la relacin entre estos objetivos y las caractersticas importantes de los protocolos.
2. Objetivo fundamental
El objetivo de nivel superior para la arquitectura de Internet DARPA fue desarrollar una tcnica
efectiva para la utilizacin de multiplexado de las redes interconectadas. Algunos de elaboracin
es conveniente aclarar el significado de ese objetivo.
Los componentes de la Internet eran las redes, que deban estar interconectadas para ofrecer un
servicio ms amplio. La meta original era para conectar entre s la original ARPANET "con la red de
radio de paquetes de ARPA, con el fin de ofrecer a los usuarios sobre el acceso de paquetes de red
de radio para las mquinas de servicio de gran tamao en la ARPANET. En el momento en que se
supone que no sera otros tipos de redes de interconexin, aunque la red de rea local no haba
surgido todava.
Una alternativa a la interconexin de las redes existentes ha sido el diseo de un sistema unificado
que incorpora una variedad de diferentes medios de transmisin, una red multi-medios de
comunicacin. Si bien esto podra haber permitido un mayor grado de integracin, y el
rendimiento por lo tanto mejor, se consider que era necesario incorporar a continuacin, las
arquitecturas de red existentes si Internet iba a ser til en un sentido prctico. Adems, las redes
representan los lmites administrativos de control, y fue la ambicin de este proyecto a
enfrentarse con el problema de la integracin de una serie de entidades administradas por
separado en una utilidad comn.
La tcnica seleccionada para la Multiplexacin fue conmutacin de paquetes. Au alternativa como
la conmutacin de circuitos se podra haber considerado, pero las aplicaciones que se apoya,
como inicio de sesin remoto, se sirve de forma natural por el paradigma de conmutacin de
paquetes, y las redes que iban a ser integrados juntos en este proyecto fueron las redes de
conmutacin de paquetes. As de conmutacin de paquetes fue aceptada como un componente
fundamental de la arquitectura de Internet.
El aspecto final de este objetivo fundamental era la asuncin de la tcnica en particular para la
interconexin de estas redes. Dado que la tcnica de la tienda y la conmutacin de paquetes hacia
adelante, como se demostr en el anterior proyecto de DARPA, el ARPANET, fueron bien
entendidas, el supuesto de nivel superior fue que las redes se interconectan por una capa de
conmutadores de paquetes de Internet, que fueron llamados pasarelas.
A partir de estos supuestos viene la estructura fundamental de Internet: un centro de
conmutacin de paquetes de comunicaciones en las que se conectan una serie de redes
distinguibles entre s mediante comunicaciones de paquetes de procesadores llamados portales
que ponen en prctica una tienda de ridos algoritmo de reenvo de paquetes hacia adelante.
3. Objetivos de segundo nivel
El objetivo de nivel superior se indica en la seccin anterior, contiene la palabra "efectivo", sin
ofrecer ninguna definicin de lo que una interconexin eficaz debe lograr. La siguiente lista

resume un conjunto ms detallado de las metas que se establecieron para la arquitectura de

Internet.
1. La comunicacin por Internet debe continuar a pesar de la prdida de las redes o pasarelas.
2. El Internet debe ser compatible con varios tipos de servicios de comunicaciones.
3. La arquitectura de Internet debe adaptarse a una variedad de redes.
4. La arquitectura de Internet debe permitir la gestin de distribucin de sus recursos.
5. La arquitectura de Internet debe ser rentable.
6. La arquitectura de Internet debe permitir la unin de acogida con un bajo nivel de esfuerzo.
7. Los recursos utilizados en la arquitectura de Internet deben ser responsables.
Este conjunto de objetivos que podra parecer nada ms que una lista de todas las caractersticas
de la red deseables. Es importante entender que estos objetivos son en orden de importancia, y la
arquitectura de red completamente diferente resultara si la resolucin fuera cambiada. Por
ejemplo, ya que esta red fue diseada para operar en un contexto militar, lo que implicaba la
posibilidad de un ambiente hostil, la supervivencia fue puesto como primer objetivo, y la rendicin
de cuentas como un ltimo gol. En tiempos de guerra, uno tiene menos que ver con la
contabilidad detallada de los recursos utilizados que con reunir todos los recursos disponibles y la
rpida implementacin de ellos-i de manera operativa. Mientras que los arquitectos de la Internet
eran conscientes de la rendicin de cuentas, el problema recibido muy poca atencin durante las
primeras etapas del diseo, y slo ahora est siendo considerada. Arquitectura principalmente
para su distribucin comercial claramente a dichos objetivos en el extremo opuesto de la lista.
Del mismo modo, el objetivo de que la arquitectura sea rentable est claramente en la lista, pero
por debajo de ciertos otros objetivos, como la gestin distribuida, o el apoyo de una amplia
variedad de redes. Otras suites de protocolo, incluyendo algunas de las arquitecturas comerciales
ms populares, se han optimizado para un tipo particular de red, por ejemplo una tienda de larga
distancia y de la red hacia delante construido en medio de lneas telefnicas de velocidad, y
ofrecer una solucin muy rentable en este contexto, a cambio de tratar un poco mal con otros
tipos de redes, tales como redes de rea local.
El lector debe considerar cuidadosamente la lista de arriba de las metas, y reconocer que esto no
es una "maternidad" lista, sino un conjunto de prioridades que de colores intensos de las
decisiones de diseo en la arquitectura de Internet. Las siguientes secciones analizan la relacin
entre esta lista y las caractersticas de la Internet.
4. La supervivencia en la cara del fracaso
El objetivo ms importante en la lista es que la Internet debe seguir suministrando servicios de
comunicaciones, a pesar de que las redes y puertas de enlace estn fallando. En particular, este
objetivo fue interpretado en el sentido de que si dos entidades se comunican a travs de Internet
y provoca cierto grado de fracaso de la Internet para ser temporalmente interrumpido y volver a
configurar para reconstituir el servicio, entonces las entidades en comunicacin que debe ser
capaz de continuar sin tener que restablecer o restaurar el estado de alto nivel de la conversacin.
Ms concretamente, en la interfaz de servicio de la capa de transporte, esta arquitectura ofrece
ninguna facilidad para comunicarse con el cliente del servicio de transporte que la sincronizacin
entre el emisor y el receptor se puede haber perdido. Se trataba de un supuesto en esta
arquitectura que la sincronizacin no se pierde a menos que no haba ruta de acceso fsica sobre la

que podra ser cualquier tipo de comunicacin logrado. En otras palabras, en la parte superior de
transporte, slo existe un fallo, y es particin total. La arquitectura era para enmascarar por
completo cualquier error transitorio.
Para lograr este objetivo, la informacin de estado que describe la conversacin en curso debe ser
protegido. Ejemplos especficos de informacin de estado sera el nmero de paquetes
transmitidos, el nmero de paquetes reconocido, o el nmero de pendientes permisos de control
de flujo. Si las capas inferiores de la arquitectura pierde esta informacin, no ser capaz de saber si
se han perdido datos, y la capa de aplicacin tendr que hacer frente a la prdida de la sincrona.
Esta arquitectura insisti en que no se producen este trastorno, lo que significa que la informacin
de estado deben ser protegidos de prdidas.
En algunas arquitecturas de red, este estado se almacena en los nodos de conmutacin de
paquetes intermedios de la red. En este caso, para proteger la informacin de prdidas, debe
replicarse. Debido a la naturaleza distribuida de la replicacin, los algoritmos para garantizar la
replicacin resistente a s mismos son difciles de construir, y pocas redes con informacin sobre el
estado distribuido proporcionan ningn tipo de proteccin contra fallos. La alternativa, que eligi
esta arquitectura, es tomar esta informacin y se renen en el punto final de la red, a la entidad
que est utilizando el servicio de la red.
Yo llamo a este enfoque de la fiabilidad "destino compartido." El modelo de destino compartido
sugiere que es aceptable para perder la informacin de estado asociada con una entidad si, al
mismo tiempo, la propia entidad se ha perdido. Especficamente, la informacin acerca de la
sincronizacin a nivel de transporte se almacena en el husped que est unido a la red y utilizando
su servicio de comunicacin.
Hay dos ventajas importantes para el destino compartido de la replicacin. En primer lugar, el
destino de intercambio protege contra cualquier nmero de fallos intermedios, mientras que la
replicacin slo puede proteger contra un cierto nmero (menor que el nmero de copias
duplicadas). En segundo lugar, el destino compartido es mucho ms fcil que el ingeniero de la
replicacin.
Hay dos consecuencias para el enfoque de destino compartido de supervivencia. En primer lugar,
los nodos de conmutacin de paquetes intermedios, o puertas de enlace, no debe tener toda la
informacin esencial sobre el estado en curso conexiones. En su lugar, son conmutadores de
paquetes sin estado, una clase de diseo de la red a veces llamado un "datagrama" red. En
segundo lugar, la confianza y no ms se coloca en la mquina host que en una arquitectura en la
red asegura la entrega confiable de datos. Si el host residentes algoritmos que garantizan la
secuenciacin y el reconocimiento de los datos falla, las aplicaciones en que la mquina se les
impide la operacin.
A pesar de que la supervivencia es el objetivo primero de la lista, sigue siendo segundo a la meta
de nivel superior de la interconexin de las redes existentes. Una tecnologa ms capacidad de
supervivencia puede ser el resultado de un diseo de red multimedia nica. Por ejemplo, el
Internet hace que los supuestos muy dbiles sobre la capacidad de una red para informar de que
ha fallado. Internet se ve forzado a detectar fallos en la red de Internet a travs de mecanismos a
nivel, con el potencial para la deteccin de errores ms lento y menos especfico.
5. Tipos de servicio

El segundo objetivo de la arquitectura de Internet es que se debe apoyar, en el nivel de servicio de

transporte, una gran variedad de tipos de servicio. Los diferentes tipos de servicios se distinguen
por los diferentes requisitos para cosas tales como la velocidad, la latencia y la confiabilidad. El
tipo tradicional de servicio es la entrega confiable de datos bidireccional. Este servicio, que a veces
se denomina un "circuito virtual" de servicio, es adecuado para aplicaciones tales como acceso
remoto o la transferencia de baldosas. Fue el primer servicio prestado en la arquitectura de
Internet, usando el Transmission Control Protocol (TCP). Se reconoci que incluso a principios de
este servicio tiene mltiples variantes, ya que el acceso remoto requiere un servicio de bajo
retardo en la entrega, pero los requisitos de bajo ancho de banda, mientras que la transferencia
de archivos es menos que ver con retraso, pero muy preocupados con un alto rendimiento. TCP
intentado ofrecer estos dos tipos de servicio.
El concepto inicial de TCP fue que podra ser lo suficientemente general como para soportar
cualquier tipo de servicio necesita. Sin embargo, como toda la gama de servicios necesarios se hizo
evidente, que pareca muy difcil de conseguir apoyo para todos ellos en un solo protocolo.
El primer ejemplo de un servicio fuera de la gama de TCP fue el apoyo a XNET I2, el depurador
cruzado de Internet. TCP no pareca un transporte adecuado para XNET por varias razones. En
primer lugar, un protocolo depurador no debe ser fiable. Esta conclusin puede parecer extrao,
pero bajo condiciones de estrs o el fracaso (que puede ser exactamente cundo se necesita un
depurador) pidiendo una comunicacin fiable puede impedir la realizacin de las comunicaciones
en absoluto. Es mucho mejor para construir un servicio que se puede tratar de lo que recibe a
travs de, en lugar de insistir en que cada byte enviado es entregado en orden. En segundo lugar,
si el protocolo TCP es lo suficientemente general como para hacer frente a una amplia gama de
clientes, es de suponer que algo complejo. Una vez ms, pareca un error esperar que el apoyo a
esta complejidad en un entorno de depuracin, que pueden carecer de los servicios ms bsicos
previstos en un sistema operativo (por ejemplo, apoyo para los temporizadores.) As XNET fue
diseado para ejecutarse directamente en la parte superior del servicio de datagramas que
proporciona Internet.
Otro servicio que no se ajusta TCP fue la entrega en tiempo real de voz digitalizada, lo que se
necesita para apoyar el aspecto de las aplicaciones de teleconferencia de mando y control. III en
tiempo real de voz digital, el requisito principal no es un servicio confiable, sino un servicio que
reduce y alisa la demora en la entrega de los paquetes. La capa de aplicacin es la digitalizacin de
la voz analgica, packetizando los bits resultantes, y su envo a travs de la red sobre una base
regular. Se debe llegar al receptor en una base regular con el fin de ser convertida de nuevo a la
seal analgica. Si los paquetes no llegan cuando se espera, es imposible volver a montar la seal
en tiempo real. Una observacin sorprendente sobre el control de la variacin en la demora es
que la fuente ms grave de retraso en las redes es el mecanismo para proporcionar una entrega
confiable. Un protocolo tpico de transporte fiable responde a un paquete faltante mediante la
solicitud de una retransmisin y retrasar la entrega de los paquetes posteriores hasta que el
paquete perdido ha sido retransmitido. A continuacin, proporciona ese paquete y todos los
restantes en secuencia. El retraso, mientras que esto ocurre puede ser muchas veces el tiempo de
viaje de entrega ronda de la red, y puede alterar por completo el discurso de montaje algoritmo.
En contraste, es muy fcil de hacer frente a un paquete ocasional falta. La expresin que falta
simplemente puede ser reemplazada por un corto perodo de silencio, que en la mayora de los
casos, no perjudica la inteligibilidad de la voz humana a la escucha. Si lo hace, la correccin de alto
nivel de error puede ocurrir, y el oyente puede preguntar al orador que repetir la frase daado.

Se decidi por lo tanto, bastante temprano en el desarrollo de la arquitectura de Internet, que

ms de un servicio de transporte se requiere, y la arquitectura debe estar preparado para soportar
simultneamente el transporte que deseen limitar la fiabilidad, el retraso, o ancho de banda,
como mnimo.
Esta meta causado TCP e IP, que originalmente haba sido un protocolo nico en la arquitectura,
que se separ en dos capas. TCP proporciona un tipo particular de servicio, el flujo de datos fiable
secuencia, mientras que IP tratado de proporcionar un bloque de construccin bsico de los cuales
podra ser una variedad de tipos de servicios de construccin. Este elemento fue el datagrama,
que tambin haba sido adoptada para apoyar la supervivencia. Puesto que la fiabilidad asociada a
la entrega de un datagrama no estaba garantizada, pero "mejor esfuerzo", fue posible la
construccin del datagrama un servicio que era fiable (por el reconocimiento y la retransmisin en
un nivel superior), o un servicio que comercializan fiabilidad de las caractersticas de retardo
primitivas del sustrato de la red subyacente. El User Datagram Protocol (UDP) fue creado para
proporcionar una interfaz de nivel de aplicacin para el servicio bsico de datagrama de Internet.
La arquitectura no ha querido asumir que las redes subyacentes propios soportar mltiples tipos
de servicios, ya que esto violara el objetivo de utilizar las redes existentes. En cambio, la
esperanza era que mltiples tipos de servicio podra ser construido a partir del bloque de
construccin bsico de datagramas usando algoritmos dentro del husped y la pasarela. Por
ejemplo, (aunque esto no se hace en implementaciones ms corrientes) es posible tomar
datagramas que estn asociados con un retraso controlado pero el servicio fiable y colocarlos a la
cabeza de las colas de transmisin a menos que su vida ha expirado, en cuyo caso se seran
descartados, mientras que los paquetes asociados con las corrientes fiables se coloca en la parte
posterior de las colas, pero descart que nunca, no importa cunto tiempo haban estado en la
red.
Result ms difcil de lo esperado para proporcionar mltiples tipos de servicio sin el apoyo
explcito de las redes subyacentes. El problema ms grave era que las redes diseadas con un tipo
particular de servicio en la mente no eran lo suficientemente flexible como para apoyar otros
servicios. Por lo general, una red que han sido diseadas bajo el supuesto de que se debe brindar
un servicio confiable, e inyectar los retrasos, como parte de la produccin de un servicio
confiable, si es o no la fiabilidad que se desea. El comportamiento de la interfaz definida por X.25,
por ejemplo, implica la entrega fiable, y no hay manera de desactivar esta funcin. Por lo tanto, a
pesar de Internet funciona con xito en las redes X.25 no puede entregar la variabilidad deseada
del tipo de servicio en ese contexto. Otras redes que tienen un intrnseco servicio de datagramas
son mucho ms flexibles en el tipo de servicio que va a permitir, pero estas redes son mucho
menos comunes, especialmente en el contexto de larga distancia.
6. Las variedades de Redes
Era muy importante para el xito de la arquitectura de Internet que sea capaz de incorporar y
utilizar una amplia variedad de tecnologas de red, incluidas las instalaciones militares y
comerciales. La arquitectura de Internet ha tenido mucho xito en el cumplimiento de este
objetivo: que se opera en una amplia variedad de redes, incluyendo redes de larga distancia (la
propia ARPANET y diversas redes X.25), redes de rea local (Ethernet, ringnet, etc), transmiten las
redes de satlite (el "DARPA del Atlntico Satellite Network", operativo I5 a 64 kilobits por

segundo y la red de banda ancha por satlite experimental de DARPA, 16 de explotacin en los
Estados Unidos a los 3 megabits por segundo), las redes de paquetes de radio (la red de paquetes
de radio, DARPA as como un paquete experimental britnica red de radio y una red desarrollada
por operadores de radio aficionados), una variedad de enlaces serie, que van desde 1200 bits por
segundo conexiones asincrnicas a los enlaces de TI, y una variedad de otras instalaciones ad hoc,
incluyendo autobuses y intercomputer el servicio de transporte proporcionado por las capas ms
altas de las suites de la red, tales como HASP de IBM.
La arquitectura de Internet alcanza esta flexibilidad, haciendo un conjunto mnimo de hiptesis
sobre la funcin que la red va a dar. El supuesto bsico es que la red puede transportar un
paquete o datagrama. El paquete debe ser de un tamao razonable, tal vez 100 bytes mnimo, y
deben ser entregados con fiabilidad razonable, pero no perfecta. La red debe tener una forma
adecuada de abordar si se trata de ms de un enlace punto a punto.
Hay una serie de servicios que no estn explcitamente asumidas desde la red. Estos incluyen la
entrega confiable o secuencial, de difusin o multidifusin a nivel de red, orden de prioridad de los
paquetes de transmisin, mltiples tipos de servicio, y el conocimiento interior; fracasos, la
velocidad, o retrasos. Si estos servicios se haban exigido, a continuacin, con el fin de dar cabida a
una red dentro de Internet, sera necesario, ya sea que la red es compatible con estos servicios
directamente, o que el software de interfaz de red proporciona mejoras para simular estos
servicios en el extremo de la red. Se consider que este enfoque era indeseable, ya que estos
servicios tendran que ser re-ingeniera y re-implementado para cada red nica y todas las
interfaces de host a cada red. Por la ingeniera de estos servicios en el transporte, por ejemplo a
travs de la entrega confiable
TCP, la ingeniera debe hacerse slo una vez, y la aplicacin debe hacerse slo una vez para cada
host. Despus de eso, la aplicacin de software de interfaz para una nueva red es generalmente
muy simple.
7. Otros objetivos
Los tres objetivos discutidos hasta el momento fueron las que tuvieron el impacto ms profundo
en el diseo de la arquitectura. Las metas restantes, porque eran ms bajos en importancia,
fueron quizs menos cumplan efectivamente, o no tan completamente diseado. El objetivo de
permitir la gestin distribuida de Internet sin duda ha sido conocido en ciertos aspectos. Por
ejemplo, no todos los portales en Internet son ejecutados y administrados por la misma agencia.
Hay varios centros de gestin diferentes dentro de la Internet, cada uno implementado un
subconjunto de funcionamiento de las puertas, y no hay un algoritmo de enrutamiento de dos
niveles que permite a portales de las distintas administraciones para intercambiar tablas de
enrutamiento, a pesar de que no confa plenamente en la otra, y una variedad de algoritmos de
enrutamiento privados utilizan una de las vas en una sola administracin. Del mismo modo, las
diversas organizaciones que gestionan las pasarelas no son necesariamente las mismas
organizaciones que gestionan las redes a las que las puertas de entrada estn conectadas.
Por otro lado, algunos de los problemas ms importantes con el Internet hoy en da se refieren a la
falta de suficientes herramientas para la gestin distribuida, especialmente en el rea de
encaminamiento. En el internet grande que es actualmente operada, las decisiones de
enrutamiento deben ser limitadas por las polticas de uso de los recursos. Hoy esto se puede hacer
solamente en una forma muy limitada, lo que requiere el ajuste manual de las tablas. Esto es

propenso a errores y al mismo tiempo no suficientemente potente. El cambio ms importante en

la arquitectura de Internet en los prximos aos probablemente ser el desarrollo de una nueva
generacin de herramientas para la gestin de los recursos en el contexto de mltiples
administraciones.
Es evidente que en ciertas circunstancias, la arquitectura de Internet no produce como rentable
una utilizacin de los recursos de comunicacin costosos como una arquitectura ms adaptada
hara. Las cabeceras de los paquetes de Internet soy bastante largo (un encabezado tpico es de 40
bytes), y si los paquetes se envan a corto, esta sobrecarga es evidente. El peor de los casos, por
supuesto, es que los paquetes de un solo carcter de inicio de sesin remoto, que llevan 40 bytes
de cabecera y un byte de datos. En realidad, es muy difcil para cualquier conjunto de protocolos
para afirmar que este tipo de intercambios se llevan a cabo con una eficiencia razonable. En el
otro extremo, los paquetes grandes para la transferencia de archivos, quizs con 1.000 bytes de
datos, tienen una sobrecarga para el encabezado de slo cuatro por ciento.
Otra posible fuente de ineficiencia es la retransmisin de paquetes perdidos. Dado que Internet no
insiste en que la prdida de paquetes se recuper a nivel de red, puede ser necesario volver a
transmitir un paquete perdido en un extremo de la Internet para el otro. Esto significa que el
paquete retransmitido puede atravesar varias redes que intervienen una segunda vez, mientras
que la recuperacin a nivel de red no generara este trfico de la repeticin. Este es un ejemplo de
la desventaja resultante de la decisin, se discuti anteriormente, la prestacin de servicios desde
los puntos finales. El cdigo de interfaz de red es mucho ms simple, pero la eficiencia global es
potencialmente menos. Sin embargo, si la tasa de retransmisin es lo suficientemente baja (por
ejemplo, 1%), entonces el costo incremental es tolerable. Como regla bsica para las redes
incorporadas en la arquitectura, la prdida de un paquete de cada cien es bastante razonable,
pero una prdida de un paquete de cada diez sugiere que las mejoras de fiabilidad se aadirn a la
red si este tipo de servicio se requiere.
El costo de conectar a un host de Internet es tal vez un poco ms alto que en otras arquitecturas,
ya que todos los mecanismos para proporcionar los tipos deseados de servicio, tales como los
reconocimientos y las estrategias de retransmisin, se debe implementar en el host en lugar de en
la red. En un principio, para los programadores que no estaban familiarizados con la
implementacin del protocolo, el esfuerzo de hacer esto pareca un tanto desalentador.
Implementador ha intentado cosas, como mover los protocolos de transporte a un procesador
frontal, con la idea de que los protocolos se llevaran a cabo slo una vez, en lugar de nuevo para
cada tipo de husped. Sin embargo, esto requiere la invencin de una mquina con el protocolo
de front-end, que algunos pensaron casi tan complicado como para poner en prctica el protocolo
de transporte original. Como la experiencia con los aumentos protocolos, las ansiedades asociados
con la implementacin de un conjunto de protocolos dentro del husped parecen estar
disminuyendo, y las implementaciones ya estn disponibles para una amplia variedad de
mquinas, incluidas las computadoras personales y otros aparatos con recursos informticos
limitados.
Un problema relacionado con derivados de la utilizacin de los mecanismos de residentes en host
es que la deficiente aplicacin del mecanismo puede perjudicar a la red, as como el anfitrin. Este
problema se toler, porque los experimentos iniciales implicado un nmero limitado de
implementaciones husped que podran ser controlados. Sin embargo, como el uso de Internet ha
crecido, este problema ha surgido en ocasiones de una manera seria. En este sentido, el objetivo

de robustez, lo que llev al mtodo de destino compartido, lo que llev a los algoritmos residentes
en host, contribuye a la prdida de robustez si el host se porta mal.
El ltimo gol fue la rendicin de cuentas. De hecho, la contabilidad se discuti en el documento
por primera vez por Cerf y Kahn como una funcin importante de los protocolos y las pasarelas.
Sin embargo, en la actualidad, la arquitectura de Internet contiene pocas herramientas para la
contabilizacin de los flujos de paquetes. Este problema slo se estn estudiando, ya que el
mbito de la arquitectura se est ampliando para incluir no militares a los consumidores que estn
seriamente interesados en comprender y controlar el uso de los recursos dentro de la Internet.
8. Arquitectura e Implementacin
El anlisis anterior sugiere claramente que uno de los objetivos de la arquitectura de Internet fue
proporcionar una gran flexibilidad en el servicio ofrecido. Los diferentes protocolos de transporte
podran ser utilizados para proporcionar diferentes tipos de servicio, y las diferentes redes se han
incorporado. Dicho de otra manera, la arquitectura trat muy duro no para limitar la gama de
servicio que podra ser el Internet diseado para proporcionar. Esto, a su vez, significa que para
entender el servicio que pueden ser ofrecidos por una implementacin particular de un Internet,
uno no debe mirar a la arquitectura, pero a la ingeniera real del software dentro de los ejrcitos
particulares y puertas de enlace, y al particular redes que se han incorporado. Voy a utilizar el
trmino "realizacin" para describir un conjunto particular de las redes, las pasarelas y los
anfitriones que han sido conectados entre s en el contexto de la arquitectura de Internet.
Realizaciones pueden diferir en varios rdenes de magnitud en el servicio que ofrecen.
Realizaciones se han construido a partir de 1900 bits por segundo las lneas telefnicas y de las
redes slo con velocidades superiores a 1 segundo por megabit. Es evidente que las expectativas
de rendimiento que se puede tener una de estas realizaciones difieren en varios rdenes de
magnitud. Del mismo modo, algunas realizaciones de Internet tienen demoras se miden en
decenas de milisegundos, donde otros tienen retrasos medidos en segundos. Algunas aplicaciones,
tales como hablar en tiempo real trabajan fundamentalmente diferente a travs de estas dos
realizaciones. Algunos Internes han sido diseados de manera que hay mucha redundancia en las
pasarelas y senderos. Estos Internes son de supervivencia, porque los recursos existen, que
pueden ser reconfigurados despus de la falla. Otras realizaciones de internet, para reducir costos,
tener puntos de conectividad a travs de la realizacin, de forma que un fallo puede dividir el
internet en dos mitades.
La arquitectura de Internet tolera esta variedad de la realizacin del diseo. Sin embargo, deja al
diseador de una realizacin particular, con una gran cantidad de ingeniera que hacer. Una de las
luchas ms importantes de este desarrollo de la arquitectura era entender cmo orientar al
diseador de una realizacin, la orientacin que se relacionara con la ingeniera de la realizacin
de los tipos de servicio que se derivaran. Por ejemplo, el diseador debe responder a la siguiente
tipo de pregunta. Qu tipo de anchos de banda que debe en las redes subyacentes, si el servicio
en general es proporcionar un rendimiento de un ndice determinado? Dado un cierto modelo de
los posibles fallos dentro de este ejercicio, qu tipo de despido debe ser dirigido a la realizacin?
La mayor parte de la conocida red de diseo de las ayudas no parece til para responder a este
tipo de preguntas. Verificadores Protocolo, por ejemplo, ayudar a confirmar que los protocolos de
cumplir con las especificaciones. Sin embargo, estas herramientas casi nunca frente a los
problemas de rendimiento, que son esenciales a la idea del tipo de servicio. En su lugar, hacer

frente a la idea mucho ms restringido de la correccin lgica del protocolo con respecto a la
especificacin. Mientras que las herramientas para verificar la correccin lgica son tiles, tanto
en la fase de especificacin y la implementacin. No ayudan a los graves problemas que surgen a
menudo relacionados con el rendimiento. Una experiencia de aplicacin tpico es el correcto,
incluso despus de lgica se ha demostrado, errores de diseo se descubri que puede causar una
degradacin del rendimiento de un orden de magnitud. La exploracin de este problema ha
llevado a la conclusin de que la dificultad se presenta generalmente, no en el propio protocolo,
pero en el sistema operativo en el que el protocolo se ejecuta. Siendo este el caso, es difcil para
abordar el problema en el contexto de la especificacin arquitectnica. Sin embargo, todava la
firme conviccin de la necesidad de dar la direccin de implementador. Seguimos luchando con
este problema hoy en da.
La otra clase de ayuda de diseo es el simulador, que tiene una realizacin particular y explora el
servicio que puede entregar bajo una variedad de cargas. Nadie ha intentado construir un
simulador que tienen en cuenta la gran variabilidad de la aplicacin de puerta de enlace, la
aplicacin de acogida, y el rendimiento de la red que se ve en Internet realizaciones posibles. Por
tanto, es el caso de que el anlisis de la mayora de las realizaciones de Internet se hace en la parte
posterior de un sobre. Es un comentario sobre la estructura de meta de la arquitectura de Internet
que un anlisis posterior de la envolvente, si se hace por una persona lo suficientemente bien
informado, suele ser suficiente. El diseador de una realizacin particular de Internet suele ser
menos preocupados por obtener el ltimo cinco por ciento es posible en la utilizacin de la lnea
que saber si el tipo de servicio deseado se puede lograr en todos dados los recursos disponibles en
este momento.
La relacin entre la arquitectura y el rendimiento es extremadamente difcil. Los diseadores de la
arquitectura de Internet tena muy claro que fue un error grave para asistir slo a la correccin
lgica y pasar por alto la cuestin de rendimiento. Sin embargo, grandes dificultades en la
formalizacin de cualquier aspecto de la restriccin de desempeo dentro de la arquitectura. Estas
dificultades se presentaron tanto por el objetivo de la arquitectura no era para limitar el
rendimiento, pero para permitir la variabilidad, y en segundo lugar (y tal vez ms fundamental),
porque no pareca haber ningn herramientas tiles formales para describir el rendimiento.
Este problema es especialmente agravante, porque el objetivo del proyecto Internet era para
producir documentos de especificaciones que se convertiran en las normas militares. Se trata de
un problema bien conocido con la contratacin del gobierno que no se puede esperar de un
contratista para cumplir con los criterios que no es una parte de la norma de contratacin. Si
Internet est preocupado por el rendimiento, por lo tanto, era obligatorio que los requisitos de
rendimiento se pone en el pliego de contratacin. Es trivial que inventar las especificaciones que
limitaban el rendimiento, por ejemplo, para especificar que la aplicacin debe ser capaz de pasar
de 1.000 paquetes por segundo. Sin embargo, este tipo de restriccin no podra ser parte de la
arquitectura, y era por lo tanto corresponde a la persona que realiza la adquisicin de reconocer
que estas limitaciones de rendimiento debe ser aadido a la especificacin y para especificar
adecuadamente para lograr una realizacin que proporciona la requerida tipos de servicio. No
tenemos una buena idea la forma de ofrecer orientacin en la arquitectura de la persona que
realiza esta tarea.
9. Datagramas

La caracterstica fundamental de la arquitectura de Internet es el uso de datagramas como la

entidad que se transporta a travs de las redes subyacentes. En este trabajo se ha sugerido, hay
varias razones por las datagramas son importantes dentro de la arquitectura. En primer lugar,
eliminar la necesidad de estado de conexin dentro de los nodos de conmutacin intermedios, lo
que significa que la Internet puede ser reconstituida despus de un fallo sin preocupacin por el
estado. En segundo lugar, el datagrama proporciona un bloque de construccin bsica de los
cuales puede ser una variedad de tipos de servicio implementado. En contraste con el circuito
virtual, que generalmente implica un tipo fijo de servicio, el datagrama proporciona un servicio
ms elemental que los extremos se pueden combinar segn sea apropiado para construir el tipo
de servicio necesario. En tercer lugar, el datagrama representa el supuesto de la red de servicios
mnimos, lo que ha permitido una amplia variedad de redes para ser incorporados en diversas
realizaciones de Internet. La decisin de utilizar el datagrama fue sumamente exitosa, que
permiti a la Internet para cumplir con sus objetivos ms importantes con mucho xito.
Hay una suposicin errnea a menudo asociado con los datagramas, que es que la motivacin de
los datagramas es el apoyo de un servicio de nivel superior, que es esencialmente equivalente a
los datagramas. En otras palabras, a veces se ha sugerido que el datagrama se proporciona porque
el servicio de transporte que la aplicacin requiere es un servicio de datagramas. De hecho, este es
raramente el caso. Mientras que algunas aplicaciones en la Internet, tales como consultas sencillas
de los servidores de la fecha o nombre de servidores, utilice un mtodo de acceso basado en un
datagrama poco fiable, la mayora de los servicios dentro de Internet le gustara un modelo de
transporte ms sofisticado que un simple datagrama. Algunos servicios le gustara que el mayor
confiabilidad, a algunos les gustara el retraso alisado y amortiguada, pero casi todos tienen una
expectativa ms complejo que un datagrama. Es importante entender que el papel del datagrama
a este respecto es como un bloque de construccin, y no como un servicio en s mismo.
10. TCP
Hubo varias decisiones de diseo interesante y controvertido en el desarrollo de TCP, y TCP en s
pas por varias versiones principales antes de convertirse en un nivel razonablemente estable.
Algunas de estas decisiones de diseo, tales como la gestin de ventanas y la naturaleza de la
estructura de direccin del puerto, se analizan en una serie de notas de aplicacin publicados
como parte del manual de protocolo TCP. Pero una vez ms la motivacin de la decisin que a
veces falta, en esta seccin, trato de capturar algunos de los principios del razonamiento, que
entr en partes de TCP. Esta seccin es necesariamente incompleta, una revisin completa de la
historia de la TCP se requerira otro artculo de esta longitud.
El original de host-a ARPANET protocolo previsto organizar el control de flujo basado en dos bytes
y paquetes. Esto parece demasiado complejo, y los diseadores de TCP consider que slo una
forma de regulacin que sera suficiente. La eleccin era para regular la entrega de bytes, en lugar
de los paquetes. El control de flujo y acuse de recibo en el TCP se basa por tanto en el nmero de
bytes en lugar del nmero de paquetes. De hecho, en el TCP no es significativo a la paquetizacin
de los datos.
Esta decisin fue motivada por varias consideraciones, algunas de las cuales se convirtieron en
irrelevantes y otros que eran ms importantes de lo previsto. Una de las razones para reconocer
octetos era para permitir la insercin de informacin de control en el espacio de secuencia de los
bytes, de modo que el control, as como los datos podran ser reconocidos. Que el uso del espacio

de secuencias se abandon en favor de tcnicas ad hoc para hacer frente a cada mensaje de
control. Aunque la idea original ha apelado generalidad, que caus la complejidad en la prctica.
Una segunda razn para el flujo de bytes iba a permitir que el paquete TCP se divida en paquetes
ms pequeos si es necesario con el fin de pasar a travs de una red con un tamao de paquete
pequeo. Sin embargo, esta funcin se traslad a la capa IP IP cuando se separ de TCP e IP se vio
obligado a inventar un mtodo diferente de la fragmentacin.
Una tercera razn para el reconocimiento de bytes en lugar de los paquetes era permitir que un
nmero de pequeos paquetes que se renan en un solo paquete ms grande en el envo de
acogida si la retransmisin de los datos era necesario. No estaba claro si esta ventaja no sera
importante, ya que result ser crucial. Los sistemas como UNIX que tienen un modelo de
comunicacin interna sobre la base de las interacciones de un solo carcter a menudo envan
muchos paquetes con un byte de datos en ellos. (Uno podra argumentar desde una perspectiva
de red que este comportamiento es una tontera, pero era una realidad y una necesidad para el
inicio de sesin remoto interactivo.) Se ha observado a menudo que un anfitrin podra producir
una inundacin de paquetes con un byte de datos, que llegara mucho ms rpido que una serie
lenta podra procesarlos. El resultado es la prdida de paquetes y retransmisin.
Si la retransmisin fue de los paquetes originales, el mismo problema se repite en cada
retransmisin, con un impacto en el rendimiento tan intolerable como para evitar la operacin.
Pero como los bytes fueron reunidos en un paquete para la retransmisin, la retransmisin se
produjo de una manera mucho ms eficaz que permiti la operacin prctica.
Por otro lado, el reconocimiento de bytes podra ser visto como la creacin de este problema en el
primer lugar. Si la base de control de flujo se haba paquetes en lugar de bytes, a continuacin,
esta inundacin no podra haber ocurrido. De control a nivel del paquete tiene el efecto, sin
embargo, de ofrecer un lmite severo en el rendimiento si los paquetes se envan pequeas. Si el
anfitrin de la recepcin especifica el nmero de paquetes a recibir, sin ningn conocimiento de la
cantidad de bytes en cada uno, la cantidad real de los datos recibidos pueden variar en un factor
de 1000, dependiendo de si el host emisor pone uno o mil bytes cada paquete.
En retrospectiva, la decisin de un correcto diseo puede haber sido que si el protocolo TCP es
proporcionar un apoyo efectivo de una variedad de servicios, tanto de paquetes y bytes que
deben ser reguladas, como se hizo en los originales de los protocolos de ARPANET.
Otra decisin de diseo relacionado con el flujo de bytes era la bandera de fin de carta, o EOL. Esto
ahora ha desaparecido del protocolo, reemplazada por la bandera de empuje, o PSH. La idea
original de EOL era romper el flujo de bytes en los registros. Se llev a cabo poniendo los datos de
registros separados en paquetes separados, que no era compatible con la idea de combinar los
paquetes en la retransmisin. As que la semntica de la EOL fue cambiado a una forma ms dbil,
es decir, slo que los datos hasta este punto en la corriente era uno o ms completos a nivel de
aplicacin, que los elementos para que salgan a ras de cualquier bfer interno en TCP o en la red.
Al decir "uno o ms" y no "exactamente uno", fue posible combinar varios juntos y mantener el
objetivo de compactar los datos en el montaje. Pero la semntica ms dbiles significa que varias
aplicaciones tuvieron que inventar un mecanismo ad hoc para la delimitacin de los registros en la
parte superior de la secuencia de datos.

En esta evolucin de la semntica de la EOL, hubo un poco de forma conocida intermedia, lo que
gener un gran debate. Dependiendo de la estrategia de amortiguamiento de la serie, el modelo
de flujo de bytes de TCP puede causar grandes problemas en un caso poco probable. Considere la
posibilidad de una serie en la que se pone los datos de entrada en una secuencia de bferes de
tamao fijo. Un tampn se devuelve al usuario ya sea cuando est lleno, o un EOL es recibido.
Ahora consideremos el caso de la llegada de un fuera de orden paquete que est tan lejos del fin
de que ms all del buffer actual. Ahora consideran adems que despus de recibir este paquete
fuera de orden, un paquete con un EOL hace que el tampn de corriente que se devuelve al
usuario slo parcialmente lleno. Esta secuencia particular de acciones tiene el efecto de causar la
salida de datos de la orden en el siguiente tampn para estar en el sitio equivocado, porque los
bytes de vacos en el buffer devuelto al usuario. Hacer frente a esta generada tenedura de libros,
problemas en el de acogida, que pareca innecesaria.
Para hacer frente a esto, se propone que la EOL debe "agotar" todo el espacio de la secuencia
hasta el siguiente valor que fue de cero mod el tamao del bfer. En otras palabras, se propuso
que EOL debe ser una herramienta para mapear el flujo de bytes para la gestin de memoria
intermedia del husped. Esta idea no fue bien recibida en el momento, ya que pareca demasiado
ad hoc, y slo un anfitrin pareca no tener este problema. "En retrospectiva, puede haber sido
correcta la idea de incorporar a algn medio de TCP sobre el espacio de secuencias y el algoritmo
de gestin de memoria intermedia del husped. En ese momento, los diseadores simplemente
carecan de la visin para ver cmo se podra hacer de una manera bastante general.
11. Conclusin
En el contexto de sus prioridades, la arquitectura de Internet ha tenido mucho xito. Los
protocolos son ampliamente utilizados en el entorno comercial y militar, y han generado una serie
de arquitecturas similares. Al mismo tiempo, su xito ha dejado claro que en ciertas situaciones,
las prioridades de los diseadores no se corresponden con las necesidades de los usuarios reales.
Ms atencin a las cosas tales como la gestin de los recursos de contabilidad, y el funcionamiento
de las regiones con administraciones separadas son necesarios.
Mientras que el datagrama ha servido muy bien en la solucin de los objetivos ms importantes de
la Internet, no ha servido tan bien cuando se intenta abordar algunos de los objetivos que eran
ms abajo en la lista de prioridades. Por ejemplo, los objetivos de la gestin de recursos y la
rendicin de cuentas han demostrado ser difcil de lograr en el contexto de los datagramas. En la
seccin anterior se analiz, la mayora de los datagramas son parte de una secuencia de paquetes
desde el origen al destino, en vez de unidades aisladas en el nivel de aplicacin. Sin embargo, la
puerta de enlace no puede ver directamente la existencia de esta secuencia, ya que est obligado
a tratar con cada paquete de forma aislada. Por lo tanto, las decisiones de gestin de recursos o la
contabilidad debe hacerse en cada paquete por separado. La imposicin del modelo de datagrama
de la capa de Internet ha privado a la capa de una importante fuente de informacin que podra
utilizar en la consecucin de estos objetivos.
12. Agradecimientos - Una perspectiva histrica
Sera imposible agradecer a todos los colaboradores del proyecto en Internet, no han sido
literalmente cientos ms de los 15 aos de desarrollo: diseadores, implementadores, escritores y
crticos. De hecho, un tema importante, que probablemente merece un documento en s mismo,

es el proceso mediante el cual se manej este proyecto. Los participantes provenan de

universidades, laboratorios de investigacin y empresas, y se unieron (hasta cierto punto) para
lograr este objetivo comn.
La visin original de TCP surgi de Robert Kahn y Vinton Cerf, quien vio muy claramente, en el ao
1973, como un protocolo con caractersticas adecuadas podra ser el pegamento que unira a
todos los diferentes tecnologas de red emergentes. Desde su posicin en DARPA, que dirigi el
proyecto en sus primeros das hasta el punto de TCP e IP se convirti en estndares para el
Departamento de Defensa.
El autor de este trabajo se uni al proyecto en los mediados de los 70, y asumi la responsabilidad
de arquitectura para TCP / IP en 198 1. A l le gustara agradecer a todos aquellos que han
trabajado con l, y en particular aquel que se tomaron el tiempo para reconstruir parte de la
historia perdida en este artculo.