<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2013/5/14 Luis Pablo Pérez <span dir="ltr"><<a href="mailto:kylroy@gmail.com" target="_blank">kylroy@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>> Me encanta cuando la cosa se vuelve así matemática :). Si, no había<br>
> tenido esa razón en cuenta, una más para evitar los enlaces largos. Me<br>
> pregunto cuál será la tasa de error habitual en enlaces de fibra de<br>
> miles de quilómetros.<br>
</div>Bajisima, la perdida 'normal' de paquetes es algo asi como 0.05% o<br>
incluso menos en STM-1, STM-16. El problema mas comun en estos enlaces<br>
es 'clock drift', es decir cuando alguno de los dispositivos intermedios<br>
se va de sincronismo y se producen rafagas de errores hasta que se<br>
recupera la sincronización.<br>
</blockquote><div><br></div></div><div>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.<br>
</div><div>Claro, si el enlace esta embromado eso es otro tema... pero no es lo normal.<br><br></div></div></div></div></blockquote><div></div></div><div>Claro pero eso es una sola capa. Hay que subir al menos dos capas mas para estar en internet.</div>
<div>La perdida en estos enlaces no es lo critico sino cuanto aporta en el error total y sobre todo</div><div>cuanto suma en el rtt.</div><div><br></div></div></div></div></blockquote><div><br></div><div>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.<br>
</div><div>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"... <br></div>
<div>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Lo que suele occurrir es:</div>
<div>
- 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)<br></div><div> - los caminos en capa 3 suelen ser largos con lo cual la probabilidad de tener problemas es alta</div>
<div><br></div><div>Dejé de lado el corte de fibras ya que en general hay respaldos pero pasa bastante seguido.</div><div><br></div><div>Cuando tenes muchos datacenters con decenas de miles de servidores (ej: 55 mil), cientos de switches, miles</div>
<div>de interfaces, ves lo que realmente le pasa a los protocolos cuando comienza a aumentar la escala.</div><div>En cierta forma, nuestra red interna es un modelo controlado de Internet real.</div><div>
<br></div></div></div></div></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>
Globalmente entre el datacenter A y el datacenter B la perdida de paquetes puede ser casi nula.<br>
</div><div>Al mismo tiempo nos ha pasado que un switch tiraba un porcentaje de paquetes alto y afectaba</div>
<div>algunos flujos con 200ms de rtt. Pasando por ese mismo camino otro flujo con rtt <5ms estaba</div><div>feliz de la vida con el mismo nivel de perdida de paquetes.</div><div><br></div></div></div></div></blockquote>
<div><br></div><div>Me explicas un poco más este ejemplo... creo que está bueno entenderlo bien para analizarlo en profundidad.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Cuando tenes suerte hay alguna de esas piezas que se rompen y dejan de funcionar. </div>
<div>Normalmente lo que ocurre es que no se rompen completamente y tenes que convivir con algún problema </div><div>porque no es simple descubrir cual o cuales interfaces son las problemáticas.</div><div>
<br></div></div></div></div></blockquote><div><br></div><div>Sin duda. :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div></div><div>Como hay tantos caminos alternativos no todos los flujos son afectados y no siempre vas o volves</div><div>por la misma ruta. No es raro tener que mirar miles de traceroutes para tratar de correlacionar errores</div>
<div>entre algunas decenas de maquinas distribuidas en el planeta.</div><div><br></div><div> ... y encima nuestra realidad es mucho mas simple:</div><div> - la red es increiblemente sofisticada y funciona.</div>
<div> - tenemos control total de extremo a extremo.. desde el equipo origen al destino</div><div> - el sistema de monitorizacion es increiblemente bueno.</div><div> - en cada punto hay un experto de primer nivel dispuesto a ayudar:</div>
<div> - nadie te va a preguntar: probaste apagar y prender ?</div><div> - si estas preguntando se asume que hay algo mal y que vos hiciste</div><div> los deberes: ie, quien pregunta y quien responde saben de lo que estan hablando.</div>
<div> - envías un correo en una lista para consultas y puede que quien responda sea</div><div> Van Jacobson.</div><div><br></div><div>Incluso así es complicado encontrar la razón por la cual el flujo X va mas lento de lo que</div>
<div>debería... y nos pasa muy seguido. En general encontramos el problema, pero aveces nos</div><div>lleva días.</div><div><br></div></div></div></div></blockquote><div><br></div><div>Jejeje, asi es Internet ! :)<br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Imaginate ahora lo que le pasa a un usuario cualquiera tratando de recibir sus bytes en su casa.</div>
<div>Estadísticamente unos cuantos van a tener problemas y nadie va enterarse ni nunca se va a saber</div><div>que pasó. Esos usuarios simplemente van a estar insatisfechos.</div><div>A un porcentaje alto de los pocos casos que se quejen con su ISP, nadie va a poder darle una respuesta</div>
<div>de que es lo que está pasando ya que cada empresa responsable en el camino va a ver que su</div><div>servicio esta funcionando 'suficientemente bien'.</div><div><br></div></div></div></div></blockquote><div>
<br></div><div>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.<br>
</div><div>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.<br>
<br></div><br></div></div></div>