Apunte de Performance de TCP Reno (Teoría de las Comunicaciones)

De Cuba-Wiki
Saltar a: navegación, buscar
Back.png Volver a la página de la materia

El siguiente es un apunte basado en el paper The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm by Matthew Mathis.

Motivación[editar]

La motivación del paper es la construcción de un modelo simplificado para el análisis de la performance de TCP Reno en función de la congestión. Notar que el modelo es simplificado y supone muchas restricciones, las cuales, si se relajan, implicarían una caída aún mayor en el throughput calculado.

La medida de throughput estándar para un algoritmo de sliding window es , donde W es el tamaño máximo de ventana. Recordar que el throughput es data de nivel 4 transmitida sobre tiempo. El objetivo es introducir factores de congestión en dicha ecuación.

Como nota aparte, considerando que el tamaño máximo de ventana de TCP es relativamente pequeño (64kB?), para aprovechar un enlace grande (100Gbps) es conveniente abrir varias conexiones TCP y utilizar el multiplicador opcional de tamaño de ventan, para no desperdiciar la potencia del enlace.


Modelo[editar]

El modelo consiste en dos hosts (uno emisor y otro receptor) unidos por un link que droppea paquetes con cierta probabilidad. La probabilidad p de drop es constante, y significa que cada 1/p paquetes, el último se pierde. Otra forma de considerar p es la cantidad de señales de congestión por cada paquete acknowledged. Recordar que para TCP la pérdida de un paquete es una señal de congestión, que en el modelo resulta periódica.

El modelo también asume que el RTT del link es constante, y el ancho de banda no es un limitante (sea por su tamaño o por la baja carga). En otras palabras, supone un régimen estable. Para esto es necesario suponer una conexión lo suficientemente larga.

Es necesario que la situación sea gobernada siempre por Congestion avoidance, si se suceden situaciones como que el advertised window del receptor es muy pequeña, o el emisor no tiene suficientes datos para enviar, el throughput bajaria aún más. Tampoco se tienen en cuenta los tiempos perdidos por time out ni retransimisiones innecesarias de implementaciones go-back-n, se supone una implementación con SACKs.

Debido a todas las presunciones realizadas, el tamaño de ventana en función del tiempo (medido en RTTs) resulta tener una forma de serrucho, correspondiente al incremento lineal del CWND para luego caer a la mitad al ocurrir una pérdida.

Redes-VentanaCongestionSerruchoEnTcpReno.PNG

Notar que el tiempo, medido en RTTs, está expresado en función del tamaño de ventana. Como el emisor aumenta su ventana en 1 segmento por RTT, el tiempo que pasa para abirirla W/2 segmentos es RTT * W/2 segundos.


Cálculo de Throughput[editar]

La cantidad de data enviada por ciclo corresponde al área debajo de cada línea del serrucho. Integrando, usando la fórmula del área de un trapecio, o sumando las áreas de un cuadrado y un triángulo, resulta . Despejando W, se obtiene .

Reemplazando los valores obtenidos para W y ciclos en la fórmula del ancho de banda y del throughput (recordar que ), resulta:

Donde la constante C es igual a en este caso, pero puede variar dependiendo de la implementación de TCP que se esté analizando.


Conclusiones[editar]

El control de congestión en TCP es un limitante del throughput. Por lo tanto, el valor de este último depende de la probabilidad de pérdida de paquetes, no solamente del tamaño de ventana y el RTT.

El modelo propuesto introduce la pérdida de paquetes y el control de congestión al modelo estándar de sliding window. Recordar que el modelo es optimista, es conveniente usar la ecuación obtenida como una cota para el throughput más que como una igualdad.