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

Mon Mar 9 16:04:54 BRT 2009

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
>