[uylug-varios] Adelantados en IPv6 y problema de latencia

[Carlos M. Martinez]

Hola! Excelente explicación. ,

Sent from my iPad

On Jun 6, 2012, at 11:54 PM, Eduardo Trápani <etrapani at unesco.org.uy> wrote:

>> Los navegadores nuevos miden performance y toman la dirección del stack que puntualmente este funcionando mejor. 
> 
> Mmmmmm, no la puedo dejar pasar.  No se trata de elegir el que esté "funcionando mejor" porque hay una preferencia predefinida (aplicación o sistema o bibliotecas) que te puede hacer elegir el peor tranquilamente.  Acá van los comportamientos de tres navegadores, versión breve y ampliada.

De acuerdo, pero es básicamente eso con un bias hacia ipv6 en general.


> 
> * Versión breve
> Chrome le da una manito a IPv6 (la prefiere), MacOSX y sus bibliotecas básicamente dejan elegir al sistema operativo la prioridad y después dejan competir los dos protocolos, pero en igualdad de condiciones.  Firefox le da una manito al protocolo que prefiere el sistema, que puede ser cualquiera de los dos.
> 
> * Versión ampliada
> Si alguien quere más detalles, sigue abajo:
> 
> Chrome:
> Intenta la conexión con IPv6 y espera 300ms, si no recibe respuesta intenta la conexión con IPv4 (la de IPv6 todavía está esperando).  A partir de ahí la primera que complete es con la que te quedás.  Por temas de "política de mismo origen" (y para no matar la red con conexiones duplicadas) esa prueba no se hace todo el tiempo.  Conclusión, si tu IPv6 funciona "peor" pero no tan peor como para demorar más de 300ms, se queda con la IPv6 igual.[1]
> 
> MacOSX Lion (acá la decisión se toma en una biblioteca del sistema operativo, no en el navegador, pensá en Safari):
> Primero listas las interfaces y si ve una con estadísticas de ruteo mejor que las otras, entonces la usa.  Si no ... bueno, ahí lo explica, pero utiliza otra manera de elegir.
> En la biblioteca común de conexión lo que se hace es arrancar las dos conexiones IPv4 e IPv6 y quedarse con la que conteste primero.[2]
> 
> Firefox:
> Es más o menos como lo de Chrome.  Intento con la familia de direcciones elegida por el sistema (que puede ser IPv4 o IPv6) y arranco el timer.  Si no se conecta, pruebo con otra dirección.  La redacción es complicada porque están intentando preservar la elección de prioridad del sistema (no darle la prioridad a IPv6 sin más) y el orden de direcciones obtenidas para el host al que se quieren conectar[3].
> 
> Así que hay un algoritmo (happy-eyeballs o algo similar) para elegir el protocolo.  De ahí a que el elegido sea el que funciona mejor ... hay una gran gran distancia (como quedó demostrado con el caché de Youtube del otro hilo).  Sobre todo porque juegan las preferencias del navegador o del sistema o incluso del proxy, que inclinan la balanza.  El más "democrático" parece ser el de Apple que los hace correr juntos.  Firefox es respetuoso y Chrome mira al futuro.
> 
> Este artículo[4] está interesante y acá [5] hay un sitio roto en IPv6 que está roto a propósito para ver cuánto demoran los navegadores en darse cuenta que IPv6 no anda e ir a IPv4.
> 
> * Sobre tus "cruces" de protocolos:
> 
>>> mio(ipv4)->FB(ipv4)
> 
> Anda (pero no era necesario aclararlo, ¿no? ;))
> 
>>> mio(ipv4)->FB(ipv6) via tunel
> 
> Precisa nat (como decía Carlos) o un proxy (en mi caso tengo un squid que habla IPv4/IPv6 para afuera y sólo IPv4 hacia la clientes.
> 
> Lo del proxy puede parecer trampa, pero no lo es.  Si se establece un http connect de hecho podría ser una charla ipv4<->ipv6 en la que el cliente no sabe que del otro lado hay un ipv6.
> 
>>> mio(ipv6)->FB(ipv4) esta seria posible????
> 
> Sí.  Precisa de DNS64 y de NAT64 (o un proxy bilingüe como el de arriba, por ejemplo en una red ipv6-only).
> 
>>> mio(ipv6)->FB(ipv6) esto seria el futuro ideal a lo que aspiran supongo
> 
> Sí :).  Lo ideal depende también de la dirección y conectividad ipv6.  Digamos que ideal-ideal sería sin tecnologías de transición, ni nat.  Un "punta a punta" con ipv6 públicas.  Pero creo que todos los que estamos peleando por esto transamos felices en un casi-ideal ;).  De hecho IPv4 va a estar ahí todavía cuando nosotros ya no.
> 
>>> Cual seria la que tendria mayor prioridad? donde se programan esas cosas? como para ir aclarando uno de los posibles escenarios que se podrian dar.
> 
> La prioridad depende del programa (lo de arriba) y de getaddrinfo() (obtener información de direcciones).  Eso se configura (en Linux) en /etc/gai.conf.  Esto hace que las direcciones para un host se ordenen antes de dárselas a la aplicación, pero después cada programa puede a su vez modificar/reordenar la lista.  Si Chrome va a preferir IPv6 sí o sí y vos le decís a getaddrinfo en gai.conf que IPv4 es la preferida, va a "ganar" Chrome, que es quien elige una dirección entre todas para hacer el connect() inicial y los que hagan falta.
> 
> Además la prioridad depende del tipo de dirección IPv6 que tengas.  Todo lo de arriba es cierto por lo menos para IPv6 públicas nativas.  No quiero hacerlo mucho más largo, pero por poner un ejemplo, si tenés una dirección teredo como yo ahora, el sistema o la aplicación va probablemente a preferir IPv4 y no esa IPv6 "de transición".
> 
> Saludos, Eduardo.
> 
> [1] http://code.google.com/p/chromium/issues/detail?id=81686
> [2] http://lists.apple.com/archives/ipv6-dev/2011/Jul/msg00009.html
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=684893#c6
> [4] https://labs.ripe.net/Members/emileaben/hampered-eyeballs
> [5] http://intentionally.broken.dualstack.wdm.sg.ripe.net/
> _______________________________________________
> Uylug-varios mailing list
> Uylug-varios at listas.uylug.org.uy
> http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy