Cómo el control de congestión de TCP salvó Internet • Registro

Enfoque de sistemas Con la conferencia anual SIGCOMM que se lleva a cabo este mes, observamos que el control de la congestión todavía está recibiendo una hora en el programa, 35 años después de que se publicara el primer artículo sobre el control de la congestión TCP. Así que éste parece un buen momento para apreciar en qué medida el éxito de Internet depende de su enfoque para la gestión de la congestión.

despues de mi charla Él habla Y para un artículo sobre 60 años de creación de redes, que se centró casi exclusivamente en Internet y ARPANET, recibí bastantes comentarios sobre diferentes tecnologías de redes que competían por el dominio al mismo tiempo.

Estos incluían la pila OSI (¿alguien recuerda CLNP y TP4?), los protocolos del libro de colores (incluido Cambridge Ring) y, por supuesto, ATM (modo de transferencia asíncrono), que en realidad fue el primer protocolo de red en el que trabajé en profundidad. Es difícil de entender ahora, pero en la década de 1980 yo era una de las muchas personas que creían que ATM podría ser la tecnología de conmutación de paquetes que conquistaría el mundo.

Considero que el control de la congestión es uno de los principales factores que ha permitido que Internet avance desde una escala moderada a una escala global.

Los defensores de los cajeros automáticos solían referirse a las tecnologías existentes, como Ethernet y TCP/IP, como protocolos “heredados” que, de ser necesario, podrían transmitirse a través de la red mundial de cajeros automáticos una vez establecidos. Uno de mis gratos recuerdos de aquellos días es el de Steve Dearing (pionero de las redes IP) afirmando audazmente (y correctamente) que ATM nunca tendría suficiente éxito como para siquiera ser un protocolo heredado.

Una de las razones por las que me salté estos otros protocolos al contar la historia de las redes anteriormente fue simplemente para ahorrar espacio; es un hecho poco conocido que mi colega de Systems Approach, Larry Peterson, y yo buscamos la brevedad, especialmente desde que recibimos un mensaje. reseña de 1 estrella En Amazon, quien llamó a nuestro libro un «muro de texto». Pero también me centré en cómo llegamos hoy a Internet, donde TCP/IP ha superado efectivamente a otros conjuntos de protocolos para lograr una penetración universal (o casi universal).

Hay muchas teorías sobre por qué TCP/IP ha tenido más éxito que sus contemporáneos, y no son fácilmente comprobables. Probablemente, hubo muchos factores que influyeron en el éxito de los Protocolos de Internet. Pero considero que el control de la congestión es uno de los principales factores que ha permitido que Internet avance desde una escala moderada a una escala global.

También es un estudio interesante sobre cómo las elecciones arquitectónicas especiales tomadas en la década de 1970 han demostrado su eficacia en las décadas siguientes.

Gestión de recursos distribuidos

En el artículo de David Clarke [PDF] La «Filosofía de diseño para protocolos de Internet» de DARPA, un objetivo de diseño declarado, es: «La arquitectura de Internet debe permitir la gestión distribuida de sus recursos». Hay muchas implicaciones diferentes de este objetivo, pero el enfoque seguido por Jacobson y Karels [PDF] La primera implementación del control de congestión en TCP es un buen ejemplo de cómo tomar en serio este principio.

Su enfoque también incluye otro objetivo de diseño de Internet: dar cabida a muchos tipos diferentes de redes. En conjunto, estos principios descartan en gran medida la posibilidad de cualquier tipo de control de admisión basado en la red, en marcado contraste con redes como ATM, que suponen que una solicitud de recurso se enviará desde el sistema final a la red antes que los datos. puede fluir.

Parte de la filosofía de «adaptarse a muchos tipos de redes» es que no se puede asumir que todas las redes tienen control de admisión. Combine eso con la gestión de recursos distribuidos y terminará con el control de la congestión como algo con lo que los sistemas finales tienen que lidiar, que es exactamente lo que hicieron Jacobson y Karels en sus cambios iniciales a TCP.

Estamos tratando de lograr que millones de sistemas finales compartan cooperativamente el ancho de banda de los enlaces cuello de botella de manera justa.

La historia del control de congestión de TCP es lo suficientemente larga como para llenar un libro (Y lo hicimos) Pero el trabajo realizado en Berkeley entre 1996 y 1998 arroja una larga sombra, ya que Jacobson Documento SIGCOM de 1988 Se encuentra entre los artículos sobre redes más citados de todos los tiempos.

El inicio lento, AIMD (aumento aditivo, disminución multiplicativa), la estimación de RTT y el uso de la pérdida de paquetes como señal de congestión estaban todos en ese documento, sentando las bases para las siguientes décadas de investigación sobre el control de la congestión. Creo que una de las razones por las que el papel fue tan influyente es que las bases que sentó eran sólidas, al tiempo que dejaban mucho margen para mejoras futuras, como vemos en los esfuerzos actuales para mejorar el control de la congestión.

El problema es fundamentalmente difícil: estamos tratando de lograr que millones de sistemas finales que no tienen comunicación directa entre sí compartan cooperativamente el ancho de banda de los enlaces cuello de botella de una manera bastante justa utilizando información que se puede obtener enviando únicamente paquetes en el red y monitoreo Cuándo y si llegan a su destino.

Podría decirse que uno de los mayores avances después de 1988 fue la comprensión de Brackmo y Peterson (sí, ese tipo) de que la pérdida de paquetes no era el único signo de congestión: también lo era el aumento de la demora. Esta fue la base para 1994. Hoja TCP VegasLa idea de utilizar el retraso en lugar de la pérdida únicamente fue controvertida en ese momento.

Sin embargo, Vegas lanzó una nueva tendencia en la investigación del control de la congestión, inspirando muchos otros esfuerzos para tener en cuenta el retraso como un indicador temprano de la congestión antes de que ocurra la pérdida. centro de datos TCP(DCTCP) y Google BBR Son dos ejemplos.

Una de las razones por las que doy crédito a los algoritmos de control de la congestión para explicar el éxito de Internet es que el camino hacia el fracaso de Internet estaba claro en 1986. Jacobson describe algunos episodios tempranos de colapso de la congestión, en los que el rendimiento disminuyó en tres órdenes de magnitud.

Cuando me uní a Cisco en 1995, todavía escuchábamos historias de clientes sobre incidentes desastrosos de congestión. Ese mismo año, Bob Metcalfe, inventor de Ethernet y reciente ganador del Premio Turing, predijo que Internet colapsaría, a medida que el acceso de los consumidores a Internet y la llegada de la Web condujeran a un rápido crecimiento del tráfico. No sucedió.

El control de la congestión ha seguido evolucionando; el protocolo QUIC, por ejemplo, proporciona mejores mecanismos de detección de congestión y la opción de probar múltiples algoritmos de control de congestión. Algunos controles de congestión se han trasladado a la capa de aplicación, por ejemplo: Dynamic Adaptive Streaming over HTTP (DASH).

Un efecto secundario interesante de los episodios de congestión de los años 1980 y 1990 es que notamos que pequeñas barreras temporales eran a veces la causa del colapso de la congestión. eso Papel influyente Villamizar y Song demostraron que el rendimiento de TCP disminuía cuando la cantidad de almacenamiento en búfer era menor que el producto promedio de retardo x ancho de banda de los flujos.

Desafortunadamente, el resultado sólo se mantuvo para un número muy pequeño de flujos (como se reconoce en el documento), pero fue ampliamente interpretado como una regla inviolable que influyó en los siguientes años de diseño de enrutadores.

Esto finalmente fue desacreditado por la acción de cambio de tamaño del búfer. Appenzell et al En 2004, pero no antes del desafortunado fenómeno Hinchazón del tampón – Tamaños de búfer realmente excesivos que provocan retrasos masivos en las colas: alcanzaron a millones de enrutadores de gama baja. el Autotest Vale la pena echarle un vistazo a tener Bufferbloat en su red doméstica.

Entonces, si bien no podemos retroceder y realizar experimentos controlados para ver exactamente cómo Internet tuvo éxito mientras otros conjuntos de protocolos fallaron, al menos podemos ver que Internet evitó fallas potenciales debido a la congestión vial de manera oportuna. Control añadido.

En 1986 era relativamente fácil probar nuevas ideas modificando el código en un par de sistemas posteriores y luego llevar la solución funcional a una amplia gama de sistemas. Nada dentro de la red tiene que cambiar. Es casi seguro que a esto ayudó el hecho de que el conjunto de sistemas operativos que necesitaban cambiar y la comunidad de personas que podían realizar esos cambios era lo suficientemente pequeña como para ver una difusión generalizada de los algoritmos iniciales basados ​​en BSD de Jacobson y Karels.

Parece claro que no existe un enfoque perfecto para el control de la congestión, razón por la cual seguimos viendo nuevas investigaciones sobre este tema 35 años después de la investigación de Jacobson. Pero la arquitectura de Internet ha fomentado un entorno en el que se pueden probar e implementar soluciones efectivas para lograr una gestión distribuida de recursos compartidos.

En mi opinión, este es un gran testimonio de la calidad de esa arquitectura. ®