<div dir="ltr">Estimados,<br><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> 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 class="h5"></div></div></blockquote><div><br></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 class="im">Claro, si el enlace esta embromado eso es otro tema... pero no es lo normal.<br><br><br><br><br></div><div class="im"><br></div><div class="im">
><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:1px solid 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 class="im"></div></blockquote><div><br></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> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">>><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>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> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid 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 class="im"></div></blockquote><div><br></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> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">><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> <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>