¿Qué es TCP Nuevo Reno?

TCP New Reno es la extensión de TCP Reno. Supera las limitaciones de Reno. TCP Reno es la segunda variante de TCP que presentó un algoritmo de congestión incorporado. El manejo de la congestión no era una parte integral de la suite TCP/IP original. TCP Reno es la extensión de TCP Tahoe y NewReno es la extensión de TCP Reno. En Reno, cuando se produce una pérdida de paquetes, el remitente reduce el cwnd en un 50 % junto con el valor de ssthresh. Esto permitiría que la red saliera fácilmente del estado de congestión. Pero Reno sufrió una acumulación de pedidos muy crítica que perjudicó su desempeño. 

Cuando se descartan varios paquetes en la misma ventana de congestión (digamos 1-10), cada vez que se entera de la pérdida de un paquete, reduce el cwnd en un 50 %. Entonces, para la pérdida de 2 paquetes, reducirá el cwnd 4 veces (50% dos veces). Pero, una reducción del 50% por ventana de congestión fue suficiente para recuperar todos esos paquetes perdidos. Digamos cwnd=1024 y se descartan 10 paquetes en esta ventana, Reno reducirá cwnd en un 50% 10 veces, finalmente cwnd=1024/2 ¹⁰ = 1, es asombroso. Se necesitarían 10 RTT por parte del remitente para volver a aumentar su cwnd hasta 1024 utilizando el inicio lento y dejar solo el algoritmo AIMD.

Limitación de Reno:

1. Lleva mucho tiempo detectar múltiples pérdidas de paquetes en la misma ventana de congestión .
2. Reduce la ventana de congestión varias veces para la pérdida de múltiples paquetes en la misma ventana, donde una reducción fue suficiente.

¿Cómo evolucionó New Reno?

La idea era superar las limitaciones de Reno. El truco consistía en hacerle saber al remitente que necesita reducir el cwnd en un 50 % para todas las pérdidas de paquetes que ocurrieron en la misma ventana de congestión. Esto se hizo usando ACK parcial. Se introdujo el nuevo tipo de ACK para informar al remitente sobre esto. En Reno, después de media ventana de silencio cuando recibe el ACK del paquete retransmitido, lo considera un nuevo ACK y sale una recuperación rápida e ingresa a AIMD, luego nuevamente si ocurre la pérdida de paquetes (mismo cwnd) luego repite el mismo procedimiento de reducción de cwnd por la mitad. Pero el remitente de NewReno verificará si el ACK del paquete retransmitido es nuevo o no en el sentido de que todos los paquetes de ese cwnd en particular son ACK por parte del receptor o no. Si todos los paquetes de ese cwnd en particular son ACK por parte del receptor, entonces el remitente considerará ese ACK como un ACK nuevo, de lo contrario parcial. Si es un ACK parcial, el remitente no volverá a reducir cwnd en un 50 %. Se mantendrá igual y no saldrá de la fase de recuperación rápida.

Solución NewReno:

Utiliza el concepto de reconocimiento parcial. Cuando el remitente recibe el ACK del primer paquete retransmitido, no lo considera un «Nuevo ACK» a diferencia de TCP Reno. NewReno comprueba si todos los paquetes transmitidos anteriormente de esa ventana en particular están ACK o no. Si se pierden varios paquetes en la misma ventana de congestión, el receptor habría estado enviando los ACK duplicados solo incluso después de recibir el paquete retransmitido. Esto dejará en claro al remitente que todos los paquetes no llegan al receptor y, por lo tanto, el remitente no considerará ese ACK como nuevo. Lo considerará un ACK parcial porque solo se está ACKing una ventana parcial, no la totalidad. Reno solía salir de la fase de recuperación rápida después de recibir un nuevo ACK, pero NewReno considera que ese ACK es parcial y no sale de la fase de recuperación rápida.

Por lo tanto, NewReno detectará la pérdida de múltiples paquetes de inmediato y no saldrá prematuramente de la fase de recuperación rápida, a diferencia de Reno.

Entendiendo con un ejemplo:

Suposición:

1. El remitente tiene datos ilimitados para enviar
2. initcwnd = 10 segmentos
3. Los paquetes 3 y 4 se descartan.

S. No.	Paquetes ACKed	cwnd	a bordo	Paquetes transmitidos
1.	Ninguna	10	10	1, 2, 3, 4, 5, 6, 7, 8, 9, 10
2.	1	11	11	11, 12
3.	2	12	12	13, 14
4.	2 (DA1, R5)	13	13	15, 16
5.	2 (DA2, R6)	14	14	17, 18
6.	2 (DA3, R7) *	7	13	Re 3
7.	2 (DA4, R8)	7	12	–
8.	2 (DA5, R9)	7	11	–
9.	2 (DA6, R10)	7	10	–
10	2 (DA7, R11)	7	9	–
11	2 (DA8, R12)	7	8	–
12	2 (DA9, R13)	7	7	–
13	2 (DA10, R14)	7	7	19
14	2 (DA11, R15)	7	7	20
15.	2 (DA12, R16)	7	7	21
dieciséis.	2 (DA13, R17)	7	7	22
17	2 (DA14, R18)			23
18	3	7	7	24
19	3 (DA1, R19)	7	7	25
20	3 (DA2, R20)	7	7	26
21	3 (DA3, R21)*	7	7	Re 4
22	3 (DA4, R22)	7	7	27
23	3 (DA5, R23)	7	7	28
24	3 (DA6, R24)	7	7	29
25	3 (DA7, R25)	7	7	30
26	3 (DA8, R26)	7	7	32
27	26	(7+1/7)	7	32

Paso 18 a 20 : TCP Reno lo considera un nuevo ACK y sale de la fase de Recuperación Rápida y entra en la fase de IA. Mientras que NewReno lo marca como ACK parcial y permanece continuamente en la fase de Recuperación Rápida. El remitente comprueba si ha recibido todos los ACK de todos los paquetes de esta ventana de congestión en particular. En caso afirmativo, entonces este es un nuevo ACK, de lo contrario, un ACK parcial.

Paso 21 : Del 18 al 20, TCP Reno aumenta la ventana de congestión en 1/7 por ACK. Pero NewReno mantiene cwnd=inflight=7 porque todavía está en la fase de recuperación rápida y aún no ha entrado en la fase de IA. Retransmite el paquete 4 después de recibir 3 ACK duplicados.

Paso 22 a 26: el remitente obtiene ACK duplicados y mantiene cwnd=inflight. Envía un nuevo paquete al enlace por ACK. La fase de Recuperación Rápida aún no ha terminado. Porque no ha recibido un nuevo ACK.

Paso 27 : El receptor recibió el paquete 4 que fue retransmitido por el remitente. Ahora, el receptor tiene todos los paquetes del 1 al 26 en orden. El receptor también recibe los paquetes perdidos 3 y 4, por lo que ahora envía el ACK acumulativo para los paquetes 4-26 como ACK-26. Hasta el último paso, enviaba un ACK-3 duplicado diciendo que había recibido hasta el paquete 3 en orden. El remitente ahora recibió el ACK acumulativo y verifica si es un ACK nuevo o no. 

ACK received > cwnd ? Yes : No
26 > 10 ? yes : No

Por lo tanto, sí, ACK-26 es un nuevo ACK. Por tanto, ahora el remitente saldrá de la fase de Recuperación Rápida.

Tenga en cuenta que el remitente permaneció más tiempo en la fase de recuperación rápida en comparación con Reno, pero no redujo cwnd y ssthresh varias veces para la misma ventana de congestión. Esto no estaba disponible en TCP Reno.