ES2349189T3 - Sistema y método para transferencia de datos mejorada en redes de comunicación por conmutación de paquetes. - Google Patents
Sistema y método para transferencia de datos mejorada en redes de comunicación por conmutación de paquetes. Download PDFInfo
- Publication number
- ES2349189T3 ES2349189T3 ES00905060T ES00905060T ES2349189T3 ES 2349189 T3 ES2349189 T3 ES 2349189T3 ES 00905060 T ES00905060 T ES 00905060T ES 00905060 T ES00905060 T ES 00905060T ES 2349189 T3 ES2349189 T3 ES 2349189T3
- Authority
- ES
- Spain
- Prior art keywords
- node
- retransmission
- value
- sending
- retransmission timer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Landscapes
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Método de ejecución de una recuperación de errores basada en temporizadores de retransmisión en un nodo emisor de una red de comunicaciones que implementa conexiones del protocolo de control de transmisión TCP entre por lo menos un nodo emisor y por lo menos un nodo receptor utilizando un control de flujo de ventana deslizante, que comprende las etapas de: (a) recibir un segmento de acuse de recibo ACK desde el nodo receptor (330); y (b) reinicializar un temporizador de retransmisión REXMT asociado a una sesión entre el nodo emisor y el nodo receptor con un valor que compensa el tiempo transcurrido desde el tiempo de transmisión de un segmento transmitido previamente desde el emisor al receptor (310).
Description
La presente invención se refiere a sistemas y métodos para la transferencia de datos en redes de comunicación por conmutación de paquetes. Más particularmente, 5 la presente invención se refiere a sistemas y métodos para mejorar la velocidad de
transferencia de datos en redes de comunicación por conmutación de paquetes.
Las redes de comunicación se pueden clasificar como redes o bien por conmutación de circuitos o bien por conmutación de paquetes. Las redes por conmutación de circuitos, usadas tradicionalmente en redes de comunicación de voz
10 tales como las redes telefónicas, funcionan estableciendo una conexión lógica entre dos puntos en la red. Típicamente, la conexión es de un ancho de banda o capacidad fijos con independencia de la velocidad deseada de transferencia de datos del emisor. Las redes por conmutación de circuitos se consideran ampliamente como rígidas en cuanto a su funcionamiento e ineficaces en cuanto a su asignación de ancho de
15 banda, o capacidad, por toda la red. Por contraposición, las redes por conmutación de paquetes, usadas tradicionalmente en comunicaciones de datos, funcionan conformando la información en paquetes, que a continuación son enviados a través de la red a un nodo destinatario deseado. Las redes por conmutación de paquetes pueden ser orientadas a conexión, de tal manera que se mantiene una conexión lógica
20 entre el emisor y el receptor, o sin conexión, de tal manera que no se mantiene ninguna conexión lógica entre un emisor y un receptor en la red. Las redes por conmutación de paquetes se consideran ampliamente como más flexibles y sustancialmente más eficaces, en la asignación del ancho de banda, que las redes por conmutación de circuitos. Debido en parte a estos factores, la demanda de servicios
25 de redes por conmutación de paquetes ha crecido drásticamente durante las últimas dos décadas. Se prevé que la demanda de redes por conmutación de paquetes continúe con su drástico crecimiento.
Las redes de datos por conmutación de paquetes están diseñadas y basadas en normativas de datos de ámbito industrial tales como el modelo de interfaz de 30 sistemas abiertos (OSI) o una implementación de la pila del Protocolo de Control de Transmisión/Protocolo de Internet (TCP/IP). Según el modelo OSI, un sistema de red se representa típicamente mediante una pila de protocolos multicapa. Los protocolos TCP/IP se modelan comúnmente como una pila de protocolos de cuatro capas. La capa 1, a la que se hace referencia como el enlace, enlace de datos, o capa de 35 interfaz de red, gestiona las interfaces y los controladores de dispositivos para comunicarse por interfaz con los elementos físicos de la red. La capa 2, a la que se hace referencia como capa de red o capa de Internet, es responsable del encaminamiento de paquetes de datos en la red. El Protocolo de Internet (IP) es un protocolo de la capa de red. La capa 3, a la que se hace referencia como capa de 5 transporte, es responsable de conformar los datos a transmitir en paquetes de tamaño apropiado, para su transmisión a través de la red. La capa de transporte gestiona además procesos de recuperación de errores y de control de congestión, el acuse de recibo de paquetes recibidos y la fijación de tiempos de espera para garantizar que el receptor deseado recibe datos transmitidos. El Protocolo de Control de Transmisión 10 (TCP) es un protocolo de la capa de transporte. La capa 4, a la que se hace referencia como capa de aplicación, es responsable de la gestión de aplicaciones TCP/IP particulares. Las aplicaciones TCP/IP ejemplificativas incluyen SMTP para correo electrónico, FTP para transferencias de archivos, Telnet para conexión remota, etcétera. El conjunto de protocolos TCP/IP es el conjunto principal de protocolos de 15 comunicaciones aplicable a la transferencia de información digital a través de múltiples redes de ordenadores conectadas, tales como Internet. El funcionamiento de una red según los protocolos TCP/IP se puede explicar, a nivel conceptual, de la manera siguiente: las aplicaciones TCP trasladan datos para su transmisión hacia procesos en la capa de transporte. La capa de transporte recibe datos para su transmisión desde 20 una aplicación tal como, por ejemplo, el correo electrónico, y conforma los datos en paquetes de tamaño apropiado, a los que se hace referencia como segmentos. A continuación, la capa de transporte traslada los segmentos de datos a una utilidad de protocolo de la capa de red, que compila paquetes de datos según protocolos de la capa de red como el IP, a los que se hace referencia como datagramas, y encamina
25 los datagramas, a través de una o más redes, hacia el receptor deseado. A su vez, la capa de red solicita a los servicios de utilidades de protocolos de la capa de enlace que gestionen un medio físico particular tal como, por ejemplo, una conexión de ethernet. El IP posibilita un servicio de entrega no fiable, sin conexión, que puede ser
30 usado por numerosos protocolos de la capa de transporte, incluyendo el TCP. La capa IP es sin conexión por cuanto el IP no mantiene ninguna relación lógica entre datagramas sucesivos transmitidos a través de la red. Cada datagrama es tratado por la red como un elemento individual de información. De este modo, aun cuando una transferencia de archivos de gran tamaño puede requerir el envío de cientos, incluso
35 miles, de datagramas, la capa IP de la red no tiene conocimiento, durante la
transferencia, de que los paquetes están relacionados. Los paquetes individuales se pueden encaminar a través de trayectos diferentes por la red y/o pueden llegar al destino en cualquier secuencia. El IP no es fiable en el sentido de que, en la capa IP, no se implementan procedimientos robustos de recuperación de errores.
5 El TCP es un protocolo orientado a conexión. En la capa TCP (de transporte), se establece una conexión lógica entre un emisor TCP y un receptor TCP. Tal como se ha descrito anteriormente, en el nodo emisor la capa TCP es responsable de dividir datos en segmentos de tamaño apropiado, para su transmisión. En el nodo receptor, la capa TCP es responsable del acuse de recibo de segmentos recibidos y de volver a
10 ensamblar segmentos relacionados. Las funciones adicionales implementadas en la capa TCP incluyen la recuperación de errores y el control de la congestión. En términos amplios, recuperación de errores se refiere al proceso de garantizar que los paquetes transmitidos por un emisor, como mínimo, fueron recibidos por el destinatario deseado. La recuperación de errores puede incluir algoritmos adicionales para
15 garantizar que el destinatario recibió los datos correctos. El TCP usa una función de retransmisión como uno de los procedimientos de recuperación de errores. Según el TCP, un emisor TCP retransmite paquetes de datos para los cuales no se recibe un paquete de acuse de recibo en un periodo de tiempo predeterminado. El TCP mantiene un temporizador de retransmisión (REXMT) para
20 implementar el procedimiento de recuperación de errores. Para cada segmento de acuse de recibo (ACK) devuelto por el receptor, el emisor reinicializa el REXMT con un valor de temporizador de retransmisión (RTO) que es una función del tiempo de ida y vuelta (RTT). En muchas implementaciones del TCP, el emisor TCP mide continuamente el RTT. En realizaciones alternativas, el RTT se puede actualizar
25 basándose en mediciones reales del RTT. El Protocolo de Enlace de Radiocomunicaciones (RLP), un protocolo de la capa de enlace para comunicaciones inalámbricas, implementa también un procedimiento de recuperación de errores basado en un temporizador de retransmisión, similar a la rutina implementada por el TCP.
30 La estimación del temporizador de retransmisión en el TCP según se ha descrito anteriormente se presenta en “Computer Networks” 1996, de A. S. Tanenbaum, PRENTICE HALL PTR, New Jersey. El temporizador de retransmisión se inicia con el valor RTO, cuando se recibe un acuse de recibo correspondiente al segmento enviado. La estimación de RTO se basa en las mediciones continuas del
35 tiempo de ida y vuelta (RTT).
Un algoritmo presentado en “Explicit loss indication and accurate RTO estimation for TCP error recovery using satellite links” Samaraweera N ET AL, IEE Proceedings: Communications, vol. 144, n.º1, 1 de febrero de 1997, páginas 47 a 53, XP 000687134, considera también mediciones continuas del tiempo de ida y vuelta
5 (RTT). La estimación del RTO se mejora usando el tiempo de transmisión de cada segmento para el cual se recibe un acuse de recibo. Este algoritmo permite muestrear el RTT muchas veces por ventana de transmisión. En la técnica convencional, el RTT se mide entre el envío de un octeto de datos con un número de secuencia particular y la recepción del acuse de recibo que cubre el mismo número de secuencia. En las
10 mediciones no se incluirán los paquetes posteriores pertenecientes a la misma ventana. En este documento se resuelve este problema. Una desventaja es el número del temporizador que se debe iniciar. Aunque varias implementaciones de la rutina de retransmisión han resultado eficaces, las mismas pueden reducir innecesariamente velocidades de transferencia
15 de datos en la red. De este modo, existe una necesidad de sistemas y métodos mejorados para la transferencia de datos en redes por conmutación de paquetes, incluyendo redes TCP. La presente invención usa técnicas nuevas para gestionar un REXMT que potencian la velocidad de transferencia de datos de una red. SUMARIO
20 La presente invención afronta estos y otros problemas proporcionando sistemas y métodos mejorados para implementar servicios de transporte de datos por conmutación de paquetes. Más particularmente, la presente invención proporciona un procedimiento de recuperación de errores basado en retransmisiones que facilita velocidades mejoradas de transferencia de datos en comparación con procedimientos
25 conocidos de recuperación de errores por temporizador de retransmisión. Según un aspecto de la invención, la velocidad de transferencia de datos se puede mejorar reinicializando el temporizador de retransmisión con un valor que compensa el tiempo transcurrido desde el tiempo de transmisión de un paquete transmitido previamente desde el emisor al receptor. De forma ventajosa, el sistema permite gestionar la
30 corrección de errores basándose en cada paquete, aunque requiere únicamente la implementación de un solo temporizador, ahorrando de este modo recursos computacionales.
La presente invención proporciona además mejoras en velocidades de transferencia de datos reduciendo la probabilidad de tiempos de espera innecesarios 35 en un nodo emisor. Más particularmente, la presente invención proporciona un método
para volver a calcular un valor de temporizador de retransmisión que determina si un emisor TCP tiene suficientes segmentos transmitidos, aunque sin acuse de recibo, pendientes para activar una rutina de retransmisión rápida. En caso afirmativo, el RTO se calcula para incluir un factor que es una función del tiempo requerido para que el
5 emisor reciba un número predeterminado de segmentos ACK desde el receptor. La inclusión de este factor incrementa la probabilidad de que el REXMT incluya el tiempo suficiente para posibilitar que el emisor TCP implemente una rutina de retransmisión rápida, en lugar de una rutina de control de congestión.
Se implementa un método según un aspecto de la invención en una red de
10 comunicaciones que implementa conexiones TCP entre por lo menos un nodo emisor y por lo menos un nodo receptor utilizando un control de flujo de ventana deslizante. La invención proporciona un método para realizar una recuperación de errores basada en temporizadores de retransmisión en un nodo emisor, que comprende las etapas de recibir un segmento ACK desde el nodo receptor y reinicializar el REXMT con un valor
15 que compensa el tiempo transcurrido desde el tiempo de transmisión de un segmento transmitido previamente desde el emisor al receptor. Preferentemente, el REXMT se reinicializa con un valor de tiempo que compensa el tiempo transcurrido desde la transmisión del paquete de datos más antiguo almacenado temporalmente para su retransmisión por parte del emisor.
20 De forma ventajosa, la presente invención no es específica del protocolo. Por consiguiente, otro aspecto de la invención proporciona un método de funcionamiento de una red de comunicaciones por conmutación de paquetes, que implementa conexiones lógicas entre nodos emisores y nodos receptores en la red. Los nodos emisores se configuran para utilizar un control del flujo por ventana deslizante y una
25 recuperación de errores basada en temporizadores de retransmisión. Según la invención, la red funciona mediante el establecimiento de conexiones lógicas entre nodos emisores y nodos receptores respectivos en la red y la inicialización, para cada conexión lógica, de un temporizador de retransmisión con un valor de temporizador de retransmisión que es una función de parámetros de tráfico de la red. Se transmiten
30 paquetes de datos desde los nodos emisores a sus nodos receptores respectivos en la red, y se reciben paquetes de acuse de recibo desde los nodos receptores respectivos. Al producirse la recepción de cada paquete de acuse de recibo para datos nuevos, el temporizador de retransmisión asociado a la conexión entre el emisor y el receptor se reinicializa con un valor correspondiente al valor del temporizador de
35 retransmisión menos el tiempo transcurrido desde el tiempo de transmisión de un paquete transmitido previamente, almacenado temporalmente en una memoria asociada al emisor para su retransmisión hacia el receptor, siempre que el emisor tenga datos sin acuse de recibo almacenados temporalmente para su retransmisión.
En otro aspecto, la invención proporciona un elemento de red de
5 comunicaciones que implementa conexiones TCP entre por lo menos un nodo emisor y por lo menos un nodo receptor utilizando un control de flujo de ventana deslizante y una recuperación de errores basada en temporizadores de retransmisión. El elemento de red incluye un módulo de salida para transmitir segmentos de datos hacia un nodo receptor, un módulo de entrada para recibir segmentos ACK desde el nodo receptor, y
10 un módulo lógico, que funciona sobre un procesador asociado al elemento de red, para reinicializar el REXMT con un valor que compensa el tiempo transcurrido desde el tiempo de transmisión de un segmento transmitido previamente desde el emisor al receptor. El módulo lógico se puede implementar en software que se ejecuta en un procesador de aplicación general asociado al elemento de red o puede estar
15 incorporado en un circuito integrado de aplicación específica (ASIC). Estos y otros aspectos de la invención proporcionan velocidades mejoradas de transferencia de datos en redes por conmutación de paquetes, particularmente en nodos que funcionan como nodos “emisores”. Las velocidades mejoradas de transferencia de datos en nodos emisores contribuyen a la mejora del rendimiento de
20 la red.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
La Fig. 1 es una ilustración esquemática de una conexión de red TCP/IP.
La Fig. 2 es una gráfica que ilustra aspectos de una sesión TCP/IP.
La Fig. 3 es un diagrama de flujo que ilustra una realización de un método mejorado
25 de transferencia de datos según la presente invención. La Fig. 4 es una gráfica que ilustra aspectos de una sesión TCP/IP. DESCRIPCIÓN DETALLADA
La presente invención se explicará en referencia a las realizaciones ejemplificativas, a los ejemplos representados en el siguiente texto y a los dibujos 30 adjuntos. En particular, la presente invención se explicará en el contexto del protocolo de la capa de transporte TCP, aunque se apreciará que las realizaciones particulares representadas en el presente documento se ofrecen con fines aclaratorios y no están destinadas a ser limitativas. Se apreciará que la presente invención es aplicable a cualquier protocolo de la capa de enlace de intercambio de paquetes o protocolo de la 35 capa de transporte que use un control de flujo por ventana deslizante en combinación
con una recuperación de errores basada en un REXMT.
La presente descripción se preparó para aquellos con conocimientos habituales en la técnica del diseño y el desarrollo de redes de comunicación por conmutación de paquetes, tales como, por ejemplo, un ingeniero en redes de telecomunicación. Se
5 puede desarrollar un conocimiento práctico del conjunto de protocolos TCP/IP a partir de los siguientes documentos: W. R. Stevens, TCP/IP Illustrated, Vol. 1, Addison-Welsley, 1994; W. R. Stevens, TCP/IP Illustrated, Vol. 2, 1995; Jacobson, V. et al., TCP Extensions for High Performance, Jacobson V., et al., 1997, Internet Draft-Network Working Group, 1997. Adicionalmente, este documento supone un
10 conocimiento práctico del Protocolo de Enlace de Radiocomunicaciones. Se puede desarrollar un conocimiento práctico del Protocolo de Enlace de Radiocomunicaciones a partir del siguiente documento, que se incorpora a la presente a título de referencia: ETSI, Radio Link Protocol for data and telemetric service on the mobile station-base station switching system interface and the Base Station System-Mobile Switching
15 Center (BSS-MSC) interface, Especificación GSM 04.22, Versión 3.7.0, febrero, 1992. En referencia a la Fig. 1, se muestra una representación en diagrama de bloques que ilustra un sistema de red de comunicaciones por paquetes designado de forma general con el carácter de referencia 20, y que se puede utilizar para implementar la presente invención. Tal como se muestra, el sistema 20 de
20 comunicaciones por paquetes incluye un sistema 22a de ordenador emisor y un sistema 22b de ordenador receptor, conectados cada uno de ellos a una red de comunicación por paquetes o Internet 24 mediante tarjetas respectivas 25a, 25b de interfaz de red. Los sistemas, 22a, 22b de ordenador emisor y receptor incluyen una pila de protocolos de software de sistema operativo que comprende módulos 30a, 30b
25 de aplicación, módulos TCP 32a, 32b, módulos IP 34a, 34b y controladores 36a, 36b de dispositivos. Una aplicación 30a accede al módulo o utilidad TCP 32a en el sistema 22a de ordenador emisor. Los módulos TCP 32a, 32b recurren a los módulos IP 34a, 34b que, a su vez, recurren a controladores 36a, 36b de dispositivos. Los módulos TCP 32a, 32b pueden recurrir a otras funciones del sistema operativo, por ejemplo,
30 para gestionar estructuras de datos. La interfaz con la red 24 la controlan módulos controladores 36a, 36b de dispositivos. En el sistema 22b de ordenador receptor, el módulo IP 34b recibe y vuelve a ensamblar un datagrama IP fragmentado procedente del controlador 36b de dispositivos y traslada el datagrama IP hacia el módulo TCP 32b.
35 La presente invención surge, en un aspecto, a partir del reconocimiento de que procedimientos de recuperación de errores especificados en el TCP pueden introducir retardos de transmisión innecesarios que reducen la velocidad de transferencia de datos de un nodo emisor TCP. Se impone una breve descripción preliminar de aspectos de una sesión de comunicaciones entre un emisor TCP y un receptor TCP,
5 incluyendo procedimientos de corrección de errores.
Tal como se ha descrito anteriormente, una conexión TCP la solicita típicamente una aplicación de nivel superior en la pila de protocolos. Cuando la capa TCP recibe una solicitud de conexión TCP, un módulo TCP inicia una sesión TCP usando el protocolo de establecimiento de conexión del TCP, al que se hace
10 referencia frecuentemente como “señalización de acuerdo a tres vías” (three-way handshake). Después de que se ha establecido la conexión TCP, el emisor TCP comienza a transmitir segmentos de datos hacia el receptor TCP. El protocolo TCP proporciona un control de flujo de ventana deslizante, según el cual un emisor TCP puede transmitir más de un segmento sin recibir un acuse de recibo. Por lo menos una
15 porción de los segmentos transmitidos sin acuse de recibo se almacena temporalmente en una posición de memoria asociada al emisor para su retransmisión en caso de un error.
Un receptor TCP responde al emisor con segmentos ACK secuenciales, acumulativos. El receptor TCP responde a la recepción del segmento N con un 20 segmento ACK que indica que está preparado para recibir el segmento N+1. A título de ejemplo, el receptor TCP acusa el recibo del segmento número 1 con un segmento ACK que indica que el receptor prevé que el segmento número 2 será el siguiente en llegar. De modo similar, el receptor TCP acusa el recibo del segmento número 50 con un segmento ACK que indica que el receptor prevé que el segmento número 51 será
25 el siguiente en llegar. Tal como se ha descrito anteriormente, el TCP especifica un procedimiento de recuperación de errores por retransmisión. Para implementar esta rutina, un módulo lógico operativo en la capa TCP del emisor mantiene un REXMT para cada conexión entre un emisor TCP y un receptor TCP. En implementaciones del control de flujo por
30 ventana deslizante, de protocolos TCP, al REXMT se le asigna el segmento de datos “más antiguo” almacenado temporalmente para su retransmisión por parte del emisor. Según el TCP, el REXMT se reinicializa con un RTO que es una función del RTT cada vez que el emisor recibe un segmento de acuse de recibo para datos nuevos, siempre que el emisor tenga datos sin acuse de recibo almacenados temporalmente para su
35 retransmisión. En caso de que un error active un procedimiento de recuperación de errores por retransmisión, el emisor reduce su ventana de congestión y, después de la expiración del REXMT, retransmite los datos almacenados temporalmente hacia el emisor, comenzando con el segmento pendiente más antiguo almacenado temporalmente para su retransmisión.
5 La Fig. 2 es una gráfica que ilustra una sesión TCP desde la perspectiva de un nodo emisor en una red. El tiempo (en segundos) se representa en el eje horizontal o “X” y los números de secuencia TCP se representan en el eje vertical o “Y”. La transferencia de segmentos TCP por parte del emisor se representa con rombos y la recepción de segmentos ACK desde el destinatario deseado se representa con
10 cuadrados. En referencia a la Fig. 2, se observa que el emisor inicia una sesión TCP, y se transmiten dos segmentos aproximadamente a los tres segundos dentro de la sesión. Aproximadamente a los cinco segundos, el emisor recibe un segmento ACK desde el receptor, que acusa el recibo del segundo segmento, y transmite dos segmentos más hacia el nodo receptor. Aproximadamente a los seis segundos, el
15 emisor recibe un segmento ACK desde el receptor y transmite tres segmentos al receptor, y la sesión continúa normalmente. Aproximadamente a los siete segundos, el emisor comienza a enviar tres segmentos cada vez que se transmiten datos. La sesión TCP representada en la Fig. 2 prosigue de forma normal durante los siguientes segundos. El emisor está transmitiendo tres segmentos por cada transmisión al
20 receptor y recibiendo segmentos ACK del receptor. Deben indicarse varios aspectos en relación con la Fig. 2. En primer lugar, a medida que progresa la sesión se desarrolla un desfase temporal entre el acontecimiento de la transmisión de información por parte del emisor y la recepción, por parte del emisor, de un segmento ACK correspondiente proveniente del receptor.
25 Este desfase temporal se pone de manifiesto por la divergencia entre las representaciones de transferencias de segmentos por parte del emisor y las representaciones de recepciones de ACK por parte del emisor. A medida que la sesión se aproxima a un estado estable, y considerando una red estable, este desfase temporal converge para aproximarse al RTT entre el emisor y el receptor. En un
30 aspecto, la presente invención se basa en el reconocimiento de que este desfase temporal introduce un error en el REXMT TCP, provocando que el REXMT sea demasiado conservador. En segundo lugar, debe indicarse que el emisor TCP implementa un control de flujo de ventana deslizante. Por consiguiente, al emisor se le permite transmitir un número predeterminado de segmentos para los cuales no se
35 produce un acuse de recibo. En tercer lugar, debe indicarse que, de acuerdo con procedimientos de recuperación de errores TCP, el emisor reinicializa su REXMT con un RTO al producirse la recepción de cada segmento ACK para datos nuevos (por ejemplo, excluyendo segmentos de acuse de recibo duplicados (DUPACKS), repetición de segmentos ACK, y segmentos ACK no válidos) siempre que el emisor
5 tenga datos sin acuse de recibo almacenados temporalmente para su retransmisión. El valor del temporizador RTO se calcula típicamente en función del RTT mediante instrucciones lógicas que funcionan sobre un procesador asociado al emisor. En muchas implementaciones TCP, el RTO converge para aproximarse al RTT en una red en estado estable.
10 Aproximadamente a los doce segundos tras el inicio de la sesión, se produce un error de red que activa una rutina de error de retransmisión. Se recibe un segmento ACK 210 aproximadamente a los 12 segundos. Por consiguiente, el REXMT se inicializa con el RTO 240 aproximadamente a los doce segundos. Se observará que han transcurrido aproximadamente tres segundos desde la transmisión de los datos
15 que activaron el segmento ACK 210. Se observará también que, de acuerdo con procedimientos de control de flujo de ventana deslizante, el emisor ha transmitido aproximadamente 15 segmentos para los cuales no se produce ningún acuse de recibo. Estos segmentos se almacenan temporalmente en una memoria asociada al emisor para su retransmisión en el caso de un error.
20 Debido a un error de red, el emisor no recibe un segmento ACK del receptor antes de la expiración del REXMT, lo cual se produce aproximadamente a los quince segundos iniciada la sesión. El error de red particular que provoca la expiración del REXMT antes de recibir un segmento ACK del receptor no es crítico para la presente invención. El error de red podría ser el resultado de una congestión en la red que
25 introduce un retardo excesivo o un resultado de un fallo en uno o más nodos o enlaces en la red entre el emisor y el receptor. La expiración del REXMT se produce aproximadamente a los quince segundos, tras lo cual el emisor inicia un procedimiento de recuperación de errores por retransmisión. Por consiguiente, de acuerdo con el TCP, el emisor reduce su velocidad de transmisión y comienza a retransmitir los
30 segmentos sin acuse de recibo, comenzando con el segmento “más antiguo” almacenado temporalmente para su retransmisión, indicado en el dibujo con círculos (por ejemplo, segmento 220). El emisor retransmite los segmentos almacenados temporalmente para la retransmisión y a continuación la sesión puede continuar normalmente.
35 La serie de acontecimientos presentada en la Fig. 2 ilustra un defecto inherente
al procedimiento de recuperación de errores por retransmisión TCP. A saber, la inicialización del REXMT con el RTO tras la recepción de cada segmento de acuse de recibo no consigue compensar el desfase temporal que se desarrolla entre el acontecimiento de la transmisión de un segmento por parte del emisor y la recepción, 5 por parte del emisor, de un segmento ACK correspondiente del receptor. En el momento del error de red en la sesión representada en la Fig. 2, existe un desfase temporal 230 de aproximadamente tres segundos entre la transmisión del segmento 220 de datos y la recepción de un segmento ACK correspondiente 210. El desfase temporal 230 introduce un retardo de tiempo innecesario en el procedimiento de 10 corrección de errores por retransmisión. Este retardo de tiempo tiene una influencia negativa sobre la velocidad de transferencia de datos del emisor. En pocas palabras, el REXMT es demasiado conservador. En un aspecto, la presente invención proporciona métodos novedosos para reinicializar el REXMT de un emisor TCP con el fin de mejorar la velocidad de transferencia de datos del emisor TCP. Según la 15 presente invención, el REXMT se inicializa con un valor que compensa el tiempo que ha transcurrido desde que el emisor transmitió un segmento de datos previo hacia el receptor. En una realización de la invención, el REXMT, tras la recepción de cada segmento ACK (excluyendo segmentos DUPACK, repetición de acuses de recibo, y acuses de recibo no válidos) se reinicializa con el valor de RTO menos el tiempo que 20 ha transcurrido desde que el emisor ha almacenado temporalmente el segmento de datos “más antiguo” para la retransmisión. La reducción del REXMT con el tiempo que ha transcurrido desde que el emisor ha almacenado temporalmente el segmento de datos “más antiguo” para la retransmisión compensa el retardo de tiempo inherente al procedimiento de recuperación de errores por retransmisión del TCP, aumentándose
25 de este modo la velocidad de transferencia de datos del emisor TCP. Se apreciará que el valor de RTO se podría reducir en una cantidad diferente al tiempo transcurrido desde que el emisor ha almacenado temporalmente el segmento “más antiguo” para su retransmisión hacia el receptor. Este valor representa un ajuste agresivo en el RTO. Se podría realizar un ajuste menos agresivo seleccionando un
30 tiempo menor que el tiempo transcurrido desde que el emisor ha almacenado temporalmente el segmento “más antiguo” para su retransmisión hacia el receptor. A título de ejemplo, el RTO se podría reducir con el tiempo transcurrido desde la transmisión de un segmento de datos transmitido más recientemente que el segmento de datos almacenado temporalmente “más antiguo”.
35 La Fig. 3 es un diagrama de flujo que ilustra una secuencia de etapas en la
gestión de una sesión de comunicaciones entre un emisor TCP y un receptor TCP según la presente invención. En referencia a la Fig. 3, en la etapa 300 el emisor abre una sesión TCP entre el emisor y el receptor. Esta etapa se puede realizar de una manera que sea consecuente con las implementaciones TCP existentes. En la etapa 5 310 el emisor inicializa el REXMT con el RTO menos el tiempo transcurrido desde el byte “más antiguo” almacenado temporalmente para su retransmisión desde el emisor al receptor. Cuando la conexión se abre por primera vez, no hay segmentos almacenados temporalmente para su retransmisión de manera que el REXMT se fija en el RTO. El TCP prevé la inicialización del REXMT al comienzo de una sesión TCP, 10 y el REXMT se puede inicializar de acuerdo con protocolos existentes. En la etapa 320, el emisor transmite uno o más segmentos de datos al emisor, dependiendo de los parámetros del procedimiento de arranque y de los procedimientos de control de flujo. Esta etapa se puede realizar también de una manera que sea consecuente con implementaciones existentes del TCP. En la etapa 330, el emisor recibe un segmento 15 ACK del receptor. En la etapa 340, se realiza una prueba para determinar si el segmento ACK es válido y, en caso afirmativo, el REXMT se reinicializa con el RTO menos el tiempo que ha transcurrido desde el segmento “más antiguo” almacenado temporalmente para la retransmisión. El REXMT no se reinicializa si el segmento ACK es un segmento DUPACK o un segmento ACK no válido. A continuación, la
20 transferencia de datos prosigue de acuerdo con implementaciones existentes del TCP. Si, durante la etapa 340, se determina que el segmento ACK es erróneo, el ACK se rechaza.
El funcionamiento de una red que soporta sesiones TCP de acuerdo con los procedimientos ilustrados en la Fig. 3 permite que los nodos emisores TCP 25 compensen el retardo inherente al procedimiento de recuperación de errores por retransmisión del TCP. De forma ventajosa, los procedimientos ilustrados en la Fig. 3 no imponen cargas computacionales elevadas adicionales sobre la red ni requieren la recogida del seguimiento de datos estadísticos adicionales de la red. En su lugar, los procedimientos ilustrados en la Fig. 3 utilizan el valor RTO, un valor estadístico que es
30 especificado por el TCP. Además, los procedimientos ilustrados en la Fig. 3 permiten que la red asigne el REXMT a un segmento individual sin incurrir en los gastos computacionales del mantenimiento de temporizadores asociados a cada segmento transmitido por un nodo emisor. En otro aspecto, la presente invención proporciona procedimientos novedosos
35 para calcular el RTO para una conexión TCP con el fin de mejorar la velocidad de
transferencia de datos de un emisor TCP. Según la presente invención, el RTO se calcula para incrementar la probabilidad de que un error de transmisión active una rutina de retransmisión rápida/evitación de la congestión, en lugar de una rutina de tiempo de espera. Para implementar este procedimiento, el módulo lógico para
5 calcular el RTO incluye procedimientos para determinar la cantidad de tiempo requerida para que el emisor reciba un número predeterminado de segmentos duplicados de acuse de recibo. Según la presente invención, el módulo lógico se puede implementar en la capa TCP. En el siguiente seudocódigo de tipo C se presenta una realización del módulo lógico adecuado:
10 if (U>N) then RTO:= Delta_1 + Delta_3 + (P x Delta_2); else RTO:= Delta_1 + Delta_2; en donde:
15 U es el número de segmentos que ha enviado el emisor, pero para los que no se ha presentado un acuse de recibo. N es un número mayor que o igual a K, que es el número de DUPACKS requerido para que el emisor TCP active el mecanismo de retransmisión rápida/evitación de la congestión. En la mayoría de las implementaciones
20 TCP, K = 3. Delta_1 es una función del RTT. Una función adecuada para Delta_1 es la función de RTT Suavizado según se expone en TCP/IP illustrated, Volumen 1, incorporado anteriormente a título de referencia. No obstante, la función Delta_1 seleccionada no es crítica para la presente invención.
25 Delta_2 es una función de la variación del tiempo de ida y vuelta. Una función adecuada para Delta_2 es la función de la Variación Media Suavizada según se expone en TCP/IP illustrated, Volumen 1, incorporado anteriormente a título de referencia. No obstante, la función Delta_1 precisa seleccionada no es crítica para la presente invención;
30 Delta_3 es una función que compensa el tiempo requerido para recibir el número predeterminado de DUPACKS requeridos para activar un algoritmo de retransmisión rápida en el emisor TCP; y P>=0. Una elección adecuada para P es fijar P = K, el número predeterminado de DUPACKS requeridos para que el emisor TCP active el
35 mecanismo de retransmisión rápida/evitación de la congestión.
De este modo, según la invención, el módulo lógico destinado a calcular el RTO realiza pruebas con el fin de determinar si el emisor tiene suficientes segmentos transmitidos, aunque sin acuse de recibo, pendientes para activar un procedimiento de retransmisión rápida. Si esto es así, el cálculo de RTO incluye un factor (por ejemplo,
5 Delta_3) que es una función de la cantidad de tiempo requerido para recibir un número predeterminado de DUPACKS necesarios para activar el procedimiento de retransmisión rápida. Este factor posibilita que el emisor TCP ajuste el RTO para incrementar la probabilidad de activar un procedimiento de recuperación de errores por retransmisión rápida, en lugar de un procedimiento de recuperación de errores por
10 tiempo de espera. A continuación se presentan funciones adecuadas para Delta_3. Ejemplo 1: determinación de Delta En una red TCP, el emisor TCP puede medir el número de segmentos (M) para los que se presentó un acuse de recibo durante el cálculo más reciente del tiempo de ida y vuelta. En referencia a la sesión TCP ilustrada en la Fig. 4, el tiempo de ida y
15 vuelta más reciente se indica como el periodo de tiempo transcurrido entre las flechas 400 y 410. Se puede observar que se transmitieron 10 paquetes y se presentó acuse de recibo para los mismos durante el tiempo de ida y vuelta indicado, y por lo tanto M=10. Considerando que K es el número de segmentos duplicados de acuse de recibo requeridos para que el emisor TCP active un mecanismo de retransmisión
20 rápida/evitación de la congestión y A es la última medición del tiempo de ida y vuelta, entonces Delta_3 se puede determinar de la manera siguiente: Delta_3 = Min(A, ((A/M) x K))) Ejemplo 2: determinación de Delta 3 Considérese que B es una función de un intervalo de tiempo entre la llegada de
25 ACKs. B puede ser cualquier función adecuada incluyendo una función de suavización adecuada. En TCP/IP Illustrated, Vol. 1, se dan a conocer funciones de suavización adecuadas. Delta_3 se puede determinar de la manera siguiente: Delta_3 = Min(A, (B x K)) Se han explicado detalles de la presente invención en el contexto de una red
30 TCP/IP. No obstante, la presente invención no se limita al conjunto TCP/IP. Los principios de la presente invención son aplicables a cualquier protocolo de red por conmutación de paquetes que utilice un control de flujo de ventana deslizante y procedimientos de recuperación de errores basados en temporizadores de retransmisión. A título de ejemplo, la presente invención es totalmente aplicable al
35 Protocolo de Enlace de Radiocomunicaciones especificado en el ETSI, Radio Link Protocol for Data and Telemetric Services on the Mobile Station – Base Station System (MS-BSS) Interface and the Base Station System -Mobile Switching Center (BSSMSC) Interface, G. M. Especificación 04.22, Versión 3.7.0, febrero, 1992.
Las realizaciones ejemplificativas antes descritas están destinadas a ser
5 ilustrativas en todos los aspectos, en lugar de limitativas, de la presente invención. De este modo, la presente invención tiene capacidad de admitir muchas variaciones de implementación detallada que pueden ser deducidas, a partir de la descripción contenida en el presente documento, por un experto en la materia. Se considera que todas estas variaciones y modificaciones están dentro del alcance de la presente
10 invención según definen las reivindicaciones adjuntas.
Claims (14)
- REIVINDICACIONES1. Método de ejecución de una recuperación de errores basada en temporizadores de retransmisión en un nodo emisor de una red de comunicaciones que5 implementa conexiones del protocolo de control de transmisión TCP entre por lo menos un nodo emisor y por lo menos un nodo receptor utilizando un control de flujo de ventana deslizante, que comprende las etapas de:(a) recibir un segmento de acuse de recibo ACK desde el nodo receptor (330); y10 (b) reinicializar un temporizador de retransmisión REXMT asociado a una sesión entre el nodo emisor y el nodo receptor con un valor que compensa el tiempo transcurrido desde el tiempo de transmisión de un segmento transmitido previamente desde el emisor al receptor (310).
- 2. Método según la reivindicación 1, en el que la etapa (b) comprende:15 determinar un valor del temporizador de retransmisión RTO; y reinicializar el temporizador de retransmisión REXMT con un valor que se corresponde con el valor del temporizador de retransmisión RTO menos el tiempo transcurrido entre el tiempo de transmisión de un segmento transmitido previamente desde el nodo emisor al nodo receptor.20 3. Método según la reivindicación 2, en el que la etapa de determinar el valor del temporizador de retransmisión RTO incluye remitirse a una posición de memoria asociada al nodo emisor.
- 4. Método según la reivindicación 2, en el que la etapa de determinar el valor del temporizador de retransmisión RTO se25 ejecuta mediante un módulo lógico independiente que funciona sobre un procesador asociado al nodo emisor.
- 5. Método según la reivindicación 2, en el que: el valor del temporizador de retransmisión RTO se determina en función del tiempo de ida y vuelta RTT entre el nodo emisor y el nodo receptor.30 6. Método según la reivindicación 2, en el que: el valor del temporizador de retransmisión RTO se determina en función de la variación del tiempo de ida y vuelta RTT entre el nodo emisor y el nodo receptor.
- 7. Método según la reivindicación 2, en el que: 35 el valor del temporizador de retransmisión RTO se determina en función del tiempo requerido para que el nodo emisor reciba un número predeterminado de segmentos duplicados de acuse de recibo DUPACKS desde el nodo receptor.
- 8. Método según la reivindicación 2, en el que el valor del temporizador de retransmisión RTO incluye un componente que se5 determina en función del tiempo de ida y vuelta RTT entre el nodo emisor y el nodo receptor y de la variación del tiempo de ida y vuelta RTT entre el nodo emisor y el nodo receptor; y si el número de segmentos sin acuse de recibo transmitidos por el nodo emisor hacia el nodo receptor supera un número predeterminado, entonces el valor del10 temporizador de retransmisión RTO incluye un componente que se determina en función del tiempo requerido para recibir un número predeterminado de segmentos duplicados de acuse de recibo DUPACKS desde el nodo receptor.
- 9. Método según la reivindicación 1, que comprende además la etapa de:repetir la etapa (b) para cada segmento de acuse de recibo recibido desde el 15 nodo receptor.
- 10. Método según la reivindicación 1, en el que: el segmento transmitido previamente se corresponde con el segmento más antiguo almacenado temporalmente para su retransmisión desde el nodo emisor al nodo receptor.20 11. Método según una de las reivindicaciones anteriores, que comprende las etapas de:(a) abrir una conexión del protocolo de control de transmisión TCP entre el nodo emisor y un nodo receptor (300);(b) inicializar un temporizador de retransmisión REXMT con un valor de 25 temporizador de retransmisión RTO predeterminado (310);
- (c)
- transmitir segmentos de datos desde el nodo emisor al nodo receptor (320);
- (d)
- recibir segmentos de acuse de recibo ACK desde el nodo receptor (330); y
- (e)
- tras la recepción de cada segmento de acuse de recibo ACK desde el nodo receptor, reinicializar el temporizador de retransmisión REXMT con un valor
30 correspondiente al valor del temporizador de retransmisión RTO menos el tiempo transcurrido desde el tiempo de transmisión de un segmento transmitido previamente almacenado temporalmente en una memoria asociada al emisor, para su retransmisión hacia el receptor (310). - 12. Método de funcionamiento de una red de comunicaciones por conmutación de 35 paquetes que implementa conexiones lógicas entre nodos emisores y nodos receptores en la red, en donde nodos emisores se configuran para utilizar un control de flujo de ventana deslizante y una recuperación de errores basada en temporizadores de retransmisión, que comprende las etapas de:
- (a)
- establecer conexiones lógicas entre nodos emisores y nodos receptores 5 respectivos en la red;
(b) inicializar, para una conexión lógica, un temporizador de retransmisión con un valor de temporizador de retransmisión que es una función de parámetros del tráfico de la red;- (c)
- transmitir paquetes de datos desde nodos emisores a nodos receptores 10 respectivos en la red;
- (d)
- recibir, en los nodos emisores, paquetes de acuse de recibo desde sus nodos receptores respectivos; y
- (e)
- tras la recepción de un paquete de acuse de recibo, reinicializar el temporizador de retransmisión asociado a la conexión entre el emisor y el
15 receptor con un valor correspondiente al valor del temporizador de retransmisión menos el tiempo transcurrido desde el tiempo de transmisión de un paquete transmitido previamente almacenado temporalmente en una memoria asociada al emisor, para su retransmisión hacia el receptor. - 13. Método según la reivindicación 12, en el que:20 el paquete transmitido previamente se corresponde con el paquete más antiguo almacenado temporalmente para su retransmisión desde un nodo emisor a un nodo receptor.
- 14. Método según la reivindicación 12, en el que: la etapa de determinar el valor del temporizador de retransmisión RTO se25 ejecuta mediante un módulo lógico independiente que funciona sobre un procesador asociado a un nodo emisor.
- 15. Método según la reivindicación 12, en el que el valor del temporizador de retransmisión incluye un componente que se determina en función del tiempo de ida y vuelta entre el nodo emisor y el nodo30 receptor y de la variación del tiempo de ida y vuelta entre el nodo emisor y el nodo receptor; y si el número de segmentos sin acuse de recibo transmitidos por el nodo emisor hacia el nodo receptor supera un número predeterminado, entonces el valor del temporizador de retransmisión incluye un componente que se determina en35 función del tiempo requerido para recibir un número predeterminado de paquetes
- duplicados de acuse de recibo desde el nodo receptor.
-
- 16.
- Elemento de red de comunicaciones que implementa conexiones del protocolo
- de control de transmisión TCP entre por lo menos un nodo emisor y por lo menos
- un nodo receptor utilizando un control de flujo de ventana deslizante y una
- 5
- recuperación de errores basada en temporizadores de retransmisión REXMT,
- que comprende:
- (a) un módulo de salida para transmitir segmentos de datos a un nodo receptor
- (320);
- (b) un módulo de entrada para recibir segmentos de acuse de recibo ACK
- 10
- desde el nodo receptor (330); y
- (c) un módulo lógico, que funciona sobre un procesador asociado al elemento
- de red, para reinicializar el temporizador de retransmisión REXMT con un valor
- que compensa el tiempo transcurrido desde el tiempo de transmisión de un
- segmento transmitido previamente desde el emisor al receptor (310).
- 15
- 17. Red de comunicaciones que implementa conexiones del protocolo de control de
- transmisión TCP entre por lo menos un nodo emisor y por lo menos un nodo
- receptor utilizando un control de flujo de ventana deslizante y una recuperación
- de errores basada en temporizadores de retransmisión, que comprende:
- (a) medios para abrir una conexión del protocolo de control de transmisión TCP
- 20
- entre el nodo emisor y un nodo receptor;
- (b) medios para inicializar un temporizador de retransmisión REXMT con un
- valor de temporizador de retransmisión RTO predeterminado;
- (c) medios para transmitir segmentos de datos desde el nodo emisor al nodo
- receptor;
- 25
- (d) medios para recibir segmentos de acuse de recibo ACK desde el nodo
- receptor; y
- (e) medios para reinicializar el temporizador de retransmisión REXMT con un
- valor correspondiente al valor del temporizador de retransmisión RTO menos el
- tiempo transcurrido desde el tiempo de transmisión de un segmento transmitido
- 30
- previamente almacenado temporalmente en una memoria asociada al emisor,
- para su retransmisión hacia el receptor.
-
- 18.
- Red de comunicaciones por conmutación de paquetes que implementa
- conexiones lógicas entre nodos emisores y nodos receptores en la red, en donde
- nodos emisores están configurados para utilizar un control de flujo de ventana
- 35
- deslizante y una recuperación de errores basada en temporizadores de
retransmisión, que comprende:- (a)
- medios para establecer conexiones lógicas entre nodos emisores y nodos receptores respectivos en la red;
- (b)
- medios para inicializar, para una conexión lógica, un temporizador de
5 retransmisión con un valor de temporizador de retransmisión que es una función de parámetros del tráfico de la red;(c) medios para transmitir paquetes de datos desde nodos emisores a nodos receptores respectivos en la red;(d) medios para recibir, en los nodos emisores, paquetes de acuse de recibo 10 desde sus nodos receptores respectivos; y(e) medios para reinicializar el temporizador de retransmisión asociado a la conexión entre el emisor y el receptor con un valor correspondiente al valor del temporizador de retransmisión menos el tiempo transcurrido desde el tiempo de transmisión de un segmento transmitido previamente almacenado15 temporalmente en una memoria asociada al emisor, para su retransmisión hacia el receptor.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12108699P | 1999-02-22 | 1999-02-22 | |
US121086P | 1999-02-22 | ||
US326952 | 1999-06-07 |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2349189T3 true ES2349189T3 (es) | 2010-12-28 |
Family
ID=43415169
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES00905060T Expired - Lifetime ES2349189T3 (es) | 1999-02-22 | 2000-02-12 | Sistema y método para transferencia de datos mejorada en redes de comunicación por conmutación de paquetes. |
Country Status (1)
Country | Link |
---|---|
ES (1) | ES2349189T3 (es) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110213024A (zh) * | 2018-04-26 | 2019-09-06 | 腾讯科技(深圳)有限公司 | 数据包重传方法、装置及设备 |
-
2000
- 2000-02-12 ES ES00905060T patent/ES2349189T3/es not_active Expired - Lifetime
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110213024A (zh) * | 2018-04-26 | 2019-09-06 | 腾讯科技(深圳)有限公司 | 数据包重传方法、装置及设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6611495B1 (en) | System and method for improved data transfer in packet-switched communication networks | |
US11876714B2 (en) | Method and apparatus for network congestion control based on transmission rate gradients | |
EP1070407B1 (en) | Method and device for data flow control | |
US7061856B2 (en) | Data throughput over lossy communication links | |
EP1230757B1 (en) | Link layer acknowledgement and retransmission for cellular telecommunications | |
EP1421500A1 (en) | Systems and methods for high speed data transmission using tcp/ip | |
US20070223529A1 (en) | Methods and apparatus for estimating bandwidth of a data network | |
US20060209838A1 (en) | Method and system for estimating average bandwidth in a communication network based on transmission control protocol | |
US20040264370A1 (en) | Congestion control method and system for reducing a retransmission timeout count in a transmission control protocol | |
Jarvinen et al. | FASOR retransmission timeout and congestion control mechanism for CoAP | |
US20120106344A1 (en) | Data communication acknowledgement in a network | |
CN101141393B (zh) | 通信终端、通信控制方法 | |
JP2008104018A (ja) | 通信システム、通信装置、及び送信制御方法 | |
ES2349189T3 (es) | Sistema y método para transferencia de datos mejorada en redes de comunicación por conmutación de paquetes. | |
KR100568232B1 (ko) | 모바일 애드 혹 네트워크에서 전송층을 이용한 효율적인데이터 송수신 방법 및 상기 방법을 이용한 네트워크 장치 | |
AU4034299A (en) | Overload control method for a packet-switched network | |
KR101231793B1 (ko) | Tcp 세션 최적화 방법 및 네트워크 노드 | |
Kabir et al. | Study of Different TCP Protocols in Wireless Network | |
KR20080042764A (ko) | 데이터 네트워크의 대역폭 추정 방법 및 네트워크 노드 |