MX2008010122A - Sistemas y metodos para mejorar el desempeño de los protocolos de transporte. - Google Patents

Abstract

Se dan a conocer sistemas y métodos para mejorar el desempeño de los protocolos de transporte. Un método ejemplar incluye: en un primer estado, incrementar de manera no lineal una ventana de congestión; en respuesta a la ventana de congestión que excede un valor de umbral mientras está en el primer estado, transitar a un segundo estado; y, en el segundo estado, incrementar de manera lineal la ventana de congestión.

Description

SISTEMAS Y MÉTODOS PARA MEJORAR EL DESEMPEÑO DE LOS PROTOCOLOS DE TRANSPORTE CAMPO DE LA INVENCIÓN La presente descripción se relaciona con protocolos de comunicación y, más específicamente, con protocolos de capa de transporte.

ANTECEDENTES DE LA INVENCIÓN El protocolo de transporte conocido como Protocolo de Control de Transmisión (TCP) se ha desempeñado bien durante las dos décadas pasadas como el protocolo de transporte de facto para la entrega confiable de datos a través de la Internet. Aunque los algoritmos usados por el TCP se diseñaron para promover estabilidad, confiabilidad e imparcialidad en la Internet, estos mismos algoritmos conducen a un desempeño reducido del TCP en presencia de ciertas condiciones a lo largo de la ruta extremo a extremo entre los sistemas de comunicación. Estas características, que incluyen gran ancho de banda, demora extensa y/o tasa significativa de pérdida, se están volviendo más comunes en la Internet de la actualidad. Aunque los algoritmos básicos usados por el TCP se han modificado a lo largo de los años, es improbable un cambio significativo a estos algoritmos, puesto que está presente esta gran base instalada de sistemas, los cuales usan el TCP. Por lo tanto, existe una necesidad de que se aborden estos y otros problemas.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Muchos aspectos de la descripción pueden entenderse mejor con referencia a los siguientes dibujos. Los componentes en los dibujos no están necesariamente a escala, en lugar de ello, se pone énfasis en ilustrar claramente los principios de la presente descripción. La FIGURA 1 es un diagrama de bloques de un ambiente en el cual se localiza una modalidad de un sistema y método para mejorar el desempeño de los protocolos de transporte. La FIGURA 2 es un diagrama de bloques de un ambiente en el cual se localiza otra modalidad de un sistema y método para mejorar el desempeño de los protocolos de transporte.

La FIGURA 3 es un diagrama de bloques' de la lógica para mejorar el desempeño de los protocolos de transporte 160 de la FIGURA 1 , en donde a es PERIODICIDADES, b es DATOS DE TCP, c es ACK, d es CONTROL, e es DATOS EXTENDIDOS, f es ACK EXTENDIDO, g es SALUDO INICIAL DE CONEXIÓN TCP. La FIGURA 4 es un diagrama de flujo de datos que muestra el procesamiento de paquetes por la lógica para mejorar el desempeño de los protocolos de transporte 160 de las FIGURAS 1 y 3, en donde a es OTRO, b es TCP, c es NO, d es Sí, e es DATOS, f es ACK, g es RST, h es SYN, i es SYNACK, j es FIN, k es TIPO DE PAQUETE, I es CONTROL, m es PROTOCOLO EXTENDIDO, n es PUENTE, ñ es DESCARTAR PAQUETE. La FIGURA 5 es un diagrama de flujo que muestra el procesamiento de una confirmación recibida por el terminador de conexión 350 de la FIGURA 3, en donde a es MIENTRAS ESTÁ EN VUELO CONTAR < BUFFER DE ENVÍO SOBRESALIENTE PERMITIDO Y NO VACÍO. La FIGURA 6 es un diagrama de flujo que muestra el procesamiento de un paquete de TCP por el terminador de conexión 350 de la FIGURA 3, en donde a es SÍ, b es NO, c es VACÍO, d es NO VACÍO, é es TERMINADO. Las FIGURAS 7A y 7B son diagramas de flujo que muestran el procesamiento de los datos de transporte extendido, control o paquete de confirmación por el núcleo 370 de la FIGURA 3, en donde, en la FIGURA 7A, a es SIN DATOS, b es DATOS, c es Sí, d es NO, e es NO VACÍO, f es VACÍO, g es TERMINADO; en la FIGURA 7B, a es OTRO, b es ACK, c es SÍ, d es NO, e es TERMINADO. La FIGURA 8 es un diagrama de flujo que muestra el procesamiento de un paquete recibido por el administrador de conexión virtual 380 de la FIGURA 3, en donde a es DATOS, b es ACK, c es Sí, d es NO, e es VACÍO, f es NO VACÍO, g es TERMINADO. La FIGURA 9 es un diagrama de flujo de un mecanismo de control de flujo usado por algunas modalidades de la lógica 160 de la FIGURA 3. La FIGURA 10 es un diagrama de estados de un mecanismo de control de congestión usado por algunas modalidades de la lógica 160 de la FIGURA 3, en donde a es INCREMENTAR LA VENTANA DE MANERA LINEAL, b es VENTANA CONSTANTE. La FIGURA 11 es un diagrama de bloques de una computadora para propósitos generales que puede usarse para implementar los sistemas y métodos para mejorar el desempeño de los protocolos de transporte dados a conocer en este documento.

SUMARIO DE LA INVENCIÓN Se dan a conocer sistemas y métodos para mejorar el desempeño de los protocolos de transporte. Un método ejemplar incluye: en un primer estado, incrementar de manera no lineal una ventana de congestión; en respuesta a la ventana de congestión que excede un valor de umbral mientras está en el primer estado, transitar a un segundo estado; y, en el segundo estado, incrementar de manera lineal la ventana de congestión.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La FIGURA 1 es un diagrama de bloques de un ambiente en el cual se localiza una modalidad de un sistema y método para mejorar el desempeño de los protocolos de transporte. Los dispositivos de punto final 110 usan un protocolo de capa de transporte (capa 4) 120 y se comunican entre sí a través de una red 130. Aunque esta descripción discute el TCP como un protocolo de capa de transporte ejemplar, una persona experimentada en la técnica deberá reconocer que los principios dados a conocer en este documento, para mejorar el desempeño de los protocolos de transporte, también se aplican a otros protocolos de capa de transporte. Los enrütadores 140 transportan tráfico de un lado a otro de la red 130, lo cual puede implicar el uso de un protocolo de capa de red (capa 3), tal como el Protocolo de Internet (IP). Aunque el término "enrutador" se usa en este documento, una persona experimentada en la técnica deberá reconocer que el enrutador 140 puede tomar la forma de un conmutador de capa 3 en lugar de ello. Los dispositivos de red 150 se localizan (en forma lógica) entre los puntos finales 110 y enrütadores 140. Cada dispositivo de red 150 incluye lógica para mejorar el desempeño de los protocolos de transporte 160, lo cual permite que un dispositivo de red 150 se comunique con un dispositivo de red entre iguales 150 usando un protocolo de transporte extendido 165. De esta manera, un par de puntos finales 110 se comunica entre si a través de un par de dispositivos de red 150. Aunque un dispositivo de red 150 aparece entre un punto final 110 y un enrutador 140 en la FIGURA 1 , esto es una representación lógica en lugar de una física, lo que indica meramente que los paquetes pasan a través del dispositivo de red 150. Como se explicará posteriormente, algunas modalidades del dispositivo de red 150 no se colocan realmente en línea entre un punto final 110 y un enrutador 140 sino, en lugar de ello, operan como un enrutador de contención de dispositivos fuera de línea 140. Algunas modalidades de un dispositivo de red 150 incluyen una interfaz de red de punto final 170 y una interfaz de red de iguales 175, donde la interfaz de red de punto final 170 se acopla a un punto final 110 a través de un enlace 180 y la interfaz de red de iguales 175 se acopla a un enrutador 140 a través de ún enlace 185. Otras modalidades de un dispositivo de red 150 incluyen una sola interfaz de red acoplada al enrutador 140. (Una sola modalidad de interfaz puede usarse "fuera de línea" en lugar de en línea, como se describirá posteriormente. • En algunas modalidades, los enlaces en la red 130 exhiben características de desempeño diferentes a los enlaces a los puntos finales 110. Por ejemplo, los enlaces a los puntos finales 1 10 pueden proporcionar una conexión alámbrica de velocidad relativamente alta (por ejemplo, Ethernet de 100 Mbit) mientras los enlaces en la red 130 pueden proporcionar una conexión alámbrica o inalámbrica de velocidad inferior (por ejemplo, T1 , WiFi). El protocolo de transporte extendido 165 se diseña para las características de desempeño de los enlaces entre los dispositivos de red 150. En algunas modalidades del dispositivo de red 150, el protocolo de transporte extendido 165 es diferente al protocolo de transporte 120 usado por los puntos finales 110: el protocolo usado entre un punto final 110 y su dispositivo de red correspondiente 150 es el protocolo de transporte original .120; el protocolo usado entre los dispositivos de red de iguales 150 es el protocolo de transporte extendido 165. En tales modalidades, el dispositivo de red 150 actúa como un proxy de transporte para un punto final 110. En algunas modalidades proxy, el punto final 110 desconoce que el punto final 110 está usando un protocolo de transporte diferente, en cuyo caso el dispositivo de red 150 es un proxy de transporte transparente para un punto final 110.

Como se describirá en mayor detalle posteriormente, el dispositivo de red 150 mantiene la transparencia al responder a paquetes enviados por los puntos finales de TCP en tal forma que los puntos finales sepan sólo del proxy como el otro punto final de comunicación y no del receptor real. El término "paquetes de transporte extendido" se usará en lo sucesivo cuando se haga referencia a paquetes usados por el protocolo de transporte extendido 165. Una persona experimentada en la técnica deberá reconocer que tal protocolo incluye típicamente paquetes que llevan datos (paquetes de datos), paquetes que confirman datos (paquetes de confirmación) y paquetes de control que se usan para establecer conexiones de caída. De esta manera, se hará referencia en este documento a "paquetes de datos de transporte extendido" y "paquetes de confirmación de transporte extendido" y "paquetes de control de transporte extendido". Estos paquetes corresponden, pero son diferentes a, el protocolo de transporte original. Por ejemplo, un paquete de Datos de TCP y un paquete de datos de transporte extendido llevan datos, pero el paquete de Datos de TCP se origina de o se suministra a un punto final de TCP 110 mientras el paquete de datos de transporte extendido se transporta entre los pares del proxy de transporte 150. En algunas modalidades, los paquetes de transporte extendido se forman al agregar campos trailer a los paquetes del protocolo de transporte original. Por ejemplo, un paquete de datos de TCP se traslada a un paquete de datos de transporte extendido al anexar un campo "tipo de protocolo" de "datos de transporte extendido", mientras un paquete de control de TCP se traslada a un paquete de control de transporte extendido al anexar un campo "tipo de protocolo" de "control de transporte extendido". Esto puede considerarse una forma de encapsulación, pero tiene la ventaja de ser transparente para los puntos finales. En algunos casos, un paquete de transporte extendido se transporta solo, sin encapsulación. En estos casos, el campo Tipo de Protocolo en el encabezado de IP puede ajustarse a un valor especial que indica la presencia del protocolo de transporte extendido. Es decir, el protocolo de transporte extendido 165 se visualiza por la capa de IP, o red, como un tipo de protocolo como TCP o UDP. Una persona experimentada en la técnica deberá apreciar que la lógica para mejorar el desempeño de los protocolos de transporte 160 puede ejemplificarse en varias formas diferentes. Un ejemplo implementa la lógica 160 en un dispositivo independiente 150 que se sitúa entre el dispositivo final de comunicación de TCP y el enrutador de acceso 140. Otra ejemplificación de la lógica 1,60 está dentro del punto final 110, por ejemplo, como un controlador de núcleo que se sitúa entre la capa TCP e IP de la pila de protocolos de núcleo. Todavía como otro ejemplo, la lógica para mejorar el desempeño de los protocolos de transporte 160 puede reemplazar el TCP como una capa de transporte en la pila de protocolos del punto final 1 10. Aunque solamente el dispositivo de red independiente 150 se discute en este documento, todas las ejemplificaciones semejantes pretenden estar dentro del alcance de esta descripción. La FIGURA 2 es un diagrama de bloques de un ambiente én el cual se localiza otra modalidad de un sistema y método para mejorar el desempeño de los protocolos de transporte. En este ambiente, un par de puntos finales 110 puede incluir conexiones múltiples 210, 220, 230 entre los pares. Cada una de estas conexiones (210-230) pasa a través del dispositivo mejorado de red 150A y 150B. En esta modalidad, el dispositivo de red 150 decide, sobre una base conexión por conexión, si se usa el protocolo de transporte extendido 165 o el protocolo de transporte original 120 para la operación de la conexión entre los dispositivos de red 150. En el ejemplo de la FIGURA 2, las conexiones 210 y 220 usan el protocolo de transporte extendido 165 para la operación media, y la conexión 230 usa el protocolo de transporte original 120. En algunas modalidades, un usuario (por ejemplo, un administrador de sistemas) decide qué conexiones usarán cuál protocolo de transporte, y configura el dispositivo de red 150 por consiguiente. Varios ejemplos de configuración son: todas las conexiones a partir de un punto final particular 110 usan el protocolo de transporte extendido 165; ningunas conexiones a partir de un punto final particular 110 usan el protocolo de transporte extendido 165; aquellas conexiones a partir de un punto final particular 110, identificadas por una combinación especifica de campos de encabezado, usan el protocolo de transporte extendido 165; aquellas conexiones a partir de un punto final particular 110 no identificadas por una combinación específica de campos de encabezado no usan el protocolo de transporte extendido 165. Una persona experimentada en la técnica deberá reconocer que estos son meramente ejemplos, y que muchas otras técnicas para determinar qué conexiones usan el protocolo de transporte extendido 165 también son posibles. La FIGURA 3 es un diagrama de bloques de la lógica para mejorar el desempeño de los protocolos de transporte 160 de la FIGURA 1. Un administrador de conexión 310 establece conexiones a otros dispositivos de red 150 en la red, y mantiene información de estado general acerca de otros dispositivos de red 150. El administrador de conexión 310 puede descubrir la presencia de, y las direcciones de otros dispositivos de red 150 a través de una base de datos de configuración (local o centralizada), o a través de un proceso de aprendizaje dinámico, o a través de cualquier otro mecanismo apropiado conocido por una persona experimentada en la técnica. Una vez que se descubre un dispositivo de iguales 150, el administrador de conexión 310 monitorea buscando fallas de un dispositivo de iguales 150. Si se descubre una falla, el administrador de conexión 310 notifica a otros componentes en la lógica para mejorar el desempeño de los protocolos de transporte 160 alrededor de la falla. Cada componente toma la acción apropiada en respuesta a la falla.de iguales. En algunas modalidades, el reconocimiento de la falla de iguales se consigue a través de una señal periódica entre los dispositivos de red de iguales 150. El componente de administrador de conexión 310 transmite la señal periódica de su dispositivo 150, y también monitorea la periodicidad de otros dispositivos de iguales 150. La ausencia de una periodicidad entonces significa falla de un dispositivo de iguales 150. Un administrador de configuración y monitoreo 320 permite que la operación del dispositivo de red 150 se sincronice. El administrador de configuración y monitoreo 320 también monitorea las características de desempeño del dispositivo de red 150. En algunas modalidades, el administrador de configuración y monitoreo 320 también monitorea las características de desempeño del tráfico del punto final que fluye a través del dispositivo 150. Un clasificador de tráfico 330 clasifica el tráfico de red que entra al dispositivo de red 150. La clasificación se basa en un N-tuplo formado por los encabezados en el empacador entrante. En algunas modalidades, el N-tuplo es el 4-tuplo que comprende la dirección IP del emisor, dirección IP de destino, puerto TCP del emisor y puerto TCP de destino. El clasificador de tráfico 330 también realiza una inspección profunda de los paquetes con el fin de identificar paquetes especiales de control de conexión (por ejemplo, SYN, ACK, FIN, etc.). El clasificador de tráfico 330 entonces notifica a otros componentes lógicos de estos paquetes de control. Después de clasificar, el clasificador de tráfico 330 decide dirigir el paquete ya sea a través de otros componentes en la lógica 160, o a través de la ruta predeterminada de reenvío." Esta decisión se hace en consulta con el administrador de configuración y monitoreo 320 (descrito posteriormente), el cual mantiene información acerca de las preferencias para perfeccionamiento del protocolo (por ejemplo, qué conexiones se aplican a los perfeccionamientos, y qué conexiones usan el protocolo convencional). El administrador de estado 340 mantiene el estado alrededor de aquellas conexiones de TCP a las cuales se aplican los perfeccionamientos. El administrador de estado 340 aprende acerca de la configuración y caída de las conexiones de TCP a partir de los datos de inspección profunda proporcionados por el clasificador de tráfico 330. En algunas modalidades, las conexiones se dividen y mezclan o se indexan con base en el N-tuplo en los paquetes de control de conexión, lo cual facilita búsquedas más rápidas de conexión y la identificación de paquetes. El administrador de estado 340 también mantiene información acerca de conexiones activas que han enviado/recibido paquetes de manera consistente y aquellas que han permanecido desocupadas. Esta distinción ayuda a lograr imparcialidad entre las diferentes conexiones de TCP y permite que la lógica 160 penalice conexiones que han obtenido más de su participación equitativa de la capacidad. El terminador de conexión 350 actúa como el destino y fuente, respectivamente, para la fuente y destino de las conexiones de TCP de punto final. Por lo tanto, el terminador de conexión 350 incluye la funcionalidad de un punto final de TCP, tal como administración de conexión, secuenciación de paquetes, control de congestión, control de flujo, transmisiones de confirmación, procesamiento de recepción de confirmación, detección de pérdidas y recuperación de pérdidas. El terminador de conexión 350 también actúa como un adaptador entre el protocolo de transporte extendido 165 y el protocolo de transporte original 120, propagando las decisiones al emisor o receptor de TCP en forma entendible por estos puntos finales 110. Por ejemplo, cuando la lógica 160 toma una decisión de control de flujo "no se transmitirán más datos", el terminador de conexión 350 lleva esta decisión al punto final de emisor de TCP 110 a través de un tamaño de ventana anunciada de cero. El terminador de conexión 350 también mantiene y administra buffers de datos para manejar el suministro fuera de orden, pérdidas de paquetes, retransmisiones de paquetes, etc. El administrador de transparencia 360 trabaja con el administrador de estado 340 para garantizar que los parámetros negociados entre los dos sistemas finales de TCP (por ejemplo, unidad de transmisión máxima, la disponibilidad de la característica de confirmación selectiva, etc.) son consistentes con aquellos requeridos por la lógica 160. Como se describe anteriormente, el clasificador de tráfico 330 realiza una inspección profunda de paquetes y examina paquetes de control de TCP (por ejemplo, SYN, ACK, FIN). El administrador de transparencia 360 se notifica de los parámetros usados en estos paquetes de control SYN y SYN-ACK. Si los parámetros predeterminados originales en sí mismos son compatibles con los requerimientos de la lógica 160, tales parámetros se dejan completamente tal como están. Sin embargo, cuando los parámetros predeterminados no son compatibles, el administrador de transparencia 360 modifica los paquetes de control de conexión para usar los parámetros alternos. El núcleo 370 suministra datos entre los dispositivos de red de iguales 150, implementando el protocolo de transporte extendido 165. Varias características del protocolo de transporte extendido 165 se describirán posteriormente. En modalidades de proxy de transporte transparente, los dispositivos de red 150 realizan sus operaciones con base en la adición y procesamiento de trailers que se agregan a los paquetes recibidos de los puntos finales de TCP. De esta manera, los paquetes que fluyen entre dos dispositivos de red 150 son similares a los paquetes enviados por los puntos finales comunicantes originales. Puesto que los componentes existentes de red usan encabezados para identificar y procesar paquetes, esta característica inventiva (junto con la funcionalidad de puente descrita anteriormente) permite que el protocolo de transporte extendido 165 sea transparente para otros componentes de red. Finalmente, el administrador de conexión virtual 380 mapea conexiones de TCP a conexiones virtuales múltiples entre los dispositivos de iguales 150 y agrega estas conexiones virtuales. Las conexiones virtuales agregadas, las cuales forman una ruta virtual extremo a extremo, se refieren en este documento como "tuberías." Un ejemplo de tal implementación se describe en U.S. No. de Serie 11/063,284, titulada "Sistemas y Métodos para Comunicación Paralela", la cual se incorpora en su totalidad para referencia en este documento. En algunas de estas modalidades, el número de conexiones virtuales es configurable y puede elegirse dinámicamente por la lógica 160. La FIGURA 3 muestra que los paquetes se hacen pasar de un componente a otro para procesamiento. En algunas modalidades, se usa una técnica de copia cero que incrementa la eficiencia del uso de memoria. El procesamiento de paquetes de copia cero usa un campo NumReferences en la representación interna de paquetes para rastrear el número de componentes que tienen acceso al paquete. En cualquier momento que un componente procesa un paquete, este incrementa el campo NumReferences. Cuando el componente termina con el procesamiento, este disminuye el valor num_references. Esto evita la necesidad de una copia cuando se hacen pasar paquetes entre componentes. La FIGURA 4 es un diagrama de flujo de datos que muestra el procesamiento de paquetes por la lógica para mejorar el desempeño de los protocolos de transporte 160 de las FIGURAS 1 y 3. El procesamiento de paquetes entrantes comienza con el clasificador de tráfico 330, el cual usa la dirección IP de fuente, dirección IP de destino y campos de encabezado de protocolo para clasificar (410) el paquete. Si el campo de tipo de protocolo indica que el paquete no es un paquete de TCP ni un paquete de transporte extendido, entonces el paquete se reenvía, sin modificación, a un puente lógico de capa 2 420, el cual transmite el paquete. Como debe entenderse por upa persona experimentada en la técnica, el puente 420 tiene una sola dirección IP y acopla la interfaz de red de punto final 170 e interfaz de red de iguales 175 al mantener una tabla de mapeos entre direcciones de capa 3 (IP) y direcciones de capa 2 (MAC). Cuando se da un paquete para transmisión, el puente 420 examina la dirección de capa 3 en el paquete y determina qué interfaz transmitir (interfaz de red de punto final 170 e interfaz de red de iguales 175), con base en la tabla de direcciones. Por lo tanto, en la discusión posteriormente, se hará referencia a transmitir, enviar o reenviar un paquete, sin especificar cuál interfaz. Operar como un puente permite que el dispositivo de red 150, incluyendo la lógica para mejorar el desempeño de los protocolos de transporte 160, realice intercepción y procesamiento de paquetes sin requerir un cambio a las tablas de enrutamiento en los puntos finales de TCP 110. La operación de puente también permite que el dispositivo de red 150 opere como un dispositivo fuera de linea, ubicado fuera del enrutador 140, en lugar de en línea entre los puntos finales de TCP 1 0 y el enrutador 140. Si el paquete se clasifica (410) por el clasificador de tráfico 330 como un paquete de TCP, entonces el paquete se proporciona al administrador de estado 340. El administrador de estado 340 determina (430) el tipo del paquete de TCP. Si el paquete de TCP es un paquete de configuración de conexión (por ejemplo, SYN o SYNACK), entonces el administrador de estado 340 crea o actualiza el estado de conexión, respectivamente, y transfiere el paquete al administrador de transparencia 360. Como se describe anteriormente, el administrador de transparencia 360 examina las opciones de conexión durante la configuración, a medida que se transporta en los paquetes TCP SYN y TCP SYNACK, y modifica estas opciones según sea necesario para garantizar la compatibilidad con el protocolo de transporte extendido 165. El administrador de transparencia 360 entonces reenvía el paquete de control de TCP. Si el administrador de estado 340 determina (430) que el paquete de TCP es un paquete RST, entonces el administrador de estado 340 determina (440) si existe la conexión (por ejemplo,, al consultar una tabla de división y mezcla de conexiones). Si existe la conexión, entonces la conexión se elimina por el administrador de estado 340 y el paquete de control de TCP se reenvía. Regresando a la determinación 430 por el administrador de estado 340, si el paquete es un paquete FIN y la conexión existe, entonces el estado de conexión se actualiza. Si un FIN también se ha recibido por el punto final local, entonces la conexión se elimina. En cualquier caso, el administrador de estado 340 solicita que el terminador de conexión 350 envíe el paquete TCP FIN, y entonces reenvía el paquete TCP FIN. Regresando nuevamente a la determinación 430 por el administrador de estado 340, si el paquete de TCP es un paquete de datos ACK o uno TCP, entonces el administrador de estado 340 determina si existe la conexión (por ejemplo, al consultar una tabla de división y mezcla de conexiones). Si la conexión no existe, entonces el administrador de estado 340 reenvía el paquete de TCP. Si la conexión existe, entonces el administrador de estado 340 actualiza la información de estado y transfiere el paquete al terminador de conexión 350. Después de recibir el paquete de TCP del administrador de estado 340, el terminador de conexión 350 clasifica (450) el paquete de TCP. Si el paquete de TCP es un ACK, el terminador de conexión 350 realiza la reparación y mantenimiento apropiados como se indica por el recibo de la confirmación, y descarta o consume el ACK. La reparación y mantenimiento realizados por el terminador de conexión 350 se describirán ahora en relación con el diagrama de flujo de la FIGURA 5. El terminador de conexión 350 comienza a procesar la confirmación en el bloque 510, donde los paquetes confirmados se remueven del buffer de envío de TCP. Después, en el bloque 520, el número en secuencia se actualiza para reflejar la confirmación. Entonces el conteo de paquetes en vuelo se actualiza en el bloque 530. El procesamiento continúa en el bloque 540, donde los paquetes sobresalientes máximos permitidos se actualizan. Finalmente, el bloque 550 se ejecuta en un circuito de iteraciones mientras el conteo en vuelo es menor a los paquetes sobresalientes máximos permitidos, donde 550 envía el siguiente paquete en el buffer de envío de TCP. Regresando ahora a la clasificación (450) por el terminador de conexión 350 en la FIGURA 4, si el paquete de TCP es datos en lugar de un paquete de control, entonces el terminador de conexión 350 procesa el paquete adicionalmente. Este procesamiento de paquetes de datos de TCP por el terminador de conexión 350 se describirá ahora en relación con el diagrama de flujo de la FIGURA 6. El terminador de conexión 350 comienza a procesar un paquete en el bloque 610, el cual compara el tamaño de buffer del componente de núcleo (370) con un umbral. Si el tamaño de buffer cumple con el umbral, entonces el bloque 620 envía un DUPACK para el siguiente paquete en secuencia. Después, el paquete se descarta (bloque 630) y el procesamiento del paquete se termina. Si el tamaño de buffer del componente de núcleo no cumple con el umbral, entonces el procesamiento continúa en el bloque 640. El bloque 640 determina si el paquete recibido es el siguiente paquete en secuencia. Si No, entonces en el bloque 645 el paquete recibido se inserta en el buffer de recibo de TCP, el bloque 650 envía un DUPACK para el siguiente paquete en secuencia y el procesamiento de este paquete se termina. Por otro lado, si el bloque 640 determina que el paquete recibido es el siguiente paquete en secuencia, entonces el procesamiento continúa en el bloque 655.

El bloque 655 actualiza el estado de conexión. Después, en el bloque 660, el componente de núcleo 370 se insta a enviar el paquete. El procesamiento continúa en el bloque 665, el cual determina si el buffer de recibo de TCP está vacío. Si está vacío, entonces el bloque 670 envía una confirmación por el paquete recibido y el procesamiento del paquete se termina. Si el buffer de recibo de TCP no está vacío, entonces el bloque 675 notifica al componente de núcleo 370 que todos los paquetes en secuencia en el buffer están listos para procesamiento de transmisión. Después, el bloque 680 envía una confirmación por todos los paquetes en secuencia que justo se procesaron por el bloque 675. El procesamiento del paquete de TCP recibido se termina ahora. El procesamiento de paquetes de TCP por la lógica 160 se ha descrito en conjunción con el diagrama principal de flujo de datos de la FIGURA 4, junto con los diagramas de flujo de las FIGURAS 5 y 6. Regresando ahora al diagrama principal de flujo de datos de la FIGURA 4, si el paquete se clasifica (410) como un paquete de transporte extendido en lugar de un paquete de TCP, entonces el paquete se proporciona al núcleo 370. El núcleo 370 determina (460) si el paquete es un paquete de datos de transporte extendido (470) o un paquete de control o confirmación de transporte extendido (480). El procesamiento posterior del paquete de datos de transporte extendido, control o confirmación por el núcleo 370 se describirá ahora en relación con el diagrama de flujo de la FIGURA 7. El procesamiento del paquete recibido de transporte extendido por el núcleo 370 comienza en el bloque 710, el cual determina si el paquete recibido es datos de transporte extendido. Si No, entonces el procesamiento continúa en el bloque 765 (FIGURA 7B), el cual se discutirá posteriormente. Si el paquete recibido es datos de transporte extendido, entonces el procesamiento continúa en el bloque 715, el cual determina si el paquete recibido de datos es el siguiente paquete en secuencia. Si No, entonces el procesamiento continúa en el bloque 720, donde el paquete se almacena en el buffer de recibo. Después, el bloque 725 envía un DUPACK para el siguiente paquete en secuencia. El procesamiento del paquete de datos de transporte extendido entonces se termina.

Regresando al bloque 715, si se determina que el paquete recibido de datos no es el siguiente paquete en secuencia, entonces el bloque 730 desencapsula el paquete de TCP del paquete de datos de transporte extendido, y el paquete de TCP se transfiere en el bloque 735 al componente de terminador de conexión 350 para su procesamiento posterior. Después del procesamiento del terminador de conexión, el buffer de recibo del componente de núcleo se verifica en el bloque 740. Si el buffer de recibo está vacío, entonces el procesamiento continúa en el bloque 745, donde se envía una confirmación por el paquete recibido de datos de transporte extendido y el procesamiento del paquete recibido de datos de transporte extendido se termina. Sin embargo, si el buffer de recibo del componente de núcleo no está vacío, entonces el bloque 750 maneja el buffer de recibo al desencapsular los paquetes de TCP contenidos dentro de los paquetes en secuencia de datos de transporte extendido en el buffer de recibo. Después, en el bloque 755, los paquetes de TCP se transfieren al componente de terminador de conexión 350 para su procesamiento posterior. Después del procesamiento del terminador de conexión, el bloque 760 envía confirmaciones por todos los paquetes en secuencia procesados en el buffer de recibo del núcleo y el procesamiento se termina. Regresando al bloque 710, si el paquete recibido no es un paquete de datos de transporte extendido, el paquete se clasifica además en el bloque 765 (FIGURA 7B). Si el paquete no es una confirmación (por ejemplo, un SYN, SYNACK, RESET o Heartbeat de transporte extendido), entonces el paquete se hace pasar en el bloque 770 al componente de administrador de conexión 310 para su procesamiento posterior. Por otro lado, si el paquete es una confirmación de transporte extendido, el procesamiento continúa en el bloque 775. En el bloque 775, el núcleo 370 determina si la confirmación es para el paquete de encabezado de línea. Si No, entonces el paquete se ignora y el procesamiento se termina. Si Sí, entonces el bloque 780 actualiza el siguiente número en secuencia, número de paquetes en vuelo y número de paquetes sobresalientes permitidos. Después de que se actualiza la estadística, los paquetes confirmados por la confirmación recibida se remueven del buffer de recibo en el bloque 785. En algunas modalidades, se usa una técnica "libre retardada" para recapturar los buffers. (La técnica libre retardada se discutirá posteriormente.) Después de la limpieza total del buffer, el administrador de conexión virtual 380 se interroga, en el bloque 790, para determinar si la ventana de congestión permite ahora transmisiones nuevas. Si es así, el bloque 795 transmite nuevos paquetes de datos de transporte extendido hasta que no hay más espacio de ventana disponible. El mecanismo libre de paquetes de retardo, implementado por algunas modalidades del núcleo 370, retrasa la liberación de paquetes confirmados a un punto posterior en el ciclo de procesamiento de paquetes. Específicamente, cuando una confirmación llega del receptor notificando el recibo de múltiples paquetes, el emisor marca la lista de paquetes confirmados y aplaza la liberación real de aquellos paquetes para después. Entonces un número especificado de paquetes se libera del buffer de retardo para cada paquete nuevo que se transmite por el emisor. Esto amortiza los costos operativos de operaciones libres de memoria de paquetes múltiples sobre las transmisiones de paquetes múltiples, y no desacelera el procesamiento inmediatamente después del recibo de confirmaciones. La FIGURA 8 es un diagrama de flujo que muestra el procesamiento de un paquete recibido de transporte extendido por el administrador de conexión virtual 380. Estos paquetes recibidos, que incluyen paquetes de datos de transporte extendido y paquetes de confirmación de transporte extendido, se proporcionan al administrador de conexión virtual 380 por el núcleo 370. El procesamiento del paquete recibido de transporte extendido por el administrador de conexión virtual 380 comienza en el bloque 805, el cual determina si el paquete de transporte extendido es datos o confirmación. Si es Datos, entonces el procesamiento continúa en el bloque 810, el cual determina si el paquete recibido de datos es el siguiente paquete en secuencia. Si No, entonces el procesamiento continúa en el bloque 815, donde el número en secuencia del paquete recibido de datos se almacena en una lista fuera de orden. Después, el bloque 820 actualiza el tablero de confirmación selectiva (SACK) y el bloque 825 envía un DUPACK para el siguiente paquete en secuencia. El procesamiento del paquete de datos de transporte extendido entonces se termina. Regresando al bloque 810, si se determina que el paquete recibido de datos es el siguiente paquete en secuencia, entonces el bloque 830 examina la lista fuera de orden. Si la lista está vacía, el bloque 835 envía una confirmación por el paquete recibido y el procesamiento se termina. Si la lista no está vacía, entonces el bloque 840 remueve los números en secuencia que corresponden al paquete recibido de la lista fuera de orden. Después, en el bloque 845, se envía una confirmación por todos los paquetes en secuencia y el procesamiento del paquete recibido se termina. Regresando a la clasificación del paquete recibido en el bloque 805, si el paquete es un paquete de confirmación de transporte extendido, entonces el bloque 850 determina si la confirmación es para el paquete de encabezado de línea. Si No, entonces el paquete se ignora y el procesamiento se termina. Si Sí, entonces el bloque 855 determina si el componente de núcleo está en el estado LOSS RECOVERY. En una modalidad, los estados del componente de núcleo incluyen NORMAL, LOSS_RECOVERY, TIMEOUT, SYN SENT y SYN RECVD. Estos estados pueden variar de conformidad con la elección del protocolo de transporte, como debe entenderse por una persona experimentada en la técnica. Si no está en el estado de recuperación de pérdidas, entonces la siguiente estadística se actualiza en el bloque 860: siguiente número en secuencia; número de paquetes en vuelo; y número de paquetes sobresalientes permitidos. Después de que se actualiza la estadística, los parámetros de control de congestión se actualizan en el bloque 865. En una modalidad, los parámetros de control de congestión incluyen el tamaño de la ventana de congestión y el umbral. El procesamiento del paquete de transporte extendido de confirmación entonces se termina. Si el bloque 855 determina que el componente de núcleo está en el estado de recuperación de pérdidas, entonces el procesamiento continúa en el bloque 870, el cual determina si la confirmación es por todos los paquetes sobresalientes al momento de entrar al estado LOSS_RECOVERY. Si Si, entonces el estado del componente de núcleo se actualiza a NORMAL. En el bloque 875, los parámetros de tubería se actualizan en el bloque 880 y el procesamiento del paquete se termina. Si el bloque 870 determina que la confirmación es para menos de todos los paquetes sobresalientes, entonces los parámetros para la tubería (ruta virtual extremo a extremo) se actualizan en el bloque 885. En una modalidad, estos parámetros incluyen un siguiente número en secuencia, un número de paquetes en vuelo y un número de paquetes sobresalientes permitidos. El paquete recibido se retransmite en el bloque 890 y el procesamiento entonces se termina. Habiendo descrito la operación global de la lógica 160 que implementa el protocolo de transporte extendido 165, se describirán ahora varias características de este protocolo. Una' persona experimentada en la técnica deberá entender que estas características generalmente son independientes entre sí, de modo que una modalidad específica del protocolo de transporte extendido 165 pueda incluir alguna combinación de estas características. El protocolo de transporte extendido 165 no se requiere para compartir memoria con otras aplicaciones y servicios a diferencia del TCP. La memoria completa del dispositivo puede dedicarse para almacenar paquetes de conexiones activas. Además, este gran buffer se comparte de manera flexible entre múltiples conexiones activas extremo a extremo sin ningunas cuotas fijas para las conexiones. El desempeño del TCP se limita en redes con gran producto de ancho de banda-retardo debido al límite impuesto en los paquetes sobresalientes máximos en la red. El protocolo de transporte extendido mejora el desempeño de las conexiones extremo a extremo en redes con gran producto de ancho de banda y retardo, al eliminar la limitación de ventanas pequeñas y al lograr la repartición perfecta de la memoria completa disponible para el sistema para almacenar paquetes de conexiones activas. El desempeño del TCP se limita en redes con gran producto de ancho de banda-retardo debido al límite impuesto en los paquetes sobresalientes máximos en la red. El protocolo de transporte extendido mejora el desempeño de las conexiones extremo a extremo en redes con gran BDP al eliminar la limitación de ventanas pequeñas y al lograr la repartición perfecta de la memoria completa disponible para el sistema para almacenar paquetes de conexiones activas. La FIGURA 9 es un diagrama de flujo del mecanismo de control de flujo usado por el protocolo de transporte extendido 165. En este ejemplo, el punto final 1 0A es el emisor de TCP y el punto final 1 10B es el receptor de TCP. El punto final 1 10A envía mensajes de datos de TCP 910 destinados para el punto final 110B. El dispositivo de red 150A recibe los Mensajes de datos de TCP 910, los encapsula en mensajes de datos de protocolo de transporte extendido 920 y los envía hacia el dispositivo de red 150B. El dispositivo de red 150B recibe los Mensajes de datos de TCP 920, remueve el mensaje de datos de TCP 910 encapsulado dentro y envía el mensaje de datos de TCP 910 hacia el punto final 110B. El control de flujo se usa en las tres operaciones de la conexión. El dispositivo de red 150A, más cercano al punto final 110A, usa mecanismos de control de flujo de TCP para controlar la tasa de envío del punto final 1 10A. Es decir, el dispositivo de red 150A administra sus propios buffers de recibo de punto final-lateral al enviar un anuncio de ventana deslizante de TCP y/o mensajes congelados 930 nuevamente al punto final 110A. El punto final 110A entiende estos mensajes de control de flujo de TCP 930 y regula el flujo como se indica. El punto final 110B, que recibe datos de TCP del punto final 110A, también usa mensajes de control de flujo de TCP 930 para regular el flujo del dispositivo de red 150B más cercano a si mismo. El dispositivo de red 150B, que prevé que los mensajes de control de flujo desde el lado del punto final sean mensajes de control de flujo de TCP 930, regula el flujo como se indica. Cuando el dispositivo de red 150B reduce la tasa de datos como se instruye por el punto final 110B, el dispositivo de red 150B a su vez puede necesitar regular el flujo del dispositivo de red de envío 150A. Si es así, el dispositivo de red 150B envía mensajes de control de flujo de transporte extendido 940 al dispositivo de red 150A (diferentes a los mensajes de control de flujo de TCP 930). Esto a su vez puede resultar en que los buffers de recibo de enrutador-laterales dentro del dispositivo de red 150B se llenen, en cuyo punto el dispositivo de red 150B regulará el flujo del punto final 1 10A al enviar mensajes de control de flujo de TCP 930. De esta manera, la tasa de datos del punto final de envío 110A puede afectarse por el control de flujo en las tres operaciones de la conexión. Una persona experimentada en la técnica deberá apreciar que, cuando un dispositivo de red 150 agota el espacio de buffer de recibo, esta estrategia proporciona un mecanismo con gracia de contrapresión para desacelerar el tráfico en la red 130 entre los dispositivos de red 150, y eventualmente de nuevo al punto final de emisor de TCP 110A. Algunas modalidades del dispositivo de red 150 incluyen un nivel adicional de control de flujo que se realiza a nivel de conexión de TCP, lo cual ocurre cuando una sola conexión de TCP excede una "participación equitativa" del buffer de recibo. Bajo esta condición, el dispositivo receptor de red 150 envía un mensaje de TCP congelado, para esa conexión específica de TCP, al dispositivo emisor de red 150. En respuesta, el dispositivo emisor de red 150 regula el flujo de la tasa de envío de la conexión correspondiente de TCP en el lado remoto. La FIGURA 10 es un diagrama de estados que ilustra un mecanismo de control de congestión implementado por algunas modalidades del dispositivo de red 150. El algoritmo transita entre seis estados: Inicio Lento 1010; Evitación de Congestión 1015; Mantener 1020; Disminución Proporcional 1025; Recuperación de Pérdidas 1030; y Ventana de Inicialización 035. El protocolo de transporte extendido 165 comienza en el estado Inicio Lento 1010. Mientras está en el estado Inicio Lento 1010, la ventana de congestión en una conexión se incrementa periódicamente en forma no lineal (1040). En una modalidad, este Si la ventana de congestión alcanza un umbral (1045) mientras está en el estado Inicio Lento 1010, el emisor transita al estado Evitación de Congestión 1015. Si en lugar de ello el tiempo de ida y vuelta de la conexión a través de la red 130 (tal como se mide por una sonda) alcanza un umbral (1050), el emisor transita al estado Mantener 1020, el cual se discutirá posteriormente. El estado Evitación de Congestión 1015, alcanzado desde el estado Inicio Lento 1010, se deja cuando un evento indica pérdida de paquetes (1055 o 1057). El estado Evitación de Congestión 1015 también puede dejarse cuando el tiempo de ida y vuelta de la conexión a través de la red 130, tal como se mide por una sonda, se incrementa más allá de un valor de umbral (1060), En el caso de un evento de pausa que indica pérdida de paquetes (1055), el emisor transita al estado Ventana de Inicialización 1035, donde la ventana de congestión se reinicia a un valor inicial, y el emisor entonces regresa al estado Inicio Lento 1010. En el caso de un evento de confirmación duplicada que indica pérdida de paquetes (1057), el emisor transita al estado Disminución Proporcional 1025, discutido posteriormente. En el caso del tiempo de ida y vuelta que alcanza un umbral (1060) desde el estado Evitación de Congestión 1015, el emisor transita al estado Mantener 1020. Mientras está en el estado Mantener 1020, la ventana de congestión permanece fija en el último valor calculado hasta que ocurre la pérdida de paquetes, como se indica ya sea por una pausa (1065) o una confirmación duplicada (1070. En el caso de una pausa 1065, el emisor regresa al estado Inicio Lento 1010. En el caso de una confirmación duplicada 1070, el emisor transita al estado Disminución Proporcional 1025.

En el estado Disminución Proporcional 1025, el emisor reacciona a la detección de pérdida de congestión al regular el flujo de la tasa por un valor proporcional al número de paquetes perdidos, y entonces entra al estado Recuperación de Pérdidas 1030. Al entrar al estado Recuperación de Pérdidas 1030, la ventana de congestión se adapta al número de paquetes sobresalientes al momento de la pérdida, reducida por una cantidad proporcional al número de paquetes perdidos en la red 130 durante un tiempo de ida y vuelta. Este mecanismo garantiza que se transmitan nuevos paquetes antes de los paquetes perdidos durante la recuperación de pérdidas. Mientras está en el estado Recuperación de Pérdidas 1030, se envían datos para cada confirmación (1075). Con la confirmación por todos los paquetes sobresalientes al momento de entrar a la recuperación de pérdidas (1080), el emisor sale del estado Recuperación de Pérdidas 1030 y regresa al estado Evitación de Congestión 1015. Con una pausa que indica pérdida de paquetes, la ventana de congestión se reinicia al tamaño original de ventana al momento de la pérdida (en el estado 1035) y el emisor regresa al estado Inicio Lento 1010. Una persona experimentada en la técnica deberá apreciar que este mecanismo de recuperación de pérdidas es un método menos agresivo en comparación con el TCP. El TCP se diseña de manera tal que cualesquier pérdidas de paquetes que ocurren durante la progreso de conexión se interpretan como una señal de congestión de red, y el TCP reacciona al regular el flujo de la tasa de la conexión a la mitad. El mecanismo de disminución proporcional usado por el protocolo de transporte extendido 165 es más apropiado en ambientes (por ejemplo, redes inalámbricas de datos y WANs privadas) donde un ancho de banda abastecido se encuentra disponible. Además de conseguir un control de congestión menos agresivo, el mecanismo de disminución proporcional empleado por el protocolo de transporte extendido 165 es capaz de manejar pérdidas aleatorias de paquetes mejor que el mecanismo de disminución multiplicativa usado por el TCP. Puesto que el protocolo de transporte extendido 165 reduce la ventana de congestión en proporción al número de pérdidas de paquetes, el impacto de las pérdidas aleatorias sobre el control de congestión disminuye. Una persona experimentada en la técnica también debe reconocer que el ajuste anterior de la ventana de congestión puede resultar en un escenario donde la ventana de congestión actualizada hace posible un gran número de transmisiones de paquetes en la salida del estado de recuperación de pérdidas. En algunas modalidades del protocolo de transporte extendido 165, el dispositivo receptor de red 150 disemina estas transmisiones de paquetes sobre futuras confirmaciones al limitar a dos el número de nuevas transmisiones de paquetes para cada recibo de una nueva confirmación. Una persona experimentada en la técnica deberá apreciar las diferencias entre el algoritmo de congestión de la FIGURA 10 y aquel usado por los protocolos convencionales de transporte, tal como el TCP. El TCP usa una estrategia de incremento lineal para sondear la tasa: si la capacidad disponible es unidades C, y la tasa actual de datos de una conexión de TCP es unidades C-X, entonces el TCP tomará aproximadamente X tiempos de ida y vuelta para alcanzar el punto de operación ideal para la tasa de datos de conexión. De esta manera, el TCP es lento en reaccionar tanto a la disponibilidad de nuevos recursos en la red 130 como a disminuir operaciones de flujo de bits que resultaron de reducciones previas en la ventana de congestión. Cuando el tiempo de ida y vuelta es grande, el TCP toma mucho tiempo para alcanzar el punto de operación ideal. Las conexiones de corta duración, tales como transacciones SSL, pueden terminar la transferencia de datos completamente antes de alcanzar el punto de operación ideal. Además, debido a la multiplexión de conexiones múltiples extremo a extremo hacia conexiones ya establecidas de protocolo de transporte extendido, el dispositivo de red elimina el retardo por sondeo al inicio para estas conexiones extremo a extremo. Esto es posible a causa de la repartición de información de red entre conexiones extremo a extremo a través de la conexión de protocolo de transporte extendido a través de lo cual se multiplexan. Esta reducción del retardo al inicio mejora significativamente el desempeño de las aplicaciones transaccionales las cuales tienen duraciones cortas. Adicionalmente, el TCP tiene una tendencia a inducir pérdidas incluso durante operaciones rutinarias de control de congestión, puesto que el proceso de control de congestión del TCP tiene solamente dos fases; una fase de incremento y una fase de disminución. Incluso sin congestión externa en la red 130, el TCP continúa incrementando la tasa de datos de conexión hasta que se induce la congestión en la red 130 y ocurre una pérdida, con lo cual la fase de disminución entra en acción y la tasa se divide a la mitad para una repetición del ciclo de control de congestión. Este ciclo innecesario que implica disminuciones forzadas e incrementos lentos limita además el desempeño de las conexiones de TCP. El protocolo de transporte extendido 165 también presenta un mecanismo de detección de pérdidas que es más adecuado para redes de alta velocidad que para protocolos convencionales de transporte. En lugar de usar pausas de altos costos operativos para detectar la pérdida, el protocolo de transporte extendido 165 usa técnicas pasivas de aprendizaje con base en el número de paquetes enviados, número de paquetes recibidos y números en secuencia de paquetes enviados en eventos memorables apropiados durante la detección de pérdidas. Más específicamente, el dispositivo emisor de red 150 usa un número en secuencia monotónicamente creciente llamado CONG_SEQ_NUM en todos los paquetes que transmite. El dispositivo receptor de red 150 refleja el CONG_SEQ_NUM en los paquetes recibidos en las confirmaciones como el ACK_CONG_SEQ. Cuando el ACK_CONG_SEQ es mayor al CONG_SEQ_NUM en un paquete retransmitido correspondiente, el dispositivo emisor de red 150 concluye que el paquete retransmitido se pierde y toma la acción apropiada para recuperarse de esa pérdida. Sin este mecanismo, la única forma para determinar si un paquete retransmitido se pierde es usar un mecanismo de pausa el cual és un uso ineficiente del preciado ancho de banda de la red. El mecanismo de reporte de pérdidas usado por el protocolo de transporte extendido 165 permite reportar más rápido que las técnicas convencionales al acomodar un mayor número de bloques perdidos, e incorporar un mecanismo de confirmación selectiva de niveles múltiples (SACK). A diferencia del mecanismo SACK de un solo estrato, usado por el TCP convencional, el protocolo de transporte extendido 165 usa niveles múltiples de SACK para llevar las pérdidas al dispositivo emisor de red 150. Cada bloque SACK tiene tanto el inicio como el final del bloque perdido de paquetes, así como el número de ciclo de transmisión de la fase de recuperación de pérdidas. El número de ciclo de transmisión se identifica por el número de retransmisiones de los paquetes en el bloque SACK. El dispositivo emisor de red 150 da prioridad al mínimo número de ciclo de transmisión con respecto al proceso de retransmisión. El dispositivo de red 150 también usa pausas gruesas para manejar casos donde la red 130 se cae durante un periodo prolongado cuando los paquetes no alcanzan el receptor. Cada vez un paquete nuevo de datos se confirma por el receptor (indicado por una confirmación), el cronometrador se restablece. Cuando el cronometrador expira, indica que el paquete de encabezado de línea en el buffer de envío no se entregó con éxito y por tanto debe retransmitirse. Estas pausas gruesas son capaces de manejar interrupciones temporales de red, mientras el mecanismo de detección y recuperación de pérdidas basado en CONG_SEQ_NUM, descrito anteriormente trabaja solamente cuando hay paquetes que alcanzan el receptor y, de esta manera, que activan confirmaciones para el emisor. Todavía otra característica del protocolo de transporte extendido 165 incrementa la confiabilidad al usar números en secuencia de manera diferente a los protocolos convencionales de transporte. El dispositivo receptor de red 150 usa un campo NXT_SEQ_NUM en la confirmación para comunicar al dispositivo emisor de red 150 el status del buffer de recibo en el dispositivo receptor de red 150. El NXT_SEQ_NUM es el número en secuencia del paquete de encabezado de línea en el buffer fuera de orden del receptor. El emisor usa el valor de NXT_SEQ_NUM para determinar si la confirmación recibida es una "confirmación parcial verdadera" o una "confirmación parcial falsa". Una confirmación parcial verdadera confirma el recibo de todos los paquetes menores al NXT_SEQ_NUM, aunque no todos los paquetes sobresalen al momento de la pérdida. Una confirmación parcial falsa no confirma el recibo de todos los paquetes menores al NXT_SEQ_NUM, aunque confirma el siguiente paquete en secuencia esperado por el receptor. Al usar el campo NXT_SEQ_NUM para diferenciar entre confirmaciones parciales verdaderas y falsas, el dispositivo emisor de red 150 incrementa la utilización de la red 130 incluso durante la recuperación de pérdidas. Todavía otra diferencia entre el protocolo de transporte extendido 165 y los protocolos convencionales de transporte, tal como el TCP, es que algunas modalidades del protocolo de transporte extendido 165 no tienen límite en el tamaño anunciado de ventana (deslizante) o el tamaño de la ventana de congestión. Otras modalidades del protocolo de transporte extendido 165 tienen un límite. Algunas de estas modalidades tienen límites que are mucho más grandes que los límites usados por los protocolos convencionales.

La FIGURA 11 es un diagrama de bloques de hardware de un dispositivo de red 150 conforme al sistema y método para mejorar el desempeño de los protocolos de transporte. El dispositivo de red 150 contiene una serie de componentes que se conocen bien en la técnica de las comunicaciones de datos, incluyendo un procesador 1110, una interfaz de red local 1120, una interfaz local remota 1130, memoria 1140 y almacenamiento no volátil 1150. Ejemplos de almacenamiento no volátil incluyen, por ejemplo, un disco duro, RAM flash, ROM flash, EEPROM, etc. Estos componentes se acoplan mediante el bus 1160. La memoria 1140 contiene lógica para mejorar el desempeño de los protocolos de transporte 160 de la FIGURA 1. El dispositivo de red 150 se muestra con dos interfaces de red. La interfaz de red local 1120 está en comunicación con el punto final 110, y la interfaz local remota 1130 está en comunicación con el enrutador 140. Una persona experimentada en la técnica deberá entender que las interfaces de las redes pueden ser de diferentes tipos, soportar diferentes medios y velocidades, etc. De la FIGURA 11 se omite una serie de componentes convencionales, conocidos por los expertos en la técnica, que no son necesarios para explicar la operación del dispositivo de red 150. Debe entenderse que cualesquier descripciones o bloques de proceso en los diagramas de flujo representan módulos, segmentos o porciones de código que incluyen una o más instrucciones ejecutables para implementar funciones o etapas lógicas específicas en el proceso. Como puede entenderse por los expertos en la técnica del desarrollo de software, también se incluyen implementaciones alternas dentro del alcance de la descripción. En estas implementaciones alternas, las funciones pueden ejecutarse fuera de orden a partir de aquella mostrada o discutida, incluyendo sustancialmente de manera concurrente o en orden inverso, dependiendo de la funcionalidad implicada. Los sistemas y métodos dados a conocer en este documento pueden representarse en cualquier medio que pueda leerse por computadora para su uso por o en relación con un sistema, aparato o dispositivo de ejecución de instrucciones. Tales sistemas de ejecución de instrucciones incluyen cualquier sistema basado en computadoras, sistema que contiene procesador u otro sistema que puede mandar llamar y ejecutar las instrucciones desde el sistema de ejecución de instrucciones. En el contexto de esta descripción, un "medio que puede leerse por computadora" puede ser cualquier medio que puede contener, almacenar, comunicar, propagar o transportar el programa para su uso por, o en relación con, el sistema de ejecución de instrucciones. El medio que puede leerse por computadora puede ser, por ejemplo, pero no limitarse a, un sistema o medio de propagación que se basa en tecnología electrónica, magnética, . óptica, electromagnética, infrarroja o semiconductora. Ejemplos específicos de un medio que puede leerse por computadora usando tecnología electrónica pueden incluir (pero no se limitan a) lo siguiente: una conexión eléctrica (electrónica) que tiene uno o más cables; una memoria de acceso aleatorio (RAM); una memoria de sólo lectura (ROM); una memoria de sólo lectura programable que puede borrarse (memoria EPROM o Flash). Un ejemplo específico que usa tecnología magnética incluye (pero no se limita a) un disco flexible portátil de computadora. Ejemplos específicos que usan tecnología óptica incluyen (pero no se limitan a) una fibra óptica y un disco compacto portátil de memoria de sólo lectura (CD-ROM). La descripción precedente se ha presentado para propósitos de ilustración y descripción. No pretende ser exhaustiva o limitar la descripción a las formas precisas dadas a conocer. Las modificaciones o variaciones obvias son posibles a la luz de las enseñanzas anteriores. Las implementaciones discutidas, sin embargo, se eligieron y describieron para ilustrar los principios de la descripción y su aplicación práctica para permitir en consecuencia, a alguien experimentado en la técnica, utilizar la descripción en diversas implementaciones y con diversas modificaciones tal y como se adecúan al uso particular contemplado. Todas las modificaciones y variación semejantes están dentro del alcance de la descripción como se determina por las reivindicaciones adjuntas cuando se interpretan conforme a la extensión a la cual facultan clara y legalmente.

Claims (5)

REIVINDICACIONES

1. Un método para controlar la congestión en una red entre un primer dispositivo y un segundo dispositivo par, el método comprendiendo las etapas de: en un primer estado, incrementar de manera no lineal una ventana de congestión; en respuesta a la ventana de congestión que excede un valor de umbral mientras está en el primer estado, transitar a un segundo estado; y en el segundo estado, incrementar de manera lineal la ventana de congestión.

2. El método de conformidad con la reivindicación 1, que además comprende las etapas de: transitar a un tercer estado al recibir una confirmación duplicada que indica pérdida de un número de paquetes; y en el tercer estado, disminuir la ventana de congestión en proporción al número de paquetes perdidos.

3. El método de conformidad con la reivindicación 1 , que además comprende las etapas de: transmitir una primera serie de paquetes, cada uno incluyendo un número en secuencia creciente; recibir una segunda serie de paquetes, cada uno incluyendo un número confirmado en secuencia; y si uno de los números confirmados en secuencia es mayor al número en secuencia creciente de uno correspondiente de la primera serie de paquetes, indicar la pérdida de un paquete.

4. El método de conformidad con la reivindicación 1 , que además comprende las etapas de transmitir una confirmación selectiva que contiene un número de inicio en secuencia, un número final en secuencia y un número de ciclo de transmisión.

5. El método de conformidad con la reivindicación 1, que además comprende las etapas de: detectar una pérdida de paquetes; al detectar la pérdida de paquetes, registrar un número de paquetes no confirmados al momento de la detección de pérdidas; recibir una confirmación que contiene un número en secuencia del siguiente paquete en un buffer fuera de orden de un receptor par; y determinar si el número recibido en secuencia indica confirmación de todos los paquetes que no se confirman al momento de la detección de pérdidas.