Fairness and Stability of Congestion Control Mechanisms of TCP
(La equidad y la estabilidad de los mecanismos de control de congestión de TCP)
-----------
Autores: Hasegawa, Masayuki Murata, and Hideo Miyahara
Department of Infomatics and Mathematical Science Graduate School of Engineering Science
-----------
En el pdf nos habla de tres versiones de TCP: Tahoe, Reno y Vegas. De las cuales las 2 primeras son ampliamente utilizadas en internet.
En TCP, el tamaño de la ventana para la conexión, llamada tamaño de ventana de congestión (cwnd), se cambia de acuerdo con la indicación de congestión de la red. El cambio del tamaño de la ventana tiene un impacto significativo sobre el comportamiento de TCP. Para ello, lo primero que resumimos son los algoritmos para actualizar cwnd (t) en las tres versiones de TCP.
Version TCP Tahoe
+13.43.41.png)
En TCP Tahoe, el tamaño de la ventana de cwnd se cambia cíclicamente. Cwnd continúa aumentando hasta que se produzca la pérdida del segmento. Cuando esto ocurre, TCP determina que la red está congestionada, y los aceleradores cwnd bajan el tamaño de un segmento. TCP Tahoe tiene dos fases en el aumento de cwnd fase de inicio lento y fase de evitar la congestión.
+13.44.02.png)
Es decir, TCP Tahoe entra de nuevo en fase de inicio lento cuando se produce la pérdida de segmento. Por lo tanto, la dinámica de la TCP Tahoe en un caso más simple es, Slow Fase Start + Congestión evitación Fase + pérdida del segmento + lenta fase de inicio = ...
Version TCP Reno
TCP Reno es similar a TCP Tahoe, pero utiliza otro algoritmo cuando se produce pérdida del segmento. En fase de inicio lento y Congestion Avoidance Phase, Reno TCP siempre usa la ecuación de abajo para actualizar el tamaño de la ventana, pero cuando la pérdida de segmento se detecta por el algoritmo de retransmisión rápida, el tamaño de la ventana de cwnd (t) se reduce a la mitad. Es decir,
+13.55.24.png){kind=small}
TCP Reno entra entonces en la fase de recuperación rápida.
En esta fase, el tamaño de la ventana se incrementa en un segmento cuando se recibe un segmento ACK duplicado, y cwnd (t) se restaura a SSTH cuando el segmento ACK no duplicados corres-pondiente al segmento retransmitido se recibida.
+13.59.16.png)
En TCP Tahoe y Reno, el tamaño de la ventana, cwnd se incrementa hasta pérdida del segmento se produce debido a la congestión. Entonces, el tamaño de la ventana es estrangulado, lo que conduce a la degradación de rendimiento de la conexión. Sin embargo, no se puede evitar debido a una naturaleza esencial del mecanismo de control de congestión de TCP adoptado en Tahoe y Reno.
Es capaz de detectar información de congestión de red sólo por la pérdida del segmento. Sin embargo, se convierte en un problema, ya que el segmento se puede perder cuando la conexión TCP en sí hace que la congestión debido a su tamaño demasiado grande ventana. Si cwnd es apropiadamente controlado de tal manera que la pérdida del segmento no se produce en la red, la degradación del rendimiento debido a la ventana estrangulado se puede evitar. Esta es la razón por la que TCP Vegas se introdujo.
TCP Vegas emplea otro mecanismo para la detección de la congestión de la red. Se controla cwnd observando los cambios de RTT (Round Trip Time) de los segmentos que la conexión ha enviado antes. Si los RTT observados se hacen grandes, TCP Vegas reconoce que la red empieza a ser congestionada y bajo los aceleradores cwnd.
Si RTT se vuelven pequeñas, TCP Vegas determina que la red se alivia de la congestión, y aumenta cwnd.
Análisis
Version TCP Tahoe
En TCP Tahoe, el cambio del tamaño de la ventana es cíclica.
+14.27.47.png)
Cuando la única conexión utiliza el enlace. También es cierto cuando dos conexiones con retardos de propagación idénticos comparten el enlace desde segmentos de dos conexiones se pierde al final del ciclo. Se trata de explicarse de la siguiente manera.
Supongamos dos remitentes, ambos TCP abren la ventana a la misma velocidad en la fase de evitar la congestión. Cada incrementos de conexión de su tamaño de la ventana por un segmento de forma simultánea, e inyecta un nuevo segmento en la red. Por último, la suma de los tamaños de las ventanas de ambas conexiones es igual a W, la suma de los productos de ancho de banda de retardo del enlace (W) y el tamaño del búfer en el interruptor (B).
Entonces nuevos segmentos de ambas conexiones son probabilidades de ser desechadas en el inicio de interruptor porque la suma de los tamaños de ventana excede la capacidad de la red por dos segmentos. Es cierto que tratamos un caso especial para la configuración de la red, pero el problema descrito en lo anterior es inherente en TCP Tahoe.
Version TCP Reno
Version TCP Reno
Como se describe anteriormente, el mecanismo de control de gestión es similar al de TCP Tahoe, excepto que TCP Reno tiene una fase de recuperación que es capaz de reaccionar a la perdida de segmentos rápidamente.
Es decir, en la fase de recuperación rápida, el tamaño de la ventana se infla temporalmente hasta que se recibe ACK no duplicados, y se restaura a SSTH. Después de eso, la fase de evitar la congestión comienza como en TCP Tahoe. Por lo tanto, si ignoramos la inflación temporal del tamaño de la ventana en rápida fase de recuperación, Reno TCP controla el tamaño de la ventana como si la fase inicial se eliminara a partir del cambio del tamaño de la ventana de TCP Tahoe.
Version TCP Vegas
Hay otra razón por la TCP Vegas no puede lograr la equidad entre las conexiones. Esto es causado por la diferencia de basertt de de dos conexiones, incluso en el caso homogéneo con retardos de propagación idénticos.
Por otro lado, el tamaño de la ventana en el caso heterogéneo se convierte en casi proporcional al retardo de propagación de cada conexión. Por lo tanto, el rendimiento se define como (tamaño de la ventana) / (propagación retardo) pasa a ser igual, y podemos decir que la justicia ser mejor cuando en el caso heterogéneo. Sin embargo, el rendimiento obtuvieron tiene algún rango depende de los parámetros elegidos y Q, Ll en TCP Vegas, lo que provoca la falta de equidad entre las conexiones.
Referencias
Autores: Hasegawa, Masayuki Murata, and Hideo Miyahara
Universidad: Osaka University, Japan
En la referencia al final pon de qué forma fue publicado el trabajo (congreso, revista, qué cosa)? Falta una crítica constructiva propia. 6 pts.
ResponderEliminar