Como mencionamos anteriormente, se pueden alcanzar rendimientos superiores a 22Mbps mediante la utilización de equipamiento 802.11g estándar para redes inalámbricas. Este valor de ancho de banda probablemente sea al menos un orden de magnitud mayor que la que le ofrece su enlace a Internet, y es capaz de soportar cómodamente muchos usuarios simultáneos de Internet.

Pero si su conexión principal a Internet es a través de un enlace VSAT, se va a encontrar con algunos problemas de desempeño si utiliza los parámetros por omisión de TCP/IP. Optimizando su enlace VSAT, se pueden mejorar significativamente los tiempos de respuesta cuando se accede a hosts de Internet.

Un VSAT es concebido a menudo como una tubería de datos larga y gruesa. Este término se refiere a los factores que afectan el desempeño de TCP/IP en cualquier red que tenga un ancho de banda relativamente grande, pero mucha latencia. La mayoría de las conexiones a Internet en África y otras partes del mundo en desarrollo son vía VSAT. Por lo tanto, aún si una universidad tiene su conexión a través de un ISP, esta sección puede ser aplicable si la conexión del ISP es a través de VSAT. La alta latencia en las redes por satélite se debe a la gran distancia del satélite y la velocidad constante de la luz. Esta distancia añade aproximadamente 520 ms al tiempo de ida y retorno de un paquete (RTT –round trip time– por su sigla en inglés), comparado con un RTT entre Europa y Estados Unidos de alrededor de 140 ms.

Los factores que impactan más significativamente el rendimiento de TCP/IP son tiempos de propagación largos, grandes productos de ancho de banda por retardo y errores de transmisión.

Generalmente en una red satelital se deben utilizar sistemas operativos que soportan las implementaciones TCP/IP modernas. Estas implementaciones soportan las extensiones RFC 1323:

• La opción de escalado de ventana para soportar ventanas TCP de gran tamaño (mayores que 64KB).

• Recepción selectiva (SACK por su sigla en inglés) para permitir una recuperación más rápida de los errores de transmisión.

• Matasellos (Timestamps) para calcular los valores de RTT y la expiración del tiempo de retransmisión para el enlace en uso.

Los enlaces por satélite tienen un promedio de RTT de alrededor de 520ms hasta el primer salto. TCP utiliza el mecanismo de comienzo lento al inicio de la conexión para encontrar los parámetros de TCP/IP apropiados para la misma. El tiempo perdido en la etapa de comienzo lento es proporcional al RTT, y para los enlaces por satélite significa que TCP se encuentra en el modo de comienzo lento por más tiempo de lo que debiera. Esto disminuye drásticamente el rendimiento de las conexiones TCP de corta duración. Esto puede verse cuando descargar un sitio web pequeño sorprendentemente toma mucho tiempo, mientras que cuando se transfiere un archivo grande se obtienen velocidades de datos aceptables luego de un rato.

Además cuando se pierden paquetes, TCP entra en la fase de control de congestión y, debido al alto RTT permanece en esta fase por largo tiempo, reduciendo así el rendimiento de las conexiones TCP, sean de larga o corta duración.

La cantidad de datos en tránsito en un enlace en un momento dado es el producto del ancho de banda por el RTT. Debido a la gran latencia del enlace satelital, este producto es grande. TCP/IP le permite a los hosts remotos enviar cierta cantidad de datos previamente sin esperar la confirmación (acknowledgment). Normalmente en una conexión TCP/IP se requiere una confirmación (ACK) para cada transmisión. Sin embargo el host remoto siempre puede enviar cierta cantidad de datos sin confirmación, lo que es importante para lograr una buena tasa de transferencia en conexiones con productos ancho de banda-retardo de propagación elevados. Esta cantidad de datos es denominada tamaño de la ventana TCP. En las implementaciones TCP/IP modernas el tamaño de la ventana generalmente es de 64KB.

En las redes satelitales, el valor del producto ancho de banda-retardo es importante. Para utilizar el enlace en toda su capacidad, el tamaño de la ventana de la conexión debe ser igual al producto del ancho de bandaretardo. Si el tamaño de ventana máximo permitido es de 64KB, teóricamente el máximo rendimiento que se puede conseguir vía satélite es (tamaño de la ventana) / RTT, o 64KB / 520 ms. Esto da una tasa de transferencia de datos máxima de 123kB/s, correspondiente a 984 kbps, aunque la capacidad del enlace sea mucho mayor.

Cada encabezado de segmento TCP contiene un campo llamado ventana anunciada, que especifica cuantos bytes de datos adicionales está preparado para aceptar el receptor. La ventana anunciada es el tamaño actual de la memoria de almacenamiento intermedio del receptor. El emisor no está autorizado a enviar más bytes que la ventana anunciada. Para maximizar el rendimiento, las memorias de almacenamiento intermedio del emisor y el receptor deben ser al menos iguales al producto ancho de banda-retardo.

El tamaño de la memoria de almacenamiento intermedio en la mayoría de las implementaciones modernas de TCP/IP tiene un valor máximo de 64KB. Para soslayar el problema de versiones de TCP/IP que no exceden el tamaño de la ventana de 64KB, se puede utilizar una técnica conocida como suplantación de confirmación (TCP acknowledgment spoofing) (vea más adelante Mejora del Rendimiento del Proxy).

En las implementaciones de TCP/IP más viejas, siempre se consideraba que la pérdida de paquetes era causada por la congestión (en lugar de errores de enlace). Cuando esto sucede TCP adopta una defensiva contra la congestión, requiriendo tres confirmaciones duplicadas (ACK), o ejecutando un inicio lento (slow start) en el caso de que el tiempo de espera haya expirado.

Debido al alto valor de RTT, una vez que esta fase de control de la congestión ha comenzado, toma un largo rato para que el enlace satelital TCP/IP vuelva al nivel de rendimiento anterior. Por consiguiente, los errores en un enlace satelital tienen un efecto más serio en las prestaciones de TCP que sobre los enlaces de latencia baja. Para solucionar esta limitación, se han desarrollado mecanismos como la Confirmación Selectiva (SACK por su sigla en inglés). SACK especifica exactamente aquellos paquetes que se han recibido permitiendo que el emisor retransmita solamente aquellos segmentos que se perdieron debido a errores de enlace.

En las implementaciones de TCP/IP más viejas, siempre se consideraba que la pérdida de paquetes era causada por la congestión (en lugar de errores de enlace). Cuando esto sucede TCP adopta una defensiva contra la congestión, requiriendo tres confirmaciones duplicadas (ACK), o ejecutando un inicio lento (slow start) en el caso de que el tiempo de espera haya expirado.

Debido al alto valor de RTT, una vez que esta fase de control de la congestión ha comenzado, toma un largo rato para que el enlace satelital TCP/IP vuelva al nivel de rendimiento anterior. Por consiguiente, los errores en un enlace satelital tienen un efecto más serio en las prestaciones de TCP que sobre los enlaces de latencia baja. Para solucionar esta limitación, se han desarrollado mecanismos como la Confirmación Selectiva (SACK por su sigla en inglés). SACK especifica exactamente aquellos paquetes que se han recibido permitiendo que el emisor retransmita solamente aquellos segmentos que se perdieron debido a errores de enlace.

El artículo sobre detalles de implementación de TCP/IP en Windows 2000 afirma:

"Windows 2000 introduce soporte para una importante característica de desempeño conocida como Confirmación Selectiva (SACK). SACK es especialmente importante para conexiones que utilizan ventanas TCP de gran tamaño."

SACK ha sido una característica estándar desde hace algún tiempo en Linux y BSD. Asegúrese de que tanto su enrutador Internet como el ISP del sitio remoto soporten SACK.

del enlace debido a los factores de "tubería de datos larga y gruesa" discutidos anteriormente. Lo que estos factores implican realmente es que impiden que una computadora tome todo el ancho de banda. Esto no es malo durante el día, porque mucha gente está usando el ancho de banda. Pero si por ejemplo, se programan grandes descargas para la noche, el administrador puede querer hacer uso de todo el ancho de banda, y los factores de "tubería de datos larga y gruesa" pueden ser un obstáculo. Esto puede transformarse en algo crítico si una cantidad significativa de su tráfico de red se enruta a través de un túnel único o una conexión VPN hasta el otro extremo del enlace VSAT.

Los administradores pueden considerar tomar algunas medidas para asegurarse de que están aprovechando la totalidad del ancho de banda disponible, afinando las configuraciones de TCP/IP. Si una universidad ha implementado una red donde el tráfico tiene necesariamente que pasar a través de un proxy (impuesto por el diseño de red), entonces las únicas computadoras que pueden realizar conexiones directas a Internet serán los servidores proxy y de correo electrónico.

Para más información, vea: http://www.psc.edu/networking/perf_tune.html

La idea de PEP se describe en la RFC 3135 (vea http://www.ietf.org/rfc/rfc3135), y podría ser un servidor Proxy con un disco cache grande que tiene extensiones RFC 1323, entre otras características. Una computadora portátil tiene una sesión TCP con PEP en el ISP. Ese PEP, y el que está en el proveedor de satélite se comunican utilizando diferentes sesiones TCP, inclusive, su propio protocolo privado. El PEP del proveedor de satélite toma los archivos desde el servidor web. De esta forma, la sesión TCP se divide y por lo tanto se evitan las características del enlace que afectan las prestaciones del protocolo (los factores de tubería larga y gruesa), utilizando por ejemplo suplantación de confirmaciones TCP (TCP ACK spoofing). Adicionalmente, PEP reactúa como proxy y realiza captura previa (pre-fetching) para acelerar todavía más el acceso a la web.

Este sistema puede ser construido desde cero utilizando por ejemplo Squid, o adquiriendo soluciones ofrecidas por varios vendedores.

• Anterior: Optimización del Tráfico.
• Siguiente:
• Volver al índice.