[lacnog] Consultas acerca de Google Cache
Ariel Weher
ariel en weher.net
Mie Jun 12 15:14:08 BRT 2013
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
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20130612/eea9a5aa/attachment.html>
Más información sobre la lista de distribución LACNOG