[uylug-varios] IXP, peering

[Nicolas Antoniello]

2013/5/14 Luis Pablo Pérez <kylroy at gmail.com>

>
>> > 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.
>
>
No veo tan clara la relación (que creo que mencionas) entre el RTT y el %
de error... el RTT en principio no depende del % de error sino del tiempo
de propagación por los canales más el tiempo de procesamiento de los
equipos intermedios.
SI hay pérdidas habrá (o es esperable que lo haya si hablamos de TCP)
retransmisiones... y allí si, concuerdo contigo en que la experiencia del
usuario se verá empeorada o "enlentecida"...


> 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.
>
>
Si, creo que la Interent real es bastante más compleja (hay otros
protocolos por lo genral y otras consideraciones que agregan muchas
variables y, como mencionas, bastante indeterminación.


> 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.
>
>
Me explicas un poco más este ejemplo... creo que está bueno entenderlo bien
para analizarlo en profundidad.


> 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.
>
>
Sin duda.  :)


> 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.
>
>
Jejeje, asi es Internet !  :)


> 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'.
>
>
Justamente por esa razón es que los puntos de intercambio de tráfico creo
que simplificarían algunos de los casos, haciendo más simple el "recorrido
de los datos" y mejorando la experiencia del usario.
Lo otro, es decir, que el usuario este siempre 100% conforme creo que es
imposible... la variabilidad de problemas y de siatuaciones particulares de
cada uno (depende de para que utilice Intenet digamos, que aplicaciones
corra, que requerimientos de retardo o de jitter o de pérdida de paquetes
tolere, etc...) es tan grande que si, es dificil depurar problemas
complejos en poco tiempo, aún con todas las herramientas que mencionas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.uylug.org.uy/pipermail/uylug-varios-uylug.org.uy/attachments/20130514/9a4f7a9e/attachment-0002.htm>