[en] Communication networks have experienced a dramatic growth in the past two decades. The number of devices connected to the Internet has been growing exponentially. If TCP congestion control algorithm was not present, network links would collapse due to generated traffic. This algorithm was developed in 1990 and was named TCP Reno. Satellite networks can connect two remote sites through a satellite communication link when there is no terrestrial network, but TCP Reno was not designed to be used over satellite links. A satellite communication link is characterized by high bandwidth, long propagation delays and corruption losses due to cosmic radiation and meteorological phenomena. When standard TCP Reno is used on such links, TCP protocol suffers from significant throughput degradation and a fairness issue so a solution is required. Identified solutions are based on TCP characteristics and TCP variants. This thesis focuses on development of a low cost platform, using channel emulation and equipment virtualization techniques, to emulate a satellite network, and its use to compare performance evaluation of TCP variants in geostationary satellite links. Tested TCP variants are TCP Reno, TCP Cubic, TCP Hybla, TCP Vegas and TCP Westwood. Our results show that TCP Cubic is the most efficient TCP variant but also the one with the long latency. TCP Hybla has a really good efficiency, particularly on short size file transfers and has low latency than TCP Reno. TCP Vegas is the lowest latency TCP variant, not as efficient as TCP Hybla and TCP Cubic, but it suffers a fairness and friendliness issue. TCP Westwood has a fairness issue and its own bandwidth estimator can sometimes underestimate link capacity causing TCP performance degradation. If corruption losses are present at satellite link, comparative performance evaluation study shows that an improvement up to 40 percentage efficiency ratio points can be achieved using a TCP variant different than TCP Reno. Satellite modem buffer sizing has been evaluated to achieve satellite link stability with maximum throughput. Our results show buffer size of BDP (Bandwidth Delay Product) satellite link as the optimum buffer size. A bigger buffer size would introduce a high latency. TCP Vegas could solve this issue if modem buffer size can?t be changed. A Performance Enhancing Proxy (PEP) can improve TCP performance when used in satellite communication link, splitting the connection and establishing another one with a TCP variant not initially supported by the host and adapted to satellite channel characteristics. Open source PEPsal solution is tested and evaluated over the developed virtual testbed platform.

[es] Las redes de comunicaciones han experimentado un crecimiento exponencial en los últimos años. El número de dispositivos conectados a Internet no ha parado de aumentar y, en el mundo digital en el que vivimos, generan un ingente tráfico de datos que colapsaría los enlaces de la red si no fuese por el mecanismo de control de congestión del protocolo TCP. El estándar de este mecanismo denominado TCP Reno fue creado en el año 1990. Cuando se quiere interconectar dos sedes remotas que se encuentran en una zona de difícil acceso o sin cobertura de datos terrestre las redes satelitales se convierten en imprescindibles, pero TCP Reno no fue diseñado pensando en un enlace satélite. Ante el retardo elevado, la alta capacidad y las pérdidas originadas por fenómenos atmosféricos y radiaciones cósmicas o solares que caracterizan este tipo de enlaces, TCP Reno sufre una degradación importante en el throughput y presenta un problema de equidad por lo que se necesitan alternativas que mejoren el rendimiento del protocolo cuando se hace uso de un satélite de comunicaciones. En este proyecto se estudian y evalúan las alternativas que pueden llegar a mejorar el desempeño del protocolo TCP en comunicaciones vía satélite geoestacionario. Para ello, se ha diseñando e implementando una infraestructura de bajo coste en la que emular el comportamiento del enlace satélite mediante la tecnología de virtualización, de forma que el sistema emulado se comporta lo más transparentemente posible, caracterizando el comportamiento del sistema real. Las soluciones de mejora identificadas se han dividido en mecanismos basados en las características estándar del protocolo TCP y en las variantes del algoritmo de control de congestión TCP. Se realiza una comparativa del estándar TCP Reno con las variantes TCP Cubic, TCP Hybla, TCP Vegas y TCP Westwood. Haciendo uso de la tecnología UML se implementan los bancos de pruebas con una infraestructura en la que emular el comportamiento del enlace satélite y se mide la evolución de la ventana de congestión para cada variante TCP evaluando su desempeño en base a su eficiencia, latencia, adaptabilidad y equidad. La comparativa muestra como TCP Cubic es la variante que presenta generalmente mayor eficiencia pero también la mayor latencia. TCP Hybla presenta una eficiencia muy buena, destacando sobre el resto en transferencias de archivos de pequeño tamaño con una latencia mejor que el estándar Reno. TCP Vegas es la variante con una menor latencia pero no supera en eficiencia a TCP Hybla y TCP Cubic. El mayor problema de TCP Vegas es su equidad con otras variantes y con otra variante afín. TCP Westwood no es equitativa con variantes afines y en algunos casos puede estimar un ancho de banda inusualmente bajo que impacte en su rendimiento. La comparativa entre variantes TCP para un entorno ruidoso del enlace satélite, muestra que la mejora del ratio de eficiencia con respecto al estándar TCP Reno es espectacular y puede suponer un incremento de 40 puntos porcentuales, si se hace uso de una variante TCP adaptada a las características del enlace satélite. Se evalúa el tamaño óptimo del búfer del módem satélite que resulta ser entorno al BDP (Bandwidth Delay Product), tamaño mínimo que asegura que el enlace satélite no fluctúa y se mantiene ocupado durante toda la transmisión. Tamaños mayores del búfer del módem satélite causan un aumento de la latencia. La variante TCP Vegas puede resultar idónea para situaciones en las que no existe control sobre el tamaño del búfer. Se estudia y evalúa el uso de la solución opensource PEPsal cuando no es posible actuar sobre la variante TCP en el emisor: Intercalar un Performance Enhancing Proxy (PEP) antes del enlace satélite provoca una mejora en el rendimiento del protocolo TCP. El PEP permite dividir la conexión, interceptar los segmentos y establecer una nueva conexión con otra variante TCP adaptada al enlace satélite y sus características.