Impacto del protocolo de enlace de tres vías y el algoritmo de inicio lento

Internet se convirtió en algo sin lo cual nuestras vidas están incompletas. Todos los días, cada usuario de Internet realiza cientos de consultas en Internet, ya sea una simple búsqueda en Google o visitando cualquier sitio web, y a nadie le gusta la demora en la respuesta. En este artículo, discutiremos el retraso de tiempo que afecta la velocidad de Internet. Se introdujo un protocolo de enlace de tres vías en la época inicial de Internet cuando se introdujo TCP. Durante el período de tiempo, el protocolo de enlace de 3 vías se evita por completo utilizando TCP FastOpen . Pero aún así, existe un algoritmo de control de congestión muy infame que siempre invoca cuando comienza el flujo TCP, este es un algoritmo de reinicio de inicio lento. Esto lleva mucho tiempo antes de que comience a enviar paquetes del tamaño del búfer a la red, incluso si el ancho de banda está totalmente disponible.

Comienzo lento:

El propósito del proceso de reinicio de inicio lento es ‘estimar’ cwnd y llegar rápidamente a una ‘estimación decente’. Este algoritmo se invoca de forma predeterminada cuando se inicia un nuevo flujo de TCP o cuando el enlace está inactivo durante 1 tiempo de RTO. El valor de cwnd aumenta lentamente de 10 a 20, 40, 80 y así sucesivamente por RTT. El cwnd se incrementa en 1 cuando llega un nuevo ACK al remitente. El remitente envía 2 nuevos paquetes al enlace al recibir un ACK. Se envía 1 paquete para compensar el paquete entregado, otro se envía de acuerdo con el valor aumentado del tamaño de la ventana de congestión.

Impacto del algoritmo de inicio lento

Cada conexión TCP debe pasar por la fase de inicio lento. Significa que no podemos utilizar la «capacidad disponible en el enlace» inmediatamente después de que se establezca la conexión. La transferencia de datos comienza con ‘initcwnd’ y se duplica (aproximadamente) en cada RTT. Suponga que el remitente está limitado por la ventana anunciada del receptor, que es de 64 KB. El remitente no puede comenzar a enviar directamente 64 KB; comienza con Slow Start y aumenta la tasa de envío. 

El tiempo que necesita el remitente para hacer crecer su ventana de congestión (cwnd) de modo que pueda transmitir 64 KB a la vez, se puede calcular utilizando la fórmula dada.

dónde, 

• RTT significa Tiempo de ida y vuelta;
• init_cwnd es la variable local que almacena el tamaño de la ventana de congestión inicial, que se establece de forma predeterminada en todos los sistemas operativos.
• N es el tamaño de ventana de congestión deseado, digamos 64 KB.

Ejemplo:

RTT = 56 ms (London to New York)
Initial congestion window (initcwnd) = 10 segments
1 segment size = 1460 bytes
For the TCP Sender to transmit 64KB simultaneously, it must have a 
congestion window value of approximately 45 segments.
N = (64KB ÷ segment size = 65536 bytes ÷ 1460 bytes = 44.88 segments)

Time = RTT x ceil(log2(1 + 45/10))
= RTT x ceil(log2(5.5))
= 56 ms x ceil(2.459)
= 56 ms x 3
= 168 ms
Thus, the sender would be able to transmit 64 KB simultaneously after 168 ms.

Apretón de manos de tres vías:

El protocolo de enlace de tres vías es el proceso inicial de establecimiento de la conexión. El cliente primero envía la solicitud de conexión al servidor (paquete SYN). Si el espacio de memoria y otros recursos están disponibles en el lado del servidor, entonces el servidor acepta la solicitud de conexión entrante y la envía al cliente mediante el envío del paquete SYN+ACK. Cuando el cliente recibe este paquete, inicia la comunicación real con el servidor y envía la solicitud GET del siguiente paquete en adelante. En la respuesta, el servidor envía los datos reales solicitados por el cliente.

Impacto del apretón de manos de tres vías:

Si la medida de RTT es de 56 ms. Esta cantidad de tiempo simplemente se desperdicia en el establecimiento de la conexión. El cliente envía el paquete SYN al receptor para solicitar la conexión. El servidor responde al cliente enviando un paquete SYN+ACK. Esta ronda bidireccional consume todo el tiempo de RTT. A partir del siguiente paquete, ocurre una comunicación real, en la que el cliente primero solicita algunos datos del servidor, enviando la solicitud GET en un nuevo paquete. Por lo tanto, un RTT es el costo que paga el cliente por el protocolo de enlace de 3 vías. Si de alguna manera se puede evitar este apretón de manos, entonces se pueden ahorrar 56 ms, en este caso, cada vez que el cliente se conecta al servidor.

Impacto del protocolo de enlace TCP y el algoritmo de inicio lento

Suponga las variables:

Round Trip Time = 56 ms, standard RTT time between London and New York
Available Bandwidth  to both server and client is= 5 MBPS
Receiver window size (rwnd) of both client and server= 
                    65,535 bytes = 64KB = 45 segments
Initial congestion window (init_cwnd)= 10 segments

Server processing time to process the given GET query and 
generate the corresponding response is = 40 ms

Assume the network is clean, with no packet loss and 
1 ACK per packet, only GET requests are sent.

Paso 1: el remitente envía el paquete SYN en el tiempo = 0.

Paso 2: el receptor recibe el paquete SYN en el tiempo = 28 ms, que es un tiempo de ida. El receptor acepta la solicitud de conexión y devuelve el paquete SYN+ACK en el tiempo = 28 ms, justo después de recibir el paquete SYN del remitente. 

Paso 3: El ACK llega al remitente en el tiempo = 56 ms, un paquete tardó otros 28 ms en llegar del lado del receptor al remitente, esto hace un total de un tiempo RTT, el viaje de ida y vuelta del paquete. Ahora la conexión se establece entre el remitente y el receptor mediante protocolos de enlace de 3 vías.

Paso 4: ahora el remitente envía la solicitud GET al receptor en el tiempo = 56 ms. Se tarda 28 ms en llegar y el receptor recibe la solicitud GET.

Paso 5: a la hora = 84 ms, el servidor recibe la solicitud GET. 

Paso 6: el servidor tarda 40 ms en procesar la solicitud y generar los datos para enviar paquetes de respuesta. Después de transcurridos 40 ms, el servidor envía los 10 segmentos de datos simultáneamente en el tiempo = 124 ms sin esperar que llegue un solo ACK.

Paso 7: El remitente o cliente comenzará a recibir los paquetes de respuesta uno tras otro y enviará el ACK de cada paquete al servidor. El cliente obtendrá los 10 segmentos por tiempo = 152 ms. Al recibir los paquetes ACK, el servidor aumentará el tamaño de su ventana de congestión en 1 por paquete ACK. Inicialmente, cwnd era 10, por lo que enviaba 10 segmentos simultáneamente. Cuando el servidor aumenta su cwnd en 1, envía 2 nuevos paquetes al enlace. 

Paso 8: en un tiempo RTT, el servidor obtendrá el ACK de los 10 paquetes y, por lo tanto, su cwnd se convertiría en 10*2 = 20 en el tiempo = 180 ms. Además, en este momento el servidor ha enviado 20 nuevos segmentos al enlace, además de los 10 segmentos iniciales cuya entrega ya ha sido ACK.

Paso 9: Ahora, 20 segmentos están en la tubería entre el emisor y el receptor en el tiempo = 180 ms.  

Paso 10: Por tiempo=208 ms, el cliente recibirá todos estos paquetes.

Paso 11: Por tiempo=236 el servidor envía 15 nuevos segmentos. En este momento, el servidor obtendrá ACK de todos estos 20 segmentos. En el interior, el servidor aumentará su cwnd en 1 por ACK pero no puede enviar 2 nuevos paquetes para cada ACK porque solo quedan 15 segmentos para enviar (45 segmentos en total). cwnd=40 ahora. 

Paso 12: Así en tiempo=264 ms, se alcanzan 15 segmentos al cliente. Por lo tanto, se requieren 264 ms para enviar 64 KB de datos al cliente.

Paso 13: En time=292 ms, 15 ACK llegarán al servidor y cwnd se convertirá en 40+15 = 55, pero el servidor no tiene datos para enviar.

Entonces, se necesitan 264 ms para enviar 45 paquetes al cliente.

El ancho de banda disponible entre el servidor y el cliente es de 5 MBPS, pero aun así, el archivo de 64 KB está tardando 264 ms. Este tiempo no disminuirá aunque aumentemos el ancho de banda a 50 MBPS o 5 GBPS. Si el cliente está visitando los servidores de Gmail o Google, el tiempo de carga de la página será de 264 ms, y este tiempo no se puede reducir aumentando el ancho de banda.

Solicitar el mismo archivo nuevamente en la misma conexión

Suponga que la conexión está inactiva durante unos segundos menos que RTO, el inicio lento no se reinicia y el cliente envía otra solicitud GET al servidor. 

Paso 1: el remitente envía una solicitud GET a la hora = 0 ms. 

Paso 2: la solicitud GET llega al servidor a la hora = 28 ms.

Paso 3: el servidor tarda 40 ms en procesar la solicitud. Genera la respuesta en tiempo=68 ms y la envía al cliente.

Paso 4: Tenga en cuenta que el cwnd del servidor ya es 55 en la transferencia anterior. Entonces, el servidor enviará 45 segmentos simultáneamente en el tiempo = 68 ms.

Paso 5: En tiempo=96 ms, el cliente recibe los 45 segmentos.

Por lo tanto, el inicio lento ha desperdiciado 264 – 96 = 168 ms. 

Conclusión:

264 ms taken by the server to successfully(with ACK) send 45 segments to the client.
By formula time taken by Slow Start to grow the cwnd to 64 KB= 168 ms.
Server processing time = 40 ms
Time elapsed in 3-way Handshakes = 56 ms
 
Total time = 3-way-handshake + server_processing + Slow_start
264 = 56(3-way-handshake) + 40(server response time) + 168(Slow_start) ms

Thus, slow start and 3-way Handshakes have wasted = 168 ms + 56 ms = 224 ms.

Si no hubo un inicio lento y un protocolo de enlace de 3 vías, se requerirían 96 ms.