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 de paquetes en orden, como en la capa de enlace de datos ( capa 2 OSI ), así como en el Protocolo de control de transmisión (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 verificación . El paradigma es similar a una ventana que se desliza hacia los lados 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", al remitente para indicar que puede enviar el siguiente paquete. En un protocolo simple de solicitud de repetición automática (ARQ), el remitente se detiene después de cada paquete y espera a que el receptor confirme. Esto garantiza que los paquetes lleguen en el orden correcto, ya que sólo 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 global puede ser mucho menor de lo teóricamente 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 qué paquetes han sido ACKed y, cuando se reciben, envía más paquetes. De esta forma, la ventana se desliza a lo largo del flujo de paquetes que componen la transferencia.
Las ventanas correderas 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 ventana como XMODEM . Véase también SEAlink .
Conceptualmente, 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 usa los números para colocar los paquetes recibidos en el orden correcto, descartando los paquetes duplicados e identificando los faltantes. . El problema con esto es que no hay límite en el tamaño del número de secuencia que puede ser requerido.
Al imponer límites a la cantidad de paquetes que se pueden transmitir o recibir en un momento dado, un protocolo de ventana deslizante permite comunicar 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 del número total de paquetes que aún deben ser reconocidos por el receptor. El receptor informa al transmisor en cada paquete de acuse de recibo del tamaño máximo actual del buffer del receptor (límite de ventana). El encabezado TCP utiliza un campo de 16 bits para informar el tamaño de la ventana del receptor al remitente. Por 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 el número 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 confirmación), seguido de tres paquetes y así sucesivamente hasta 10 paquetes. Pero después de alcanzar los 10 paquetes, las transmisiones adicionales se restringen a un paquete transmitido por cada paquete de confirmación recibido. En una simulación, esto parece como si la ventana se moviera una distancia de paquete por cada paquete de confirmación recibido. Del lado del receptor también la ventana 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 TCP en el lado del remitente y del receptor implementa ventanas deslizantes del 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 un tiempo de retardo de ida y vuelta (RTT). El límite de la cantidad de datos que puede enviar antes de detenerse a esperar un acuse de recibo debe ser mayor que el producto del ancho de banda-retraso del enlace de comunicaciones. De lo contrario, el protocolo limitará el ancho de banda efectivo del enlace.
En cualquier protocolo de comunicación basado en solicitud de repetición automática para control de errores , el receptor debe acusar recibo de los paquetes recibidos. Si el transmisor no recibe un acuse de recibo dentro de un tiempo razonable, reenvía los datos.
Un transmisor que no recibe un acuse de recibo no puede saber si el receptor realmente recibió el paquete; puede ser que se haya perdido o dañado en 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 configurarse para no enviar ningún acuse de recibo. De manera similar, el receptor generalmente no está seguro de si se están recibiendo sus acuses de recibo. Puede ser que se envió un acuse de recibo, pero se perdió o se corrompió en el medio de transmisión. En este caso, el receptor debe acusar recibo de la retransmisión para evitar que los datos se reenvíen continuamente, pero en caso contrario debe ignorarla.
El transmisor y el receptor tienen cada uno un número de secuencia actual n t y n r , respectivamente. Cada uno de ellos también tiene un tamaño de ventana w t y w r . Los tamaños de las ventanas pueden variar, pero en implementaciones más simples son fijos. El tamaño de la ventana debe ser mayor que cero para que se pueda realizar algún progreso.
Como se implementa normalmente, n t es el siguiente paquete a transmitir, es decir, el número de secuencia del primer paquete aún no transmitido. Asimismo, n r es el primer paquete aún no recibido. Ambos números aumentan monótonamente con el tiempo; sólo aumentan.
El receptor también puede realizar un seguimiento 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. Tenga en cuenta la distinción: se han recibido todos los paquetes por debajo de n r , no hay paquetes por encima. Se han recibido n s , y entre n r y n s , se han recibido algunos paquetes.
Cuando el receptor recibe un paquete, actualiza sus variables adecuadamente y transmite un acuse de recibo con el nuevo n r . El transmisor realiza un seguimiento del reconocimiento 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 la regla de que n a ≤ n r ≤ n s < n t ≤ n a + w t . Eso es:
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 pronto recibe 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 "demora 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 con el número x , el receptor verifica si cae en la ventana de recepción, n r ≤ x < n r + w r . (Los receptores más simples sólo tienen que realizar un seguimiento de un valor n r = n s ). Si cae dentro de la ventana, el receptor lo acepta. Si tiene el número n r , el número de secuencia de recepción aumenta en 1, y posiblemente más si anteriormente se recibieron y almacenaron más paquetes consecutivos. 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 o n s .
Ya sea que el paquete haya sido 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 sólo ayuda a la eficiencia).
Tenga en cuenta que no tiene sentido tener la ventana de recepción w r 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 estuvieran en constante aumento. Sin embargo, en lugar de transmitir el número de secuencia completo x en mensajes, es posible transmitir solo x mod N , para algún N finito . ( N suele ser una potencia de 2 ).
Por ejemplo, el transmisor solo recibirá confirmaciones en el rango n a a n t , inclusive. Dado que garantiza que n t − n a ≤ w t , hay como máximo w t +1 posibles números de secuencia que podrían llegar en cualquier 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 pueda distinguir de manera confiable 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 más serán retransmitidos.
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 . Entonces, 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 números de secuencia diferentes que el receptor puede recibir en cualquier momento. Por 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 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 tanto, sólo es necesario que N ≥ w t + w r . Como es común tener w r < w t (por ejemplo, ver Go-Back-N a continuación), esto puede permitir w t mayor dentro de un N fijo .
Aunque comúnmente se distingue del protocolo de ventana deslizante, el protocolo ARQ de detener y esperar es en realidad la implementación más simple posible del mismo. 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 (convenientemente representados por un solo bit ).
El transmisor envía alternativamente paquetes marcados como "impar" y "par". Los agradecimientos también dicen "impar" y "par". Supongamos que el transmisor, después de haber enviado un paquete impar, no esperó un acuse de recibo impar y, en cambio, envió inmediatamente el siguiente paquete par. Es posible que luego reciba un acuse de recibo que diga "esperando un paquete extraño a continuación". 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 excepto el siguiente en secuencia. Si un paquete se pierde en tránsito, los siguientes paquetes se ignoran hasta que se retransmite el paquete faltante, una pérdida mínima de un tiempo de ida y vuelta . Por este motivo, resulta ineficiente en enlaces que sufren frecuentes pérdidas de paquetes.
Supongamos que estamos utilizando un número de secuencia de 3 bits, como el típico de 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. Son 8 posibilidades y el transmisor necesita suficiente información en el reconocimiento para distinguirlas todas.
Si el transmisor envió 8 paquetes sin esperar confirmación, podría encontrarse en un dilema similar al caso de detener y esperar: ¿la confirmación significa que los 8 paquetes se recibieron exitosamente o ninguno de ellos?
El caso más general del protocolo de ventana deslizante es 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 r actual y almacenarlos hasta que se llene el espacio.
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 que se requiere una retransmisión. Por lo tanto, esto se prefiere para enlaces con baja confiabilidad y/o un producto con alto retardo de ancho de banda.
El tamaño de la ventana w r sólo necesita ser mayor que el número de paquetes perdidos consecutivos que se pueden tolerar. Por tanto, los valores pequeños son populares; w r =2 es común.
El extremadamente popular protocolo HDLC 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 nt + n r ≤ 8; si w r aumenta a 2, w t debe disminuir a 6.
Supongamos que w r =2, pero se usa un transmisor no modificado con w t =7, como se usa típicamente con la variante de retorno N de HDLC. 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 en módulo 8):
Debido a que 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 ha retransmitido el paquete 0. En este último caso, el receptor aceptaría el paquete incorrecto como paquete 8.
La solución es que el transmisor limite w t ≤6. Con esta restricción, el receptor sabe que si se perdieron todos los acuses de recibo, 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 acuse de recibo para el paquete 0 ( n a ≥1 del transmisor). , y por lo tanto el siguiente paquete numerado 0 debe ser el paquete 8.
Hay muchas formas de ampliar el protocolo: