Trabajo 2: Análisis Crítico del artículo "Worldwide TCP/IP using Satellites. The Great Debate" de Bill Sepmeier, 

En este articulo "Worldwide TCP/IP using Satellites. The Great Debate" de Bill Sepmeier, se plantea una discusión sobre el uso de TCP/IP en conexiones sobre enlaces satelitales. 

En primer lugar, se comentan artículos publicados en la prensa en donde se señala que el uso de TCP/IP sobre Satélites son un fracaso debido al problema de retardos. Estos ocurren debido a que TCP/IP es un protocolo de paquetes ACK/nak (ACKnowledgment/ negative acknowledgment) usado para indicar que lo datos han sido recibidos sin error y que la próxima parte de la transmisión puede ser enviada o que los datos no fueron recibidos correctamente y que deben ser enviados de nuevo, este es un robusto esquema de corrección de errores, usado ampliamente desde X.25. 

Este sistema de corrección de errores trabaja bien en aplicaciones en las que la información viaja a distancias relativamente cortas. Al enviar datos a través de un sistema basado en satélites GEOestacionarios con un enlace de 60.000 Km. de longitud, la velocidad de la luz impone un retardo de 250 mSeg por cada salto de la trayectoria, para un total de 500 mSeg de un punto de la tierra a otro. Este retardo afecta el rendimiento de este tipo de conexiones, en comparación con las realizadas a través de fibra óptica, cable coaxial u otro medio de transmisión terrestre ya que se enviarán los paquetes y solo cuando sean recibidos sin error se continuaran enviando datos, esta espera es lo que retarda un poco el proceso.  

Se plantea entonces la siguiente interrogante ¿Cómo se explica que los proveedores de acceso a Internet con conexiones basadas únicamente en satélites incrementen sus clientes diariamente? Si tCP/IP es un fracaso por que la NASA y las ramas militares de USA lo siguen usando.

La respuesta está en términos de "eficiencia". Puesto que la mayoría de las aplicaciones de Internet basadas en satélites están situadas en países en vías de desarrollo, donde no existía conectividad antes del establecimiento de este tipo de conexión, o donde habían conexiones con rutas complejas a través de otros países,  el tiempo de espera del TCP no es un problema. Las conexiones se realizan bien, y en muchos casos mejor que las alternativas terrestres. En las rutas cortas que implican pocas conexiones al satélite que impliquen este efecto del tiempo de espera,  estos retrasos del TCP/IP son transparentes al usuario final. 

Es sabio recordar que el tiempo de espera del TCP en una conexión dial up o discada a cualquier servidor de IP se acerca a los  200 mSeg, cuando se está conectado a 14,4 kbps. En países en vías de desarrollo, ésta es a menudo la velocidad más alta de la conexión que se puede utilizar por la infraestructura local telefónica, así que los retrasos de Internet en conexiones satelitales nunca son visibles para el usuario final, aunado esto a que la red es  rápida si el servidor esta conectado en ese momento, y dependiendo de la cantidad de usuarios utilizando sus recursos en ese instante.

Debido a que TCP/IP  es un protocolo ampliamente usado y extendido siendo reconocido como una especificación mundial de LANs,  y a que los satélites se vislumbran como una verdadera opción para las conexiones  a Internet y a redes WAN, se hace necesario la utilización de TCP/IP sobre soluciones satelitales.

Entonces, el gran debate no es que TCP/IP "vuele" sobre el satélite, sino como el tráfico de TCP/IP se puede transportar con alta confiabilidad y a alta velocidad en ambientes de costos fijos como los ofrecidos por los satélites GEOestacionarios, ya que los satélites LEO resultan en costos muy elevados.

 Actualmente, hay dos o tres escuelas que trabajan hacia una solución al problema del tiempo de espera, dentro de la misma universidad. 

La primera, la escuela "Really Big Buffer" desean mantener la integridad del TCP/IP,  trabajan en modificar un dígito binario ampliando la cantidad de datos que puedan ser enviados antes de que se requiera un acuse de recibo o un ACK/nak.  Este tipo de modificación del TCP es realmente parte de la especificación para las conexiones largas. Tomando a esto un dígito binario más lejos, algunos investigadores están mirando la viabilidad de ampliar esta idea de modo que mientras que el sistema está esperando un ACK a una de estas secuencias enormes, continúe enviando datos a través de la conexión. El flujo no se interrumpe a menos que el otro extremo de la conexión señale un error. Si sucede esto, se vuelve a enviar el " paquete enorme, pero protegido " otra vez, donde se recibe y se vuelve a montar en orden apropiada.

En segundo lugar, está el UDP, o escuela " de paquete no fiable de los datos ". Este grupo básicamente "ha roto" el protocolo del control de la transferencia en la conexión basada en los satélites, y utiliza un esquema de transferencia sobre la conexión basada en satélites similar al UDP, el protocolo usado cuando se hace "ping" a un sitio. El UDP, según lo especificado, asume que realmente no importa si hay tráfico allí o no. Si se transfieren grandes paquetes y al ejecutar la aplicación se encuentran errores binarios,  las soluciones de UDP sin corrección de error no resultan muy atractivas. Puesto que el resto del TCP/IP requiere que los paquetes del ACK estén ordenados para continuar enviando, esta escuela ha empleado el "spoofing" generando mensajes válidos del ACK en la conexión satelital final. Trabaja realmente bien, hasta que hay un problema con el enlace satelital ya que se pierde todo.

La tercera escuela, ha propuesto la puesta en práctica de partes de las dos anteriores, la corrección de error para proteger la integridad del TCP, algo más que lo que el UDP puede proporcionar.

Cualquier solución tendrá que resolver la compatibilidad establecida y los estándares de funcionamiento fijados por la base TCP/ip mundial, y deberá seguir siendo competitiva con respecto a las soluciones terrestres disponibles. En toda la probabilidad, el ganador será una combinación de los tres, y no se podrán eliminar las soluciones adicionales que conlleven a otras especificaciones.