Evaluando la efectividad de "Happy Eyeballs"

El IETF ha desarrollado soluciones que promuevan una convivencia sana entre IPv4 e IPv6. El algoritmo "happy eyeballs", por ejemplo, ofrece recomendaciones a los desarrolladores de aplicaciones para ayudar a prevenir la mala experiencia de usuario en situaciones donde la conectividad IPv6 está caida.

Motivación

La función "getaddrinfo" resuelve un nombre de servicio a una lista de puntos finales en un orden que dé prioridad a una ruta IPv6. El orden puede reducir drásticamente la capacidad de respuesta de la aplicación cuando la conectividad IPv6 está caida. La experiencia de usuario perdida puede alterarse por la aplicación del algoritmo de happy eyeballs. El algoritmo recomienda que un anfitrión, después de resolver el nombre del servicio, intente una TCP "connect", para el primer punto final. Sin embargo, en lugar de esperar un tiempo, espera solo 300 ms, después de lo cual se debe iniciar otro TCP "connect" a un punto final con una familia de direcciones diferente y comenzar un concurso para escoger el que termina primero.

Métrica

Se definió una métrica que utiliza la conexión TCP estableciendo el tiempo como un parámetro para medir el algoritmo eficacia. La metodología también ayuda a examinar el impacto de la construcción de mecanismos de túneles empleados por los primeros adoptantes. El parámetro de entrada de la métrica es una (dirección IP, número de puerto) tupla y el de salida es el tiempo de establecimiento de la conexión, típicamente medido en microsegundos.

Implementación

Se desarrolló "happy", una herramienta simple TCP de happy eyeballs que se ajusta a la definición de la métrica sondeo. Utiliza un "connect" sin bloqueo que establecer conexiones de forma simultánea a todos los extremos de un servicio y mide el tiempo transcurrido. La herramienta aplica un pequeño retraso entre el concurrente "connect", llama para evitar ráfagas de tráfico TCP SYN. La resolución de nombres de servicio realizado en un principio no se tiene en cuenta en el establecimiento de la conexión del tiempo transcurrido.

Mediciones Trials

Utilizamos el Alexa top 1M como insumo para preparar un top 100 de nombres de servicio en dual-stack. Se corre "happy" en el banco de pruebas internas de múltiples agentes de medición con diferentes sabores de conectividad como IPv4 nativo, IPv6 nativo, puntos finales IPv6 Tunnel Broker , Teredo y tunelizados IPv4.

Análisis de datos Insight

Los resultados iniciales muestran mayores tiempos de conexión y variaciones a través de IPv6, como se muestra en la gráfica a continuación (puede dar click sobre la imagen para verla más grande). Parece que una aplicación nunca utiliza IPv6 utilizando Teredo excepto cuando la conectividad IPv4 está caída. Se dió cuenta de que una ventaja de 300ms deja un host con dual-stack tan sólo 1% de probabilidad de preferir una ruta IPv4 a pesar de que puede ser significativamente más rápido que IPv6.

Gráfica: Tiempo y sus desviaciones estándar medias para establecer conexiones TCP a una lista de servicios web. El agente de medición es un servidor que se encuentra en la Universidad de Braunschweig. Cuenta con conectividad IPv4 e IPv6 nativo a través de la Red de Investigación Alemana.

FUENTE.