[lacnog] Internet Anycast: Performance, Problems, & Potential

[Nicolas Antoniello]

Interesante...
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.
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.

Saludos,
Nico


El El jue, 4 de oct. de 2018 a las 14:07, Hugo Salgado-Hernández <
hsalgado en nic.cl> escribió:

> Hola Gaël, gracias por el paper!
> En resumen el estudio está diciendo que en los casos en que BGP da
> rutas de igual costo a un destino, muchas veces se termina dirigiendo
> a lugares "poco eficientes" en distancia/tiempo. Para eso proponen una
> extensión a BGP que agregue datos "geográficos" a las rutas, para usarlo
> como argumento en estos casos.
>
> En lo personal creo que la geografía no lo es todo! Bien sabemos que la
> distancia y tiempo es solo 1 de los factores a considerar, frente a
> otros incluso más importantes como los económicos, estratégicos, etc.
>
> Igual me parece bien que se agregue un factor de decisión extra al
> BGP. Puede ayudar en ciertos casos, pero las políticas de ruteo son
> bastante más complejas como para determinar que porque llego a una
> instancia más lejos que otra, eso sea necesariamente "malo"!
>
> Saludos,
>
> Hugo
>
> On 09:52 25/09, Gael Hernandez wrote:
> > Hola a todos,
> >
> > Para aquellos con interés en el enrutamiento IP anycast y su
> rendimiento, un
> > nuevo paper sobre el tema
> >
> > https://www.cs.umd.edu/~dml/papers/anycast_sigcomm18.pdf
> >
> > Saludos,
> > Gaël
> >
> >
> > **Abstract**
> >
> > Internet anycast depends on inter-domain routing to direct clients to
> their
> > “closest” sites. Using data collected from a root DNS server for over a
> year
> > (400M+ queries/day from 100+ sites), we characterize the load balancing
> and
> > latency performance of global anycast. Our analysis shows that site loads
> > are often unbalanced, and that most queries travel longer than necessary,
> > many by over 5000 km.
> >
> > Investigating the root causes of these inefficiencies, we can attribute
> path
> > inflation to two causes. Like unicast, anycast routes are subject to
> > inter-domain routing topology and policies that can increase path length
> > compared to theoretical shortest (e.g., great-circle distance). Unlike
> > unicast, anycast routes are also affected by poor route selection when
> paths
> > to multiple sites are available, subjecting anycast routes to an
> additional,
> > unnecessary, penalty.
> >
> > Unfortunately, BGP provides no information about the number or goodness
> of
> > reachable anycast sites. We propose an additional hint in BGP
> advertisements
> > for anycast routes that can enable ISPs to make better choices when
> multiple
> > “equally good” routes are available. Our results show that use of such
> > routing hints can eliminate much of the anycast path inflation, enabling
> > anycast to approach the performance of unicast routing.
> >
>
> > _______________________________________________
> > LACNOG mailing list
> > LACNOG en lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/lacnog
> > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20181005/431ab22f/attachment-0001.html>