ES2249474T3 - Control de flujo. - Google Patents

Abstract

Nodo (25) de comunicaciones de datos destinado a funcionar en un camino (22) de comunicaciones entre un transmisor de datagramas (20) y un receptor de datagramas (21) bajo un protocolo en el que la transmisión de datagramas por parte del transmisor depende de la recepción, por parte de este último, de un mensaje de confirmación de recepción correspondiente a un datagrama transmitido previamente, comprendiendo el nodo: un aparato (29) de detección para detectar comunicaciones en el camino; un generador (36) de confirmaciones de recepción adaptado para generar mensajes de confirmación de recepción para datagramas y transmitir dichos mensajes hacia el transmisor; y un aparato de interrupción del flujo adaptado para interrumpir comunicaciones en el camino; caracterizado porque el nodo está adaptado para funcionar en el segundo y en por lo menos uno de entre el primero y el tercero de los siguientes modos: - un primer modo en el cual no interrumpe las comunicaciones en el camino; - un segundo modo en el cual transmite un mensaje de confirmación de recepción para un datagrama que sucede al último datagrama detectado en el nodo; y - un tercer modo en el cual retarda la comunicación de mensajes de confirmación de recepción hacia el transmisor.

Description

Control de flujo.

La presente invención se refiere al control del flujo de datos, especialmente en redes de las cuales se requiere que funcionen a una velocidad elevada.

Muchas redes usan el protocolo de control de transmisión (TCP) como su protocolo de capa de transporte. El protocolo de control de transmisión es el protocolo de transporte principal en el conjunto de protocolos TCP/IP usado habitualmente. El protocolo de Internet (IP) no proporciona un tren de bits fiable: los errores durante el transcurso de la transmisión no son corregidos por el IP. La superposición del TCP sobre un enlace IP implementa un tren de bytes fiable con respecto al servicio de datagramas no fiable proporcionado por el IP. Como parte de la implementación del servicio fiable, el TCP también es responsable del control del flujo y de la congestión: garantizando que los datos se transmiten a una velocidad en concordancia con las capacidades tanto del receptor como de los enlaces intermedios en el camino de la red. Como consecuencia, el origen de la mayoría de los problemas del caudal en un sistema TCP/IP se encuentra en el TCP.

El TCP es uno de los pocos protocolos de transporte que tiene mecanismos de control de la congestión (ver las publicaciones "TCP/IP Illustrated Volume 1, The protocols", de W. Richard Stevens, y "Transport Control Protocol", IETF RFC 793, Septiembre de 1981). Un elemento clave del mecanismo de congestión del TCP es su algoritmo sonda de arranque lento. Cuando una conexión TCP se pone en marcha, la especificación TCP requiere que la conexión sea prudente y que considere que el ancho de banda disponible para el receptor es pequeño. Se supone que el TCP usa un algoritmo denominado de arranque lento, para sondear el camino con vistas a saber cuánto ancho de banda hay disponible antes de aumentar la velocidad del flujo de datos. El arranque lento se usa de manera que cuando se pone en marcha una conexión TCP nueva, el flujo TCP continuará después de cierto periodo de reposo o cuando no se haya conseguido devolver una confirmación de recepción (ACK) después de un periodo fijado (lo cual indica un paquete perdido). Adicionalmente, se reduce el tamaño de la ventana de transmisión. Cada confirmación de recepción TCP especifica un paquete correspondiente de manera que el sistema puede identificar qué paquete se ha perdido.

Se establece un enlace TCP entre dos unidades, una de las cuales es la fuente de un mensaje de datos a transmitir y la otra debe recibir el mensaje de datos. Las dos unidades están conectadas por un camino de datos a través del cual deben desplazarse los datos. La unidad fuente genera datagramas (es decir, paquetes) que combinados representan el mensaje que debe ser enviado. Los datagramas se transmiten a través del camino de datos. Finalmente, la unidad receptora vuelve a ensamblar los datagramas, solicitando además dicha unidad receptora la retransmisión de cualquier datagrama que no pueda decodificar correctamente.

Mientras se está ejecutando el algoritmo de arranque lento, la fuente TCP comienza con una ventana de transmisión imaginaria fijada a un segmento. En este estado, la misma no transmitirá más de un datagrama (es decir, paquete) si no ha recibido ninguna confirmación de recepción de la unidad receptora. Cuando se recibe una confirmación de recepción (ACK), el tamaño de la ventana se reduce en uno. En la práctica, el tamaño de la ventana tiende a aumentar exponencialmente, ya que una ACK aumenta el tamaño a dos, las ACK de estos dos segmentos aumentan el tamaño a cuatro, sus ACK aumentan el tamaño a ocho, etcétera. Esta situación se ilustra en la figura 1. La línea 1 de la figura 1 ilustra el aumento exponencial del tamaño de la ventana WS hasta un máximo WS_{dispon} en el instante de tiempo t_{1}.

Existen dos problemas relacionados con el algoritmo de arranque lento en redes de alta velocidad. En primer lugar, el algoritmo sonda es tal que el enlace puede tardar un tiempo considerable en alcanzar su velocidad máxima. El tiempo (t_{1} en la figura 1) requerido para llegar a la velocidad máxima es una relación directa del tiempo de ida y vuelta (RTT), el producto de retardo-ancho de banda (DBW) y una relación inversa de la longitud media del segmento (L). Si el ancho de banda disponible sube o el tiempo de ida y vuelta aumenta, o se producen ambas situaciones, este tiempo de arranque puede resultar bastante largo. Si, por otro lado, el enlace está en reposo, durante ese periodo no se hará uso de gran parte del ancho de banda del enlace y por lo tanto, potencialmente, el mismo se desperdicia. Esta situación se ilustra en la figura 1. Puede considerarse que desde la puesta en marcha de la conexión TCP, existe un ancho de banda disponible que se corresponde con el tamaño de la ventana disponible WS_{dispon}. No obstante, ese ancho de banda no se usa totalmente hasta el instante de tiempo t_{1}. Por esta razón, el área sombreada 2 de la figura 1 representa el ancho de banda desperdiciado.

Un problema potencialmente más significativo es que en muchos casos (especialmente cuando se deben enviar mensajes relativamente cortos) se habrá completado la transferencia total de datos antes de que haya finalizado el algoritmo de arranque lento y de que se haya alcanzado el tamaño de ventana máximo WS_{dispon} limitado por el ancho de banda. En esta situación, el usuario nunca probará el ancho de banda completo del enlace. Todo el tiempo de transferencia se consumirá en el arranque lento. Existen algunas situaciones prácticas habituales en las que se puede producir dicho fenómeno. Por ejemplo, este problema resulta particularmente grave para conexiones (como las que se usan para transferir datos de la malla mundial multimedia) de protocolo de transferencia de hipertexto (HTTP) ya que el HTTP es conocido por poner en marcha una conexión TCP nueva por cada elemento de una página web.

Además del derroche de ancho de banda que viene provocado por el algoritmo de arranque lento, existe un punto débil en el propio algoritmo de arranque lento por cuanto el mismo interpreta una pérdida de paquete como una indicación de congestión. De hecho, la pérdida de paquetes puede ser debida a otras causas, tales como errores de transmisión. No existe ningún camino sencillo abierto en el TCP para distinguir las pérdidas debidas a errores de transmisión con respecto a las pérdidas debidas a la congestión, por lo que el algoritmo de arranque lento se ha diseñado considerando prudentemente que todas las pérdidas son debidas a la congestión. De este modo, incluso si se produce una pérdida de paquetes debida a un error de transmisión en lugar de la congestión, la fuente TCP reduce su velocidad de transmisión. Después de dicha reducción de la velocidad, se puede tardar un tiempo innecesariamente prolongado en alcanzar la velocidad de transmisión completa. Como consecuencia, nuevamente se sigue desperdiciando el ancho de banda disponible.

Estos problemas se acentúan cuando el TCP se ejecuta sobre enlaces que presentan tasas de errores relativamente altas o una capacidad de datos variable. Por ejemplo, en algunos casos los enlaces inalámbricos (tales como los correspondientes a los teléfonos celulares o los satélites) presentan unas tasas de errores mayores que en los enlaces terrestres convencionales por cable. Dichas tasas de errores más grandes son importantes por dos razones. En primer lugar, provocan errores en los datagramas, los cuales deberán volver a ser transmitidos. En segundo lugar, el TCP interpreta típicamente una pérdida como una señal de congestión y cuando se observa dicha pérdida el mismo vuelve a una versión modificada del algoritmo de arranque lento.

Sí que existen sistemas que pueden hacer uso del ancho de banda de reserva de un enlace que sobra en ese momento de otras conexiones que se están ejecutando a través del enlace. Un ejemplo es el servicio de velocidad binaria disponible (ABR) del sistema de modo de transferencia asíncrono (ATM). Con el servicio ABR, un usuario puede usar el ancho de banda que sobra de la velocidad binaria constante (CBR) y otro tráfico de prioridad superior. Otro ejemplo es el sistema genérico de radiocomunicaciones por paquetes (GRPS), el cual utiliza el ancho de banda de una red telefónica celular del sistema global para comunicaciones móviles (GSM) que no se ha usado para las conexiones de voz GSM. En el sistema GSM, existe una serie de intervalos de frecuencia GSM, estando dividido cada uno de ellos en ocho intervalos de tiempo. Cada combinación de intervalo de tiempo y frecuencia puede soportar una conexión de voz GSM. La idea básica del GPRS es usar intervalos de tiempo que no estén siendo usados en ese momento para las comunicaciones de voz con vistas a transportar paquetes de datos. Naturalmente, el número de intervalos de tiempo disponibles para el GPRS varía con el tiempo, dependiendo de la demanda de conexiones de voz GSM del momento en cuestión.

Uno de los problemas de los sistemas dinámicos de este tipo es que el ancho de banda asignado para el servicio varía con el tiempo. Por ejemplo, cuando se transmite tráfico TCP a través del GPRS, el ancho de banda disponible para las conexiones TCP puede aumentar o reducirse de forma repentina (cuando finalizan o comienzan simultáneamente varias llamadas GSM). Esto significa que una conexión TCP a través de un sistema dinámico de este tipo puede tener que detenerse y arrancar frecuentemente, y en ese entorno, el algoritmo de arranque lento del TCP evita que la conexión TCP haga un uso total del ancho de banda disponible. De este modo, se desperdician recursos de la red y un usuario no puede aprovecharse completamente del ancho de banda disponible dinámico. Este problema resulta especialmente importante con sistemas de comunicaciones inalámbricas, ya que la capacidad de la interfaz de radiocomunicaciones es limitada y cara.

Si el sistema TCP dispusiera de más información sobre las características del camino a través del cual se están enviando los datos, en ese caso podría ser capaz de acelerar el proceso de arranque lento, por ejemplo, eludiendo por lo menos parte del proceso de arranque lento y comenzando la transmisión a una velocidad algo superior a la que representa un datagrama, si se supiera que existe la probabilidad de que la misma sea soportada por el enlace. Para acelerar el proceso de arranque lento, se han propuesto varios esquemas.

Una de dichas técnicas se conoce como "Fisgoneo (snooping) TCP". (Ver publicación "Evaluation of TCP Vegas: Emulation and Experiment", de Z. Liu et al., Proc. ACM SIGCOMM'95, Agosto de 1995, págs. 185 a 196; e "Improving TCP/IP Performance over Wireless Networks", de H. Balakrishnan, et al., Proc. ACM SIGCOMM'95, Agosto de 1995). Esta idea se ilustra en la figura 2. La idea requiere la presencia de un encaminador u otro nodo 10 entre la fuente TCP 11 y el receptor TCP 12. El nodo 10 envía de vuelta hacia la fuente 11 confirmaciones ACK correspondientes a los datos TCP que ha enviado la fuente, con vistas a generar en la fuente 11 la ilusión de un camino de retardo corto. A continuación, el nodo 10 suprime las ACK que vuelven desde el receptor 12, y acepta la responsabilidad de volver a transmitir hacia el receptor 12 cualquier segmento perdido en el camino después del encaminador según el sentido de avance (es decir, sobre la parte del camino entre el nodo 10 y el receptor 12). De este modo, dicho nodo 10 de fisgoneo TCP proporciona a la fuente TCP 11 la impresión de que el nodo 10 es el receptor TCP real.

La figura 2 ilustra el flujo de paquetes (PKn) y las confirmaciones de recepción numeradas de forma correspondiente (ACKn). En la disposición mostrada en la figura 2, cuando un paquete PK64 alcanza el nodo 10 proveniente de la fuente 11, el nodo genera una confirmación de recepción ACK64 correspondiente para el paquete y devuelve la misma a la fuente. El nodo 10 almacena en la memoria 13 los paquetes que él mismo ha recibido pero cuya recepción no ha sido confirmada todavía por el receptor 12. A su vez, el nodo 10 envía paquetes al receptor (ver los paquetes PK59, PK60). El receptor devuelve confirmaciones de recepción para los paquetes que ha recibido correctamente (ACK58, ACK59). Cuando el nodo 10 recibe una confirmación de recepción de este tipo (por ejemplo, la ACK57 tal como se ilustra en la figura 2), el mismo suelta el paquete correspondiente de sus medios 13 de almacenamiento. De este modo, el nodo 10 de fisgoneo debe realizar una cantidad considerable de trabajo después de enviar una ACK a la fuente 11. El mismo debe almacenar en memoria intermedia el segmento de datos que acaba de recibir debido a que en ese momento la fuente 11 tiene la libertad de rechazar su copia ya que se ha confirmado la recepción del segmento, y por lo tanto si el segmento se pierde entre el encaminador y el receptor, el encaminador debe poder responsabilizarse completamente de volver a transmitir dicho segmento. Por esta razón, los datos de la memoria intermedia no se pueden eliminar hasta que el nodo de fisgoneo obtenga las ACK pertinentes del receptor TCP 12. Desafortunadamente, este método presenta el gran problema de que la memoria intermedia en un nodo de fisgoneo se puede llenar rápidamente si se reduce el ancho de banda disponible (tal como los recursos de una red celular) entre el nodo y el receptor TCP (enlace 14 en la figura 2). El problema se ha ilustrado en la figura 3, la cual ilustra un paquete PK69 que desborda la capacidad de la memoria intermedia 13 del nodo 10.

Debería indicarse que la necesidad de que el nodo 10 almacene segmentos, y por lo tanto el problema del desbordamiento de la memoria intermedia, tiene su origen en el hecho de que el nodo de fisgoneo genera una confirmación de recepción que se corresponde con el mismo segmento TCP que acaba de recibir.

Otro de los planteamientos para superar algunos de los problemas del algoritmo de arranque lento TCP se conoce como TCP dividido. En este planteamiento, una conexión TCP se divide en múltiples conexiones TCP, con una conexión TCP especial. Como cada conexión TCP está terminada, el TCP dividido no es vulnerable a los caminos asimétricos. Además, el mismo funciona bien en los casos en los que las aplicaciones participan activamente en la gestión de conexiones TCP (tal como el almacenamiento de páginas web en memoria caché). No obstante, por otro lado el TCP dividido presenta los mismos problemas que el fisgoneo TCP, especialmente la acumulación de las memorias intermedias.

La publicación "TCP ACK pacing in ATM networks" de N Ghani describe un dispositivo de control de la cadencia de confirmaciones de recepción en un camino de transmisión. El dispositivo modula la temporización entre paquetes ACK TCP para limitar las emisiones durante los periodos de congestión. El dispositivo de control de la cadencia intercepta un paquete ACK y lo retarda si el enlace hacia adelante está congestionado.

El documento WO 00/21231 da a conocer una entidad de red de almacenamiento intermedio ubicada en un camino de transmisión. La entidad de almacenamiento intermedio intercepta paquetes y transmite un mensaje de estado a la entidad transmisora. La entidad de almacenamiento intermedio transmite el paquete recibido a la entidad receptora. Al recibir una confirmación de recepción de la entidad receptora, confirmando que el paquete se recibió correctamente, la entidad de almacenamiento intermedio transmite otro mensaje de estado a la entidad transmisora indicando la transmisión satisfactoria del paquete.

Por lo tanto, existe la necesidad de un método mejorado de funcionamiento en protocolos tales como el TCP para superar por lo menos parcialmente uno o más de los problemas descritos anteriormente.

Según un aspecto de la presente invención se proporciona un nodo de comunicaciones de datos destinado a funcionar en un camino de comunicaciones entre un transmisor de datagramas y un receptor de datagramas bajo un protocolo en el que la transmisión de datagramas por parte del transmisor depende de la recepción, por parte de este último, de un mensaje de confirmación de recepción correspondiente a un datagrama transmitido previamente, comprendiendo el nodo: un aparato de detección para detectar las comunicaciones en el camino; un generador de confirmaciones de recepción capaz de generar mensajes de confirmaciones de recepción para datagramas y de transmitir dichos mensajes hacia el transmisor; y un aparato de interrupción del flujo capaz de interrumpir las comunicaciones en el camino; siendo capaz el nodo de funcionar en el segundo y en por lo menos uno de entre el primero y el tercero de los siguientes modos: un primer modo en el cual no interrumpe las comunicaciones en el camino; un segundo modo en el cual transmite un mensaje de confirmación de recepción para un datagrama que suceda al último datagrama detectado en el nodo; y un tercer modo en el cual retarda la comunicación de mensajes de confirmación de recepción hacia el transmisor.

Adecuadamente, en el primer modo, el nodo preferentemente no influye en las comunicaciones en el camino, de manera que los datagramas provenientes del transmisor pueden fluir libremente pasando por el nodo hacia el receptor y los mensajes de confirmación de recepción provenientes del receptor pueden fluir libremente hacia el transmisor.

En el segundo y/o tercer modo, el nodo preferentemente interrumpe la comunicación de los mensajes de confirmación de recepción provenientes del receptor hacia el transmisor. En el segundo y/o tercer modo, el nodo preferentemente interrumpe la comunicación de datagramas provenientes del transmisor hacia el receptor.

El nodo puede comprender una memoria capaz de almacenar datagramas y/o mensajes de confirmación de recepción. En el segundo y/o tercer modo, el nodo preferentemente almacena en la memoria datagramas detectados en la transmisión desde el transmisor al receptor. A continuación, en el segundo y/o tercer modo, si en un periodo fijado el nodo no detecta ningún mensaje de confirmación de recepción para un datagrama desde del receptor, el mismo puede volver a transmitir dicho datagrama hacia el receptor. Al recibir un mensaje de confirmación de recepción correspondiente a un datagrama, el nodo puede eliminar el datagrama de la memoria.

Preferentemente, el nodo comprende una unidad de determinación de modo para determinar el modo de funcionamiento del nodo. La unidad de determinación de modo es preferentemente capaz de determinar si hay capacidad disponible en el camino de comunicación, por ejemplo, ancho de banda sin usar en el camino de comunicación (preferentemente en ambas direcciones a través del camino), y/o capacidad disponible en dicha memoria del nodo (en caso de que la misma esté presente). Si existe dicha capacidad disponible, preferentemente la unidad de determinación de modo es capaz de provocar que el nodo funcione en el segundo modo. Preferentemente, la unidad de determinación de modo es capaz de determinar si existe congestión en el camino de comunicaciones. La congestión en el camino de comunicaciones puede venir indicada por retardos en la comunicación a través del camino (bien de datagramas o bien de confirmaciones de recepción), pérdidas excesivas de datos, demandas excesivas en el camino, etcétera. La congestión puede aparecer debido bien a un aumento de la cantidad de datos dirigidos a través del camino o bien a una reducción en la capacidad de datos (ancho de banda) del camino, o por ambos motivos simultáneamente. Cuando la unidad determina que existe congestión, preferentemente la misma es capaz de provocar que el nodo funcione en el tercer modo. En cualquier otro caso (es decir, si no existe capacidad disponible o congestión en el camino de comunicaciones), la unidad de determinación es capaz adecuadamente de provocar que el nodo entre en el primer modo.

Preferentemente, el nodo es capaz de funcionar en cualquiera de entre el primer, el segundo y el tercer modos.

De acuerdo con un segundo aspecto de la presente invención, se proporciona un método para la comunicación de datos a través de un camino de comunicaciones entre un transmisor de datagramas y un receptor de datagramas bajo un protocolo en el que la transmisión de datagramas por parte del transmisor depende de la recepción, por parte de este último, de un mensaje de confirmación de recepción correspondiente a un datagrama transmitido previamente, existiendo un nodo ubicado en el camino de comunicaciones entre el transmisor y el receptor; comprendiendo el método: la transmisión de datagramas hacia el receptor por parte del transmisor; la detección de dichos datagramas por parte del nodo; y la transmisión repetida, por parte del nodo, hacia el transmisor, de un mensaje de confirmación de recepción correspondiente a un datagrama que sucede al último datagrama detectado en el nodo.

En ambos aspectos de la invención, el protocolo es preferentemente un protocolo de control de transmisión (TCP). Preferentemente, el protocolo proporciona un tipo de funcionamiento en el cual el transmisor no transmitirá un datagrama hasta que haya recibido un mensaje de confirmación de recepción correspondiente a un datagrama transmitido previamente desde hace un intervalo almacenado, y con la mayor preferencia en el cual el intervalo almacenado se incrementa si se recibe un mensaje de confirmación de recepción. Este tipo de funcionamiento puede ser de arranque lento.

El intervalo almacenado se expresa preferentemente como un número de unidades de datos, por ejemplo, un número de datagramas o un número de bits. Preferentemente, el intervalo se expresa como un número de datagramas. En ese caso, el protocolo proporciona preferentemente un tipo de funcionamiento en el cual no se transmitirá un datagrama hasta que se haya recibido una confirmación de recepción correspondiente al datagrama que se transmitió n datagramas previamente, en el cual n es el número de datagramas expresado por el intervalo almacenado.

En ambos aspectos de la invención, por lo menos parte del camino de comunicaciones lo proporciona preferentemente un enlace de radiocomunicaciones, con la mayor preferencia un enlace celular de radiocomunicaciones.

A continuación se describirá la presente invención a título de ejemplo, haciendo referencia a los dibujos adjuntos, en los cuales:

la figura 1 ilustra el algoritmo de arranque lento TCP;

las figuras 2 y 3 ilustran aspectos del procedimiento de fisgoneo TCP;

la figura 4 muestra esquemáticamente la arquitectura de un sistema de comunicaciones;

la figura 5 ilustra regímenes preferidos del modo de funcionamiento;

las figuras 6 a 9 ilustran el funcionamiento del sistema de la figura 4 en los modos de la figura 5; y

la figura 10 ilustra una estrategia para seleccionar un modo de funcionamiento.

La figura 4 muestra una vista esquemática de un sistema de comunicaciones. El sistema de comunicaciones comprende una unidad emisora 20 conectada a una unidad receptora 21 por un camino bidireccional 22 de comunicaciones. La unidad emisora es capaz de descomponer un mensaje en paquetes y de enviarlo hacia la unidad receptora usando el protocolo TCP. En aras de una mayor simplicidad en la explicación, el camino 22 de comunicaciones se muestra de manera que comprende un canal 23 de salida y un canal 24 de retorno que pueden funcionar para enviar señales en direcciones opuestas, aunque en la práctica, el camino puede ser un único canal físico en cualquier punto de su dimensión longitudinal. El camino lo puede proporcionar una cadena de uno o más enlaces establecidos en serie, los cuales podrían ser del mismo o de diferente tipo físico (por ejemplo, cables fijos, canales de radiocomunicaciones o canales ópticos).

Se dispone de un nodo 25 establecido en el camino 22 de comunicaciones. El nodo 25 comprende conmutadores 26, 27 instalados, respectivamente, en los canales 23, 24 de salida y de retorno. Los conmutadores funcionan bajo el control de un controlador 28. Se dispone de un detector 29 de paquetes conectado a una salida del conmutador 26. Se dispone de un detector 30 de confirmaciones de recepción conectado a una salida del conmutador 27. Las otras salidas de los conmutadores 26, 27 van respectivamente al receptor 21 y el emisor 20. Las salidas de los detectores 29, 30 van al controlador 28. El nodo incluye también una memoria 31, en la cual el controlador 28 puede almacenar datos, y un generador 36 de confirmaciones de recepción el cual puede generar mensajes de confirmación de recepción para los paquetes bajo la dirección del controlador 28. En uno de los ajustes ("A") del conmutador 26, las señales entrantes hacia el nodo en el canal 23 (desde la entrada 32) se dirigen directamente a la salida 33 del nodo 25 en el canal 23. En el otro ajuste ("B") del conmutador 26, las señales de la entrada 32 están aisladas con respecto a la salida 33; en cambio, la salida de la memoria 31 va dirigida a la salida 33. En uno de los ajustes ("X") del conmutador 27, las señales entrantes al nodo en el canal 24 (provenientes de la entrada 34) se dirigen directamente a la salida 35 del nodo 25 en el canal 24. En el otro ajuste ("Y") del conmutador 27, las señales de la entrada 34 están aisladas con respecto a la salida 35; en cambio, la salida del generador 36 de confirmaciones de recepción va dirigida a la salida 35.

El controlador 28 funciona bajo la supervisión de una unidad 37 de selección de modo la cual monitoriza los canales 23 y 24 para determinar el estado del sistema de comunicaciones y es controlable por una señal externa en la referencia 38. La unidad 37 de selección de modo también puede monitorizar los canales 23 y 24, especialmente cuando los mismos incluyen un camino inalámbrico o algún otro camino que pueda resultar un cuello de botella.

En aras de una mayor claridad en la descripción, el nodo 25 se describe en el presente documento de manera que comprende diferentes aparatos individuales. No obstante, el nodo 25 se podría proporcionar en forma de uno o más bloques de funcionalidad diferente con respecto a los mostrados en la figura 4. Las funciones del nodo 25 las podría proporcionar de forma total o parcial un software que se ejecutase en uno o más microprocesadores.

Durante el funcionamiento, el nodo 25 tiene tres modos, a los que se hace referencia en el presente documento como modo "normal", modo "rápido" y modo de "confirmación de recepción anticipada".

\bullet

En el modo normal, el conmutador 26 se fija en el ajuste A y el conmutador 27 se fija en el ajuste X. Esto permite que las señales provenientes de la unidad emisora 20 vayan directamente a través del nodo hacia la unidad receptora 21, y que las señales provenientes de la unidad receptora vayan directamente hacia la unidad emisora.

\bullet

En el modo rápido, el conmutador 26 se fija al ajuste A, el conmutador 27 se fija al ajuste Y. Cuando el nodo recibe un paquete de la unidad emisora 20, el controlador 28 lo retransmite hacia la unidad receptora. La unidad receptora genera confirmaciones de recepción para los paquetes que recibe. Cuando se confirma la recepción de un paquete, el nodo 25 retransmite la confirmación de recepción después de un retardo hacia la unidad emisora. Adicionalmente, el nodo 25 puede almacenar el paquete recibido de la unidad emisora 21 y volver a enviarlo hacia la unidad receptora 21 si no se recibe ninguna confirmación de recepción después de un periodo de tiempo fijado. En la confirmación de recepción anticipada, los conmutadores 26 y 27 se fijan respectivamente al ajuste B e Y. Este proceso se describe posteriormente de forma más detallada.

\bullet

En el modo normal, el enlace 22 entre la unidad emisora 20 y la unidad receptora 21 funciona de extremo a extremo como si el nodo 25 no estuviera presente. En el modo de confirmación de recepción anticipada, el nodo proporciona la capacidad de acelerar que el aumento de la velocidad de transmisión por parte de la unidad emisora bajo el arranque lento TCP mediante el envío de confirmaciones de recepción inmediatas. En el modo rápido, el nodo puede reducir la velocidad de transmisión del emisor, con vistas a hacer frente a la reducción de la capacidad a través del enlace o al llenado de la memoria intermedia de los nodos. La disponibilidad de más de uno de estos modos proporciona al nodo la capacidad de mejorar el funcionamiento del enlace TCP en una amplia gama de circunstancias, tal como se describirá posteriormente de forma más detallada. En particular, la gama de modos permite un esquema de funcionamiento el cual puede evitar los inconvenientes del algoritmo de arranque lento TCP y aliviar la acumulación en memoria intermedia en el nodo retransmisor.

La unidad 37 de selección de modos monitoriza el enlace 22 y provoca que el controlador 28 adopte uno de entre los modos disponibles dependiendo de las condiciones del enlace. La figura 5 ilustra una estrategia preferida. En el funcionamiento normal, la unidad 37 de selección de modos selección el modo normal. Cuando la memoria intermedia 31 tiene espacio disponible y existe un ancho de banda disponible en el enlace en ambas direcciones, la unidad de selección de modos selecciona el modo de confirmación de recepción anticipada para conseguir que la velocidad de transmisión de paquetes aumente. Cuando existe congestión en el enlace, o la memoria intermedia está llena, la unidad de selección de modos selecciona el modo rápido para conseguir que la velocidad de transmisión de paquetes se reduzca.

A continuación se describirá más detalladamente el efecto de los modos disponibles.

Cuando existe un ancho de banda disponible por encima de un umbral fijado, y el selector 37 de modos no detecta pérdidas de paquetes debido a la congestión, se selecciona el modo de confirmación de recepción anticipada. Cuando un paquete es recibido por el nodo 25 y detectado por el detector 29, el controlador 28 controla el generador 36 de confirmaciones de recepción para que genere una confirmación de recepción "anticipada", y la envía hacia el emisor 20. El número de paquete especificado en el mensaje de confirmación de recepción anticipada es el correspondiente a un paquete que no ha sido recibido todavía por el nodo 25 (aunque, por compatibilidad con la mayoría de protocolos, es el correspondiente a uno que es probable que haya sido enviado por el emisor antes de que le llegue la confirmación de recepción). De este modo, mientras ese paquete de datos en cuestión está en camino desde el controlador de confirmaciones de recepción hacia el receptor TCP y/o la confirmación de recepción generada por el receptor TCP está en camino desde el receptor al controlador de confirmaciones de recepción. El número según el cual el número de confirmación de recepción se adelanta con respecto al último paquete recibido por el nodo depende del ancho de banda disponible, de la naturaleza de las pérdidas de los paquetes y del espacio de memoria intermedia disponible en el nodo de red. De este modo, el controlador de confirmaciones de recepción prevé la necesidad de enviar un mensaje de confirmación de recepción verdadero para un cierto paquete y envía una confirmación de recepción anticipada generada por él mismo hacia la fuente TCP de manera que la fuente TCP obtiene una confirmación de recepción antes de lo que lo haría incluso si se usara un nodo de fisgoneo. A continuación, el nodo 25 reenviará el paquete, cuando lo reciba, hacia el receptor, o simplemente permitirá que el paquete pase a través del nodo 25. Cuando el mensaje de confirmación de recepción correspondiente que es generado por el receptor TCP alcanza el nodo, el controlador 28 lo elimina de la memoria 31.

Para ilustrar la eficacia de este modo, con el número de secuencia del paquete de llegada en el nodo definido como PK(i), la confirmación de recepción de llegada como ACK^{i}(i) y la confirmación de recepción generada como ACK^{0}(i), respectivamente, la ACK^{0}(i) se puede ajustar en función del ancho de banda disponible BW_{a} y el espacio de memoria intermedia disponible BS_{a} y de ACK^{0}(i-1). Se puede formular de la manera siguiente

(1)ACK^{0} \ (i) = ACK^{0} \ (i-1) + f(BW_{a}, BS_{a})

ACK^{i}(i) \leq ACK^{0} \ (i) \leq PK(i)

Por ejemplo, la función f puede ser

(2)f = (PK - ACK^{0}(i-1))\left(a_{1}\frac{BS_{a}}{BS_{max}} + a_{2}BW_{a}\right)

en la que BS_{max} es el espacio de memoria intermedia máximo y a_{1} y a_{2} son constantes. Obsérvese que si f = PK-ACK^{0}(i-1), el método de confirmación de recepción anticipada se ha reducido al fisgoneo TCP convencional.

En el modo de confirmación de recepción anticipada, a la fuente TCP se le confirma rápidamente la recepción de sus paquetes, y la fuente comienza a aumentar su velocidad de transmisión. A su vez, esta situación reduce el tiempo que tarda el protocolo TCP en alcanzar su velocidad completa y mejora el caudal total.

Como la función f (ecuación 2) tiene en cuenta el ancho de banda disponible y la ocupación de la memoria intermedia, la misma supera los problemas del método de fisgoneo TCP. Efectivamente, la ACK^{0} transmitida se aproxima a ACK^{i} cuando el espacio de memoria intermedia y/o el ancho de banda disponibles se reducen. Cuando no hay disponible ningún ancho de banda no usado, ACK^{i} = ACK^{0}, y se ha alcanzado el funcionamiento normal del TCP. Por otro lado, cuando el ancho de banda y/o el espacio de memoria intermedia disponible aumenta, ACK^{0} se aproxima a PK. De este modo, cuando se dispone de una gran cantidad de ancho de banda disponible no usado, el nodo 25 en el modo de confirmaciones de recepción anticipadas funciona de una forma similar al método de fisgoneo TCP descrito anteriormente.

El modo normal se usa una vez que el sistema TCP en el emisor ha alcanzado la velocidad completa y no existe sustancialmente ningún ancho de banda disponible no usado en la dirección desde el emisor al receptor. La llegada de un paquete TCP al nodo ya no activa la generación de la confirmación de recepción anticipada. En su lugar, el controlador de confirmaciones de recepción simplemente deja que los paquetes TCP y las confirmaciones de recepción correspondientes fluyan a través de él de una manera natural, sin perturbaciones.

En el modo TCP rápido, el cual se usa si el selector de modos detecta pérdidas de paquetes debido a la congestión, el controlador de confirmaciones de recepción pospone la devolución de confirmaciones de recepción al emisor. Esto se podría realizar mediante la recepción de confirmaciones de recepción por parte del nodo desde el receptor, su almacenamiento durante un periodo y a continuación su retransmisión hacia el emisor; o mediante la introducción de un retardo por parte del nodo antes de que genere el mismo una confirmación de recepción. El proceso de posponer las confirmaciones de recepción se podría efectuar según una manera descrita en el documento WO 99/04536, cuyo contenido se incorpora al presente documento a título de referencia. El efecto del retardo de las confirmaciones de recepción es la reducción de la congestión, y por lo tanto de la pérdida de paquetes.

La figura 6 ilustra adicionalmente el modo de confirmaciones de recepción anticipadas. Sobre la base de la información que ha detectado sobre la naturaleza de la pérdida de paquetes y del ancho de banda disponible, el selector de modos del nodo 25 ha seleccionado el modo de confirmaciones de recepción anticipadas, y ha provocado que el controlador funcione en dicho modo. Hay un paquete TCP con el número de secuencia PK que viene desde la fuente hacia el nodo. El controlador de confirmaciones de recepción recibe el paquete TCP. El nodo envía una confirmación de recepción ACK^{0} hacia la fuente TCP. La confirmación de recepción podría ser generada en su totalidad por el nodo o se podría capturar y modificar un paquete de confirmación de recepción adecuado que pase por el nodo en ese momento (que haya sido generado por el receptor TCP) para transportar la ACK^{0}. En la anterior ecuación 1 se ha mostrado un método que puede usar el nodo en el cálculo del valor de ACK^{0}.

El envío de ACK^{0} y otros similares provocará que la fuente TCP se acelere rápidamente ya que entonces recibirá confirmaciones de recepción más rápidamente que con otros métodos. Esencialmente se produce un ahorro de más del tiempo de ida y vuelta entre el nodo y el receptor TCP. Efectivamente, la fuente TCP ve en esa situación que existe una distancia más corta al receptor que incluso la distancia al nodo.

El paquete TCP PK se reenvía al receptor TCP. Obsérvese que la generación y transmisión (o captura y modificación) de ACK^{0} y el reenvío (o la autorización a pasar) de PK se pueden producir también en el orden inverso. Una copia del paquete TCP PK se almacena en la memoria 31 de manera que la misma puede volver a ser transmitida por el nodo si el paquete se pierde entre el controlador ACK y el receptor TCP.

El receptor TCP recibe el paquete TCP PK y, como es habitual, confirma su recepción enviando una ACK^{i} correspondiente hacia la fuente TCP. Finalmente, el controlador ACK intercepta la ACK^{i} y la descarta o usa la ACK para alguna otra ACK^{0}.

El controlador ACK también debe ocuparse de las retransmisiones. De este modo, monitoriza el flujo de confirmaciones de recepción ACK^{i} desde el receptor TCP. Si antes de un cierto tiempo especificado, no ha llegado ninguna ACK, el mismo vuelve a transmitir el paquete TCP con el número de secuencia PK. Obsérvese que en este caso es posible el uso de los mecanismos de retransmisión TCP normalizados según se especifica en la publicación "Transport Control Protocol", IETF RFC 793, Septiembre de 1981.

La figura 7 ilustra un ejemplo más detallado de la transmisión según la presente invención. En este caso, se considera que existe el suficiente ancho de banda y espacio de memoria intermedia disponible como para aumentar adicionalmente las velocidades de transmisión. Supóngase que un paquete con el número de secuencia 64 llega al nodo proveniente de la fuente mientras que un mensaje de confirmación de recepción con el número 57 llega proveniente del receptor. Basándose en el ancho de banda disponible, el nodo ha determinado el uso del modo de confirmaciones de recepción anticipadas. El mismo crea un mensaje de confirmación de recepción con el número 60 y lo transmite hacia la fuente TCP. Obsérvese que el número de este mensaje está por debajo del 64 (el número de paquete que ha llegado). El mensaje de confirmación de recepción con el 57 recibido desde el receptor TCP se descarta (o el mismo se podría haber modificado para llevar el valor 60). El paquete 64 se almacena en la memoria intermedia del nodo por si debe volver a ser transmitido. El paquete 57 se elimina de la memoria intermedia ya que en ese momento ya ha sido recibido.

En una fase posterior, ilustrada por la figura 8, ya no existe ningún ancho de banda no usado disponible. Por esta razón, en este caso las confirmaciones de recepción provenientes del receptor TCP hacia el nodo simplemente se dejan pasar, de manera que ACK^{0} = ACK^{i}. Esta situación se corresponde con el modo TCP normal.

En alguna otra fase, tal como se ilustra por medio de la figura 9, se puede producir una congestión. La memoria intermedia en el nodo de red se ha llenado y/o el ancho de banda no usado es pequeño y/o se detectan errores debidos a la congestión. En ese caso, el nodo comienza a retardar las confirmaciones de recepción (confirmaciones ACK^{i}) que fluyen desde el receptor TCP hacia la fuente TCP para reducir la congestión.

La presente invención resulta especialmente adecuada para ser usada conjuntamente con redes de radiocomunicaciones, tales como el GPRS o las redes celulares de tercera generación (3GN), u otros sistemas en los cuales pueda haber un enlace que tenga una capacidad que varía rápidamente para la conexión TCP (debido, por ejemplo, a niveles variables de interferencia). En un sistema de radiocomunicaciones, el nodo 25 se podría situar cerca de la interfaz de radiocomunicaciones en un enlace de comunicaciones. El nodo podría recibir una señal indicativa de la capacidad disponible en ese momento a través de la interfaz de radiocomunicaciones. Por ejemplo, el nodo se podría situar en el controlador de red de radiocomunicaciones (RNC) de un sistema 3GN. El nodo monitoriza la capacidad disponible. Cuando existe una gran cantidad de capacidad libre para el tráfico TCP que viene desde fuera del sistema 3GN, el nodo comienza a generar confirmaciones de recepción anticipadas, incluso aunque los octetos reales sigan estando en el camino a través de la interfaz de radiocomunicaciones. De este modo, el transmisor TCP obtendrá confirmaciones de recepción antes, acelerará sus transmisiones, y hará un mejor uso de la capacidad disponible. Por otro lado, durante la congestión (por ejemplo, debido a unas condiciones de radiocomunicaciones deficientes) el nodo puede entrar en el modo TCP rápido.

El método de confirmaciones de recepción anticipadas puede acelerar el proceso de arranque lento TCP y de esta manera utilizar más eficazmente el ancho de banda disponible, así como mitigar los problemas de acumulación de la memoria intermedia que pueden experimentarse en los sistemas anteriores de fisgoneo TCP. El método se realiza por medio de un nodo ubicado entre un transmisor TCP y un receptor TCP. El nodo genera y devuelve confirmaciones de recepción al transmisor TCP por paquetes de datos que todavía no han llegado al nodo, y que por lo tanto no han sido recibidos ni su recepción ha sido confirmada por el receptor TCP. Esto puede reducir el tiempo que debe esperar el transmisor TCP por una confirmación de recepción, y por lo tanto permite que el transmisor TCP acelere sus transmisiones de forma más rápida que sin este mecanismo. La secuencia de confirmaciones de recepción se ajusta según el ancho de banda y el espacio de memoria intermedia disponible, la medición del número de secuencia de los paquetes de llegada y de las confirmaciones de recepción de llegada al nodo.

El método de confirmaciones de recepción anticipadas puede tomar forma en un nodo que pueda funcionar en dos o más (preferentemente por lo menos tres) modos, por ejemplo: el modo de confirmaciones de recepción anticipadas, un modo TCP normal y un modo TCP rápido. La decisión sobre el modo a usar se puede basar, por ejemplo, en el ancho de banda no usado, disponible, en los niveles de ocupación de la memoria intermedia, y en la congestión. La figura 10 es un diagrama de flujo que ilustra un ejemplo de un proceso de decisión sobre qué modo usar.

La presente invención no se limita a los ejemplos descritos anteriormente.

El solicitante llama la atención sobre el hecho de que la presente invención puede incluir cualquier característica o combinación de características dadas a conocer en el presente documento de forma bien implícita o bien explícita o cualquier generalización de las mismas.

Claims (24)

1. Nodo (25) de comunicaciones de datos destinado a funcionar en un camino (22) de comunicaciones entre un transmisor de datagramas (20) y un receptor de datagramas (21) bajo un protocolo en el que la transmisión de datagramas por parte del transmisor depende de la recepción, por parte de este último, de un mensaje de confirmación de recepción correspondiente a un datagrama transmitido previamente, comprendiendo el nodo:

un aparato (29) de detección para detectar comunicaciones en el camino;

un generador (36) de confirmaciones de recepción adaptado para generar mensajes de confirmación de recepción para datagramas y transmitir dichos mensajes hacia el transmisor; y

un aparato de interrupción del flujo adaptado para interrumpir comunicaciones en el camino;

caracterizado porque el nodo está adaptado para funcionar en el segundo y en por lo menos uno de entre el primero y el tercero de los siguientes modos:

- un primer modo en el cual no interrumpe las comunicaciones en el camino;

- un segundo modo en el cual transmite un mensaje de confirmación de recepción para un datagrama que sucede al último datagrama detectado en el nodo; y

- un tercer modo en el cual retarda la comunicación de mensajes de confirmación de recepción hacia el transmisor.

2. Nodo de comunicaciones de datos según la reivindicación 1, en el que en el segundo y/o tercer modos, el nodo interrumpe la comunicación de mensajes de confirmación de recepción provenientes del receptor hacia el transmisor.

3. Nodo de comunicaciones de datos según la reivindicación 1 ó 2, que comprende una memoria; y en el que en el segundo y/o tercer modo, el nodo almacena en la memoria datagramas detectados en la transmisión desde el transmisor al receptor.

4. Nodo de comunicaciones de datos según la reivindicación 3, en el que en el segundo y/o tercer modo, el nodo interrumpe la comunicación de datagramas provenientes del transmisor hacia el receptor.

5. Nodo de comunicaciones de datos según la reivindicación 3 ó 4, en el que en el segundo y/o tercer modo, si en un periodo fijado el nodo no detecta ningún mensaje de confirmación de recepción para un datagrama desde del receptor, el mismo vuelve a transmitir dicho datagrama hacia el receptor.

6. Nodo de comunicaciones de datos según cualquiera de las reivindicaciones 3 a 5, en el que en el segundo y/o tercer modo, al recibir un mensaje de confirmación de recepción correspondiente a un datagrama, el nodo elimina dicho datagrama de la memoria.

7. Nodo de comunicaciones de datos según cualquiera de las reivindicaciones anteriores, que comprende una unidad (37) de determinación de modo para determinar el modo de funcionamiento del nodo.

8. Nodo de comunicaciones de datos según la reivindicación 7, en el que la unidad de determinación de modo es capaz de determinar si hay capacidad disponible en el camino de comunicación y, si hay capacidad disponible, es capaz de provocar que el nodo funcione en el segundo modo.

9. Nodo de comunicaciones de datos según la reivindicación 7 u 8, en el que la unidad de determinación de modo es capaz de determinar si existe congestión en el camino de comunicaciones y, si existe congestión, es capaz de provocar que el nodo funcione en el tercer modo.

10. Nodo de comunicaciones de datos según la reivindicación 9 en dependencia de la reivindicación 8, en el que si no existe capacidad disponible o congestión en el camino de comunicaciones, la unidad de determinación es capaz de provocar que el nodo entre en el primer modo.

11. Nodo de comunicaciones de datos según cualquiera de las reivindicaciones anteriores, en el que el nodo es capaz de funcionar en cualquiera de entre el primer, el segundo y el tercer modos.

12. Nodo de comunicaciones de datos según cualquiera de las reivindicaciones anteriores, en el que el protocolo es un protocolo de control de transmisión (TCP).

13. Nodo de comunicaciones de datos según cualquiera de las reivindicaciones anteriores, en el que el protocolo proporciona un tipo de funcionamiento en el cual el transmisor no transmitirá un datagrama hasta que haya recibido un mensaje de confirmación de recepción correspondiente a un datagrama transmitido previamente desde hace un intervalo almacenado.

14. Nodo de comunicaciones de datos según la reivindicación 13, en el que en dicho tipo de funcionamiento el protocolo prevé que el intervalo almacenado se incremente si se recibe un mensaje de confirmación de recepción.

15. Nodo de comunicaciones de datos según la reivindicación 13 ó 14, en el que dicho tipo de funcionamiento es un tipo de funcionamiento de arranque lento.

16. Nodo de comunicaciones de datos según cualquiera de las reivindicaciones anteriores, en el que por lo menos parte del camino de comunicaciones es un enlace de radiocomunicaciones.

17. Nodo de comunicaciones de datos según la reivindicación 16, en el que el enlace de radiocomunicaciones es un enlace de radiocomunicaciones celular.

18. Método para la comunicación de datos a través de un camino (22) de comunicaciones entre un transmisor de datagramas (20) y un receptor de datagramas (21) bajo un protocolo en el que la transmisión de datagramas por parte del transmisor depende de la recepción, por parte de este último, de un mensaje de confirmación de recepción correspondiente a un datagrama transmitido previamente, existiendo un nodo (25) ubicado en el camino de comunicaciones entre el transmisor y el receptor; caracterizado porque el método comprende:

la transmisión de datagramas hacia el receptor por parte del transmisor;

la detección de dichos datagramas por parte del nodo; y

la transmisión repetida, por parte del nodo, hacia el transmisor, de un mensaje de confirmación de recepción correspondiente a un datagrama que sucede al último datagrama detectado en el nodo.

19. Método según la reivindicación 18, en el que el protocolo es un protocolo de control de transmisión (TCP).

20. Método según la reivindicación 18 ó 19, en el que el protocolo proporciona un tipo de funcionamiento en el cual el transmisor no transmitirá un datagrama hasta que haya recibido un mensaje de confirmación de recepción correspondiente a un datagrama transmitido previamente desde hace un intervalo almacenado.

21. Método según la reivindicación 20, en el que en dicho tipo de funcionamiento el protocolo prevé que el intervalo almacenado se incremente si se recibe un mensaje de confirmación de recepción.

22. Método según la reivindicación 20 ó 21, en el que dicho tipo de funcionamiento es un tipo de funcionamiento de arranque lento.

23. Método según cualquiera de las reivindicaciones anteriores, en el que por lo menos parte del camino de comunicaciones es un enlace de radiocomunicaciones.

24. Método según la reivindicación 23, en el que el enlace de radiocomunicaciones es un enlace de radiocomunicaciones celular.