Protocolo de ventana deslizante

Un protocolo de ventana deslizante es una característica de los protocolos de transmisión de datos basados en paquetes. Se utilizan cuando se requiere una entrega fiable y ordenada de paquetes, como en la capa de enlace de datos (capa 2 de OSI) y en el Protocolo de Control de Transmisión (es decir, el sistema de ventanas TCP). También se utilizan para mejorar la eficiencia cuando el canal puede presentar 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 garantizar su correcta recepción, como una suma de comprobación. El paradigma es similar a una ventana que se desliza lateralmente para permitir la entrada de nuevos paquetes y rechazar los que ya han sido reconocidos. Cuando el receptor verifica los datos, envía una señal de reconocimiento (ACK) al emisor para indicar que puede enviar el siguiente paquete. En un protocolo simple de solicitud de repetición automática (ARQ), el emisor se detiene después de cada paquete y espera a que el receptor lo reconozca. 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 ser considerable en comparación con el tiempo necesario para enviar el paquete. En este caso, el rendimiento total puede ser mucho menor de lo teóricamente posible. Para solucionar esto, los protocolos de ventana deslizante permiten enviar un número seleccionado 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 registra los paquetes que han recibido ACK y, al recibirlos, 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 un componente clave de muchos protocolos. Son un componente clave del protocolo TCP, que permite inherentemente que los paquetes lleguen desordenados, y también se encuentran en muchos protocolos de transferencia de archivos como UUCP-g y ZMODEM para mejorar la eficiencia en comparación con protocolos sin ventanas como XMODEM. Véase también SEAlink.Conceptualmente, a cada porción 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 estos números para ordenar los paquetes recibidos correctamente, descartando los duplicados e identificando los que faltan. El problema es que no hay límite en el tamaño del número de secuencia requerido.Al limitar la cantidad de paquetes que se pueden transmitir o recibir en un momento dado, un protocolo de ventana deslizante permite la comunicación de un número ilimitado de paquetes mediante números de secuencia de tamaño fijo. El término «ventana» en el transmisor representa el límite lógico del número total de paquetes que el receptor aún debe reconocer. 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). La cabecera TCP utiliza un campo de 16 bits para informar al emisor del tamaño de la ventana del receptor. Por lo tanto, la ventana más grande que se puede utilizar es 2¹⁶ = 64 kilobytes.

En el modo de inicio lento, el transmisor comienza con un número bajo de paquetes y aumenta el número de paquetes en cada transmisión tras recibir los paquetes de acuse de recibo del receptor. Por cada paquete de acuse de recibo recibido, la ventana se desliza un paquete (lógicamente) para transmitir un nuevo paquete. Cuando se alcanza el umbral de la ventana, el transmisor envía un paquete por cada paquete de acuse de recibo recibido.Si el límite de la ventana es de 10 paquetes, en el modo de inicio lento, el transmisor puede comenzar a transmitir un paquete seguido de dos (antes de transmitir dos paquetes, se debe recibir un acuse de recibo), seguido de tres paquetes, y así sucesivamente hasta 10 paquetes. Sin embargo, 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 moviera 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 evita 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 la congestión del tráfico de red, ya que TCP, tanto en el lado del emisor como del receptor, implementa ventanas deslizantes para el búfer de paquetes. El tamaño de la ventana puede variar dinámicamente según el tráfico de red.Para obtener el máximo rendimiento posible, es importante que el transmisor no se vea obligado a detener el envío por el protocolo de ventana deslizante antes de un tiempo de retardo de ida y vuelta (RTT). El límite en la cantidad de datos que puede enviar antes de detenerse a esperar una confirmación debe ser mayor que el producto del ancho de banda por el retardo 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 la solicitud de repetición automática 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 plazo razonable, reenvía los datos.Un transmisor que no recibe un acuse de recibo no puede saber si el receptor realmente recibió el paquete; podría haberse 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 igual manera, el receptor suele tener dudas sobre si se están recibiendo sus acuses de recibo. Es posible 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 confirmar la retransmisión para evitar que los datos se reenvíen continuamente, pero de lo contrario debe ignorarla.El transmisor y el receptor tienen un número de secuencia actual n_t y n_r, respectivamente. También tienen un tamaño de ventana w_t y w_r. Los tamaños de ventana pueden variar, pero en implementaciones más sencillas son fijos. El tamaño de ventana debe ser mayor que cero para que se pueda avanzar.

Como se implementa típicamente, 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; solo aumentan continuamente.

El receptor también puede registrar el número de secuencia más alto recibido hasta la fecha; 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 igual a 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 según corresponda y transmite un acuse de recibo con el nuevo n_r. El transmisor registra el acuse de recibo más alto recibido n_a. El transmisor sabe que se han recibido todos los paquetes hasta n_a, 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 n_a ≤ n_r ≤ n_s < n_t ≤ n_a + w_t. Es decir:

• n_a ≤ n_r: El mayor reconocimiento recibido por el transmisor no puede ser superior al más alto n_r reconocido por el receptor.
• n_r ≤ n_s: El lapso de paquetes totalmente recibidos no puede extenderse más allá del final de los paquetes parcialmente recibidos.
• n_s c) n_t: El paquete más alto recibido no puede ser más alto que el paquete más alto aún por enviar.
• n_t ≤ n_a + w_t: El paquete más alto enviado está limitado por el mayor reconocimiento recibido y el tamaño de la ventana de transmisión.

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 una confirmación de todos los paquetes enviados, 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 el retraso razonable pueden ser extremadamente elaboradas, pero solo 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 comprueba si se encuentra dentro de la ventana de recepción: n_r ≤ x n_r+w_r. (Los receptores más sencillos solo tienen que registrar un valor: n_r=n_s). Si se encuentra dentro de la ventana, el receptor lo acepta. Si se encuentra dentro de la ventana, el número de secuencia de recepción se incrementa en 1, y posiblemente más si se recibieron y almacenaron paquetes consecutivos previamente. Si x > n_r, el paquete se almacena hasta que se hayan recibido todos los paquetes anteriores. 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 se aceptó o no, el receptor transmite un acuse de recibo con 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 esto 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, ya que no hay que 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 ilimitados y en constante crecimiento. 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á acuses de recibo en el rango de 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 cualquier momento. Por lo tanto, el transmisor puede decodificar inequívocamente el número de secuencia siempre que N > w_t.

El receptor impone una restricción más estricta. El funcionamiento del protocolo depende de que el receptor pueda distinguir con fiabilidad 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 lograr conociendo el tamaño de la ventana del transmisor. Tras 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 2w_t números de secuencia diferentes que el receptor puede recibir en cualquier momento. Por lo tanto, podría parecer que debemos tener N ≥ 2w_t. Sin embargo, el límite real es menor.La idea adicional es que el receptor no necesita distinguir entre números de secuencia demasiado bajos (menores que n_r) o demasiado altos (mayores o iguales a 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. Dado que es común tener w_rw_t (p. ej., véase Go-Back-N más adelante), esto puede permitir un w_t mayor dentro de un N fijo.Aunque comúnmente se distingue del protocolo de ventana deslizante, el protocolo ARQ de parada y espera es en realidad su implementación más simple. 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 impar y par. Los acuses de recibo también indican impar y par. Supongamos que el transmisor, tras enviar un paquete impar, no esperó un acuse de recibo impar y, en su lugar, envió inmediatamente el siguiente paquete par. Podría entonces recibir un acuse de recibo que indique "Se espera un paquete impar a continuación". Esto plantearía una duda para el transmisor: ¿ha recibido el receptor ambos paquetes o ninguno?Go-Back-N ARQ es el protocolo de ventana deslizante con w_t>1, pero un valor fijo de w_r=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 esta razón, es ineficiente en enlaces con pérdida frecuente de paquetes.Supongamos que usamos un número de secuencia de 3 bits, como el típico para HDLC. Esto da como resultado N=2³=8. Dado que w_r=1, debemos limitar w_t≤7. Esto se debe a que, tras transmitir 7 paquetes, hay 8 resultados posibles: se podrían haber recibido correctamente entre 0 y 7 paquetes. Esto supone 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 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 correctamente o que no se recibió ninguno?El caso más general del protocolo de ventana deslizante es el ARQ de Repetición Selectiva. Este requiere un receptor mucho más potente, capaz de aceptar paquetes con números de secuencia superiores al n_r actual y almacenarlos hasta que se complete el espacio.

La ventaja, sin embargo, es que no es necesario descartar los siguientes datos correctos durante un solo viaje de ida y vuelta antes de que se informe al transmisor de que se requiere una retransmisión. Por lo tanto, esto es preferible para enlaces con baja fiabilidad o un producto con un retardo de ancho de banda elevado.El tamaño de la ventana w_r solo debe ser mayor que el número de paquetes perdidos consecutivos que se pueden tolerar. Por lo tanto, los valores pequeños son comunes; w_r=2 es común.

El protocolo HDLC, muy popular, utiliza un número de secuencia de 3 bits y ofrece la opción de repetición selectiva. Sin embargo, si se utiliza la repetición selectiva, debe mantenerse el requisito de que w_t+w_r ≤ 8; si w_r aumenta a 2, w_t debe reducirse a 6.

Supongamos que w_r =2, pero se utiliza un transmisor sin modificar con w_t =7, como se suele usar con la variante de retorno N de HDLC. Supongamos además que el receptor comienza con n_r =n_s =0.

Supongamos ahora que el receptor ve la siguiente serie de paquetes (todos módulo 8):

1 2 3 4 5 6 (pausa) 0

Dado que w_r =2, el receptor aceptará y almacenará el último paquete 0 (considerando que es el paquete 8 de la serie), mientras solicita la 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 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 perdieran todos los acuses de recibo, el transmisor se habría detenido después del paquete 5. Al recibir el paquete 6, el receptor puede inferir que el transmisor recibió el acuse de recibo del paquete 0 (el n_a ≥1 del transmisor), y, por lo tanto, el siguiente paquete numerado 0 debe ser el paquete 8.Hay muchas maneras de ampliar el protocolo:

• Los ejemplos anteriores suponen que los paquetes nunca se reordenan en la transmisión; pueden perderse en tránsito (la detección del terrorismo hace que la corrupción sea equivalente a la pérdida), pero nunca aparecerá fuera de orden. El protocolo se puede ampliar para apoyar la reordenación de paquetes, siempre y cuando la distancia pueda ser atada; el módulo número de secuencia N debe ser expandido por la distancia máxima de malordenamiento.
• Es posible no reconocer cada paquete, siempre y cuando se envíe un reconocimiento eventualmente si hay una pausa. Por ejemplo, TCP normalmente reconoce cada segundo paquete.
  • Es común informar al transmisor inmediatamente si se detecta una brecha en la secuencia del paquete. HDLC tiene un paquete especial REJ (rechazar) para esto.
• El tamaño de la ventana de transmisión y recepción puede cambiarse durante la comunicación, siempre y cuando su suma permanezca dentro del límite N. Normalmente, se les asignan valores máximos que respetan ese límite, pero el valor de trabajo en cualquier momento dado puede ser inferior al máximo. En particular:
  • Es común reducir el tamaño de la ventana de transmisión para frenar la transmisión para que coincida con la velocidad del enlace, evitando la saturación o congestión.
  • Una simplificación común de la réplica selectiva es la llamada ARQ SREJ-REJ. Esto funciona con w_r=2 y paquetes de amortiguadores siguiendo una brecha, pero sólo permite un paquete perdido; mientras espera ese paquete, w_r=1 y si se pierde un segundo paquete, no más paquetes se amortiguan. Esto proporciona la mayor parte del beneficio de rendimiento del protocolo completo de réplica selectiva con una implementación más simple.

• Federal Standard 1037C
• Compound TCP
• Número de serie aritmética
• TCP Apertura rápida

• Comer, Douglas E. "Internetworking with TCP/IP, Volumen 1: Principios, Protocolos y Arquitectura", Prentice Hall, 1995. ISBN 0-13-216987-8

• RFC 1323 - TCP Extensions for High Performance
• Escalada de ventanas TCP y routers rotos, 2004