Un protocolo de ventana deslizante es una característica de los protocolos de transmisión de datos basados en paquetes . Los protocolos de ventana deslizante se utilizan cuando se requiere una entrega confiable y ordenada de paquetes, como en la capa de enlace de datos ( capa 2 de OSI ) así como en el Protocolo de control de transmisión (es decir, ventanas TCP ). También se utilizan para mejorar la eficiencia cuando el canal puede incluir alta latencia .
Los sistemas basados en paquetes se basan en la idea de enviar un lote de datos, el paquete , junto con datos adicionales que permiten al receptor asegurarse de que se recibió correctamente, tal vez una suma de comprobación . El paradigma es similar a una ventana que se desliza lateralmente para permitir la entrada de paquetes nuevos y rechazar los que ya han sido reconocidos. Cuando el receptor verifica los datos, envía una señal de reconocimiento , o "ACK", de vuelta al remitente para indicar que puede enviar el siguiente paquete. En un protocolo de solicitud de repetición automática (ARQ) simple, el remitente se detiene después de cada paquete y espera a que el receptor realice el ACK. Esto garantiza que los paquetes lleguen en el orden correcto, ya que solo se puede enviar uno a la vez.
El tiempo que tarda en recibirse la señal ACK puede representar una cantidad significativa de tiempo en comparación con el tiempo necesario para enviar el paquete. En este caso, el rendimiento general puede ser mucho menor de lo que teóricamente es posible. Para solucionar esto, los protocolos de ventana deslizante permiten enviar una cantidad seleccionada de paquetes, la ventana , sin tener que esperar un ACK. Cada paquete recibe un número de secuencia y los ACK devuelven ese número. El protocolo realiza un seguimiento de los paquetes que han recibido un ACK y, cuando se reciben, envía más paquetes. De esta manera, la ventana se desliza a lo largo del flujo de paquetes que componen la transferencia.
Las ventanas deslizantes son una parte clave de muchos protocolos. Es una parte clave del protocolo TCP, que inherentemente permite que los paquetes lleguen desordenados, y también se encuentra en muchos protocolos de transferencia de archivos como UUCP-g y ZMODEM como una forma de mejorar la eficiencia en comparación con protocolos sin ventanas como XMODEM . Consulte también SEAlink .
En teoría, a cada parte de la transmisión (paquetes en la mayoría de las capas de enlace de datos, pero bytes en TCP) se le asigna un número de secuencia consecutivo único, y el receptor utiliza los números para colocar los paquetes recibidos en el orden correcto, descartando los paquetes duplicados e identificando los que faltan. El problema con esto es que no hay límite en el tamaño del número de secuencia que se puede requerir.
Al establecer límites en la cantidad de paquetes que se pueden transmitir o recibir en un momento dado, un protocolo de ventana deslizante permite que se comunique una cantidad ilimitada de paquetes utilizando números de secuencia de tamaño fijo. El término "ventana" en el lado del transmisor representa el límite lógico de la cantidad total de paquetes que aún deben ser reconocidos por el receptor. El receptor informa al transmisor en cada paquete de reconocimiento el tamaño máximo actual del búfer del receptor (límite de la ventana). El encabezado TCP utiliza un campo de 16 bits para informar al remitente del tamaño de la ventana del receptor. Por lo tanto, la ventana más grande que se puede utilizar es 2 16 = 64 kilobytes.
En el modo de inicio lento, el transmisor comienza con un recuento bajo de paquetes y aumenta la cantidad de paquetes en cada transmisión después de recibir paquetes de confirmación del receptor. Por cada paquete de confirmación recibido, la ventana se desliza un paquete (lógicamente) para transmitir un paquete nuevo. Cuando se alcanza el umbral de la ventana, el transmisor envía un paquete por cada paquete de confirmación recibido.
Si el límite de la ventana es de 10 paquetes, entonces, en el modo de inicio lento, el transmisor puede comenzar a transmitir un paquete seguido de dos paquetes (antes de transmitir dos paquetes, se debe recibir un paquete de acuse de recibo), seguido de tres paquetes y así sucesivamente hasta 10 paquetes. Pero después de alcanzar los 10 paquetes, las transmisiones posteriores se limitan a un paquete transmitido por cada paquete de acuse de recibo recibido. En una simulación, esto parece como si la ventana se estuviera moviendo una distancia de un paquete por cada paquete de acuse de recibo recibido. En el lado del receptor, la ventana también se mueve un paquete por cada paquete recibido.
El método de ventana deslizante garantiza que se evite la congestión del tráfico en la red. La capa de aplicación seguirá ofreciendo datos para su transmisión a TCP sin preocuparse por los problemas de congestión del tráfico de la red, ya que el TCP del lado del remitente y del receptor implementa ventanas deslizantes de búfer de paquetes. El tamaño de la ventana puede variar dinámicamente según el tráfico de la red.
Para obtener el mayor rendimiento posible , es importante que el protocolo de ventana deslizante no obligue al transmisor a detener el envío antes de que transcurra un tiempo de retardo de ida y vuelta (RTT). El límite de la cantidad de datos que puede enviar antes de detenerse para esperar un acuse de recibo debe ser mayor que el producto del ancho de banda por el retardo del enlace de comunicaciones. Si no lo es, el protocolo limitará el ancho de banda efectivo del enlace.
En cualquier protocolo de comunicación basado en la repetición automática de solicitudes para el control de errores , el receptor debe confirmar la recepción de los paquetes. Si el transmisor no recibe una confirmación en un tiempo razonable, vuelve a enviar los datos.
Un transmisor que no recibe un acuse de recibo no puede saber si el receptor recibió realmente el paquete; puede ser que se haya perdido o dañado durante la transmisión. Si el mecanismo de detección de errores revela corrupción, el receptor ignorará el paquete y enviará un acuse de recibo negativo o duplicado. El receptor también puede estar configurado para no enviar ningún acuse de recibo. De manera similar, el receptor normalmente no está seguro de si se están recibiendo sus acuses de recibo. Puede ser que se haya enviado un acuse de recibo, pero se haya perdido o dañado en el medio de transmisión. En este caso, el receptor debe reconocer la retransmisión para evitar que los datos se reenvíen continuamente, pero en caso contrario debe ignorarlo.
El transmisor y el receptor tienen cada uno un número de secuencia actual n t y n r , respectivamente. Cada uno también tiene un tamaño de ventana w t y w r . Los tamaños de ventana pueden variar, pero en implementaciones más simples son fijos. El tamaño de ventana debe ser mayor que cero para que se pueda realizar cualquier progreso.
Tal como se implementa normalmente, n t es el siguiente paquete que se transmitirá, es decir, el número de secuencia del primer paquete que aún no se ha transmitido. Asimismo, n r es el primer paquete que aún no se ha recibido. Ambos números aumentan de forma monótona con el tiempo; solo aumentan.
El receptor también puede llevar un registro del número de secuencia más alto recibido hasta ahora; la variable n s es uno más que el número de secuencia del número de secuencia más alto recibido. Para receptores simples que solo aceptan paquetes en orden ( w r = 1), esto es lo mismo que n r , pero puede ser mayor si w r > 1. Nótese la distinción: se han recibido todos los paquetes por debajo de n r , no se ha recibido ningún paquete por encima de n s , y entre n r y n s , se han recibido algunos paquetes.
Cuando el receptor recibe un paquete, actualiza sus variables de forma adecuada y transmite un acuse de recibo con el nuevo n r . El transmisor lleva un registro del acuse de recibo más alto que ha recibido n a . El transmisor sabe que se han recibido todos los paquetes hasta n a , pero sin incluirlo , pero no está seguro de los paquetes entre n a y n s ; es decir, n a ≤ n r ≤ n s .
Los números de secuencia siempre obedecen a la regla de que n a ≤ n r ≤ n s < n t ≤ n a + w t . Es decir:
Siempre que el transmisor tenga datos para enviar, puede transmitir hasta w t paquetes antes del último acuse de recibo n a . Es decir, puede transmitir el paquete número n t siempre que n t < n a + w t .
En ausencia de un error de comunicación, el transmisor recibe pronto un acuse de recibo de todos los paquetes que ha enviado, dejando n a igual a n t . Si esto no sucede después de un retraso razonable, el transmisor debe retransmitir los paquetes entre n a y n t .
Las técnicas para definir un "retraso razonable" pueden ser extremadamente elaboradas, pero sólo afectan la eficiencia; la confiabilidad básica del protocolo de ventana deslizante no depende de los detalles.
Cada vez que se recibe un paquete numerado x , el receptor comprueba si cae en la ventana de recepción, n r ≤ x < n r + w r . (Los receptores más simples solo tienen que realizar un seguimiento de un valor n r = n s .) Si cae dentro de la ventana, el receptor lo acepta. Si está numerado n r , el número de secuencia de recepción se incrementa en 1, y posiblemente más si se recibieron y almacenaron previamente paquetes consecutivos adicionales. Si x > n r , el paquete se almacena hasta que se hayan recibido todos los paquetes anteriores. [1] Si x ≥ n s , este último se actualiza a n s = x +1.
Si el número del paquete no está dentro de la ventana de recepción, el receptor lo descarta y no modifica n r ni n s .
Independientemente de si el paquete fue aceptado o no, el receptor transmite un acuse de recibo que contiene el n r actual . (El acuse de recibo también puede incluir información sobre paquetes adicionales recibidos entre n r y n s , pero eso solo mejora la eficiencia).
Tenga en cuenta que no tiene sentido que la ventana de recepción w r sea mayor que la ventana de transmisión w t , porque no hay necesidad de preocuparse por recibir un paquete que nunca se transmitirá; el rango útil es 1 ≤ w r ≤ w t .
Hasta ahora, el protocolo se ha descrito como si los números de secuencia fueran de tamaño ilimitado y en constante aumento. Sin embargo, en lugar de transmitir el número de secuencia completo x en los mensajes, es posible transmitir solo x mod N , para un valor finito de N ( N suele ser una potencia de 2 ).
Por ejemplo, el transmisor solo recibirá reconocimientos en el rango n a a n t , ambos inclusive. Dado que garantiza que n t − n a ≤ w t , existen como máximo w t +1 números de secuencia posibles que podrían llegar en un momento dado. Por lo tanto, el transmisor puede decodificar sin ambigüedades el número de secuencia siempre que N > w t .
El receptor impone una restricción más fuerte. El funcionamiento del protocolo depende de que el receptor sea capaz de distinguir de forma fiable los paquetes nuevos (que deben aceptarse y procesarse) de las retransmisiones de paquetes antiguos (que deben descartarse y retransmitirse el último acuse de recibo). Esto se puede hacer si se conoce el tamaño de la ventana del transmisor. Después de recibir un paquete numerado x , el receptor sabe que x < n a + w t , por lo que n a > x − w t . Por lo tanto, los paquetes numerados x − w t nunca volverán a retransmitirse.
El número de secuencia más bajo que recibiremos en el futuro es n s − w t
El receptor también sabe que el n a del transmisor no puede ser mayor que el acuse de recibo más alto jamás enviado, que es n r . Por lo tanto, el número de secuencia más alto que podríamos ver es n r + w t ≤ n s + w t .
Por lo tanto, hay 2 w t números de secuencia diferentes que el receptor puede recibir en cualquier momento. Por lo tanto, podría parecer que debemos tener N ≥ 2 w t . Sin embargo, el límite real es menor.
La idea adicional es que el receptor no necesita distinguir entre números de secuencia que son demasiado bajos (menores que n r ) o que son demasiado altos (mayores o iguales que n s + w r ). En cualquier caso, el receptor ignora el paquete excepto para retransmitir un acuse de recibo. Por lo tanto, solo es necesario que N ≥ w t + w r . Como es común que w r < w t (por ejemplo, consulte Go-Back-N a continuación), esto puede permitir un w t mayor dentro de un N fijo .
Aunque comúnmente se lo distingue del protocolo de ventana deslizante, el protocolo ARQ de parada y espera es en realidad la implementación más simple posible de este último. La ventana de transmisión es de 1 paquete y la ventana de recepción es de 1 paquete. Por lo tanto, se requieren N = 2 números de secuencia posibles (representados convenientemente por un solo bit ).
El transmisor envía alternativamente paquetes marcados como "par" y "impar". Los acuses de recibo también dicen "par" y "impar". Supongamos que el transmisor, después de enviar un paquete impar, no esperó un acuse de recibo impar y, en su lugar, envió inmediatamente el siguiente paquete par. Entonces podría recibir un acuse de recibo que dijera "se espera un próximo paquete impar". Esto dejaría al transmisor en un dilema: ¿ha recibido el receptor ambos paquetes o ninguno?
Go-Back-N ARQ es el protocolo de ventana deslizante con w t >1, pero un w r fijo = 1. El receptor se niega a aceptar cualquier paquete que no sea el siguiente en la secuencia. Si un paquete se pierde en tránsito, los paquetes siguientes se ignoran hasta que se retransmite el paquete faltante, una pérdida mínima de un tiempo de ida y vuelta . Por este motivo, es ineficiente en enlaces que sufren pérdidas frecuentes de paquetes.
Supongamos que estamos usando un número de secuencia de 3 bits, como es típico para HDLC . Esto da N = 2 3 = 8. Como w r = 1, debemos limitar w t ≤ 7. Esto se debe a que, después de transmitir 7 paquetes, hay 8 resultados posibles: se podrían haber recibido con éxito entre 0 y 7 paquetes. Esto son 8 posibilidades y el transmisor necesita suficiente información en el acuse de recibo para distinguirlas todas.
Si el transmisor envió 8 paquetes sin esperar el acuse de recibo, podría encontrarse en un dilema similar al caso de detener y esperar: ¿el acuse de recibo significa que los 8 paquetes se recibieron correctamente o que ninguno de ellos se recibió?
El caso más general del protocolo de ventana deslizante es el ARQ de repetición selectiva . Esto requiere un receptor mucho más capaz, que pueda aceptar paquetes con números de secuencia superiores al n actual y almacenarlos hasta que se complete el espacio vacío.
La ventaja, sin embargo, es que no es necesario descartar los siguientes datos correctos durante un tiempo de ida y vuelta antes de que se pueda informar al transmisor de que se requiere una retransmisión. Por lo tanto, esto es preferible para enlaces con baja confiabilidad y/o un producto de retardo de ancho de banda alto.
El tamaño de la ventana w r sólo debe ser mayor que la cantidad de paquetes perdidos consecutivos que se pueden tolerar. Por lo tanto, los valores pequeños son populares; w r = 2 es común.
El protocolo HDLC, muy popular , utiliza un número de secuencia de 3 bits y tiene una disposición opcional para la repetición selectiva. Sin embargo, si se va a utilizar la repetición selectiva, se debe mantener el requisito de que n t + n r ≤ 8; si w r se aumenta a 2, w t se debe reducir a 6.
Supongamos que w r = 2, pero se utiliza un transmisor no modificado con w t = 7, como se suele utilizar con la variante de HDLC con retorno N. Supongamos además que el receptor comienza con n r = n s = 0.
Ahora supongamos que el receptor ve la siguiente serie de paquetes (todos módulo 8):
Como w r = 2, el receptor aceptará y almacenará el paquete final 0 (pensando que es el paquete 8 de la serie), mientras solicita una retransmisión del paquete 7. Sin embargo, también es posible que el transmisor no haya recibido ningún acuse de recibo y haya retransmitido el paquete 0. En este último caso, el receptor aceptaría el paquete equivocado como paquete 8.
La solución es que el transmisor limite w t ≤6. Con esta restricción, el receptor sabe que si se perdieran todos los reconocimientos, el transmisor se habría detenido después del paquete 5. Cuando recibe el paquete 6, el receptor puede inferir que el transmisor recibió el reconocimiento para el paquete 0 ( n a del transmisor ≥1), y por lo tanto el siguiente paquete numerado 0 debe ser el paquete 8.
Hay muchas formas de ampliar el protocolo: