<div><div dir="auto">Interesante...</div></div><div dir="auto">Yo estoy bastante de acuerdo con las consideraciones de Hugo, la “geografía” nunca fue una metrica para el ruteo, a excepción del deseo de que (exclusivamente por temas de seguridad) mis paquetes no pasen por determinada red o redes.</div><div dir="auto">Nuevamente, en términos de seguridad podría considerarse, lo cual finalmente complicaría aún más la ineficiencia en la práctica, creo yo... ahora bien, en términos de velocidad no veo ventajas prácticas por ahora y hay un montón de razones por las que seguramente la cosa empeore con esa métrica, porque las redes rara vez mapean geografía y porque además se me ocurre que para que eso funcione realmente el protocolo tendría que conocer el mapa completo de la red y justamente BGP no es Link State.</div><div dir="auto"><br></div><div dir="auto">Saludos,</div><div dir="auto">Nico</div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr">El El jue, 4 de oct. de 2018 a las 14:07, Hugo Salgado-Hernández <<a href="mailto:hsalgado@nic.cl">hsalgado@nic.cl</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hola Gaël, gracias por el paper!<br>
En resumen el estudio está diciendo que en los casos en que BGP da<br>
rutas de igual costo a un destino, muchas veces se termina dirigiendo<br>
a lugares "poco eficientes" en distancia/tiempo. Para eso proponen una<br>
extensión a BGP que agregue datos "geográficos" a las rutas, para usarlo<br>
como argumento en estos casos.<br>
<br>
En lo personal creo que la geografía no lo es todo! Bien sabemos que la<br>
distancia y tiempo es solo 1 de los factores a considerar, frente a<br>
otros incluso más importantes como los económicos, estratégicos, etc.<br>
<br>
Igual me parece bien que se agregue un factor de decisión extra al<br>
BGP. Puede ayudar en ciertos casos, pero las políticas de ruteo son<br>
bastante más complejas como para determinar que porque llego a una<br>
instancia más lejos que otra, eso sea necesariamente "malo"!<br>
<br>
Saludos,<br>
<br>
Hugo<br>
<br>
On 09:52 25/09, Gael Hernandez wrote:<br>
> Hola a todos,<br>
> <br>
> Para aquellos con interés en el enrutamiento IP anycast y su rendimiento, un<br>
> nuevo paper sobre el tema<br>
> <br>
> <a href="https://www.cs.umd.edu/~dml/papers/anycast_sigcomm18.pdf" rel="noreferrer" target="_blank">https://www.cs.umd.edu/~dml/papers/anycast_sigcomm18.pdf</a><br>
> <br>
> Saludos,<br>
> Gaël<br>
> <br>
> <br>
> **Abstract**<br>
> <br>
> Internet anycast depends on inter-domain routing to direct clients to their<br>
> “closest” sites. Using data collected from a root DNS server for over a year<br>
> (400M+ queries/day from 100+ sites), we characterize the load balancing and<br>
> latency performance of global anycast. Our analysis shows that site loads<br>
> are often unbalanced, and that most queries travel longer than necessary,<br>
> many by over 5000 km.<br>
> <br>
> Investigating the root causes of these inefficiencies, we can attribute path<br>
> inflation to two causes. Like unicast, anycast routes are subject to<br>
> inter-domain routing topology and policies that can increase path length<br>
> compared to theoretical shortest (e.g., great-circle distance). Unlike<br>
> unicast, anycast routes are also affected by poor route selection when paths<br>
> to multiple sites are available, subjecting anycast routes to an additional,<br>
> unnecessary, penalty.<br>
> <br>
> Unfortunately, BGP provides no information about the number or goodness of<br>
> reachable anycast sites. We propose an additional hint in BGP advertisements<br>
> for anycast routes that can enable ISPs to make better choices when multiple<br>
> “equally good” routes are available. Our results show that use of such<br>
> routing hints can eliminate much of the anycast path inflation, enabling<br>
> anycast to approach the performance of unicast routing.<br>
> <br>
<br>
> _______________________________________________<br>
> LACNOG mailing list<br>
> <a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
> <a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
> Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
<br>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div></div>