[lacnog] [LAC-TF] Presentacion sobre CGN y transicion de NTT (Japon)
Carlos Martinez-Cagnazzo
carlosm3011 en gmail.com
Jue Sep 8 10:27:15 BRT 2011
Algunos comentarios sobre lo que dice Fernando:
- El cambio de modelo no se refiere tanto a un aspecto técnico como al
aspecto de acuerdos de servicio. El modelo de prestación de servicio
cambia con CGN, los clientes tienen una serie de restricciones que
antes no tenian y por eso dificilmente se pueda aumentar el ingreso x
usuario; a lo mas se podra mantener constante. Es mas, el va mas alla
y dice que al usuario en realidad se le tendria que cobrar *menos*.
- Cuando dice que el costo de IPv6 es "bajo", primero no esta diciendo
que sea cero, y el lo considera bajo *comparado con el costo de
despliegue de CGN*. Seguro que nadie cree que las cajas CGN vayan a
ser gratis ni que se vayan a poder simplemente tirar en la red y que
funcionen solas. Las cajas CGN van a venir con su propia cuenta de
problemas y necesidades de administración. IPv4 c/NAT en el usuario
*no es lo mismo* que CGN, no es la misma red que va a poder seguir
funcionando "como siempre"
- Estoy de acuerdo que desplegar IPv6 tiene costo ($$ y otros); pero
pensar que CGN no los tiene, o que estos costos son despreciables,
tambien es un error.
- Sobre tu punto sobre los proxies transparentes, tenes razon, pero de
nuevo, esos proxies tienen costo; alguien los tiene que administrar y,
viniendo de un ISP, cualquier elemento de red stateful agrega un
elemento de gestión en absoluto despreciable. Recuerdo en una epoca
que tratamos de desplegar web cachés con la promesa de ahorro de BW
internacional, *y los terminamos sacando, a pesar de ya haberlos
pagado*, justamente por que el costo de gestion que agregaban era mas
alto que el supuesto ahorro de BW.
- Finalmente, mientras puede que tengas razon (ojo que no estoy
convencido :-) ) que el abuso de conexiones simultaneas es un "error"
(o al menos una decision poco feliz) de los desarrolladores de
aplicaciones y de contenido; esta misma gente puede argumentar que el
problema son los ISPs que dejaron pasar los años y no desplegaron
IPv6. Ambos lados tienen razon, el punto es ahora quien corre con el
costo de arreglar los problemas.
Creo que el punto mas interesante es ver que ninguna de las
alternativas a futuro es de costo nulo, ni IPv6 ni CGN. El punto es
donde tienen mas sentido gastar el dinero.
s2
Carlos
2011
Ω/9/8 Fernando Gont <fgont en si6networks.com>:
> Hola, Carlos,
>
> On 09/07/2011 04:00 PM, Carlos Martinez-Cagnazzo wrote:
>> *Muy recomendable* sobre todo la primera parte:
>>
>> http://meetings.apnic.net/__data/assets/file/0011/38297/Miyakawa-APNIC-KEYNOTE-IPv6-2011-8.pptx.pdf
>
> Lei la presentación, y estuvo interesante.
>
> Algunos comentarios:
>
> * Personalmente estoy en desacuerdo que la introducción del "IP
> communication model" cambia con la introducción de CGNs. Los NATs ya son
> parte del modelo actual. De hecho, no es poco comun cosas tales como
> "proxies HTTP transparentes", lo cual tiene un efecto similar al de CGN.
>
> * Los graficos sobre el efecto en el límite de la cantidad de conexiones
> TCP fueron interesantes y sobre todo muy ilustrativos.
>
> * Hay muchisimas cosas que deberían ser tenidas en cuenta al hablar
> sobre la cantidad de conexiones que utiliza cada pagina/aplicación.
> Entre otras, hay que tener en cuenta que el uso de multiples sessiones
> "trampea" con el modelo de control de congestion de TCP. Hay mucho
> publicado sobre esto... pero entre todo lo que hay, voy a mencionar algo
> reciente:
> http://tools.ietf.org/id/draft-gettys-iw10-considered-harmful-00.txt
>
> * Los números utilizados en al diapositiva pagina #20 (diapositiva #19)
> son incorrectos, junto con el "razonamiento". Los numeros de puerto
> efimeros no tienen porqué limitarse a 32K. Ver, por ejemplo, RFC 6056.
> El motivo esprincipalmente historico. A modo de ejemplo, FreeBSD usa el
> rango 10K-65K.
>
> * Si la aplicación que principalmente consume puertos es HTTP, deberia
> considerarse el uso de HTTP proxies, incluyendo los transparentes.
>
> * Nada de lo anterior debe leerse como "No desplieguen IPv6": Esta
> clarisimo que el uso de CGN "no escala", y eventualmente la red
> funcionaría de manera horrible,
>
> * Migrar a IPv6 no tiene bajo costo -- ni siquiera hay motivo por el
> cual esto debería ser así. IPv6 requiere de capacitación, equipamiento,
> etc., etc., etc., nada de lo cual (o "la mayoria de lo cual no es...")
> gratuito. Mucho de nosotros, de hecho, vivimos de ello.
>
> * Las comunicaciones son parte del ecosistema del mundo. Quienes
> participan en el ecosistema de las comunicaciones (o alguien vinculado a
> él, lo cual significa "al menos un subset de todo el mundo"), deberá
> pagar por lo vinculado al despliegue y operación de IPv6, por el mismo
> motivo en que los ISPs cobran a sus clientes, que el panadero cobra por
> el pan que vende, o que uno debe pagar (directa o indirectamente) por
> tener asistencia médica.
>
> * ICMP *siempre* fue necesario: tanto en IPv4 como en IPv6: los
> blackholes de PMTUD causan los mismo problemas en IPv6 que en IPv4 --
> pese a que la mayoria de las presentaciones sobre IPv6 pinten esto como
> "algo nuevo".
>
> Un abrazo,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont en si6networks.com
> web: http://www.si6networks.com | Twitter: @SI6Networks
>
>
>
>
--
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================
Más información sobre la lista de distribución LACNOG