NACK vs. ACK? ¿Cuándo usar uno sobre el otro?

Personalmente, ni siquiera siento que sea necesario ACK. Es más rápido si solo enviamos NACK (n) para los paquetes perdidos en lugar de enviar un ACK por cada paquete recibido. Entonces, ¿cuándo / qué situaciones se usaría ACK sobre NACK y viceversa?

La razón del ACK es que un NACK simplemente no es suficiente. Digamos que le envío un flujo de datos de segmentos X (digamos 10 por simplicidad).

Está en una mala conexión y solo recibe los segmentos 1, 2, 4 y 5. Su computadora envía el NACK para el segmento 3, pero no se da cuenta de que debe haber segmentos 6-10 y no los NACK.

Entonces, reenvío el segmento 3, pero mi computadora cree falsamente que los datos se enviaron con éxito.

Los ACK brindan cierta seguridad de que el segmento ha llegado al destino.

Si desea que la aplicación maneje el orden de los datos y las retransmisiones, simplemente puede optar por utilizar un protocolo como UDP (por ejemplo, como lo hace TFTP).

Todo se reduce a la distribución de probabilidad de pérdida y el patrón de tráfico.

Tomemos, por ejemplo, un enlace inalámbrico típico, con una tasa de pérdida constante del 10-30%. Si reconoce cada cuadro recibido (como 802.11abg), detectará rápidamente cuándo se ha perdido un cuadro, por lo que no perderá tiempo para esperar un tiempo de espera.

Si fuera a NAK, dependerá del patrón de tráfico: - Si envía un paquete de solicitud único y espera una respuesta, y esa solicitud se pierde, deberá tener un tiempo de espera que caduque si no recibe un responder. - Si solo está enviando una secuencia de paquetes a un destinatario en su mayoría silenciado, entonces es aceptable recibir un NAK solo cuando el destinatario reciba el siguiente paquete más o menos. Pero esto significa que el destinatario tiene que reordenar los paquetes y que el remitente debe realizar un seguimiento de una gran cantidad de mensajes atrasados ​​que ha enviado.

(¿adivina qué solución elegir 802.11n? ambas. El receptor envía un mapa de bits de trama de longitud variable que ha recibido)

Ahora tome una red de Internet típica: tiene una pérdida de paquetes cercana al 0%, hasta que algo malo suceda, y tiene una pérdida de paquetes cercana al 100% durante un cierto tiempo siguiendo alguna ley de distribución exponencial, desde una interrupción de 200 ms hasta un minuto y un medio.

Hacer clic en cada paquete parecería inútil en una red sin pérdidas, hasta que considere el caso cuando se corta el enlace: no recibirá ACK o NACK por un período de tiempo posiblemente extendido, y el receptor generalmente no enviará nada hasta que el enlace Esta restaurado.

Si usa ACK, el remitente dejará de enviar y mantendrá su cartera de pedidos hasta que se restablezca el enlace. Si usa NACK en su lugar, entonces el receptor puede decirle que no ha recibido el paquete que se cayó de la cartera de pedidos del remitente desde hace mucho tiempo, y la conexión es esencialmente irrecuperable.

Los ACK son útiles en los protocolos de ventanas deslizantes, permiten que el Transmisor A sepa que los datos enviados han sido recibidos por el control remoto B. El Transmisor A puede proceder a enviar los siguientes datos, hasta que su ventana de transmisión esté llena (de datos enviados al control remoto pero aún no admitido).

Los ACK pueden considerarse más esenciales que los NAK. Los NAK simplemente permiten una recuperación más rápida , en el caso de que un paquete / bloque enviado por A no sea recibido por B, y B detecta de alguna manera que falta un paquete / bloque.

Es perfectamente factible diseñar un protocolo que soporte transferencia confiable y control de flujo solo con ACK, sin NAK (con retransmisión por Transmisor en caso de que el Transmisor no reciba un ACK, mecanismo de retransmisión que se necesita en cualquier caso).

Una cosa muy importante que me gustaría agregar aquí, en TCP, NO enviamos ACK por CADA PAQUETE RECIBIDO.

Sin embargo, los ACK se envían solo para el ÚLTIMO PAQUETE RECIBIDO.

Por favor, corríjame si estoy equivocado.