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

[Arturo Servin]

	A mi toda esta conversación me parece "me quiero quejar porque Google habilito IPv6 sin cuidado y ahora estoy peor".

	Y la cosa es mucho más compleja que esto, no voy a entrar en detalle pero me parece excelente que google tenga IPv6 en Youtube y al que no le guste que apague IPv6 o que se vaya a ver videos a otro lado.

Slds
as

On 5 Jun 2012, at 12:53, Eduardo Trápani wrote:

>> Google no tiene como saber que no está la capacidad disponible.
> 
> ¿¿Eee??  ¿Contratás colocation y no sabés?  Mirá ...
> 
>> Es ese servidor el que tiene una IPv6 nativa en un lugar donde no hay
>> buena conectividad IPv6.
> 
> Supongo que incluís el ruteo en la conectividad.  La IPv6 asignada no es
> uruguaya.  Así que tendría que usar anycast.  Es difícil pretender que
> todo eso es ajeno a Google ...  Ponele una IPv6 uruguaya, publicá la
> ruta, hacé anycast, algo de eso y queda todo bárbaro.  Y ojo, estás en
> el corazón de la conectividad del país.
> 
> En cualquier caso, mi problema es el mismo.  Si antes de "desplegar"
> IPv6 en ese nodo hubieran hecho *una* prueba, sabrían que me estaban
> alejando el contenido.
> 
>> En realidad hasta hace pocos años tampoco habia buena conectividad
>> IPv4 porque para llegar a buena parte de Argentina o Brasil tenias que
>> ir por Miami.... eso cambió ?
>> Si se arregló en IPv4, no pasa con IPv6 ?
> 
> No, no tiene por qué.  Los arreglos de intercambio pueden ser diferentes
> (en teoría calculo que todo debería converger).
> 
>> Por otra parte, el DNS te resolvió una IP en BsAs. Si tenes 300ms a
>> una IP en BsAs .. es problema de Google ?
> 
> :)  La pregunta es porqué un servidor en colocation en Uruguay para
> hacer de caché dentro del país tendría que resolver a una IP en
> Argentina ...
> 
>> Es problema de Google que Antel no tenga IPv6 ?
> 
> A ver, para empezar Antel sí tiene IPv6.  Para seguir ¿quién maneja el
> DNS de youtube?  ¿Alguien *obliga* a Google a publicar un AAAA?  Si sí,
> entonces no es problema de Google, pobres, tuvieron que publicar y
> eligieron lo más cercano.  Pero si nadie los obliga, entonces sí son
> culpables, por no verificar si la colocation que contrata tiene esa
> conectividad, que la tiene, y por no verificar que la dirección
> estuviera en el mismo "dominio".  *Parece* simple.
> 
> Hace poco reporté un sitio de la RAU que tenía ese problema.  El
> administrador agarró y publicó el AAAA.  Sería un túnel o algo, que se
> cayó.  Como nadie lo levantó para mí el sitio estaba muerto (happy
> eyeballs será muy lindo, pero no todos lo implementan).  Lo que la gente
> no termina de entender es que publicar un AAAA significa dejar ese sitio
> como ipv6-only para los nativos.
> 
> Y me gusta ser nativo y ayudar a que esto ruede cada vez mejor, pero me
> choca un poco que alguien pretenda que rueda solamente por ser redondo.
> Hay que empujar un poquito también.
> 
>> A vos te parece que Google tiene tiempo de hacer una configuración
>> especial para cada caso ? Quizas si tiene pero si tengo que apostar
> 
> ¿Y yo qué sé?  Veo el nombre del servidor y parece que sí, no se llama
> "jpqrs", se llama "antel-mvd1" tiene bien definido un nombre según el
> proveedor y la ciudad, saben dónde está y qué hace y a quién sirve.  Me
> sorprende como se puede pasar, en relación a Google ahora, a Microsoft
> hace algún tiempo, de la omnisapiencia con soluciones infinitas a
> problemas debidos a la escasez de recursos en un abrir y cerrar de ojos
> ;). (y no lo digo especialmente por vos).
> 
>> diría que te van a direccionar al servidor mas 'cercano' que esté en
>> mejor   'condición' de atenderte con IPv6... seguramente para el caso
>> de UY esto no esté funcionando bien.
> 
> A mí se me pueden ocurrir mil excusas.  Podemos seguir por el tamaño de
> Uruguay, la cantidad de tráfico afectado (IPv6 nativo en Uruguay).  Pero
> mi preocupación es más general, estoy tratando de decir al resto de los
> hinchas de IPv6, "no publiquemos AAAA sólo porque se puede, le pueden
> estar complicando la vida a quienes no tenían ningún problema".
> Tratemos de dar un mismo nivel de servicio, o parecido y verificarlo
> *antes*.
> 
> Creo que es bueno tener eso en cuenta.  No quiero atacar a Google, si
> quieren ponemos en la misma bolsa todas las excusas que ya manejamos,
> con las de arriba, y lo dejamos por ahí.  Con el AAAA yo llego,
> *obligado*, más de tres veces más lento a un servidor de CDN
> supuestamente para Uruguay.  Me jodo, no hay drama.  O bajo el stack de
> IPv6 del servidor de squid hasta que todo madure.  Porque por mucho que
> argumenten 300ms contra 90ms es un hecho.  Si quieren ver todo rosa,
> está bien, algunos pueden (podemos) esperar a que efectivamente lo esté.
> 
> Yo que sé, con Debian pasó que hicieron geodns y resulta que el sitio
> principal nos quedaba en Brasil (con rutas medio horribles).  Hecha la
> consulta ofrecieron cambiar la resolución para que UY prefiriera a EEUU,
> que nos quedaba más cerca.  Todo el mundo le puede errar.  Por suerte en
> Debian además nos escucharon y trataron de arreglarlo.  Y a Debian le
> escribo y le aviso, pero de Google espero que se den cuenta solitos ;).
> 
>> Disclaimer: no tengo nada que ver con el area de Traffic de Google así
>> que ignoro mas de lo que se.
> 
> Mmmm, voy a ver si te creo, pidiendo traceroutes y todo :).  Hablando en
> serio, si lograste que eso llegara a alguien que lo pueda arreglar, genial.
> 
> Eduardo.
> _______________________________________________
> Uylug-varios mailing list
> Uylug-varios at listas.uylug.org.uy
> http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy