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

Mon Mar 9 16:28:39 BRT 2009

Hola,

Entre el mail de Jorge y el de Nicolas creo que podemos empezar a
contestar parte de la pregunta. Que les parece si decimos:

"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."

Que les parece como para ir dando una respuesta, ya que no ha sido
facil esta parte del FAQ?

Saludos,

                                    Guillermo.

2009/3/9 Nicolas Antoniello <nantoniello at gmail.com>:
> 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
>