<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/13 Nicolas Antoniello <span dir="ltr"><<a href="mailto:nantoniello@gmail.com" target="_blank">nantoniello@gmail.com</a>></span><br><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">Estimados,<br><br><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>> 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>
<div><div></div></div></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><br></div><div style>Claro pero eso es una sola capa. Hay que subir al menos dos capas mas para estar en internet.</div>
<div style>La perdida en estos enlaces no es lo critico sino cuanto aporta en el error total y sobre todo</div><div style>cuanto suma en el rtt.</div><div style><br></div><div style>Lo que suele occurrir es:</div><div style>
- 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 style> - los caminos en capa 3 suelen ser largos con lo cual la probabilidad de tener problemas es alta</div>
<div style><br></div><div style>Dejé de lado el corte de fibras ya que en general hay respaldos pero pasa bastante seguido.</div><div style><br></div><div style>Cuando tenes muchos datacenters con decenas de miles de servidores (ej: 55 mil), cientos de switches, miles</div>
<div style>de interfaces, ves lo que realmente le pasa a los protocolos cuando comienza a aumentar la escala.</div><div style>En cierta forma, nuestra red interna es un modelo controlado de Internet real.</div><div style>
<br></div><div style>Globalmente entre el datacenter A y el datacenter B la perdida de paquetes puede ser casi nula.<br></div><div style>Al mismo tiempo nos ha pasado que un switch tiraba un porcentaje de paquetes alto y afectaba</div>
<div style>algunos flujos con 200ms de rtt. Pasando por ese mismo camino otro flujo con rtt <5ms estaba</div><div style>feliz de la vida con el mismo nivel de perdida de paquetes.</div><div style><br></div><div style>Cuando tenes suerte hay alguna de esas piezas que se rompen y dejan de funcionar. </div>
<div style>Normalmente lo que ocurre es que no se rompen completamente y tenes que convivir con algún problema </div><div style>porque no es simple descubrir cual o cuales interfaces son las problemáticas.</div><div style>
<br></div><div style>Como hay tantos caminos alternativos no todos los flujos son afectados y no siempre vas o volves</div><div style>por la misma ruta. No es raro tener que mirar miles de traceroutes para tratar de correlacionar errores</div>
<div style>entre algunas decenas de maquinas distribuidas en el planeta.</div><div style><br></div><div style> ... y encima nuestra realidad es mucho mas simple:</div><div style> - la red es increiblemente sofisticada y funciona.</div>
<div style> - tenemos control total de extremo a extremo.. desde el equipo origen al destino</div><div style> - el sistema de monitorizacion es increiblemente bueno.</div><div style> - en cada punto hay un experto de primer nivel dispuesto a ayudar:</div>
<div style> - nadie te va a preguntar: probaste apagar y prender ?</div><div style> - si estas preguntando se asume que hay algo mal y que vos hiciste</div><div style> los deberes: ie, quien pregunta y quien responde saben de lo que estan hablando.</div>
<div style> - envías un correo en una lista para consultas y puede que quien responda sea</div><div style> Van Jacobson.</div><div style><br></div><div style>Incluso así es complicado encontrar la razón por la cual el flujo X va mas lento de lo que</div>
<div style>debería... y nos pasa muy seguido. En general encontramos el problema, pero aveces nos</div><div style>lleva días.</div><div style><br></div><div style>Imaginate ahora lo que le pasa a un usuario cualquiera tratando de recibir sus bytes en su casa.</div>
<div style>Estadísticamente unos cuantos van a tener problemas y nadie va enterarse ni nunca se va a saber</div><div style>que pasó. Esos usuarios simplemente van a estar insatisfechos.</div><div style>A un porcentaje alto de los pocos casos que se quejen con su ISP, nadie va a poder darle una respuesta</div>
<div style>de que es lo que está pasando ya que cada empresa responsable en el camino va a ver que su</div><div style>servicio esta funcionando 'suficientemente bien'.</div><div style><br></div><div> </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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br><br><br></div><div class="im"><div><br></div><div>
><br>
>> Pero bueno, justo en este caso, según lo que decía Carlos, no influiría<br>
>> más que en mi latencia, no habría que pagar más por el peering en NOTA<br>
>> (¡hey! *NAP* of the Americas, alguien que les avise que son un IXP ;)).<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Jua! En USA se usa (pun intended!) el termino NAP mas que IXP. Es lo<br>
mismo. Es como escribir 'color' vs 'colour' o 'behaviour' vs 'behavior'<br>
o usar el termino 'hoover' vs 'vacuum cleaner' para llamar a la<br>
aspiradora :D<br>
<div></div></blockquote><div><br></div></div><div>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. :)<br></div><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>>><br>
>> Latencia no es algo que debas despreciar tan facilmente, va a depender<br>
>> de que quieras hacer.<br>
> No, no lo despreciaba, como todo empezó en la plata que íbamos a gastar<br>
> con las aplicaciones de Adobe y el ancho de banda adicional, aclaraba<br>
> que acá el impacto sólo iba a ser la latencia, no el costo del tráfico.<br>
> Fue una mención al hilo original. Sí, la latencia puede arruinarte una<br>
> experiencia. De hecho por eso en IPv6 en casa uso teredo y no un túnel a<br>
> HE, por la latencia para sitios locales.<br>
</div>La latencia es el factor determinante en la performance de las<br>
aplicaciones. Ya no lo es el ancho de banda (hace mucho que no lo es). Y<br>
como dice Tannenbaum en el libro, uno siempre puede comprar mas fibras,<br>
poner mas antenas para tener mas ancho de banda, pero la latencia no se<br>
compra... la latencia te hace sentir la fria cara de las leyes de la<br>
física, las únicas leyes ante las cuales todos realmente somos iguales :D<br>
<br>
Hay solo una manera de achicar la latencia dramáticamente: acercar el<br>
contenido al usuario, y la tecnica que mas resultado ha demostrado dar<br>
para hacer esto de una manera económicamente viable es el<br>
establecimiento de IXPs.<br>
<br></blockquote><div><br></div></div><div>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.<br>
</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
La segunda fase, y donde tambien hay para ganar, es en la interconexión<br>
de IXPs, pero si el tema IXPs es muchas veces una carrera cuesta arriba,<br>
el de la interconexión de IXPs lo es aún mas. Hace falta mucha<br>
evangelización al respecto. Es muy bueno que se haya dado este hilo.<br>
<div></div></blockquote><div><br></div></div><div>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).<br>
</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>><br>
>> Totalmente de acuerdo, no puede ser un problema de plata, y Antel<br>
>> debería agarrarlo, siempre y cuando se precise y no tenga ya negativas<br>
>> de los otros pocos posibles participantes (es fácil pensar que no han<br>
>> hecho nada y tirar un par de cascotazos, pero cabe la posibilidad de que<br>
>> se haya hecho los contactos y no haya respaldo). Pero bueno, de última<br>
>> que lo empiecen Antel, RAU y LACNIC.<br>
>><br>
>><br>
>> Al final del día no importa si hicieron o no hicieron algo, el problema<br>
>> es demasiado viejo.<br>
>> Si lo analizaron y la se tomó la decisión de no hacerlo y tienen<br>
>> argumentos sólidos<br>
>> (ej: de verdad no justifica la inversión) todo bien, lástima que no se<br>
>> explica al publico.<br>
> ¡Es que a mí tampoco me importa si lo hicieron o no! El resultado es el<br>
> mismo. Por eso sugiero que lo empiecen los que están de acuerdo. Y esos<br>
> tres: Antel, RAU y LACNIC, seguro que están de acuerdo. Ya se sumarán<br>
> los otros. Y además así tenemos un IXP y no pasamos la vergüenza de<br>
> alojar una organización regional de algo que no tenemos ;).<br>
</div>El IXP se paga solo y puede arrancar con una inversión no muy grande,<br>
menos de 100.000 dolares te diria para la infraestructura propia del<br>
IXP. Hay ejemplos donde lo han hecho con mucho menos de eso, pero para<br>
plantearnos algo decente digamos 100k. Este dinero es _caja chica_ para<br>
un consorcio que junte a ANTEL, Telefonica, Claro, RAU, LACNIC y AGESIC.<br>
<br></blockquote></div><div> <br>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...<br>
</div></div><div class="gmail_quote">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.<br>
<br></div><div class="gmail_quote">Saludos,<br>Nico<br><br></div><div class="gmail_quote"><br></div></div></div>
<br>_______________________________________________<br>
Uylug-varios mailing list<br>
<a href="mailto:Uylug-varios@listas.uylug.org.uy">Uylug-varios@listas.uylug.org.uy</a><br>
<a href="http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy" target="_blank">http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy</a><br>
<br></blockquote></div><br></div></div>