Investigación y borradores

Investigación de TCP

Un argumento para aumentar la ventana inicial de congestión de TCP

Los flujos de TCP comienzan con una ventana de congestión inicial de cuatro segmentos como máximo o aproximadamente 4 KB de datos. Debido a que la mayoría de las transacciones web son de corta duración, la ventana de congestión inicial es un parámetro de TCP fundamental para determinar la rapidez con la que pueden finalizar los flujos. Si bien las velocidades de acceso a la red globales aumentaron en promedio de forma drástica en la última década, el valor estándar del período de congestión inicial de TCP se mantuvo sin cambios. En este documento, proponemos aumentar la ventana de congestión inicial del TCP a al menos diez segmentos (alrededor de 15 KB). A través de experimentos de Internet a gran escala, cuantificamos los beneficios y costos de latencia de usar una ventana más amplia, como funciones de ancho de banda de red, tiempo de ida y vuelta (RTT), producto de retraso de ancho de banda (BDP) y naturaleza de las aplicaciones. Demostramos que la latencia promedio de las respuestas HTTP mejoró aproximadamente en un 10%. Los mayores beneficios se demostraron en redes con un alto RTT y BDP. La latencia de las redes con bajo ancho de banda también mejoró significativamente en nuestros experimentos. La tasa de retransmisión promedio aumentó en un modesto 0.5%, y la mayor parte del aumento provino de aplicaciones que eluden eficazmente el algoritmo de inicio lento de TCP mediante el uso de varias conexiones simultáneas. Según los resultados de nuestros experimentos, creemos que la ventana de congestión inicial debería ser de al menos diez segmentos, y el IETF debe investigar estos mismos para su estandarización.

TCP Fast Open

En la actualidad, los servicios web están dominados por flujos TCP tan cortos que finalizan algunas idas y vueltas después del protocolo de enlace. Este protocolo de enlace es una fuente importante de latencia para esos flujos. En este documento, describimos el diseño, la implementación y la implementación del protocolo TCP Fast Open, un nuevo mecanismo que permite el intercambio de datos durante el protocolo de enlace inicial del TCP. De este modo, TCP Fast Open disminuye la latencia de red de la aplicación en un tiempo de ida y vuelta completo, lo que disminuye el retraso que experimentan las transferencias de TCP tan cortas. Abordamos los problemas de seguridad inherentes a permitir el intercambio de datos durante el protocolo de enlace de tres vías, que mitigamos con un token de seguridad que verifica la propiedad de la dirección IP. Detallamos otros mecanismos de defensa de resguardo y abordamos los problemas que encontramos con los dispositivos intermedios, la retrocompatibilidad con las pilas de red existentes y la implementación incremental. En función del análisis de tráfico y la emulación de la red, demostramos que TCP Fast Open reduciría la latencia de red de la transacción HTTP en un 15%y el tiempo de carga de toda la página más de un 10% en promedio y, en algunos casos, hasta un 40%.

Reducción de la tasa proporcional para TCP

Las pérdidas de paquetes aumentan la latencia para los usuarios de la Web. La recuperación rápida es un mecanismo clave para que TCP se recupere de la pérdida de paquetes. En este informe, exploramos algunas de las debilidades del algoritmo estándar descrito en RFC 3517 y los algoritmos no estándar implementados en Linux. Descubrimos que estos algoritmos se desvían del comportamiento previsto en el mundo real debido al efecto combinado de los flujos cortos, los bloqueos de aplicaciones, las pérdidas por aumentos de actividad, la pérdida de reconocimiento (ACK) y el reordenamiento, y las confirmaciones extendidas. Linux sufre reducciones excesivas de períodos de congestión, mientras que RFC 3517 transmite grandes picos de actividad con pérdidas altas, que dañan el resto del flujo y aumentan la latencia web. Nuestra contribución principal es un nuevo diseño para controlar la transmisión en la recuperación rápida llamado reducción proporcional de la tasa (PRR). La PRR se recupera de las pérdidas de forma rápida, fluida y precisa mediante el ritmo de las retransmisiones entre las ACK recibidas. Además de la PRR, evaluamos el algoritmo de retransmisión temprana (ER) del TCP, que reduce el umbral de confirmación de duplicados para transferencias cortas, y mostramos que retrasar las retransmisiones tempranas durante un intervalo corto es eficaz para evitar las retransmisiones falsas en presencia de un pequeño grado de reordenamiento. PRR y ER reducen la latencia de TCP de las conexiones que experimentan pérdidas en un 3% a 10%, según el tamaño de la respuesta. En función de nuestra instrumentación en los servidores web de Google y YouTube en EE.UU. y la India, también presentamos estadísticas clave sobre la naturaleza de las retransmisiones de TCP.

Laminar TCP

Laminar es un nuevo framework para el control de la congestión de TCP que separa la programación de la transmisión, que determina con precisión cuándo se envían los datos, del control puro de la congestión, que determina la cantidad total de datos enviados durante cada RTT. Se espera que Laminar habilite nuevos algoritmos avanzados para regular el tráfico de TCP con mayor precisión.

Borradores de SSL y TLS

Inicio falso de la seguridad de la capa de transporte (TLS)

False Start es un comportamiento opcional de las implementaciones de TLS. Solo afecta la sincronización del protocolo, no los datos de protocolo en cable, y se puede implementar de manera unilateral. La función TLS False Start reduce la latencia de un proceso de ida y vuelta para ciertos protocolos de enlace.

Extensión de negociación del protocolo siguiente de seguridad de la capa de transporte (TLS)

Extensión de seguridad de la capa de transporte (TLS) para la negociación del protocolo de la capa de la aplicación. Esto permite que la capa de aplicación negocie qué protocolo se debe aplicar en la conexión segura, de forma que se eviten las idas y vueltas adicionales y que sea independiente de los protocolos de la capa de aplicación.

Borrador de DNS

Subred del cliente en las solicitudes de DNS

Este borrador define una extensión EDNS0 para llevar información sobre la red que originó una consulta de DNS, y la red para la que se puede almacenar en caché una respuesta.