Acuses de recibo selectivos (SACK) en TCP

Cuando se detecta la pérdida de un paquete en la comunicación TCP entre el cliente y el servidor, el siguiente paso es recuperar el paquete de datos perdido. Hay algunos de los algoritmos para la recuperación de pérdidas en TCP. Estos son: 

  1. Rápida recuperación
  2. Acuses de recibo selectivos (SACK)
  3. Tasa de Reducción Proporcional (PRR)

Limitaciones de la recuperación rápida:

El mecanismo de ‘Recuperación rápida’ en TCP Reno tiene dos problemas principales. 

  1. Reducción de varias veces de la ventana de congestión (cwnd) para el mismo conjunto de paquetes. Este problema lo resuelve TCP New Reno.
  2. Lleva mucho tiempo recuperarse de varios paquetes que se pierden en la misma ventana de congestión. Este problema se resuelve mediante reconocimientos selectivos (SACK).

Agradecimientos Selectivos (SACK):

SACK es una optimización del lado del remitente y del receptor para TCP . Tanto el remitente como el receptor deben admitir la función SACK, solo entonces es posible usar esto. La función SACK está habilitada de forma predeterminada en todos los sistemas operativos, es decir, Linux, Windows y macOS. SACK no reemplaza los ACK originales en el encabezado de TCP, pero agrega otro campo en el campo de opciones del encabezado de TCP para la información de SACK. El campo ‘Opciones’ en el encabezado TCP se usa para enviar SACK, no se modifica el campo ACK real. Se puede utilizar un máximo de 32 bytes (de 40 bytes) para SACK en el campo ‘Opciones’. 8 bytes en el campo ‘Opciones’ ya están reservados para ‘marcas de tiempo’.

Funcionamiento de SACK: 

La función SACK ayuda al remitente a identificar «brechas» en el búfer del receptor. Cuando el receptor no recibe los paquetes en orden, existen algunos agujeros (puntos faltantes) en el búfer. SACK ayuda al remitente a conocer estos agujeros en el búfer del receptor en un momento temprano. Cuando el remitente sabe acerca de los agujeros o paquetes perdidos, los retransmite al mismo tiempo. A diferencia de Fast Recovery, SACK no informa al remitente muy tarde sobre los paquetes perdidos.

Working of SACK

Funcionamiento de SACK

Explicación:

El remitente envía los paquetes 0, 1, 2, 3 y 4 al mismo tiempo inicialmente. El receptor recibe el paquete 0 y solicita el siguiente paquete secuenciado mediante el envío de ACK-1. 

El remitente obtiene ACK-1 y envía el paquete-5 para mantener cwnd=5.

El paquete 1 se descarta debido a la congestión de la red.

El receptor recibe el paquete-2. Envía el paquete-6 para mantener cwnd=5. Ahora el receptor está desordenando los paquetes. Solicita el paquete-1 enviando ACK-1 y crea un bloque SACK para el siguiente paquete requerido. El campo de reconocimiento seguirá enviando números duplicados. El receptor envía ACK-1 y SACK 2-3. ACK-1 significa que el receptor está solicitando el paquete-1. SACK 2-3 significa que el receptor recibió el paquete 2 y solicitó el paquete 3.

El paquete = 3 se descarta.

El receptor recibe el paquete-4. Envía el paquete-7 para mantener cwnd=5. El búfer del receptor se parece a: [0, 2, 4]. Entonces, hay dos agujeros en su búfer. El receptor envía ACK-1 y SACK 2-3, 4-5. Significa que el receptor tiene los paquetes 2 y 4 y solicita los paquetes 3 y 5. También envía el segundo ACK-1 duplicado.

El receptor obtiene el paquete = 5. El receptor envía ACK-1 y SACK 2-3, 4-6. 
El remitente obtiene el tercer ACK-1 duplicado, por lo que ingresa a la fase de recuperación rápida y transmite todos los paquetes perdidos hasta ahora al mismo tiempo. El receptor está solicitando los paquetes 1 y 3.

La pérdida del paquete 1 se transmite mediante el campo ACK y la pérdida del paquete 3 se transmite mediante SACK.

El remitente retransmite los paquetes 1 y 3. En vuelo parece 6, 7, 1, 3

El receptor recibe el paquete 6 con éxito. 

Cuando el receptor recibe el paquete-1. El búfer se ve así: [0, 1, 2, 4, 5, 6]. Todavía hay un agujero en el búfer.
El receptor envía ACK-3, SACK 4-7. ACK-3 significa que el receptor ha recibido hasta el paquete 2 en orden. SACK 4-7 dice que el receptor recibió los paquetes 4, 5 y 6 y solicitó el 7.

Cuando el receptor recibe el paquete-3. El búfer se ve así: [0, 1, 2, 3, 4, 5, 6]. Ahora todos los paquetes han llegado en orden. El receptor envía ACK-7 solicitando el siguiente paquete.

El receptor recibe el paquete 7 con éxito y solicita el siguiente paquete 8.

SACK en cabecera TCP:

La extensión SACK usa ‘dos’ opciones de TCP. La opción ‘ Permitido por SACK ‘ se usa con el paquete SYN. Cuando el cliente habla con el servidor por primera vez, le dice al servidor que se usa SACK. La segunda opción es la opción ‘ SACK ‘, que se usa solo cuando el receptor está recibiendo paquetes desordenados. La primera opción es hacerle saber al servidor que el cliente es compatible con SACK, en respuesta, el servidor-cliente sabrá si el servidor es compatible con SACK o no.

Opción ”SACK-Permitido”:

Kind=4, Length=2

“SACK-opción”:

Kind=5, Length=8*number of SACK blocks.

“Bloque SACK”:

|Left edge of block of size 4 bytes||| Right edge of block of size 4 bytes|

Cada bloque SACK requiere 8 bytes. 4 bytes para el borde izquierdo del bloque. 4 bytes para el borde derecho del bloque. Bordes = números de secuencia que tienen 32 bits (4 bytes) de largo. 

Limitación de SACO:

El receptor puede informar un máximo de cuatro bloques SACK en un segmento. Un bloque SACK necesita 8 bytes, por lo que hay disponibles 8 x 4 bloques SACK = 32 bytes para bloques SACK. Porque se reservan 8 bytes para la opción de marca de tiempo TCP (Tipo = 8, Longitud = 10). 

8 bytes de TCP Timestamp + 32 bytes de SACK = 40 bytes (capacidad total del campo Opciones TCP).

Mejoras a SACK 

  1. Confirmación de reenvío (FACK)
  2. Reconocimiento selectivo duplicado (DSACK)
  3. Reconocimiento reciente (RACK)

¿Por qué SACK es bueno para las redes inalámbricas?

SACK es bueno para las redes inalámbricas porque las redes inalámbricas informan más rápido de múltiples pérdidas de paquetes. Las pérdidas de paquetes y las retransmisiones son más frecuentes en un entorno inalámbrico. La aplicación en el lado del receptor no necesita esperar más para que se llenen los ‘vacíos’ en el búfer del receptor.  

SACK minimiza el tiempo de finalización del flujo (FCT). Las pérdidas consecutivas de paquetes se pueden informar en un solo bloque SACK. SACK mejora el rendimiento en gran medida porque todos los paquetes se retransmiten inmediatamente. El remitente puede medir con precisión el número de paquetes en vuelo. Proporciona una mejor estimación de la «tasa de entrega». Es útil para algoritmos como Westwood que dependen de la estimación de la «tasa de datos» de una conexión TCP.

Publicación traducida automáticamente

Artículo escrito por pintusaini y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *