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

[Gael Hernandez]

Nico, Hugo: de acuerdo con vuestros comentarios acerca de la geografía 
como métrica, y que quizá puede producir anomalías en el ruteo que no 
son para nada beneficiosas para el usuario final.

Para un operador anycast como PCH, entregar el trafico DNS lo mas cerca 
posible (ciudad/pais/region/continente) del usuario final y evitar 
ruteos en el peor de los casos a otro continente forma parte de los 
desafíos a los que intentamos poner solución.

Saludos,
Gaël

On 5 Oct 2018, at 13:13, Nicolas Antoniello wrote:

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


> _______________________________________________
> 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/20181008/e37e7e80/attachment.html>