[uylug-varios] IXP, peering

[Luis Pablo Pérez]

2013/5/13 Nicolas Antoniello <nantoniello at gmail.com>

> Estimados,
>
> > Me encanta cuando la cosa se vuelve así matemática :). Si, no había
>> > tenido esa razón en cuenta, una más para evitar los enlaces largos.  Me
>> > pregunto cuál será la tasa de error habitual en enlaces de fibra de
>> > miles de quilómetros.
>> Bajisima, la perdida 'normal' de paquetes es algo asi como 0.05% o
>> incluso menos en STM-1, STM-16. El problema mas comun en estos enlaces
>> es 'clock drift', es decir cuando alguno de los dispositivos intermedios
>> se va de sincronismo y se producen rafagas de errores hasta que se
>> recupera la sincronización.
>>
>
> Permitanme agregar que en un enlace normal, luego de que está testeado y
> puesto en operación, las tazas de error normales son muy inferiores a
> 1x10-3 (en la mayoría de los casos muuuy inferiores)... en términos
> prácticos sería cero.
> Claro, si el enlace esta embromado eso es otro tema... pero no es lo
> normal.
>
>
Claro pero eso es una sola capa. Hay que subir al menos dos capas mas para
estar en internet.
La perdida en estos enlaces no es lo critico sino cuanto aporta en el error
total y sobre todo
cuanto suma en el rtt.

Lo que suele occurrir es:
   - los equipos se rompen o funcionan mal (los que usan esa fibra o los
que estan en el camino del cual esta fibra es solo un tramo)
   - los caminos en capa 3 suelen ser largos con lo cual la probabilidad de
tener problemas es alta

Dejé de lado el corte de fibras ya que en general hay respaldos pero pasa
bastante seguido.

Cuando tenes muchos datacenters con decenas de miles de servidores (ej: 55
mil), cientos de switches, miles
de interfaces, ves lo que realmente le pasa a los protocolos cuando
comienza a aumentar la escala.
En cierta forma, nuestra red interna es un modelo controlado de Internet
real.

Globalmente entre el datacenter A y el datacenter B la perdida de paquetes
puede ser casi nula.
Al mismo tiempo nos ha pasado que un switch tiraba un porcentaje de
paquetes alto y afectaba
algunos flujos con 200ms de rtt. Pasando por ese mismo camino otro flujo
con rtt <5ms estaba
feliz de la vida con el mismo nivel de perdida de paquetes.

Cuando tenes suerte hay alguna de esas piezas que se rompen y dejan de
funcionar.
Normalmente lo que ocurre es que no se rompen completamente y tenes que
convivir con algún problema
porque no es simple descubrir cual o cuales interfaces son
las problemáticas.

Como hay tantos caminos alternativos no todos los flujos son afectados y no
siempre vas o volves
por la misma ruta. No es raro tener que mirar miles de traceroutes para
tratar de correlacionar errores
entre algunas decenas de maquinas distribuidas en el planeta.

 ... y encima nuestra realidad es mucho mas simple:
     - la red es increiblemente sofisticada y funciona.
     - tenemos control total de extremo a extremo.. desde el equipo origen
al destino
     - el sistema de monitorizacion es increiblemente bueno.
     - en cada punto hay un experto de primer nivel dispuesto a ayudar:
           - nadie te va a preguntar: probaste apagar y prender ?
           - si estas preguntando se asume que hay algo mal y que vos
hiciste
             los deberes: ie, quien pregunta y quien responde saben de lo
que estan hablando.
     - envías un correo en una lista para consultas y puede que quien
responda sea
       Van Jacobson.

Incluso así es complicado encontrar la razón por la cual el flujo X va mas
lento de lo que
debería... y nos pasa muy seguido. En general encontramos el problema, pero
aveces nos
lleva días.

Imaginate ahora lo que le pasa a un usuario cualquiera tratando de recibir
sus bytes en su casa.
Estadísticamente unos cuantos van a tener problemas y nadie va enterarse ni
nunca se va a saber
que pasó. Esos usuarios simplemente van a estar insatisfechos.
A un porcentaje alto de los pocos casos que se quejen con su ISP, nadie va
a poder darle una respuesta
de que es lo que está pasando ya que cada empresa responsable en el camino
va a ver que su
servicio esta funcionando 'suficientemente bien'.



>
>
>
>
> >
> >>     Pero bueno, justo en este caso, según lo que decía Carlos, no
> influiría
> >>     más que en mi latencia, no habría que pagar más por el peering en
> NOTA
> >>     (¡hey! *NAP* of the Americas, alguien que les avise que son un IXP
> ;)).
>
>
>> Jua! En USA se usa (pun intended!) el termino NAP mas que IXP. Es lo
>> mismo. Es como escribir 'color' vs 'colour' o 'behaviour' vs 'behavior'
>> o usar el termino 'hoover' vs 'vacuum cleaner' para llamar a la
>> aspiradora :D
>>
>
> De acuerdo! Da igual, en mi opinión, que lo llamen como quiera cada uno...
> lo importante, creo yo, es que en español es un punto de intercambio de
> tráfico.  :)
>
>
>> >>
>> >> Latencia no es algo que debas despreciar tan facilmente, va a depender
>> >> de que quieras hacer.
>> > No, no lo despreciaba, como todo empezó en la plata que íbamos a gastar
>> > con las aplicaciones de Adobe y el ancho de banda adicional, aclaraba
>> > que acá el impacto sólo iba a ser la latencia, no el costo del tráfico.
>> > Fue una mención al hilo original. Sí, la latencia puede arruinarte una
>> > experiencia. De hecho por eso en IPv6 en casa uso teredo y no un túnel a
>> > HE, por la latencia para sitios locales.
>> La latencia es el factor determinante en la performance de las
>> aplicaciones. Ya no lo es el ancho de banda (hace mucho que no lo es). Y
>> como dice Tannenbaum en el libro, uno siempre puede comprar mas fibras,
>> poner mas antenas para tener mas ancho de banda, pero la latencia no se
>> compra... la latencia te hace sentir la fria cara de las leyes de la
>> física, las únicas leyes ante las cuales todos realmente somos iguales :D
>>
>> Hay solo una manera de achicar la latencia dramáticamente: acercar el
>> contenido al usuario, y la tecnica que mas resultado ha demostrado dar
>> para hacer esto de una manera económicamente viable es el
>> establecimiento de IXPs.
>>
>>
> Que los IXP acercan el contenido a los usuarios es indiscutible, pero solo
> el contenido local, lo que se origina lejos, sigue estando lejos... es
> buena la combinación de IXPs con CDNs y servidores de Cache locales
> específicos, los que al igual que un IXP (y en ocasiones en forma mucho más
> efectiva) acercan el contenido al usuario y reducen dramáticamente la
> latencia... calro está, nuevamente, para intercambios de información en
> tiempo real punto a punto no sirven de mucho (y porsupuesto que no reducen
> la latencia en esos casos). Luego vienen los temas de la competencia de los
> contenidos locales con los cacheados o brindados desde una CDN local...
> que, sin llegar a un fundamentalismo proteccionista, se debe tener en
> cuenta a la hora de tomar la decisicón.
>
>
>> La segunda fase, y donde tambien hay para ganar, es en la interconexión
>> de IXPs, pero si el tema IXPs es muchas veces una carrera cuesta arriba,
>> el de la interconexión de IXPs lo es aún mas. Hace falta mucha
>> evangelización al respecto. Es muy bueno que se haya dado este hilo.
>>
>
> Ese tema indefectiblemente se resuelve "pagando"... pero el pago por
> transporte conjunto de todo el tráfico de un IXP siempre es menor al que
> debería pagar cada uno por conectarse con un sitio remoto... y justamente
> allí es donde entra uno de los negocios de los ISP o Carriers en el IXP
> pues pueden perfectamente venderles la capacidad de interconexión, la cual,
> en general, es paga por todos los miembros del IXP en relación al
> porcentaje de tráfico que cursen por dichos vínculos. Todo es cuestión de
> que el ISP o el Carrier no se "pase de mambo" con los precios de
> interconexión (pues eso destruye o termina anulando al IXP).
>
>
>> >
>> >>     Totalmente de acuerdo, no puede ser un problema de plata, y Antel
>> >>     debería agarrarlo, siempre y cuando se precise y no tenga ya
>> negativas
>> >>     de los otros pocos posibles participantes (es fácil pensar que no
>> han
>> >>     hecho nada y tirar un par de cascotazos, pero cabe la posibilidad
>> de que
>> >>     se haya hecho los contactos y no haya respaldo). Pero bueno, de
>> última
>> >>     que lo empiecen Antel, RAU y LACNIC.
>> >>
>> >>
>> >> Al final del día no importa si hicieron o no hicieron algo, el problema
>> >> es demasiado viejo.
>> >> Si lo analizaron y la se tomó la decisión de no hacerlo y tienen
>> >> argumentos sólidos
>> >> (ej: de verdad no justifica la inversión) todo bien, lástima que no se
>> >> explica al publico.
>> > ¡Es que a mí tampoco me importa si lo hicieron o no! El resultado es el
>> > mismo. Por eso sugiero que lo empiecen los que están de acuerdo. Y esos
>> > tres: Antel, RAU y LACNIC, seguro que están de acuerdo. Ya se sumarán
>> > los otros. Y además así tenemos un IXP y no pasamos la vergüenza de
>> > alojar una organización regional de algo que no tenemos ;).
>> El IXP se paga solo y puede arrancar con una inversión no muy grande,
>> menos de 100.000 dolares te diria para la infraestructura propia del
>> IXP. Hay ejemplos donde lo han hecho con mucho menos de eso, pero para
>> plantearnos algo decente digamos 100k. Este dinero es _caja chica_ para
>> un consorcio que junte a ANTEL, Telefonica, Claro, RAU, LACNIC y AGESIC.
>>
>>
> Consorcio ... ta complicado (en términos prácticos y por muchas razones lo
> veo bastante imposible)... pero lo que no veo tan imposible es que alguno
> de ellos arme algo, a donde el resto se puedan conectar (a precios de
> transmisión hasta el IXP razonables) y con una mínima regulación que
> obligue a no discriminar a quien se conecta y quien no... y que luego, por
> su propio peso, el resto indefectiblemente se tendrá que sumar... En lo
> personal estoy de acuerdo en que el dinero que cuesta el IXP no es lo que
> mueve la balanza...
> Porque si es cierto y nadie puede negarlo que es bastante feo tener que ir
> hasta USA para intercambiar tráfico con un vecino... sobre todo porque a mi
> y al vecino, como clientes, por lo general no nos importa (debería?) que
> ambos seamos clientes de diferentes emrpesas.
>
> Saludos,
> Nico
>
>
>
> _______________________________________________
> Uylug-varios mailing list
> Uylug-varios at listas.uylug.org.uy
> http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.uylug.org.uy/pipermail/uylug-varios-uylug.org.uy/attachments/20130514/3a1b6e7f/attachment-0002.htm>