[LAC-TF] FAQ: Grupo2 - Pregunta "a"

Mon Mar 9 17:19:11 BRT 2009

Nicolas, como estas?

Pues bueno, la pregunta esta formulada de la manera mas generica posible, y 
pienso que NO es posible estimar "de forma general" la cantidad de dinero 
requerida para actualizar aplicaciones, porque los procesos son diferentes 
por completo (segun la complejidad de cada aplicacion) y las condiciones en 
las que se hace el proceso para cada aplicacion tambien es diferente, y todo 
ello influye. En mi respuesta anterior me habia referido a 5 topicos, que 
por lo general de una manera u otra influyen en el proceso, y ya eso te 
genera una buena aleatoriedad en los costos asociados. Por tanto la 
estimacion tendra que hacerla cada quien para su situacion particular.

En este caso, no es como estimar el costo de una camara fotografica, digamos 
de 8 megapixels de una marca conocida (Sony, Canon, Fuji, Panasonic, Kodak, 
etc). Es cierto que los precios pueden variar, pero una camara de una marca 
conocida, de las normalitas (para uso domestico) de esa resolucion puede 
andar entre los 150 y 400 dolares, segun donde se compre y segun la marca y 
modelo. A lo mejor en Estados Unidos la consigues en 150 dolares minimo, y 
en otros paises la misma camara sale en el doble, pero mas o menos puedes 
dar una idea a grosso modo de cuanto se requiere para tener una camara asi.

En el caso de lograr que aplicaciones actualmente IPv4 funcionen 
correctamente en IPv6, por lo menos yo, no me atreveria a dar una cifra y 
que fuera algo real. No se si Fernando, Alvaro o alguno de los que han 
estado participando en el FAQ, o de los que no lo han hecho pero si lo van 
siguiendo, pueden dar otra luz al respecto.

Por lo demas, me siento satisfecho por la respuesta que ha ido estructurando 
Guillermo, porque aporta elementos a quien esta buscando "la respuesta 
magica" a esta pregunta. O sea, uno puede decirle a cualquiera: No te puedo 
decir cuanto te cuesta llevar tu aplicacion a IPv6 (haria falta una bola de 
cristal); pero si puedes sacar tus propias cuentas teniendo en cuenta estos 
factores, y ademas, te sugiero que la valoracion la pueda hacer un equipo 
multidisciplinario, pues aunque se hable de aplicaciones no solo los 
desarrolladores de software estan involucrados"; asi que aqui copio la 
respuesta de Guillermo.

"No es posible estimar la inversion desde un punto de vista generico,
ya que dependera de varios factores, tales como

- arquitectura de la aplicacion
- tecnologias empleadas
- calidad del codigo fuente
- capacitación del personal
- sistemas operativos
- arquitectura de red

Sin embargo, en cada caso particular se podra hacer una estimacion de
la inversion necesaria, de acuerdo a los factores que correspondan.
Como recomendacion general, es conveniente pensar en que intervenga un
equipo multidisciplinario ya que no esta involucrado solo un
conocimiento de programacion, sino tambien cuestiones referentes a la
tecnología IP, sistemas operativos, etc."

Saludos,
Jorge
----- Original Message ----- 
From: "Nicolas Antoniello" <nantoniello at gmail.com>
To: <lactf at lac.ipv6tf.org>
Sent: Monday, March 09, 2009 3:04 PM
Subject: Re: [LAC-TF] FAQ: Grupo2 - Pregunta "a"

> Hola Jorge,
>
> Justamente yo decia que para mi SI se puede estimar, siempre que se
> tengan en cuenta los factores correspondientes a cada caso en
> particular.
> Ahora me pregunto si la pregunta (aunque suene redundante) ¿apunta a
> estimarlos en un caso genérico o en cada caso?
>
> Saludos,
> Nicolas.
>
>
> 2009/3/6 Jorge Villa <villa at reduniv.edu.cu>:
>> Hola a tod at s, como estan?
>>
>> Pues como que se quedo en el aire la respuesta de la nueva pregunta del 
>> FAQ,
>> luego de la ultima respuesta de Fernando haciendo referencia a la 
>> RFC5461.
>>
>> La pregunta a responder es la siguiente:
>>
>> ¿Es posible estimar la inversión de dinero requerida para actualizar
>> aplicaciones, de manera que funcionen correctamente sobre IPv6?
>>
>> Pienso que se han aportado muchos elementos acerca de que seria necesario
>> modificar o de aspectos tecnicos de implementacion, pero seguimos sin
>> responder exactamente la pregunta.
>>
>> Yo creo que NO es posible estimar la inversion de dinero que se requiere
>> para actualizar aplicaciones IPv4, de manera que funcionen correctamente
>> sobre IPv6, producto que ello dependera de varios factores. Entre ellos,
>> creo fundamentales los siguientes:
>>
>> - arquitectura de la aplicacion
>> - tecnologias empleadas
>> - calidad del codigo fuente
>> - capacitación del personal
>> - sistemas operativos
>> - arquitectura de red
>>
>> La arquitectura de la aplicacion se relaciona con si la aplicacion es
>> monolitica, o es una aplicacion cliente-servidor (basadas o no en web), y
>> por supuesto de la modularidad con que haya sido diseñada la aplicacion. 
>> En
>> algunos casos puede necesitarse rehacer un modulo, pero en otros casos 
>> puede
>> necesitar rehacerse un porciento significativo del producto. Si la
>> aplicacion tiene clientes Web, entonces sera necesario rehacer solo el
>> servidor, pero si tiene un cliente personalizado, con seguridad habra que
>> trabajar tanto en el cliente como en el servidor.
>>
>> Tambien existen multiples tecnologias con las que puede construirse una
>> aplicacion. Algunas son mas simples y otras mas complejas. En muchos 
>> casos
>> se emplean bibliotecas estandares y en otras bibliotecas diseñadas a la
>> medida. Puede suceder que tambien alguna de las tecnologias con que se ha
>> construido una aplicacion se haya descontinuado por sus fabricantes, y 
>> por
>> tanto haya que rehacer el producto con base en una nueva plataforma.
>>
>> Los codigos fuentes son otro dolor de cabeza para muchas aplicaciones, ya
>> que en algunos casos estos no estan disponibles, otras veces estan
>> disponibles pero no estan hechos con calidad o no estan comentados
>> adecuadamente, y eso complica la legibilidad del codigo, sobre todo 
>> cuando
>> quien tiene que actualizar la aplicacion no fue su diseñador original.
>>
>> El personal que participa en el proceso tiene que estar bien capacitado. 
>> Hay
>> programadores que no dominan ni siquiera aceptablemente la tecnologia IP, 
>> y
>> logran hacer aplicaciones que funcionen en red adecuadamente confiando en
>> las librerias de comunicacion de los paquetes de desarrollo de 
>> aplicaciones.
>> Para entender correctamente la RFC5461 y algunos de los otros draft al
>> respecto, hay que saber de tecnologia IP. Por lo general, en este proceso 
>> de
>> actualizacion debe intervenir un equipo multidisciplinario.
>>
>> Los sistemas operativos tambien influyen, segun la calidad de la
>> implementacion del stack IPv6 en los mismos. Tambien puede existir un 
>> costo
>> asociado a sistemas operativos, ya que si la aplicacion actual se ejecuta 
>> en
>> Windows 98 o 2000, en W98 no hay soporte IPv6 y en W2K hay soporte 
>> limitado,
>> por tanto habra que crear al menos a nivel experimental, una 
>> infraestructura
>> basada en XP o Vista.
>>
>> La arquitecturas de red puede complicar en mayor o menor medida el 
>> proceso
>> de desarrollo de aplicaciones. Es mucho mas facil crear un entorno de
>> desarrollo y/o actualizacion a nivel local (para aplicacion para Internet
>> desde PCs) que cuando hablamos de aplicaciones para dispositivos moviles,
>> donde hay otros aspectos a tener en cuenta.
>>
>> Como quiera que tras cada aplicacion hay un cerebro diferente, las formas 
>> de
>> pensar y de llegar a las soluciones difieren y por esto es muy dificil
>> cuantificar el proceso (a grosso modo). Tambien las condiciones tecnicas 
>> en
>> que se desarrolle el proceso influyen, y por supuesto que la inversion en
>> capacitacion es fundamental.
>>
>> Bueno, hasta aqui mi respuesta a la pregunta A del grupo 2 del FAQ. Que 
>> siga
>> la ronda.
>>
>> Saludos,
>> Jorge
>> ----- Original Message -----
>> From: "Fernando Gont" <fernando at gont.com.ar>
>> To: <lactf at lac.ipv6tf.org>
>> Sent: Monday, March 02, 2009 1:34 PM
>> Subject: Re: [LAC-TF] FAQ: Grupo2 - Pregunta "a"
>>
>>
>>> Hola, Nicolás,
>>>
>>> Comentarios entre lineas....
>>>
>>>
>>>> Le había echado un vistazo hace un tiempo a la RFC que tu propusiste.
>>>> La consulta que te hago es sobre que es lo que te parece que
>>>> tendríamos que agregar o tener en cuenta, en particular para las
>>>> aplicaciones.
>>>> ¿Te referís en estos casos a entornos mixtos IPv4-IPv6, donde por
>>>> ejemplo, una aplicación debe "lidiar" con los errores derivados de
>>>> time-outs,
>>>
>>> En aquellos casos en que una se publican RRs (resource records) AAAA
>>> apra un determinado nombre de dominio, y la conectividad IPv6 es
>>> limitada, se corre el peligro de caer en el escenario de "grandes
>>> esperas antes de poder establecer una conexion" que se describe en el
>>> RFC mencionado. Para el caso de aplicaciones interactivas, esto es
>>> directamente intolerable (ver referencias en el RFC.. aunque tambien
>>> puedo aportar otras).
>>>
>>>
>>>
>>>> que no sean manejados directamente por los módulos que
>>>> manejan las conexiones correspondientes o por ejemplo para
>>>> aplicaciones de tiempo real o similares?
>>>
>>> Esta cuestion es muy dificil de manejar. En primer lugar, porque
>>> tradicionalmente NO se maneja a nivel TCP, entonces termina siendo
>>> responsabilidad de la aplicación. EN segundo lugar, porque la mayoria de
>>> las aplicaciones no imponen timeouts apra el establecimiento de 
>>> conexión.
>>>
>>> Ajeno al workaround explicado en RFC 5461 (que puede NO funcionar, en
>>> caso que no se generen mensajes ICMP), hay algunas otras alternativas,
>>> como las descriptas en este I-D:
>>> http://tools.ietf.org/id/draft-gont-tcpm-connection-delays-00.txt
>>> Si bien recuerdo, la gente de Mac hace algo de esto.
>>>
>>> En cualquiera de los casos, todavia no existe una solucion completa a
>>> esta cuestion, y conozco de proveedores de Internet que han encontrado
>>> grandes problemas debido a esta cuestión. Por ej., la gente de NTT Japón
>>> incluso ha hecho presentaciones sobre esta cuestión en algunas
>>> conferencias (si alguien las desea, puedo buscar las diapositivas
>>> correspondientes).
>>>
>>>
>>>
>>>> Creo que tu aporte y tus conocimientos al respecto aportarán mucho en
>>>> esta fase de las FAQ.
>>>
>>> En "alto nivel", la cuestion es que publicar registros AAAA apra nombres
>>> de dominio que tambien son accesibles mediante IPv4 puede llevar a
>>> grandes demoras en el establecimiento de conexion, que apra aplicaciones
>>> interactivas resultaria directamente inaceptable.
>>>
>>> En lo que se refiere al workaround propuesto/descripto en RFC 5461, apra
>>> que funcione se necesitan dos cosas:
>>>
>>> * Que las implementaciones de TCP funcionen como lo describe el
>>> documento (Windows *no* lo ahce asi, por ejemplo... aunque LInux y e.g.
>>> NetBSD *si* lo hacen)
>>>
>>> * Que en aquellos puntos de la red donde se limita la conectividad IPv6,
>>> se generen errores ICMPv6 cuando se tenga queo que rutear algun paquete
>>> IPv6, pero no se pueda hacerlo por falta de conectividad, etc.
>>>
>>>
>>> En lo que hace a las "conexiones paralelas" descriptas en
>>> http://tools.ietf.org/id/draft-gont-tcpm-connection-delays-00.txt, esto
>>> deberia implementarse a nivel aplicacion, lo que agergaria complejidad a
>>> las aplicaciones (y ajeno a eso, la mayoria de las aplicaciones NO hacen
>>> esto).
>>>
>>> Cualquier cosa en la que pueda ayudar, estoy a tus ordenes.
>>>
>>> Un abrazo,
>>> --
>>> Fernando Gont
>>> e-mail: fernando at gont.com.ar || fgont at acm.org
>>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> LACTF mailing list
>>> LACTF at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lactf
>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>> _______________________________________________
>> LACTF mailing list
>> LACTF at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lactf
>>
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.