[lacnog] Consultas acerca de Google Cache

Dom Jun 16 20:20:03 BRT 2013

Excelente tool Ariel,
te comento un detalle... en la nomenclatura actual de los nodos GGC suele
haber muchos hostsname del tipo:

r5---sn-a8au-hp5e.c.youtube.com

Me parece que debería ser un poco mas permisiva la expresión regular.

Con respecto al host de ejemplo, es donde están mapeando en este momento
varios ISPs argentinos conectados al NAP de CABASE, donde Google tiene
peering directo y un nodo GGC local... pero igualmente el algoritmo
prefiere un host internacional y distante para los prefijos del ISP. Ocurre
esa preferencia tanto para vídeos regionalmente populares como aleatorios.

Slds.

El 12 de junio de 2013 15:14, Ariel Weher <ariel en weher.net> escribió:

> Aca tengo un script bash bastante rústico que por ahí puede acortar los
> tiempos:
>
> La idea es que trae los videos populares del país seteado en la variable
> PAIS y luego analiza las direcciones IPv(4|6) de los hostnames
> representados en los sources de cada video.
>
> Espero les sirva para hacer análisis:
>
> <!-- script
>
> #!/bin/bash
> # Modificar y distribuir libremente
> # Gracias a S. Segovia y a M. Troncoso por los aportes
>
> PAIS=AR
>
> N=0
> echo > /tmp/caches.txt
> echo > /tmp/caches-v4.txt
> echo > /tmp/caches-v6.txt
> echo > /tmp/caches-organizaciones.txt
>
> for VIDEO in `links -source http://www.youtube.com/?gl=$PAIS | grep -o -P
> "watch.v"............ | sort -u`; do
>         let N=$N+1
>         C=0
>         for SERVER in `links -source "http://www.youtube.com/$VIDEO" |
> grep -o -P ...---sn-........'.c.youtube.com' | sort -u`; do
>                 let C=$C+1
>                 CACHE=`echo $SERVER | sed 's/^.r/r/g'`
>                 echo $CACHE >> /tmp/caches.txt
>                 sort -u /tmp/caches.txt > /tmp/caches-unicos.txt
>                 for HOST in `cat /tmp/caches-unicos.txt`; do
>                         IPV4=`dig +short A $HOST | tail -1`
>                         IPV6=`dig +short AAAA $HOST | tail -1`
>                         echo "$IPV4" >> /tmp/caches-v4.txt
>                         echo "$IPV6" >> /tmp/caches-v6.txt
>                 done
>                 cat /tmp/caches-v?.txt | sort -u > /tmp/caches-ip.txt
>         done
> done
>
> for host in `cat /tmp/caches-ip.txt`; do
>         whois $host | grep -P "(owner:|OrgName)" >>
> /tmp/caches-organizaciones.txt
> done
>
> echo "Los cache de youtube que se estan usando estan en:"
> sort -u /tmp/caches-organizaciones.txt
> echo "Presione enter para continuar"
> read null
> echo "Listado de direcciones IPv4 de los cache"
> cat /tmp/caches-v4.txt
> echo "Presione enter para continuar"
> read null
> echo "Listado de direcciones IPv6 de los cache"
> cat /tmp/caches-v6.txt
>
> -->
>
>
>
>
>
> 2013/6/7 Ivan Chapero <info en ivanchapero.com.ar>
>
>> Alex, esto no tiene que ver con el dimensionamiento de la última milla.
>> Los enlaces que menciono en el ejempo que saturan no es por una excesiva
>> sobreventa sino porque el mayor generador de downstrea-traffic (Youtube)
>> tiene un comportamiento oscilante y poco estable que rompe con el
>> load-balance diseñado.
>>
>> Es cierto que el ISP de acceso siempre tiende a hacer shaping o estar al
>> limite de lo contratado en sus enlaces. Pero tampoco se puede pedir a un
>> ISP de acceso que contrate  "trafico pico normal" x 2 en cada carrier para
>> prevenir un eventual flapeo de Youtube. Otro dato, en Argentina el
>> percentil 95 no existe como contrato.
>>
>> Pongamos el ejemplo del DC de Chile cuando se encuentre activo.... los
>> ISP nacionales seguro interconecten directa o indirectamente. Esto llevara
>> a una descompresión importante de la carga sobre los enlaces de internet
>> "general" que contratan dichos ISPs. Ahora dimensionaran sus enlaces
>> restando gran parte del tráfico de Google ya que lo tienen en un IX local.
>>
>> Imaginate el problema si de repente el tráfico que esperabas ingrese por
>> el DC de Chile empieza a ingresar por los links internacionales/internet de
>> manera abrupta. Ese es nuestro caso.
>>
>>
>> Slds.
>>
>> El 7 de junio de 2013 18:35, Alex Ojeda <alex en chilenetworks.com>escribió:
>>
>>>  Estos problemas cada vez son más comunes y agresivos… ****
>>>
>>> Pero “no importa…” continúen los ISP vendiendo conexiones de 10 , 20 ,
>>> 40 , 100 megas a usuarios finales… teniendo la misma infraestructura de 5
>>> años atrás…****
>>>
>>> ** **
>>>
>>> Los puntos de interconexión en muchos países no han evolucionado a
>>> nuevas y mejores infraestructuras… ****
>>>
>>> Gigantes como Google generan cache regionales que ayudan a su propia
>>> existencia. Se preocupan de evolucionar. ¿Y nosotros?****
>>>
>>> ** **
>>>
>>> Al menos, en la región se vendrá un respiro con el nuevo Datacenter de
>>> Google que se está construyendo en Chile. ****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> Saludos!****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> Alex Matias Ojeda Mercado****
>>>
>>> Chile Networks SpA.****
>>>
>>> Fono: (+56 2) 58 58 120****
>>>
>>> Fono: (+56 2) 58 30 117****
>>>
>>> Móvil: (+56 9) 719 22 362****
>>>
>>> https://chilenetworks.com/****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> Correo Electrónico Procesado en la Plataforma Microsoft Exchange
>>> Office365****
>>>
>>> Servicios Corporativos en la nube.****
>>>
>>> Estos servicios son entregados por Chile Networks SpA.****
>>>
>>> ** **
>>>
>>> Mail Disclaimer :****
>>>
>>> Descargo de responsabilidad Correo electronico :****
>>>
>>> https://chilenetworks.com/g/maildisclaimer/****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *De:* lacnog-bounces en lacnic.net [mailto:lacnog-bounces en lacnic.net] *En
>>> nombre de *Ivan Chapero
>>> *Enviado el:* viernes, 07 de junio de 2013 17:02
>>> *Para:* Latin America and Caribbean Region Network Operators Group
>>> *Asunto:* Re: [lacnog] Consultas acerca de Google Cache****
>>>
>>> ** **
>>>
>>> Estimados,****
>>>
>>> soy operador de NOC de Argentina en varios ISPs de acceso. Confirmo y
>>> reafirmo la inquietud de Ariel.****
>>>
>>> ** **
>>>
>>> Entiendo que Google puede guardar como secreto comercial los detalles
>>> del algoritmo CDN pero como operadores y administradores de los
>>> enlaces deberíamos tener un contacto más fluido y directo ante
>>> la detección de comportamientos erróneos que afectan a los
>>>  clientes detrás del ASN gestionado. Si no vamos a
>>> tener información pública de como opera y se persuade la elección de los
>>> mejores nodos GGC, por lo menos deberíamos contar con una herramienta de
>>> reporte que genere un escalamiento y procesos internos por parte de Google
>>> que terminen reflejando los cambios deseados.****
>>>
>>> ** **
>>>
>>> Parece que el trato fluido es con los grandes carriers que disponen
>>> colocar en su backbone un nodo GGC, pero no con los operadores de ISPs de
>>> acceso, que son en definitiva los que aportan sus clientes en el despacho
>>> de contenidos de los caches.****
>>>
>>> ** **
>>>
>>> *Pregunta: la alternancia que ven es para un mismo cliente (es decir,
>>> accediendo desde una misma direccion IP) o se da que para algunas
>>> direcciones IP acceden al local y para otras al remoto??*****
>>>
>>> ** **
>>>
>>> Sucede con las IPs de TODO el ASN. Expongo un caso puntual y real para
>>> que se interprete mejor:****
>>>
>>> ** **
>>>
>>> - Un ISP multi-homed con TELECOM Arg (TECO) y TELEFONICA Arg (TASA) como
>>> carriers contratados.****
>>>
>>> - El ISP dispone de ASN y prefijos propios que anuncia por ambos
>>> carriers, prependeando algunos sobre uno y otro link para lograr el
>>> load-balance.****
>>>
>>> - TECO dispone un nodo GGC local de latencia mínima (10-15ms).****
>>>
>>> - TASA dispone de un nodo GGC indirectamente de su carrier internacional
>>> TIWS, como es un enlace internacional la latencia promedio es 190ms hacia
>>> los hosts de ese nodo.****
>>>
>>> - Desde la activación del nodo local de TECO, tanto para los prefijos
>>> anunciados sin prepends por TECO (con prepend por TASA) como los
>>> prependeados por el mismo link (sin prepend por TASA) el trafico Youtube
>>> era mapeado de manera estable y sostenida al nodo GGC local. Lo que parece
>>> coherente dado que se estaba disputando el despacho del streaming entre un
>>> host extremadamente nacional y otro internacional.****
>>>
>>> - Por esta razón el balanceo BGP se tuvo que
>>> modificar dramáticamente dado que, independientemente de los prepends, el
>>> 90% del tráfico Youtube ingresaba por el link de TECO.****
>>>
>>> ** **
>>>
>>> - Hace un tiempo de manera extraña, y al menos desde mi extremo
>>> injustificada, en ciertos horarios esta clase de tráfico switchea
>>> bruscamente y se migra al enlace de TASA. Se comienza a ver que para todos
>>> los prefijos el mapeo de la reproducción de Youtube empieza a apuntar a
>>> hosts del nodo GGC de TIWS (salida internacional de TASA). ****
>>>
>>> ** **
>>>
>>> - Esto produce una terrible saturación sobre el enlace de TASA dado que
>>> el anuncio de rutas estaba acomodado de manera tal que no se contara con
>>> esa importante carga que aporta Youtube por estar ingresando por TECO.
>>> Termina afectando entonces, no solo la performance de Youtube, sino a todas
>>> las conexiones que hacen downstream-traffic por dicho link para las IP del
>>> ASN. Se debe estar encima de las gráficas de consumo para empezar a
>>> "patear" prefijos hacia TECO y así descomprimir TASA, algo poco práctico y
>>> que no escala.****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>>   Si el cache cercano esta en su limite de capacidad o sin
>>> disponibilidad del video solicitado, la alternativa es lo cache a +200.
>>> ****
>>>
>>>  ****
>>>
>>> ** **
>>>
>>> Rubens****
>>>
>>> ** **
>>>
>>>  ** **
>>>
>>> Rubens, para este caso no es un factor válido (nodo GGC local saturado)
>>> porque al momento de perder el cache de TECO para las IPs del ISP
>>> multi-homed en cuestión se verifica sobre otros ISPs que tiene ÚNICAMENTE a
>>> TECO como carrier y en ese escenario el mismo cache local
>>> sigue sirviendo sin problemas contenidos en casi la totalidad de las
>>> consultas. Parece una disputa entre el cache local de TECO y el
>>> internacional de TIWS que ganan y pierden de manera brusca uno y otro.**
>>> **
>>>
>>> ** **
>>>
>>>    ¿Tienen idea de cómo funciona el algoritmo de selección de cache de
>>> youtube?****
>>>
>>>  ** **
>>>
>>> https://wwws.cs.umn.edu/tech_reports_upload/tr2011/old_files/11-012.pdf
>>> ****
>>>
>>>
>>> http://scholarworks.umass.edu/cgi/viewcontent.cgi?article=1178&context=cs_faculty_pubs
>>> ****
>>>
>>> ** **
>>>
>>>  ** **
>>>
>>> Rubens, ****
>>>
>>> esos docs los tengo presentes pero ya no son válidos y son previos a
>>> GGC. En ese momento la inteligencia del CDN estaba en los DNS dado que las
>>> URL del link del vídeo eran dominios globales únicos que se mapeaban de
>>> manera dinámica a diferentes IPs según de que DNS server venia el pedido de
>>> recursión. Ahora el DNS solo afecta al frontend web del los servicios de
>>> Google pero no al despacho de contenido.****
>>>
>>> ** **
>>>
>>> Actualmente en los nodos GGC colocados en los carrires/NAPS se le
>>> asignan a los hosts dominios especiales de resolución única. Siguiendo con
>>> el ejemplo argentino:****
>>>
>>> - los vídeos servidos desde el nodo local de TECO son del tipo *
>>> r4---sn-uxaxjvh5gbxoupo5-x1xs.c.youtube.com* y mapean (uses el DNS que
>>> uses) a IPs del rango *181.15.96.0/21* (propias de TECO).****
>>>
>>> - los vídeos servidos desde el nodo internacional de TASA/TIWS son del
>>> tipo r*1---sn-upfn-hp5e.c.youtube.com* y mapean (uses el DNS que uses)
>>> a IPs del rango *208.117.253.0/24* (si bien son de Google se propagan
>>> por TIWS exclusivamente).****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> Espero exista gente de Google en la lista para que pueda aportar un poco
>>> de certezas o herramientas que a nuestro entender faltan ya que un CDN como
>>> Youtube flapeando de un link al otro no es poca cosa y termina degradando
>>> la experiencia general del usuario, no solo la del sitio en cuestión. **
>>> **
>>>
>>> ** **
>>>
>>> Saludos y gracias por los prontos aportes.****
>>>
>>> ** **
>>>
>>> -- ****
>>>
>>> *Ivan Chapero
>>> Área Técnica y Soporte*
>>> Fijo: 03464-470280 (interno 535) | Móvil:  03464-155-20282  | Skype ID:
>>> ivanchapero****
>>>
>>> --****
>>>
>>> Go Banda Ancha - CABLETEL S.A. | Av. 9 de Julio 1163 - 2183 - Arequito -
>>> Santa Fe - Argentina****
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ****
>>>
>>>
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>> Cancelar suscripcion: lacnog-unsubscribe en lacnic.net
>>>
>>>
>>
>>
>> --
>> *Ivan Chapero
>> Área Técnica y Soporte*
>> Fijo: 03464-470280 (interno 535) | Móvil:  03464-155-20282  | Skype ID:
>> ivanchapero
>> --
>> Go Banda Ancha - CABLETEL S.A. | Av. 9 de Julio 1163 - 2183 - Arequito -
>> Santa Fe - Argentina
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: lacnog-unsubscribe en lacnic.net
>>
>>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: lacnog-unsubscribe en lacnic.net
>
>

-- 
*Ivan Chapero
Área Técnica y Soporte*
Fijo: 03464-470280 (interno 535) | Móvil:  03464-155-20282  | Skype ID:
ivanchapero
--
Go Banda Ancha - CABLETEL S.A. | Av. 9 de Julio 1163 - 2183 - Arequito -
Santa Fe - Argentina
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20130616/db8a288e/attachment.html>