[go: up one dir, main page]

MX2008013325A - Habilitar dispositivos de red para correr multiples algoritmos de control de congestion. - Google Patents

Habilitar dispositivos de red para correr multiples algoritmos de control de congestion.

Info

Publication number
MX2008013325A
MX2008013325A MX2008013325A MX2008013325A MX2008013325A MX 2008013325 A MX2008013325 A MX 2008013325A MX 2008013325 A MX2008013325 A MX 2008013325A MX 2008013325 A MX2008013325 A MX 2008013325A MX 2008013325 A MX2008013325 A MX 2008013325A
Authority
MX
Mexico
Prior art keywords
connection
network
congestion
congestion control
control module
Prior art date
Application number
MX2008013325A
Other languages
English (en)
Inventor
Abolade Gbadegesin
Henry L Sanders
Murari Sridharan
Sanjay N Kaniyar
Original Assignee
Microsoft Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of MX2008013325A publication Critical patent/MX2008013325A/es

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/11Identifying congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • H04L47/193Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2475Traffic characterised by specific attributes, e.g. priority or QoS for supporting traffic characterised by the type of applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/02Capturing of monitoring data
    • H04L43/022Capturing of monitoring data by sampling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852Delays
    • H04L43/0864Round trip delays

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Se describe la creación de diferentes módulos de control de congestión (CCMs) que pueden conectarse a una pila de comunicaciones de red (por ejemplo, una pila de TCP/IP). Se pueden exponer abstracciones de software que definen eventos de control de transporte, algoritmos de control de congestión y otra información a través de una interfase de programación de aplicación, por ejemplo, de un sistema operativo, y estas abstracciones pueden ser utilizadas para definir un CCM. La pila de comunicaciones de red puede ser configurada para seleccionar uno de los múltiples CCMs disponibles para controlar la congestión para una conexión dada. Esta selección puede basarse en cualquiera de una variedad de factores que incluyen, pero no se limitan a: ambiente de red; características de trayectoria de conexión; características de enlace de conexión; un valor de un parámetro de socket de una aplicación; otros factores; y cualquier combinación adecuada de lo anterior. De esta manera, los CCMs pueden ser seleccionado e implementados en una base por conexión.

Description

HABILITAR DISPOSITIVOS DE RED PARA CORRER MULTIPLES ALGORITMOS DE CONTROL DE CONGESTION ANTECEDENTES El protocolo de control de transmisión (TCP) permite a los dispositivos de red establecer una conexión en una red e intercambiar corrientes de datos en la conexión en la forma de paquetes. TCP garantiza la entrega de datos y también garantiza que los paquetes se entregarán en el mismo orden en el cual se enviaron. TCP emplea algoritmos de control de congestión que ayudan a desactivar la congestión de red al estrangular agresivamente el índice al cual se transmiten los paquetes (es decir, se envían) desde la fuente. En redes de retraso de banda ancha alta, estas medidas agresivas resultan en TCP que substancialmente utiliza poco el ancho de banda de red en la presencia incluso de un porcentaje pequeño de pérdida de paquete. Por ejemplo, alguna de la familia de sistemas operativos de Windows® emplean una forma de TCP que implementa el algoritmo de control de congestión de NewReno extendido, que trabaja pobremente en ambientes de retraso de ancho de banda alta. La comunidad de búsqueda de red propuso varias mejoras y modificaciones al algoritmo de control de congestión de TCP en un intento para mejorar su desempeño en redes de alta velocidad.
Existen varios factores a considerar y no existe una solución "de un tamaño que se ajusta a todo". Entre más agresivo el algoritmo, más injusto será para otro TCP fluir. Además, debido a que no hay estándar umversalmente aceptado, la decisión en la cual el algoritmo de control de congestión para implementar un sistema operativo dado es a su vez difícil.
BREVE DESCRIPCION DE LA INVENCION Esta breve descripción proporciona un contexto ilustrativo para aspectos de la invención, en una forma simplificada. No se pretende utilizar para determinar el alcance del tema reclamado. Los aspectos de la invención se describen más completamente más adelante en la descripción detallada. Aquí se describen sistemas, métodos y software (por ejemplo, estructura de trabajo) para crear diferentes módulos de control de congestión (CCMs) que interactúan con (por ejemplo, se "conectan en") una pila de comunicaciones de red (por ejemplo, una pila de TCP/IP). Las abstracciones de software que definen eventos de control de transporte, algoritmos de control de congestión (CCAs) y otra información pueden exponerse por una interfase de programación de aplicación, por ejemplo, de un sistema operativo. Estas abstracciones pueden utilizarse para definir un tipo de CCM, del cual pueden generarse múltiples CCMs (por ejemplo, iniciarse). La pila de comunicaciones de red puede configurarse para seleccionar uno de múltiples CCMs disponibles para controlar congestión para una conexión dada. Esta selección puede basarse en cualquiera de una variedad de factores que incluyen, pero no se limitan a: ambiente de red; características de ruta de conexión; características de enlace de conexión; un valor de un parámetro de enchufe de una aplicación; otros factores y cualquier combinación adecuada de lo anterior. De esa forma, CCMs pueden seleccionarse e implementarse en una base por conexión, para que múltiples CCMs puedan, operar concurrentemente. La pila de comunicaciones de red puede reportar eventos de control de transporte para una conexión dada a sus CCM correspondiente, y el CCM puede actualizar los valores de una o más variables de estado para la conexión por consiguiente. El CCM puede proporcionar los valores actualizados de una o más variables de estado a la pila de comunicaciones de red, y la pila puede modificar su control de la conexión por consiguiente. En algunas modalidades, para reducir la cantidad de memoria consumida al mantener información de estado para cada conexión, la información puede muestrearse desde menos que todos los paquetes transmitidos y/o recibidos para una conexión. Un índice de muestreo para cada conexión puede determinarse basándose en cualquiera de una variedad de factores, que incluyen, pero no se limitan a, la velocidad de transmisión de la conexión y el tiempo de viaje redondo (RTT) de la conexión. Un grupo de memoria puede designarse para uso para control de congestión, y una porción del grupo de memoria puede distribuirse a cada conexión basándose en su velocidad de muestreo. La información puede muestrearse de paquetes enviados de y/o recibidos en cada conexión de acuerdo con la velocidad de muestreo de la conexión, y la información muestreada puede almacenarse en la porción de memoria distribuida a cada conexión respectiva. Por ejemplo, el tiempo en el cual se transmite una pieza de información (por ejemplo, bytes de datos) pueden mezclarse, y el tiempo en el cual un conocimiento para la pieza de datos se recibe puede muestrearse, y esta información puede utilizarse para determinar un RTT para una conexión. La velocidad de muestreo y cantidad de memoria distribuida a cada conexión puede ajustarse como la velocidad de transmisión y/o RTT de los cambios de conexión. En algunas modalidades, un módulo de interfase de red, por ejemplo, una tarjeta de interfase de red (NIC), puede generar marca de tiempo para paquetes recibidos en una conexión. Para cada paquete recibido de una red, una marca de tiempo puede generarse y pasarse a la pila de comunicaciones de red para utilizarse al controlar congestión en la conexión. Por ejemplo, el módulo de interfase de red puede almacenar información de marca de tiempo que asocia la marca de tiempo y conexión en la estructura de datos (por ejemplo, una estructura de datos de RED_MEMORI A INTERMEDIA y/o RED_MEMORI A I NTE R M E D I A_L I ST A en un sistema operativo de Windows® Vista™). Esta información de marca de tiempo puede utilizarse por la pila de comunicaciones de red para determinar un RTP y/o otra información de control de transporte para la conexión. La pila de comunicaciones de red puede reportar el RTP y/o otra información al CCM que controla congestión para la conexión. El CCM puede actualizar variables de estado de conexión, y proporcionar los valores actualizados de una o más variables de estado de conexión a la pila de comunicaciones de red. La pila entonces puede modificar su control de la conexión por consiguiente.
En una modalidad de la invención, un sistema se proporciona para crear un módulo de control de congestión para controlar congestión en una conexión de red. El sistema incluye una inferíase de programación de aplicación que expone una o más abstracciones de evento para uso al definir tipos de módulo de control de congestión para los cuales pueden generarse módulos de control de congestión, cada abstracción de evento que define un evento de control de transporte. En otra modalidad de la invención, un sistema para controlar congestión en una o más conexiones de red entre un dispositivo de red y una red de comunicaciones se proporciona. El sistema incluye una pila de comunicaciones de red operativa para controlar comunicaciones de red en una o más conexiones, y uno o más módulos de control de congestión, cada módulo de control de congestión que define un algoritmo de control de congestión para controlar congestión en uno respectivo de una o más conexiones de red y mantener una o más variables de estado de conexión para la conexión respectiva. La pila de comunicaciones de red es operativa, para cada una de una o más conexiones, para notificar al módulo de control de congestión que controla congestión en la conexión de uno o más eventos de control de transporte que ocurren en la conexión. En otra modalidad de la invención, se proporciona un producto de programa computadora. El producto de programa de computadora incluye un medio legible por computadora y señales legibles por computadora, almacenadas en el medio legible por computadora, que definen instrucciones que, como un resultado de ejecutarse por una computadora, controlan la computadora para realizar un método de controlar congestión en una conexión de red entre un dispositivo de red y una red de comunicaciones. El método incluye actos de: seleccionar un primer tipo de control de congestión para una primera conexión; generar un primer módulo de control de congestión del primer tipo; y controlar congestión de red en la primera conexión que utiliza el primer módulo de control de congestión. En otra modalidad de la invención, la congestión en una conexión de red se controla. Una velocidad a la cual muestrea la información de paquetes transmitidos de un dispositivo de red en la conexión de red se determina basándose, al menos en parte, en una velocidad de transmisión de la conexión de red y un tiempo de viaje redondo para la conexión. La información de paquete es transmitida y la conexión se muestrea a la velocidad de muestreo determinada, congestión en la conexión de red se controla basándose al menos en parte en la información muestreada. Incluso en otra modalidad de la invención, se proporciona un sistema para controlar congestión en una conexión de red. El sistema incluye una pila de comunicaciones de red operativas para determinar una velocidad en la cual muestrea la información de paquetes transmitidos de un dispositivo de red en la conexión de red basándose, al menos en parte, en una velocidad de transmisión de la conexión de red y un tiempo de viaje redondo para la conexión, para muestrear, a una velocidad de muestreo determinada, información de paquetes transmitidos en la conexión, y para controlar conexión en la conexión de red basándose al menos en parte en la información muestreada. En otra modalidad de la invención, se proporciona un producto de programa de computadora, el cual incluye un medio legible por computadora y señales legibles por computadora, almacenadas en el medio legible por computadora, que definen instrucciones que, como un resultado de ejecutarse por una computadora, controla la computadora para realizar un método de controlar congestión en una conexión de red. Los métodos incluyen actos de: determinar una velocidad en la cual muestrea la información de paquetes transmitidos de un dispositivo de red en la conexión de red basándose, al menos en parte, en una velocidad de transmisión de la conexión de red y un tiempo de viaje redondo para la conexión; muestrear, a una velocidad de muestreo determinada, información de paquetes transmitidos de la conexión; y controlar congestión en la conexión de red basándose al menos en parte en la información muestreada.
En otra modalidad de la invención, la congestión en una conexión de red entre un dispositivo de red y una red de comunicaciones se controla. El dispositivo de red incluye una pila de comunicaciones de red y un módulo de interfase de red separado. En el módulo de interfase de red, se recibe un paquete en la conexión de red de la red de comunicaciones. Una marca de tiempo se genera en el módulo de interfase de red, la marca de tiempo que corresponde a un tiempo en el cual el paquete se recibió. La información que asocia en la marca de tiempo con el paquete se almacena en una estructura de datos accesible por la pila de comunicaciones de red, y el paquete se envía a la pila de comunicaciones de red. Incluso en otra modalidad de la invención, se proporciona un sistema para controlar congestión en una conexión de red entre un dispositivo de red y una red de comunicaciones. El dispositivo de red incluye una pila de comunicaciones de red. El sistema incluye un módulo de interfase de red operativo para recibir un paquete en la conexión de red de la red de comunicaciones, para generar una marca de tiempo en el módulo de interfase de red, la marca de tiempo que corresponde a un tiempo en el cual se recibió el paquete, para almacenar información que asocia la marca de tiempo con el paquete en una estructura de datos accesible con la pila de comunicaciones de red, y para enviar el paquete a la pila de comunicaciones de red. En otra modalidad de la invención, se proporciona un producto de programa de computadora, que incluye un medio legible por computadora y señales legibles por computadora, almacenadas en el medio legible por computadora, que definen instrucciones que, como un resultado de ejecutarse por una computadora, controlan la computadora para realizar un método de controlar congestión en una conexión de red entre un dispositivo de red y una red de comunicaciones. El dispositivo de red incluye una pila de comunicaciones de red y un módulo de interfase de red separado. El método incluye actos de: en el módulo de interfase de red, recibir un paquete en la conexión de red de la red de comunicaciones; generar una marca de tiempo en el módulo de interfase de red, la marca de tiempo que corresponde a un tiempo en el cual se recibió el paquete; almacenar información que asocia la marca de tiempo con el paquete en una estructura de datos accesible por la pila de comunicaciones de red; y enviar el paquete a la pila de comunicaciones de red. Otras ventajas, características novedosas, y objetos de la invención, y aspectos de modalidades de la misma, serán evidentes a partir de la siguiente descripción detallada de la invención, que incluye aspectos y modalidades de la misma, cuando se considera en conjunto con los dibujos que son esquemáticos y no pretenden dibujarse a escala. En las figuras, cada componente idéntico o casi idéntico que se ilustró en varias figuras se representa por un número individual. Para propósitos de claridad, no todo componente se etiqueta en cada figura, ni cada componente de cada modalidad o aspecto de la invención mostrado en donde la ilustración no necesariamente permite a aquellos expertos en la técnica entender la invención.
BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 es un diagrama de bloques que ilustra un ejemplo de un sistema para controlar congestión en una o más conexiones de red entre un dispositivo de red y red de comunicación, de acuerdo con algunas modalidades de la invención; la Figura 2 es un diagrama de bloques que ilustra un ejemplo de un sistema para definir tipos de CCM para controlar congestión en una conexión de red, de acuerdo con algunas modalidades de la invención; la Figura 3 es un cuadro de flujo que ilustra un ejemplo de un método para controlar congestión en una conexión de red, de acuerdo con algunas modalidades de la invención; la Figura 4 es un cuadro que ilustra un ejemplo de velocidades de muestreo para conexiones para ciertas combinaciones de velocidad de conexión y RTT, de acuerdo con algunas modalidades de la invención; la Figura 5 es un diagrama de bloques que ilustra un ejemplo de una estructura de datos para almacenar información muestreada de paquetes recibidos en una conexión, de acuerdo con algunas modalidades de la invención; la Figura 6 en el cuadro de flujo que ilustra un ejemplo de un método de controlar congestión en una conexión de red, de acuerdo con algunas modalidades de la invención; la Figura 7 ilustra un ejemplo de un método de controlar congestión en una conexión de red, de acuerdo con algunas modalidades de la invención; la Figura 8 es un diagrama de bloques que ilustra un ejemplo de un sistema de computadora en donde algunas modalidades de la invención pueden implementarse; y la Figura 9 es un diagrama de bloques que ilustra un ejemplo de un sistema de almacenamiento que puede utilizarse como parte del sistema de computadora para implementar algunas modalidades de la invención.
DESCRIPCION DETALLADA En ausencia de notificación de congestión explícita, algunos protocolos de capa de transporte (por ejemplo, TCP) confían en ciertos eventos para detectar congestión incipiente, pérdida de paquete y construcción de fila en un enrutador de "cuello de botella". La investigación actual en control de congestión puede clasificarse ampliamente como basándose en pérdida, que confía en pérdida de paquete como indicación de congestión, o basadas en retraso, que verifica ocupación de memoria intermedia en un enrutador de cuello de botella para evitar proactivamente cogestión. Los esquemas basados en retraso deducen construcción de fila al verificar aumentos en RTTs de conexiones. Las modalidades de la invención aquí descritas pueden utilizarse para implementar control de congestión basado en retraso y/o basado en pérdida. Por ejemplo, como se describe con más detalle más adelante, una o más abstracciones de evento, abstracciones de algoritmo de control de congestión (CCA) y abstracciones que definen otra información asociada con control de congestión pueden exponerse a través de una interfase. Estas abstracciones pueden utilizarse para definir uno o más módulos de control de congestión (CCMs) para controlar congestión en una o más conexiones respectivas que utilizan esquemas basados en retraso y/o basados en pérdida. La función y ventaja de modalidades de la presente invención descrita anteriormente y otras modalidades se entenderán más concretamente a partir de ejemplos descritos más adelante. Los siguientes ejemplos pretenden facilitar un mejor entendimiento e ilustrar los beneficios de la presente invención, pero no es ejemplificar el alcance completo de la invención. Como se utiliza aquí, si en la descripción escrita o las reivindicaciones, los términos "que comprenden", "que incluyen", "que transportan", "que tiene", "que contiene", "que involucra", y similares se debe entender al extremo abierto, es decir, para significar que incluyen pero no se limitan a. Sólo frases de transición "que consiste de" y "que consiste esencialmente de", respectivamente, deben ser frases de transición cerradas o sem ¡cerradas, como se menciona anteriormente, con respecto a las reivindicaciones, en el Manual de Oficina de Patente de los Estados Unidos de Procedimientos de Examen de Patente (Octava Edición, Revisión 2, mayo 2004), Sección 2111.03.
EJEMPLOS La Figura 1 es un diagrama de bloques que ilustra un ejemplo de un sistema 100 para controlar congestión en una o más conexiones de red entre un dispositivo de red 102 y red comunicación 128, de acuerdo con algunas modalidades de la invención. El sistema 100 es simplemente una modalidad ilustrativa de un sistema para controlar congestión entuna o más conexiones de red entre un dispositivo de red y una red de comunicaciones, y no pretende limitar el alcance de la invención. Cualquiera de numerosas otras implementación de tal sistema, por ejemplo, variaciones del sistema 100, son posibles y se pretende que caigan dentro del alcance de la invención. Como se utiliza aquí, una "red" es un grupo de dos o más componentes ¡nterconectados por uno o más segmentos de medios de transmisión en los cuales las comunicaciones pueden intercambiarse entre los componentes. Cada segmento puede ser cualquiera de una pluralidad de tipos de medios de transmisión, que incluyen uno o más cordones o cables eléctricos u ópticos hechos de metal y/o fibra óptica, aire (por ejemplo, que utilizan transmisión inalámbrica en ondas de portador) o cualquier combinación de estos medios de transmisión. Como se utiliza aquí, "pluralidad" significa dos o más. Se debe apreciar que una red puede ser tan simple como dos componentes conectados por un cable individual, conductor común, conexión inalámbrica, u otro tipo de segmento. Además, se debe apreciar que cuando se ilustra una red en un dibujo de esta aplicación como conectado a un elemento en el dibujo, el elemento conectado por si mismo se considera parte de la red. Como se utiliza aquí, un "dispositivo de red" es un dispositivo operativo para comunicarse en una red, que incluye, pero no se limita a: estaciones de trabajo, computadoras personales, terminales, computadoras portátiles, estaciones finales, dispositivos de usuario, servidores, entradas, registros, interruptores, enrutadores, centrales, puentes, directorios, transmisores, receptores, transceptores, puntos de acceso inalámbrico (APS), repetidores, y cualquier combinación de los mismos. Como se utiliza aquí, un "dispositivo de usuario" es un dispositivo de red desde/hacia el cual un usuario puede enviar/recibir comunicaciones, y que puede servir como un punto final a comunicaciones en una red de comunicaciones. Dispositivos de usuario incluyen, pero no se limitan a: estaciones de trabajo, computadoras personales (por ejemplo, PCs); computadoras portátiles, computadoras de cuaderno; teléfonos (por ejemplo, línea terrestre o móvil); localizadores; dispositivos de la marca Blackberry™, dispositivos de PCs, asistentes digitales personales (PDAs), radios de dos direcciones (por ejemplo, "walkietalkie") , otros tipos de dispositi os de usuario, y cualquier combinación adecuada de los anteriores. Una red puede ser o incluir cualquiera de una variedad de tipos de redes que incluyen, pero no se limitan a, una red de área local (LAN), una red de área metropolitana (MAN), una red de área ancha (WAN), una red inalámbrica, una Red Móvil de Tierra pública (PLMN), un Sistema Global para red de Comunicaciones Móviles (GSM), una red de Servicio de Radio de Paquete General (GPRs), un Sistema de Telecomunicaciones Móviles Universal (UMPS), una red de Acceso Múltiple de División de Código (CDMA), una red óptica, una red de datos, una red amplia de empresa, una red de área personal inalámbrica (PAN), una red de hogar, una red de telecomunicaciones, una red de teléfono conmutada pública (PSTN), una red de banda ancha, otro tipo de red, o cualquier combinación de lo anterior. El dispositivo de red 102 puede incluir cualquiera de: una o más aplicaciones 108; sistema operativo 104; módulos de interfase de red 122; uno o más módulos de control de congestión (CCMs) 116; otros componentes; o cualquier combinación adecuada de lo anterior. El módulo de interfase de red 122 puede ser cualquiera de una variedad de tipos de componentes de red, tal como, por ejemplo, una tarjeta interfase de red (NIC). El módulo 122 puede configurarse para recibir paquetes 126 de la red 128, por ejemplo, una o más conexiones de red, y realizar operaciones en los paquetes. Por ejemplo, el módulo de interfase de red 122 puede realizar cualquiera de una variedad de operaciones bien conocidas. Además, el módulo 122 puede configurarse para generar marcas de tiempo para paquetes cuando se reciben. Por ejemplo, el generador de marca de tiempo 124 puede generar una marca de tiempo en un tiempo tan cerca como sea posible al tiempo en el cual se recibe cada paquete. La información que asocia la marca de tiempo 118 con el paquete (es decir, información de marca de tiempo) puede almacenarse en una estructura de datos (por ejemplo, una estructura de datos RED_MEMORIA INTERMEDIA o R E D_M E M OR I A INTERMEDIAS_LISTA de un sistema operativo de Windows® Vista™). Esta estructura de datos (o la información de marca de tiempo almacenada aquí) puede pasarse o hacerse accesible a la pila de comunicaciones de red 110. Como se describirá en mayor detalle más adelante, la información de marca de tiempo puede utilizarse para determinar congestión de red en una conexión de red. El sistema operativo 104 puede incluir cualquiera de: una o más estructuras de datos de control de transmisión 106; pila de comunicaciones de red 110; otros componentes; y cualquier combinación adecuada de lo anterior. La pila de comunicaciones de red 110 puede ser cualquiera de una variedad de tipos de pila de comunicaciones de red tal como, por ejemplo, una pila de TCP/IP. La pila de comunicaciones de red 110 puede configurarse para recibir paquetes 120 y control de conexiones en donde se reciben los paquetes 120 (y en donde los paquetes se transmiten) aunque no se muestra en la Figura 1 ó se discute a través de esta aplicación, se debe apreciar que la pila de comunicaciones de red 110 también puede configurarse para transmitir paquetes a la red 128, por ejemplo, a través del módulo de interfase de red 122. La pila 110 puede hacer uso de una o más estructuras de datos de control de transmisión 106 para controlar conexiones entre el dispositivo de red 102 y la red 128. Por ejemplo, para cada conexión, una estructura de datos de control de transmisión separada 106 puede utilizarse para almacenar y actualizar información que se. relaciona con la conexión (por ejemplo, información de estado), que pila 110 puede utilizar para controlar comunicaciones en las conexiones. La Estructura de datos de control de transmisión 106 puede ser o incluir cualquiera de una variedad de tipos de estructuras de datos, tal como, por ejemplo, un bloque de control de transmisión (TCB). Aunque las estructuras de datos de control de transporte 106 se muestran como recibiendo dentro del sistema operativo 104, la invención no se limita así. Tales estructuras pueden recibir en cualquiera de una variedad de ubicaciones en un dispositivo de red 102, que incluye en módulos de interfase de red 122. La pila 110 puede configurarse para detectar y/o determinar uno o más eventos de control de transporte, actualizar una o más estructuras de control de transmisión 106 por consiguiente, y/o reportar estos uno o más eventos de control de transporte 112 a uno o más CCMs 116. Estos eventos pueden incluir cualquiera de los siguientes: tiempo agotado de retransmisión de una conexión; regresar cambios de tiempo de viaje; nuevo conocimiento de datos; recepción de un conocimiento duplicado; enviar un nuevo paquete de datos; otros eventos de control de transporte o cualquier combinación adecuada de lo anterior. En un protocolo de capa de transporte típico (capa 4) (por ejemplo, TCP), cuando un dispositivo de red (por ejemplo, el receptor) recibe datos en una conexión, responde al dispositivo de red que envió los datos (por ejemplo, el remitente con un conocimiento (es decir, ACK). Una expiración de tiempo de retransmisión ocurre en el remitente (por ejemplo, dispositivo de red 102) para una conexión cuando un mensaje de conocimiento para datos previamente enviado por el remitente en la conexión no se recibió del receptor dentro de una cantidad de tiempo predefinida. La ocurrencia de una expiración de tiempo de retransmisión puede resultar en la retransmisión de los datos para los cuales ocurrió la expiración de tiempo. Un tiempo de viaje redondo (RTT) es una cantidad de tiempo que transcurre entre un remitente que envía datos a otra entidad y cuando el remitente envía un conocimiento de la otra entidad que se recibió en los datos. La información RTT puede utilizarse para establecer el cronómetro para expiración de tiempo de retransmisión. Un cambio de RTT ocurre cuando el RTT para una conexión dada cambia, por ejemplo, como un resultado de una congestión de red aumentada o disminuida en una conexión. Cuando se transmiten datos entre un remitente y receptor en una red, los datos frecuentemente se dividen en piezas, es decir, grupos de bytes, y estos grupos de bytes se envían en paquetes. Aunque las piezas de datos se transmiten en orden en el de cual se distribuyeron originalmente, las piezas de datos (y los paquetes que las combinan) pueden llegar en un orden diferente en el receptor. Un protocolo de capa de transporte típica, tal como, por ejemplo, TCP, mantiene el rastro del orden de las piezas y que piezas se recibieron en el receptor, y reensamblan las piezas en el orden apropiado. El receptor envía conocimientos a un remitente de un paquete que indica que piezas de datos que tiene recibió, y puede indicar aquellas piezas que aún no recibió. Por ejemplo, considerar datos divididos en piezas 1-9. Si el receptor de estos datos recibe piezas 1-20 en un paquete, 31-60 en otro paquete y 61-90 en un tercer paquete, puede enviar un conocimiento al remitente cada vez que recibe uno de estos paquetes. El conocimiento indica que piezas recibió, y también puede indicar que piezas de los datos no recibió. Por ejemplo, un receptor puede recibir un primer paquete que incluye piezas 1-20, y enviar un conocimiento que indica que recibió piezas 1-20. Entonces puede recibir un paquete que incluye piezas 31-60, y enviar un conocimiento que recibió 1-20 y 31-60 pero no piezas 21-30. Puede recibir otro paquete que incluye piezas 61-90, y enviar un conocimiento que recibió 1-20 y 31-90, pero no 21-30. De esa forma, el remitente puede recibir múltiples conocimientos del receptor que indica que el receptor aún no recibió piezas 21-30. Un nuevo conocimiento de datos es un primer conocimiento o inicial recibido por el remitente par una pieza de datos particular, de acuerdo con el protocolo de capa de transporte, que indica que la pieza de datos se recibió por el receptor. Un conocimiento duplicado es cualquier conocimiento diferente a un primer conocimiento que indica que una pieza particular de datos no se recibió por un receptor. La recepción del conocimiento duplicado puede ser indicativa de un todo (por ejemplo, piezas 21-30) en los datos recibidos por el receptor. La pila de comunicaciones de red 110 puede configurarse para detectar estos o uno o más eventos de control de transporte, y otros eventos, al examinar información relevante dentro de paquetes 120 recibidos del módulo de interfase de red 122. Es decir, además de procesar paquete 120 antes de pasar sus contenidos a una o más aplicaciones 108, la pila 110 también puede examinar información dentro de estos paquetes que controlan su transporte, que incluyen controlar congestión en la conexión(es) en donde se transmiten estos paquetes. En algunas modalidades, la pila 110 puede ser información de muestra menor que todos los paquetes que recibe. Este muestreo puede realizarse para reducir la cantidad de información de estado que es necesaria para mantenerse para cada conexión por su CCM 116 respectiva. La velocidad de muestreo para cada conexión puede determinarse basándose en una velocidad de transmisión y un RTP de la conexión. Tal muestreo puede realizarse como se describe más adelante en detalle con relación a las Figura 4-7. Como se utiliza aquí un "módulo de control de congestión" o "CCM" es una abstracción de software que define un CCA para controlar congestión en una o más conexiones. Cada CCM 116 puede corresponder sólo a una conexión entre dispositivo de red 102 y una entidad en la red 128, y cada CCM puede implementar un tipo particular de CCA. La pila de comunicaciones de red 110 puede reportar a un CCM 116 los eventos de control de transporte para una conexión para la cual el CCM controla congestión. Un CCM 116 puede mantener variables de estado de conexión para una conexión, y puede actualizar estas variables de estado en respuesta a eventos de control de transporte. El CCM puede proporcionar los valores actualizados de las variables de estado a la pila de comunicaciones de red 110, y la pila puede modificar su control de la conexión por consiguiente. Durante el tiempo de vida de una conexión dada, un CCM 116 puede distribuirse en una porción de memoria para controlar la conexión, y esta porción de memoria puede permanecer opaca a la pila 110 y estructuras de datos de control de transmisión 106. Esta porción de memoria puede obtenerse por el CCM y utilizarse para rastrear y actualizar las variables de estado de conexión utilizadas para controlar congestión en la conexión. La pila de comunicaciones de red 110 puede configurarse para seleccionar una de múltiples de CCMs disponible 116 para controlar congestión para una conexión dada. Esta selección puede basarse en cualquiera de una variedad de factores que incluyen, pero no se limitan a: ambiente de red; características de ruta de conexión; características de enlace de conexión; un valor de un parámetro de enchufe de una aplicación 108; otros factores y cualquier combinación adecuada de lo anterior. Es decir, CCMs 116 puede seleccionarse e implementarse en una base por conexión por la pila 110, y múltiples CCMs 116 pueden operar concurrentemente. Cada uno de estos CCMs puede ser de un tipo diferente, o dos o más de estos CCMs pueden ser del mismo tipo (es decir, correr un mismo tipo de CCA). En algunas modalidades de la invención, cuando ciertas versiones de Windows® (por ejemplo, Windows® Windows™) se emplean como un de sistema operativo, puede proporcionarse una interfase de programación de red (NPI). La NPI puede ayudar a desarrollar y configurar una interfase de red entre un dispositivo de red (por ejemplo, dispositivo 102) y una red (por ejemplo, 128). La NPI puede proporcionar una estructura de datos (por ejemplo, un Registro de Módulo de red (NMR)) que permite la asociación de una o más CCMs 116 con pila de comunicaciones de red 110. Por ejemplo, la pila 110 (por ejemplo, controlador tcp.sys en Windows® Vista™) puede registrarse como un cliente CCM, y una o más CCMs 116 pueden registrarse como "proveedores" de CCM. NPI para Windows® Vista™, que incluye el uso de NMR, se describe en más detalle en la biblioteca de Red de desabolladores de Microsoft (SMDN) en http://msdn.microsft.com/library dentro del siguiente directorio: tecnologías de dispositivo y controlador/Red/Red de ganado bovino de nombre de código de Windows. En algunas modalidades de la invención, un CCM puede generarse (por ejemplo, iniciarse) al utilizar una abstracción de tipo de CCM. Una abstracción de tipo de CCM puede definirse al utilizar una o más abstracciones de software predefinidas (por ejemplo, tipos de objeto), que pueden proporcionarse por un API de CCM, por ejemplo, como se describió más adelante con relación a la Figura 2.
La Figura 2 es un diagrama de bloques que ilustra un ejemplo de un sistema 200 para definir un tipo de CCM para controlar congestión en una conexión de red, de acuerdo con algunas modalidades de la invención. El sistema 200 es simplemente una modalidad ilustrativa del sistema para definir tipos de CCM, y no pretende limitar el alcance de la invención. Cualquiera de numerosas otras implementaciones de tal sistema, por ejemplo, variaciones de sistema 200, son posibles y pretenden caer dentro del alcance de la invención. Como será más evidente a partir de la siguiente descripción, en algunas modalidades de la invención, el sistema 200 solo y/o en combinación con el sistema 100 proporciona una o más de las siguientes propiedades: una forma fácil de implementar cualquiera de una variedad de tipos de CCA; la capacidad para alguien (por ejemplo, un programador o desarrollador) para escribir un CCA sin tener que observar el código de TCP; la capacidad de seleccionar un CCM de una pluralidad de CCMs disponibles en una base por conexión, por ejemplo, basándose en el ambiente de red, características de ruta y/o enlace, a través de una opción de enchufe, etc.; la disponibilidad de controlar cuántos datos se envían en una conexión; y la capacidad de controlar que bytes de datos se envían en una conexión. El sistema 200 puede incluir cualquiera de: un ambiente de desarrollo de software 202; interfase de programación de aplicación (API) de CCM 204; otros componentes; o cualquier combinación adecuada de lo anterior. Como utiliza aquí, una "interfase de programación de aplicación" o "API" es un grupo de una o más instrucciones legibles por computadora que proporcionan acceso a uno o más otros grupos de instrucciones legibles por computadora que definen funciones y/o tipos de datos, para que tales funciones y/o tipos de datos puedan configurarse para ejecutarse en una computadora en conjunto con un programa de aplicación. Una API puede considerarse el "pegamento" entre programas de aplicación y un ambiente de computadora particular o plataforma (por ejemplo, cualquiera de aquellas discutidas aquí) y puede permitir a un programador programar aplicaciones para correr en una o más plataformas de computadora particulares o en uno o más ambientes de computadora particulares. Un tipo de CCM puede desarrollarse en el ambiente de desarrollo de software 202 en al menos parte al utilizar API de CCM 204, que puede proporcionarse por un sistema operativo (por ejemplo, 104) de un dispositivo de red (por ejemplo, 102). En algunas modalidades de la invención, API de CCM 204 puede ser, o puede incluirse como parte de, una NPI de un sistema operativo tal como, por ejemplo, Windows® Vista™.
API de CCM 204 puede incluir cualquiera de: una o más abstracciones de CCA 205; una o más abstracciones de venta de control de transporte 206; otros componentes; o cualquier combinación adecuada de lo anterior. Cada abstracción de evento de control de transporte 206 puede definir un evento de control de transporte particular tal como, por ejemplo, cualquiera de los eventos de control de transporte descritos anteriormente. Además, API de CCM 204 puede proporcionar una o más abstracciones de CCA 205. Cada abstracción de CCA puede definir un tipo particular de CCA tal como, por ejemplo, una CCA predeterminada, Nuevo Reno; CTCP; HSTCP; BIC; Rápido; otros tipos de de CCAs, o cualquier combinación adecuada de lo anterior. De esa forma, API de CCM puede exponer una o más abstracciones de CCA 205, una o más abstracciones de evento de control de transporte 206 y otras abstracciones que definen información que puede utilizarse por un ambiente de desarrollo de software 202 para definir una o más abstracciones de tipo de CCM 208, para los cuales puede generarse una o más CCMs. Por ejemplo, en algunas modalidades en donde se emplea Windows® Vista™, uno o más tipos de CCM puede unirse con una o más abstracciones 205 y 206 al registrarse con un NMR. En tal modalidad, la pila de comunicaciones de red 110 (por ejemplo, tcpip.sys) puede registrarse como un cliente de CCM, y múltiples abstracciones de tipo de CCM 208 pueden registrarse con la pila 110 utilizando el NMR.
En algunas modalidades de la invención, API de CCM 204 y ambiente de desarrollo de software 202 puede ser parte de una estructura de CCM proporcionada por el sistema 200, que puede utilizarse para ayudar a desarrollar tipos de CCM. Como se utiliza aquí, una "estructura" es una estructura de diseño reutilizable que incluye uno o más componentes de soporte predefinidos (por ejemplo, abstrae y/o concreta clases de un lenguaje de programación orientado a objetos) que ayuda a construir aplicaciones. De esa forma, una "estructura de CCM" es una estructura de diseño reutilizable que incluye uno o más componentes de software predefinidos (por ejemplo, abstracciones de CCA 205, abstracciones de evento de control de transporte 206, otras abstracciones, y cualquier combinación adecuada de lo anterior), que ayuda a construir abstracciones de tipo de CCM. En algunas modalidades de las invenciones, la abstracción(es) de evento de control de transporte 206 y abstracción(es) que define información asociada con eventos de control de transporte se definen al utilizar el lenguaje de programación C. Tales alteraciones pueden incluir, pero no se limitan a, cualquiera de los siguientes: tipodef enúm { CcmEventodeTiempoagotado = 0x1, CcmRttEventoMuestra, CcmEventoAckAcumulativo, CcmEventoAckDuplicado, Ccm En viarE vento } CcmTipodeEvento; tipodef estruct { PU LARGO Cwns; PU LARGO Ss Trillar; } CCM_CONGESTION_ESTADO_INFORMACION: tipode estruct { BOOLEAN EnRecuperación; ULARGO RecupreciónUna; ULARGO RecuperaciónSig; ULARGO Recuperación Máx; }CC M_PER DI DA_REC U PE RACIONJN FORMACION; tipodef estruct { ULARGO Retransmitir Cuenta; ULARGO Mss; ULARGO SendWnd; ULARGO MáxSndWnd; }CCM_RETRANSMITIR_TIEMPOAGOTADO_IN FORMACION; tipodef estruct { ULARGO SRtt; ULARGO RttVar; ULARGO RttMuestra: }CCM_RTT_MUESTRA_IN FORMACION; tipodef estruct { ULARGO SecAcked; ULARGO BytesAcked; ULARGO Mss; ULARGO SndWnd; ULARGO MáxSndWnd; #sidef_cmásmás CCM_PERDIDA_RECUPERACION_IN FORMACION Recuperación; #también CCM_PERDIDA_RECUPERACION_IN FORMACION; #term inarsi }CCM_ACUMULATIVO_ACK_IN FORMACION; tipodef estruct { ULARGO DupAckCuenta; ULARGO SndUna; ULARGO Mss; ULARGO SndWnd; ULARGO MáxSndWnd; #sidef_cmásmás CCM_PERDIDA_RECUPERACION_IN FORMACION Recuperación; #también CCM_PERDIDA_RECUPERACION_IN FORMACION; #f i n s i }CCM_DUPLICADO_ACK_IN FORMACION; tipodef estruct { ULARGO SecNúmero; ULARGO EnviarLongitud; }C C M_E VI A R_PAQUETE_IN FORMACION: tipodef NTESTADO (NTAPI*PCCM_PROVEEDOR_NOTIFICAR_EVENTO)( EN CONTROL TcpCcmEstado, EN Ccm EventoTipo CcmEvento, EN PVACIO Ccmlnformación, Salida PCCM_CONGESTION_ESTADO_INFORMACION Estado de Congestión ); Se debe apreciar que otra abstracción que define otros eventos e información relacionada puede proporcionarse por API de CCM 204, y puede removerse o agregarse de/hacia la API con el tiempo. Además, en algunas modalidades de las invenciones, una o más abstracciones de CCA expuestas por API de CCM 204 se definen al utilizar el lenguaje de programación C. Tales abstracciones pueden incluir, pero no se limitan a, ninguno de los siguientes: tipodef enum { TcpCcm Predeterminado, TcpCcmNuevoReno, TcpCcmCtcp, TcpCcm Hstcp, TcpCcm Bic, TcpCcmRápido, TcpCcmReservadol, TcpCcmReservado2, TcpCcmReservado3, TcpCcm M AX JTcpCcmTipo; Se debe apreciar que otras abstracciones que definen otros CCAs e información relacionada pueden proporcionarse por API de CCM 204, y pueden removerse o agregarse de/a la API con el tiempo. En modalidades en donde se emplea Windows® Vista™, una abstracción de tipo CCM 208 puede registrarse para implementar uno de los CCAs anteriores. Por ejemplo, una abstracción de tipo CCM puede definirse, al menos en parte, al utilizar la siguiente abstracción definida en el lenguaje de programación C. tipodef estruct_CCM_PROVEEDOR_CARACTERISTICAS { UCORTO Versión; UCORTO Longitud; // //Algoritmo de control de congestión que este proveedor implementa // TcpCcmTipo Ccm Algoritmo; // // Estado de control de congestión que este algoritmo requiere.
El // tamaño se especifica en bytes // ULARGO Tamaño; }CCM_PROVEEDOR_CARACTERISTICAS; En algunas modalidades en donde se emplea el lenguaje de programación C. Una abstracción de tipo CCM puede utilizar una de las siguientes abstracciones que definen funciones para inicio y limpieza de un CCM: tipodef NTESTADO (NTAPI*PCCM_PROVEEDOR_INICIAR_CONEXION)( DENTRO FUERA CONTROL TcpCcmEstado ); tipodef NTESTADO (NTAPI*PCCM_PROVEEDOR_LIMPIEZA_CONEXION)( DENTRO FUERA CONTROL TcpCcmEstado ); tipodef estruct_CCM_PROVEEDOR_DISTRIBUIR{ UCORTO Versión; UCORTO Longitud; // //Iniciar conexión con estado de congestión especifico de proveedor // PCCM PROVEEDOR_INICIAR_CONEXION Ccmlniciar; // //Limpieza // PCCM_PROVEEDOR_LIMPIEZA_CONEXION Ccm Limpieza; // //Notificar Evento Ccm // PCCM_PROVEEDOR_NOTIFICAR_EVENTO Ccm Notif ¡carEvento; }CC _PROVEEDOR_DISTRIBUIR, *PCCM_PROVEEDOR_DISTRIBUR; Los sistemas 100 y/o 200 y sus componentes, pueden implementarse al utilizar cualquiera de una variedad de tecnologías, que incluyen software (por ejemplo, C, C#, C + + , Java, o una combinación de los mismos), hardware (por ejemplo, uno o más circuitos integrados específicos de aplicación), firmware (por ejemplo, memoria electrónicamente programada) o cualquier combinación de los mismos. Uno o más de tos componentes de sistema de 100 y/o 200 pueden recibir en un dispositivo individual (por ejemplo, una computadora), o uno o más componentes pueden recibir en dispositivos separados, individuales. Además, cada componente puede distribuirse a través de múltiples dispositivos, y uno o más de los dispositivos pueden interconectarse. Además, en cada uno de uno o más dispositivos que incluyen uno o más componentes de sistema 100 a 200 cada uno de los componentes puede recibir en una o más ubicaciones en el sistema. Por ejemplo, diferentes porciones de los componentes de estos sistemas pueden residir en diferentes áreas de memoria (por ejemplo, RAM, ROM, disco, etc.) en el dispositivo. Cada uno de uno o más servicios pueden incluir, entre otros componentes, una pluralidad de componentes conocidos tal como uno o más procesadores, un sistema de memoria, un sistema de almacenamiento de disco, una o más interfases de red, y uno o más conductores comunes u otros enlaces de comunicación interna que interconectan a los varios componentes. Los sistemas 100 y/o 200, y componentes de los mismos, pueden im plementarse al utilizar un sistema de computadora tal como el descrito más adelante en relación con las Figuras 8 y 9. La Figura 3 es un cuadro de flujo que ilustra un ejemplo del método 300 de controlar congestión en una conexión de red, de acuerdo con algunas modalidades de la invención. El método 300 es simplemente una modalidad ilustrativa de un método para controlar congestión en una conexión de red y no pretende limitar el alcance de la invención. Numerosas otras implementaciones, por ejemplo, variaciones del método 300, son posibles y pretenden caer dentro del alcance de la invención. En el acto 302, un tipo de control de congestión puede seleccionarse, por ejemplo, por una pila de comunicaciones de red (por ejemplo, pila 110) como se describió anteriormente con relación al sistema 100.
En el acto 304, un CCM del tipo seleccionado puede generarse (por ejemplo, de una abstracción de tipo de CCM 208), y en el acto 306, la congestión de red en una conexión puede controlarse al utilizar el CCM generado. Cada uno de los actos 304 y 306 puede realizarse como se describió anteriormente en relación a los sistemas 100 y 200. Durante la vida de la conexión, en el acto 308, el módulo de control de congestión generado puede notificarse de uno o más eventos de transporte, por ejemplo, por pilas 110 como se describió anteriormente con relación al sistema 100. En el acto 310, el valor de una o más variables de estado de conexión puede actualizarse (por ejemplo, por el CCM generado) basándose en uno o más eventos de transporte, y en el acto 312, la pila de comunicaciones de red pueden notificarse (por ejemplo, por el CCM) del valor actualizado a una o más variables de estado de conexión, por ejemplo, como se describió anteriormente con relación al sistema 100. El control de la conexión puede modificarse en el acto 314 (por ejemplo, por la pila 110) basándose en el valor actualizado de una o más variables de estado de conexión, por ejemplo, como se describió anteriormente con relación al sistema 100. El método 300 puede incluir actos adicionales. Además, el orden de los actos realizados como parte del método 300 no se limita al orden ilustrado en la Figura 3, ya que los actos pueden realizarse en otros órdenes y/o uno o más de los actos puede realizarse en paralelo, al menos parcialmente. Por ejemplo, cualquiera de los actos 308-314 puede realizarse para uno o más eventos o variables concurrentemente al desempeño de cualquiera de los actos para otra conexión. La pila de comunicación de red 110 puede adaptar una cantidad significativa de memoria al registrar eventos de control de transporte, por ejemplo, como parte de implementar un CCA basado en retraso. Es decir, una cantidad masiva de información de estado puede mantenerse para cada conexión. En algunas modalidades de la invención, la cantidad de memoria consumida por la información de estado por conexión se reduce al mostrar información menor que todos los paquetes transmitidos y/o recibidos en una o más conexiones. La información puede ser muestreada de menos que todos los paquetes mientras aún mantiene una velocidad de muestreo suficientemente alta para detectar congestión en una forma de tiempo, por ejemplo, al detectar un cambio en el RTT para una conexión. Si la velocidad de muestreo fuera demasiado baja, entonces la determinación de congestión puede ser demasiado tarde para modificar la transmisión de información en la conexión para prevenir un sobreflujo de una memoria intermedia de cuello de botella. En algunas modalidades de la invención, la velocidad de muestreo de una conexión se basa en un producto de retraso de ancho de banda (BDP) de la conexión; es decir, el producto de una velocidad de conexión de una conexión y el RTT de la conexión (es decir, velocidad*RTT) . De esa forma, si la velocidad de conexión se expresan en megabytes por segundo (Mbps) y RTT se expresa en segundos, entonces BDP puede expresarse en unidades de bits o bytes. Una ventana de congestión para una conexión puede determinarse basándose en BDP de la conexión. Como se utiliza aquí, una "ventana de congestión" es una cantidad máxima de datos que se permite "al momento" para una conexión dada en cualquier momento dado. Por ejemplo, la ventana de congestión puede definir el número máximo de paquetes para una conexión que: 1) se transmitió; y 2) para el cual aún no se recibe conocimiento. Una pila de comunicaciones de red (por ejemplo, 110) puede configurarse para utilizar el valor de una ventana de control de congestión para controlar la transmisión de datos en la conexión, para que no más del número permitido máximo de paquetes de la conexiones estén al momento (es decir, no más de la ventana de congestión) hasta que se recibe un conocimiento para uno de los paquetes al momento. El Cuadro 1 más adelante ilustra velocidades de muestreo, para una conexión que tiene RTT de 100 ms, que los inventores determinaron por experimento para tener un balance aceptable de: 1) la cantidad de memoria consumida para mantener información de estado para la conexión; y 2) la capacidad de identificar congestión en la conexión en una forma tiempo. Una velocidad de muestreo es el número de paquetes transmitidos en una conexión de los cuales se muestrea información, por ronda. Una "ronda" se define como sigue. Se considera una conexión cuyos datos sólo iniciaron a transmitirse.
En respuesta a un conocimiento (es decir, "ACK") para la primera pieza de datos (es decir, "segmento") se transmitió al recibirse, un número de secuencias (descrito más adelante; u otro identificador) de un último segmento de los datos que se transmitieron pero que un ACK no se recibió puede registrarse (por ejemplo, en una variable llamada "fin de ronda"). La ronda termina cuando se recibe un ACK para este último segmento. La primera columna en el Cuadro 1 indica la velocidad de la conexión. La segunda columna indica la ventana de congestión (en unidades de paquete) definida para la conexión para: RTT = 100 ms; y la velocidad de conexión definida en la primera columna. La tercera columna define la velocidad de muestreo aceptable, en unidades de paquetes muestreados por ronda, que se determinó experimentalmente. Por ejemplo, la tercera fila indica que, para una velocidad de conexión de 1 Gbps y RTT de 100 ms, para los cuales se definió una ventana de congestión de 8,333 paquetes, una velocidad de muestreo de 128 paquetes por ronda se determinó para ser aceptable. Se debe apreciar que la presente invención no se limita a los valores mostrados en el cuadro, ya que de otros valores pueden utilizarse y pretenden caer dentro del alcance de la invención.
Cuadro 1: Velocidades de Muestreo para Diferentes Velocidades de Conexión para RTT de 100 ms La Figura 4 es un cuadro 400 que ilustra un ejemplo de velocidades de muestreo para conexiones para ciertas combinaciones de una velocidad de conexión y RTT, de acuerdo con algunas modalidades de la invención. Se debe apreciar que la invención no se limita a los valores mostrados en la Figura 5, como otros valores pueden utilizarse y pretenden caer dentro del alcance de la invención . Las velocidades de muestreo en la columna 404 corresponden a las velocidades de muestreo mostradas en la tercera columna del Cuadro 1 anterior. Las columnas 406-412 ilustran que para una velocidad de conexión dada, una velocidad de muestreo designada es una función de RTT. Para una velocidad de conexión dada (es decir, una fila dada), una posición más a la derecha en el cuadro 400 corresponde a un RTT superior, y una velocidad de muestreo superior correspondiente que se designa, con la velocidad de muestreo que se cubre en 256 paquetes por segundo sin importar la velocidad de conexión y RTT. En algunas modalidades de la invención, un grupo de memoria se comparte entre múltiples (por ejemplo, todas) conexiones en dispositivo de red, o, en una modalidad de procesador múltiple, por múltiples (por ejemplo, todas) conexiones para un procesador dado, para los propósitos de muestrear información para controlar congestión. Este grupo puede ser de un tamaño fijo, y ranuras del grupo de memoria pueden distribuirse y no distribuirse a conexiones (por ejemplo, por una pila de comunicaciones de red, por ejemplo 110) en una base necesaria. Es decir, la cantidad de memoria (es decir, el número de ranuras) del grupo de memoria distribuido en una conexión puede basarse en los datos actualmente que se transmiten y/o reciben de una conexión. Como se utiliza aquí, el término "intercambiado" significa transmitido y/o recibido. De esa forma, la cantidad de memoria distribuida a cada conexión no se basa únicamente en BDP calculado de la conexión, en lugar de esto la cantidad de datos realmente que se intercambia en la conexión. Por ejemplo, una conexión intermitente puede aumentar su ventana de congestión a un gran valor (es decir, un valor igual a BDP para la conexión), y como un resultado distribuirse más memoria del grupo. Sin embargo, la conexión no continuará distribuyendo la cantidad aumentada de memoria a menos que mantenga la velocidad de intercambio de datos; es decir, a menos que mantenga la cantidad de datos al momento definida por su ventana de congestión.
Esta técnica para compartir un grupo de memoria entre conexiones en una base necesaria, para el propósito de control de congestión, es un uso más eficiente de memoria que pre distribuye memoria a conexiones (por ejemplo, basándose puramente en BDP) sin importar los datos reales intercambiados en las conexiones. En algunas modalidades de la invención, la siguiente estructura de datos puede utilizarse para definir una muestra: tipodef estruct_CTCP_RTT_MUESTRA{ SEC_NUM Sec; //Enviar Secuencia ULARGO Tiempo; //Enviar Tiempo }CTCP_RTT_MUESTRA. *PCTC P_RTT_M U ESTRA; y la siguiente estructura de datos puede utilizarse para registrar y rastrear información muestreada de paquetes para el propósito de controlar congestión en una conexión: #definirCTCP_DWND_RTT_MUESTRAS_NUM 32 tipodef estruct_CTCP_RTT_MUESTRA_CUADRO { LISTA_ENTRADA Enlace; CTCT_RTT_MU ESTRA RttMuestras[CTCP_DWND_RTT_MUESTRAS_NUM]; }CTCP_RTT_MUESTRA_CUADRO, *PCTCP_RTT_MUESTRA_CUADRO; Las definiciones de estructuras de datos anteriores pueden utilizarse para construir la estructura de datos ilustrada en la Figura 5. La Figura 5 es un diagrama de bloques que ilustra un ejemplo de una estructura de datos 500 para almacenar información muestreada de paquetes recibidos en una conexión, de acuerdo con algunas modalidades de la invención. La Figura 5 es simplemente una modalidad ilustrativa de una estructura de datos para almacenar información muestreada de paquetes recibidos en una conexión, y no pretende limitar el alcance de la invención. Otras estructuras de datos, por ejemplo, variaciones de estructura 500, pueden utilizarse y pretenden caer dentro del alcance de la invención. La estructura de datos 500 puede ser una memoria intermedia circular, y puede incluir múltiples ranuras de memoria, que incluyen ranuras de memoria 502 y 512, cada una que incluye una pluralidad (por ejemplo, 32) ranuras tal como, por ejemplo, ranuras 504-508 y 514-518, respectivamente. El índice 520 ("Enviar Siguiente") indica la siguiente posición en la memoria distribuida para la conexión en la cual la información muestreada se almacenará. El índice 510 ("Recibir Siguiente") indica la siguiente entrada que incluye información muestreada para la cual una ACK correspondiente a la información muestreada se espera (por ejemplo, una entrada previa para lo cual no se recibió un ACK). Por ejemplo, la entrada 506 ya puede incluir una marca de tiempo generada para una pieza de información cuando un paquete que incluye la pieza de información se transmitió en la conexión, y para lo cual aún no se recibió un ACK, pero se espera después cuando el ACK para un paquete que corresponde a la pieza de información se recibe, la marca de tiempo del paquete puede agregarse a la entrada 506. La diferencia entre las dos marcas de tiempo ahora incluidas en la entrada puede utilizarse para determinar RTT para la pieza de información. Este RTT puede utilizarse para determinar un cambio en RTT, que puede ser un evento de control de congestión, puede reportarse aún CCM para la conexión, y puede resultar en un cambio en distribución de memoria como se describe más adelante. Los índices 510 y 520 pueden utilizarse para determinar la cantidad de datos al momento para una conexión en un tiempo dado. Por ejemplo, la cantidad de datos al momento para una conexión en un tiempo dado puede determinarse como Cuadro de Muestra RTT [Enviar Siguiente]. Sec- Cuadro de Muestra de RTT [Recibir Siguiente], Sec. Para verificar un número real de muestras distribuidas a una conexión, dos variables por conexión pueden utilizarse: Muestras Reales; y Muestras Asignadas. Muestras Reales pueden rastrear un número exacto de bloques realmente distribuidos a una conexión. Muestras Asignadas puede ser la cantidad que la conexión puede potencialmente utilizar, que se basa en la ventana de congestión para la conexión. Sin embargo, la memoria realmente no se distribuye (y se refleja por Muestras Reales) a menos que la conexión realmente intenté enviar una ventana de congestión valiosa de datos. Las Muestras Asignadas siempre son >= Muestras Reales.
Cuando se crea una conexión, la conexión puede (por ejemplo, predeterminado) asignarse a un bloque individual de 32 muestras, y Muestras Asignadas pueden establecerse igual a Muestras Reales; es decir, ambas pueden establecerse igual al 1 (es decir, 1 bloque de datos). Mientras los datos se envían en la conexión, los Índices 510 y 520 pueden rastrear la cantidad de datos al momento, por ejemplo, Cuadro de Muestra RTT [Enviar Siguiente]. Sec- Cuadro de Muestra RTT [Recibir Siguiente], Sec. La siguiente entrada dentro de la estructura de datos 500 en donde se almacena una muestra puede determinarse basándose en las muestras asignadas; por ejemplo, (Enviar Siguiente + 1)% Muestras Asignadas *CTCP_DWND_RTT_MUESTRAS_NUM. Si este valor calculado es mayor que Muestras Reales *CTCP_DW D_RTT_MU E STR A_N U M , entonces un nuevo bloque (por ejemplo, otras entradas de 32 muestras) puede distribuirse del grupo de memoria y el valor de Muestras Reales puede aumentar por 1. Si la distribución de uno o bloque de falla, entonces las Muestras Asignadas pueden establecerse igual a Muestras Reales, y el valor de índice 520 ("Enviar Siguiente") recalculado. Si la estructura de datos 500 está llena (es decir, la cantidad de memoria realmente distribuida a la conexión encontró la cantidad de memoria asignada), entonces la muestra puede no registrarse. Una muestra puede registrarse mientras la velocidad de muestreo para la conexión dada lo permite (y existe un espacio de memoria aún disponible en el grupo). Por ejemplo, por Cuadro 1 y Figura 4, si la velocidad de conexión (es decir, ancho de banda) para la conexión es 1 Gbps y RTT actualmente se establece en 100 ms, 128 muestras (por ejemplo, 4 bloques de valor de espacio de memoria) puede muestrearse por ronda, es decir, por ventana de congestión. Uno o más eventos pueden realizarse al final de cada ronda. Como se notó anteriormente, una ronda termina cuando se recibe un ACK para el último segmento de una ronda. Por ejemplo, cuando una ronda termina, la ventana de congestión puede recalcularse, y la velocidad de muestreo puede reconf igurarse como (ventana de congestión recalculada) % Muestras Asignadas *CTCP_DWND_RTT_MUESTRA_NUM. Además, cuando una ronda termina, puede decidirse si existen entradas no utilizadas de la estructura de datos 500 que se distribuyeron a la conexión que pueden liberarse de nuevo en el grupo de memoria. Esta decisión puede basarse en donde índices 510 y 520 se distribuyen dentro de la estructuras de datos 500. Por ejemplo, para un bloque particular (por ejemplo, 502 ó 512), si 510 y 520 no están en un bloque, el bloque puede liberarse (y pueden reajustarse variables de estado de conexión). Si 510 y 520 están en un mismo bloque, todos los bloques en la estructura de datos 500, si hay alguna siguiendo tal bloque puede liberarse. En una modalidad en la cual la estructura de datos 500 es una memora intermedia circular, otra técnica es localizar índice 520 ("Enviar Siguiente") en la estructura de datos 500, y eliminar todos los bloques siguientes hasta que el bloque que tiene una entrada a la cual el índice 510 ("Recibir Siguiente") señala. Al utilizar las técnicas de distribución/no distribución de memoria antes descrita, si una conexión siempre transmite una cantidad de datos conmensurados con esta ventana de congestión, entonces la memoria distribuida del grupo de memoria (por ejemplo, bloques de estructura de datos 500) no se libera. De otra forma, el espacio de memoria no utilizado se regresa al grupo de memoria, y puede utilizarse por otras conexiones. La Figura 6 es un cuadro de flujo que ilustra un ejemplo de un método 600 para controlar congestión en una conexión de red, de acuerdo con algunas modalidades de la invención, por ejemplo, basándose en la discusión anterior de muestreo RTT. Se debe apreciar que el método 600 meramente es una modalidad ilustrativa de un método para controlar congestión en una conexión de red, y no pretende limitar el alcance de la invención. Cualquiera de numerosos otras implementaciones de tal método, por ejemplo, variaciones del método 600, son posibles y pretenden caer dentro del alcance de la invención. En el acto 602, una velocidad a la cual la información de muestra de paquete es recibida en la conexión se determina basándose al menos en parte en una velocidad de transmisión de la conexión y un tiempo de viaje redondo para la conexión, por ejemplo, como se describió anteriormente. Una porción de un grupo de memoria (por ejemplo, uno o más bloques de estructuras de datos 500) puede distribuirse a la conexión en el Acto 604 basándose en la velocidad de muestreo determinada.
En el acto 606, la información de paquetes recibidos en la conexión puede muestrearse a la velocidad de muestra determinada, y, en el acto 608, la información muestreada puede almacenarse en la porción distribuida de memoria, por ejemplo, en una entrada de estructura 500. Además, en el acto 607, la información puede muestreada de paquetes entrantes recibidos en una conexión, en donde estos paquetes corresponden a paquetes muestreados en el acto 606, y esta información puede almacenarse en la memoria distribuida. Por ejemplo, como se describió anteriormente, una marca de tiempo para una pieza de información (es decir, un segmento) puede almacenarse en una entrada de estructura de datos 500. Cuando un paquete se recibe posteriormente que incluye un ACK para la pieza de información, la marca de tiempo para este paquete puede almacenarse en la misma entrada. En el acto 610, la congestión en la conexión de red puede controlarse basándose al menos en parte en la información muestreada. Por ejemplo, como se describió anteriormente, el RTT de una pieza de información puede determinarse basándose en las dos marcas de tiempo muestreada para una pieza de información, y este RTT puede utilizarse para controlar congestión. Por ejemplo, al final de una ronda, puede determinarse que el RTT de una conexión cambió, y esto puede reportarse al CCM correspondiente, que puede modificar su control de congestión en la conexión por consiguiente, como se describió anteriormente. Como se muestra por la flecha que señala del acto 610 al acto 602, el control de congestión en una conexión y la cantidad de memoria y el grupo de memoria distribuida a la conexión puede ajustarse basándose en la información muestreada. El método 600 puede incluir actos adicionales. Además, el orden de los actos realizados como parte del método 600 no se limita al orden ilustrado en la Figura 5, ya que los actos pueden realizarse en otros órdenes y/o uno o más de los actos puede realizarse paralelo, al menos parcialmente. Por ejemplo, cualquiera de los actos 602-510 puede realizarse para una conexión y actualmente cualquiera de los actos 602-510 se realiza para otra conexión. Algunos sistemas operativos proporcionan una API que proporciona una cuenta en funcionamiento que puede utilizarse por aplicaciones en el sistema operativo. Por ejemplo, algunos sistemas operativos disponibles de Microsoft Corporation proporcionan una API llamada KEContadordeDesempeñodeConsulta, que proporciona la cuenta de funcionamiento de grano más fino disponible en el sistema operativo. Sin embargo, una llamada a esta API es muy costosa, y llamarla frecuentemente puede degradar el desempeño del dispositivo de red en donde reside el sistema operativo. Por consiguiente, en algunas modalidades de la invención, una marca de tiempo (por ejemplo, marca el tiempo 118) para un paquete entrante (por ejemplo, 126) se genera en un módulo de interfase de red (por ejemplo, por generador de marca de tiempo 124 del módulo 122) que está separado del sistema operativo (por ejemplo, 104) y la pila de comunicaciones de red (por ejemplo, 110) del dispositivo de red (por ejemplo, 102) en donde se recibe el paquete. La marca de tiempo puede utilizarse para determinar una RTT de la conexión, que puede utilizarse para controlar congestión en la conexión, como se describirá en más detalle más adelante. La marca de tiempo puede capturarse en el módulo de interfase de red tan cerca como sea posible a un tiempo en donde se recibió un paquete, e incluirse dentro de una estructura de datos que se pone a disponibilidad para la pila de comunicaciones de red 110, como se describió más adelante en más detalle. De esa forma, para cada paquete recibido en el módulo de interfase de red, una marca de tiempo puede registrarse para reflejar más exactamente el tiempo en el cual se recibe el paquete que si la marca de tiempo se generará por el sistema operativo. De esa forma, incluso si hubiera un retraso entre cuando se recibe un paquete en el módulo de interfase de red y el tiempo que se envía la pila de comunicaciones de red, la marca de tiempo aún indica precisamente cuando el paquete realmente se recibió en el dispositivo de red. Además, los recursos de sistema operativo se liberan de la carga de generar la marca de tiempo, que puede proporcionar una solución menos costosa para controlar congestión en el dispositivo de red. La Figura 7 es un cuadro de flujo que ilustra un método 700 de congestión de control en una conexión de red entre un dispositivo de red y una red de comunicaciones, el dispositivo de red que comprende una pila de comunicaciones de red y un componente de interfase de red separado, de acuerdo con algunas modalidades de la invención. En el acto 702, un paquete (por ejemplo, 126) puede recibirse en la conexión de la red, por ejemplo, en el módulo de interfase de red 122 como se describió anteriormente. Una marca de tiempo (por ejemplo, 118) que corresponde a un tiempo en el cual se recibió el paquete puede generarse en el acto 704, por ejemplo, por un generador de marca de tiempo 124 del módulo 122. En el acto 706, la información que asocia la marca de tiempo con el paquete puede almacenarse en una estructura de datos accesibles por la pila de comunicaciones de red. Por ejemplo, en modalidades de la invención en donde el sistema operativo Windows® Vista™ se emplea, el acto 706 puede incluir almacenar la información que asocia la marca de tiempo con el paquete en una estructura de datos RED_MEMORI A y INTERMEDIA y/o RED_LISTA DE MEMORIA INTERMEDIA. El paquete puede enviarse a la pila de comunicaciones de red (por ejemplo, 110) en el acto 708, por ejemplo, como se describió anteriormente en relación al sistema 100. En el acto 710, un RTT de datos se envía del dispositivo de red a otra entidad de red puede determinarse basándose al menos en parte en la información que asocia la marca de tiempo y el paquete. Por ejemplo, una marca de tiempo pudo generarse cuando una pieza de datos se transmitió de un dispositivo de red a otra entidad de red. Un RTT de una conexión puede determinarse al determinar la diferencia entre la marca de tiempo que indica cuando esta pieza de datos se transmitió y la marca de tiempo generada en el acto 704 para un conocimiento que indica que la pieza de datos se recibió por la entidad de red. En el acto 712, la congestión de red puede determinarse basándose al menos en parte en el tiempo de viaje redondo determinado. Por ejemplo, si el RTT determinado en el acto 710 es indicativo de un cambio en RTT para la conexión, este cambio puede reportarse al CCM que controla congestión en la conexión, por ejemplo, como se describió anteriormente con relación al sistema 100. El CCM entonces puede actualizar variables de estado de conexión para la conexión, y reportar las variables actualizadas a las comunicaciones de re d *- p i I a (por ejemplo, 110) que entonces pueden alterar el control de la conexión, por ejemplo, como se describió anteriormente. El método 700 puede incluir actos adicionales. Además, el orden de los actos realizados como parte del método 400 no se limita al orden ¡lustrado en la Figura 4, ya que los actos pueden realizarse en otras órdenes y/o uno o más de los actos pueden realizarse en paralelo, al menos parcialmente. Por ejemplo, el acto 708 puede realizarse antes o concurrentemente al acto 706. Los métodos 300, 600 y 700, y actos de los mismos, varias modalidades y variaciones de estos métodos y estos actos y otras metodologías y técnicas descritas anteriormente, individualmente o en combinación, pueden definirse por señales legibles por computadora tangiblemente representadas en uno o más medios legibles por computadora, por ejemplo, medios de registro no volátiles, elementos de memoria de circuito integrados, o una combinación de los mismos. Los medios legibles por computadora puede ser cualquier medio disponible que puede accederse por una computadora. A manera de ejemplo, y no de limitación, los medios legibles por computadora pueden comprender medios de almacenamiento por computadora y medios de comunicación. Los medios de almacenamiento por computadora incluyen medios volátiles y no volátiles, removibles y no removibles implementados en cualquier método o tecnología para almacenamiento de información tal como instrucciones legibles por computadora, estructuras de datos, módulos de programa u otros datos. Los medios de almacenamiento por computadora incluyen, pero no se limitan a, RAM, ROM, EEPROM, memoria flash u otra tecnología de memoria, CD-ROM, discos versátiles digitales (DVD) u otro almacenamiento óptico, cassettes magnéticos, cinta magnética, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, otros tipos de memoria volátil y no volátil, cualquier otro medio que puede utilizarse para almacenar la información deseada y que puede accederse por una computadora, y cualquier combinación adecuada de lo anterior. Los medios de comunicación típicamente representan instrucciones legibles por computadora, estructuras de datos, módulos de programa y otros datos en una señal de datos modulada tal como una onda portadora u otro mecanismo de transporte e incluye cualquier medio de entrega de información. El término "señal de datos modulada" significa una señal que tiene una o más de sus características establecidas o cambiadas de tal forma para codificar información en la señal. A manera de ejemplo, y no de limitación, los medios de comunicación incluyen medios por cable tal como una red por cable o conexión por cable directa, medios inalámbricos tal como medios acústicos, RF, infrarrojos y otros inalámbricos, otros tipos de medios de comunicación, y cualquier combinación adecuada de los anteriores. Las señales legibles por computadora representadas en uno o más medios legibles por computadora pueden definir instrucciones, por ejemplo, como parte de uno o más programas, que, como un resultado de ejecutarse por una computadora, instruyen a la computadora a realizar una o más de las funciones descritas anteriormente (que incluyen métodos 300, 600 y 700 ó cualquiera de los actos de los mismos), y/o varias modalidades, variaciones y combinaciones de los mismos. Tales instrucciones pueden escribirse en cualquiera de una pluralidad de lenguajes de programación, por ejemplo, Java, J#, Visual Basic, C, C#, o C + + , Fortran, Pascal, IFEL, Básico, COBOL, etc., o cualquiera de una variedad de combinaciones de los mismos. Los medios legibles por computadora en donde tales instrucciones se representa o puede recibir en uno o más de los componentes de cualquiera de los sistemas 100, 200, 800 y 900 aquí descritos, pueden distribuirse a través de uno o más de tales componentes, y pueden estar en transición entre ellos. Los medios legibles por computadora puede ser transportables para que las instrucciones almacenadas en este puedan cargarse en cualquier recurso de sistema de computadora para implementar los aspectos de la presente invención discutidos aquí. Además, se debe apreciar que las instrucciones almacenadas en el medio legible por computadora, descrito anteriormente, no se limitan a instrucciones representadas como parte de un programa de aplicación que corre en una computadora huésped. En lugar de esto, las instrucciones pueden representarse como cualquier tipo de código de computadora (por ejemplo, software o microcódigo) que puede emplearse para programar un procesador para implementar los aspectos antes discutidos de la presente invención. Se debe apreciar que cualquier componente individual o conexión de múltiples componentes de un sistema de computadora, por ejemplo, cualquiera de los sistemas de computadora descritos en relación a las Figuras 1, 2, 8 y 9, que realizan las funciones descritas anteriormente pueden considerarse genéricamente como uno o más controladores que controlan tales funciones. Uno o más controladores pueden ¡mplementarse en varias formas, tal como con hardware y/o firmware dedicado, que utiliza un procesador que se programa al utilizar microcódigo o software para realizar las funciones mencionadas anteriormente o cualquier combinación r adecuada de lo anterior. Varias modalidades de acuerdo con la invención pueden implementarse en uno o más sistemas de computadora. Estos sistema de computadora, pueden ser, por ejemplo, computadoras de propósito general tal como aquellas basadas en procesadores de tipo de PENTIUM de Intel, PC de Energía de Motorola, Sun UltraSARC, procesadores de PA-RISC de Hewlett-Packard, cualquiera de una variedad de procesadores disponibles de Micro Dispositivos Avanzados (AMD) o cualquier otro tipo de procesador. Se debe apreciar que uno o más de cualquier tipo de sistema de computadora puede utilizarse para implementar varias modalidades de la invención. Un sistema de computadora de propósito general de acuerdo con una modalidad de la invención se configura para revisar una o más de las funciones descritas anteriormente. Se debe apreciar que el sistema pueda realizar otras funciones y la invención no se limita a tener ninguna función particular o grupo de funciones. Por ejemplo, varios aspectos de la invención pueden implementarse como software especializado que se ejecuta en un sistema de computadora de propósito general 800 tal como se muestra en la Figura 8. El sistema de computadora 800 puede incluir un procesador 803 conectado a uno o más dispositivos de memoria 804, tal como una unidad de disco, memoria, u otros dispositivos para almacenar datos. La memoria 804 típicamente se utiliza para almacenar programas y datos durante operación del sistema de computadora 800. Los componentes del sistema de computadora 800 pueden acoplarse por un mecanismo de interconexión 805, que puede incluir uno o más conductores comunes (por ejemplo, entre componentes que se integran dentro de una misma máquina) y/o una red (por ejemplo, entre componentes que residen en máquinas separadas individuales). El mecanismo de interconexión 805 permite comunicaciones (por ejemplo, datos, instrucciones) intercambiarse entre componentes del sistema 800. El sistema de computadora 800 también incluye uno o más dispositivos de entrada 802, por ejemplo, un teclado, ratón, seguibola, micrófono, pantalla táctil, y uno o más dispositivos de salida 801, por ejemplo, un dispositivo de impresión, una pantalla de presentación, bocina. Además, el sistema de computadora 800 puede contener una o más interfases (no mostradas) que conectan el sistema de computadora 800 a una red de comunicación (además de o cómo una alternativa al mecanismo de conexión 805). ( El sistema de almacenamiento 806, mostrado en mayor detalle en la Figura 9, típicamente incluye un medio de grabación legible por computadora y no volátil escribible 901 en donde las señales se almacenan y definen un programa para ejecutarse por el procesador o información almacenada en el medio 901 para procesarse por el programa. El medio, por ejemplo, puede ser un disco o memoria flash. Típicamente, en operación, el procesador causa que los datos se lean del medio de registro no volátil 901 en otra memoria 902 que permite acceso más rápido a la información por el procesador que lo hace al medio 901. Esta memoria 902 típicamente es una memoria de acceso aleatorio, volátil tal como una memoria de acceso aleatorio dinámica (DRAM) o memoria estática (SRAM). Puede localizarse en sistema de almacenamiento 806, como se muestra, o en sistema de memoria 804, no mostrado. El procesador 803 generalmente manipula los datos dentro de la memoria de circuito integrado 804, 902 y entonces copia los datos al medio 901 después que se completa el procesamiento. Una variedad de mecanismos se conocen para manejar movimiento de datos entre el medio 901 y el elemento de memoria de circuito integrado 804, 902, y la invención no se limita a esto. La invención no se limita a un sistema de memoria particular 804 ó sistema de almacenamiento 806. El sistema de computadora puede incluir hardware especialmente programado, de propósito especial, por ejemplo, un circuito integrado específico de aplicación (ASIC). Aspectos de la invención pueden implementarse en software, hardware o firmware, o cualquier combinación de los mismos. Además, tales métodos, actos, sistemas, elementos de sistema y componentes de los mismos pueden implementarse como parte del sistema de computadora descrito anteriormente o como un componente independiente. Aunque el sistema de computadora 800 se muestra a manera de ejemplo como un tipo de sistema de computadora en el cual pueden practicarse varios aspectos de la invención, se debe apreciar que aspectos de la invención no se limitan a implementarse en el sistema de computadora mostrado en la Figura 8. Varios aspectos de la invención pueden practicarse en una o más computadoras que tienen una arquitectura o componentes diferentes a los mostrados en la Figura 8. El sistema de computadora 800 puede ser un sistema de computadora de propósito general que es programable al utilizar un lenguaje de programación de computadora de alto nivel. El sistema de computadora 800 también puede implementarse al utilizar hardware especialmente programado, de propósito especial. En el sistema de computadora 800, el procesador 803 típicamente es un procesador comercialmente disponible tal como el procesador de clase de Pentium bien conocido disponible de Intel Corporation. Muchos otros procesadores están disponibles. Tal procesador usualmente se ejecuta en un sistema operativo que puede ser, por ejemplo, los sistemas operativos Windows® 95, Windows®' 98, Windows NT®, Windows® 2000 (Windows® ME) o Windows® XP disponibles de Microsoft Corporation, sistema X de MAC OS disponible de apple Computer, el sistema operativo de Solaris disponible de Sun Microsystems, Linux disponible de varias fuentes o UNIX disponible de varias fuentes. Cualquier otra variedad de otros sistemas operativos puede utilizarse. El procesador y sistema operativo juntos definen una plataforma de computadora para el cual se escriben programas de aplicación en lenguajes de programación de alto nivel. Se debe entender que la invención no se limita a una plataforma de sistema de computadora particular, procesador, sistema operativo, o red. También, debe ser evidente para aquellos expertos en la técnica que la presente invención no se limita a un lenguaje de programación específico o sistemas de computadora, y que otros lenguajes de programación apropiados y otros sistemas de computadora apropiados también deben utilizarse. Una o más porciones del sistema de computadora pueden distribuirse a través de uno o más sistemas de computadora (no mostrado) acoplados a una red de comunicaciones. Estos sistemas de computadora también pueden ser sistemas de computadora de propósito general. Por ejemplo, varios aspectos de la invención pueden distribuirse entre uno o más sistemas de computadora configurados para proporcionar un servicio (por ejemplo, servidores) a una o más computadoras de cliente, o para realizar una tarea total como parte en un sistema distribuido. Por ejemplo, varios aspectos de la invención pueden realizarse en un sistema de cliente-servidor que incluye componentes distribuidos entre uno o más sistemas de servidor que realizan varias funciones de acuerdo con varias modalidades de la invención. Estos componentes pueden ser ejecutables, intermedios (por ejemplo, IL) o código interpretado (por ejemplo, Java) que se comunican en una red de comunicación (por ejemplo, Internet) que utiliza un protocolo de comunicación (por ejemplo, TCP/IP). Se debe apreciar que la invención no se limita a ejecutarse en un sistema particular o grupo de sistemas, y que la invención no se limita a ninguna arquitectura distribuida particular, red, o protocolo de comunicación. Varias modalidades de la presente invención pueden programarse al utilizar un lenguaje de programación orientado objeto, tal como SmallTalk, Java, J#(J-Sharp), C + + , Ada, o C#(C-Sharp). Otros lenguajes de programación orientados a objeto también pueden utilizarse. Alternativamente, los lenguajes de programación funcionales, de escritura, y/o lógicos pueden utilizarse. Varios aspectos de la invención pueden implementarse en un ambiente no programado (por ejemplo, documentos creados en HTML, XML u otro formato que, cuando se observan en una ventana de un programa de navegador, presenta aspectos de una interfase de usuario gráfica (GUI) o realiza otras funciones). Varios aspectos de la invención pueden implementarse como elementos programados o no programados, o cualquier combinación de los mismos. Además, varias modalidades de la invención pueden implementarse al utilizar tecnología de Microsoft®. NET disponible de Microsoft Corporation. Ahora al haber descrito algunas modalidades ilustrativas de la invención, debe ser evidente para aquellos expertos en la técnica que lo anterior es simplemente ilustrativo y no limitante, al haber presentado a manera de ejemplo solamente. Numerosas modificaciones y otras modalidades ilustrativas están dentro del alcance de un experto en la técnica y se contemplan como que caen dentro del alcance de la invención. En particular, aunque muchos de los ejemplos aquí presentados involucran combinaciones específicas de actos de método o elementos de sistema, se debe entender que estos actos y esos elementos pueden combinarse en otras formas para realizar los mismos objetivos. Los actos elementos y aspectos discutidos solamente en conexión con uña modalidad no pretenden excluirse de un papel similar en otras modalidades. Además, para una o más limitaciones de medios más función mencionados en las siguientes reivindicaciones, los medios no pretenden limitarse a los medios aquí descritos para realizar la función mencionada, pero pretenden cubrirse en . alcance cualquiera de los medios equivalentes, ahora o posteriormente conocidos desarrollados, para realizar la función mencionada. El uso de términos ordinales tal como "primero", "segundo", "tercero", etc., en las reivindicaciones para modificar un elemento de reivindicación por sí mismo no connota ninguna prioridad, precedencia, u orden de un elemento de reivindicación sobre otro o el orden temporal en el cual los actos de un método se realizan, pero se utilizan simplemente como etiquetas para distinguir un elemento de reivindicación que tiene cierto nombre para otro elemento que tiene el mismo nombre (pero para uso de un término ordinal) para distinguir los elementos de reivindicación.

Claims (9)

REIVINDICACIONES
1.- Un sistema para crear un módulo de control de congestión para controlar congestión en una conexión de red, que comprende: una interfase de programación de aplicación que expone una o más abstracciones de evento para usarse para definir tipos de módulo de control de congestión del cual pueden generarse módulos de control de congestión, cada abstracción de evento define un evento de control de transporte. 2 - El sistema de acuerdo con la reivindicación 1, en donde la interfase de programación de aplicación expone una o más abstracciones de información que cada una define información para procesar los eventos definidos por las abstracciones de evento. 3. - El sistema de acuerdo con la reivindicación 1, en donde la interfase de programación de aplicación expone uno o más abstracciones de algoritmo de control de congestión que cada una define un algoritmo de control de congestión para controlar la congestión en una conexión de red. 4. - El sistema de acuerdo con la reivindicación 1, en donde la interfase de programación de aplicación se proporciona por un sistema operativo de un dispositivo de red. 5. - El sistema de acuerdo con la reivindicación 1 , en donde la abstracción de evento define dos o más de los siguientes eventos: expiración de tiempo de retransmisión en una conexión; regresar cambios de tiempo de viaje; nuevo conocimiento de datos; recepción de un conocimiento duplicado; y envío de un nuevo paquete de datos. 6. - Un sistema para controlar congestión en una o más conexiones de red entre un dispositivo de red y una red de comunicaciones, que comprende: una pila de comunicaciones de red operativa para controlar comunicaciones de red en una o más conexiones; y uno o más módulos de control de congestión, cada módulo de control de congestión definiendo un algoritmo de control de congestión para controlar congestión en uno respectivo de una o más conexiones de red y mantener una o más variables de estado de conexión para la conexión respectiva, en donde la pila de comunicaciones de red es operativa, para cada una de una o más conexiones, para notificar el módulo de control de congestión que controla congestión en la conexión de uno o más eventos de control de transporte que ocurren en la conexión. 7. - El sistema de acuerdo con la reivindicación 6, en donde cada módulo de control de congestión es operativo para actualizar una o más variables de estado de conexión en respuesta al notificarse de un evento de control de transporte que ocurrió en la conexión para la cual el módulo de control de congestión controla la congestión. 8. - El sistema de acuerdo con la reivindicación 7, en donde cada módulo de control de congestión es operativo para notificar a la pila de comunicaciones de red de una o más variables de estado de conexión actualizadas para la conexión para la cual el módulo de control de congestión controla la congestión. 9. - El sistema de acuerdo con la reivindicación 8, en donde la pila de comunicaciones de red es operativa para controlar comunicaciones de red en una o más conexiones basándose en una o más variables de estado de conexión actualizadas que recibe de uno o más módulos de control de congestión. 10. - El sistema de acuerdo con la reivindicación 6, que además comprende: una pluralidad de abstracciones de módulo de control de congestión, cada abstracción de módulo de control de congestión definiendo un tipo de módulo de control de congestión, en donde la pila de comunicaciones de red es operativa para seleccionar una primera de la pluralidad de abstracciones de módulo de control de congestión para una primera de una o más conexiones y para crear un primero de uno o más módulos de control de congestión de la primera abstracción de módulo de control de congestión. 11. - El sistema de acuerdo con la reivindicación 10, en donde, la pila de comunicaciones de red es operativa para seleccionar la primera de la pluralidad de abstracciones de módulo de control de congestión para una segunda de una o más conexiones y para crear un segundo de uno o más módulos de control de congestión de la primera abstracción de módulo de control de congestión. 1
2.- El sistema de acuerdo con la reivindicación 6, en donde la pila de comunicaciones de red es una pila TCP/IP. 1
3. - Un producto de programa de computadora que comprende: al menos un medio legible por computadora; y señales legibles por computadora, almacenadas al menos en un medio legible por computadora, que definen instrucciones que, como un resultado de ejecutarse por una computadora, controlan la computadora para realizar un método para controlar congestión en una conexión de red entre un dispositivo de red y una red de comunicaciones, el método comprende actos de: (A) seleccionar un primer tipo de control de congestión para una primera conexión; (B) generar un primer módulo de control de congestión del primer tipo; y (C) controlar congestión de red en la primera conexión utilizando el primer módulo de control de congestión. 1
4. - El producto de programa de computadora de acuerdo con la reivindicación 13, en donde el dispositivo de red tiene acceso a una pluralidad de abstracciones de módulo de control de congestión, cada abstracción de módulo de control de congestión define un tipo de módulo de control de congestión, en donde el acto (A) comprende seleccionar una primera de la pluralidad de abstracciones de módulo de control de congestión, la primera abstracción de módulo de control de congestión define el primer tipo de módulo de control de congestión, y en donde el acto (B) comprende generar el primer módulo de control de congestión utilizando la primera abstracción de módulo de control de congestión. 1
5. - El producto de programa de computadora de acuerdo con la reivindicación 13, en donde el método además comprende: (D) seleccionar el primer tipo de control de congestión para una segunda conexión; (E) generar un segundo módulo de control de congestión del primer tipo; y (F) controlar congestión de red en la segunda conexión utilizando el segundo módulo de control de congestión. 1
6. - El producto de programa de computadora de acuerdo con la reivindicación 13, en donde el método además comprende: (D) seleccionar un segundo tipo de control de congestión para una segunda conexión; (E) generar un segundo módulo de control de congestión del segundo tipo; y (F) controlar congestión de red en la segunda conexión utilizando el segundo módulo de control de congestión, en donde el segundo tipo es diferente al primer tipo. 1
7.- El producto de programa de computadora de acuerdo con la reivindicación 13, en donde los actos (A)-(C) se realizan a través de una pila de TCP/IP. 1
8.- El producto de programa de computadora de acuerdo con la reivindicación 13, que además comprende: (D) notificar al primer módulo de control de congestión de uno o más eventos de control de transporte que ocurren en la conexión. 1
9. - El producto de programa de computadora de acuerdo con la reivindicación 18, el método además comprende un acto de: (E) el primer módulo de control de congestión que actualiza una o más variables de estados de conexión en respuestas a la notificación . 20. - El producto de programa de computadora de acuerdo con la reivindicación 19, en donde los actos (A)-(C) se realizan por una pila de comunicaciones de red, en donde el acto (C) comprende controlar comunicaciones de red en las primeras conexiones basándose en una o más variables de estado de conexión actualizadas; y en donde el método además comprende un acto del primer módulo de control de congestión que notifica a la pila de comunicaciones de red de una o más variables de estado actualizadas.
MX2008013325A 2006-04-21 2007-04-23 Habilitar dispositivos de red para correr multiples algoritmos de control de congestion. MX2008013325A (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US79377406P 2006-04-21 2006-04-21
US11/507,403 US7782759B2 (en) 2006-04-21 2006-08-21 Enabling network devices to run multiple congestion control algorithms
PCT/US2007/009831 WO2007124154A1 (en) 2006-04-21 2007-04-23 Enabling network devices to run multiple congestion control algorithms

Publications (1)

Publication Number Publication Date
MX2008013325A true MX2008013325A (es) 2008-12-10

Family

ID=38619398

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2008013325A MX2008013325A (es) 2006-04-21 2007-04-23 Habilitar dispositivos de red para correr multiples algoritmos de control de congestion.

Country Status (9)

Country Link
US (1) US7782759B2 (es)
EP (1) EP2011280B1 (es)
JP (1) JP5174807B2 (es)
KR (1) KR101344153B1 (es)
BR (1) BRPI0710571A2 (es)
CA (1) CA2649375C (es)
MX (1) MX2008013325A (es)
RU (1) RU2438162C2 (es)
WO (1) WO2007124154A1 (es)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8000242B2 (en) * 2006-07-06 2011-08-16 Alcatel Lucent Reducing packet loss for a packet data service during congestion in a transport network
US8102852B2 (en) * 2006-12-14 2012-01-24 Oracle America, Inc. Method and system for time-stamping data packets from a network
US20080263389A1 (en) * 2007-04-20 2008-10-23 At&T Knowledge Ventures, L.P. System for monitoring enum performance
KR101268621B1 (ko) * 2009-12-21 2013-05-29 한국전자통신연구원 동적 플로우 샘플링 장치 및 방법
US8340126B2 (en) 2010-06-07 2012-12-25 Lockheed Martin Corporation Method and apparatus for congestion control
US20120163178A1 (en) * 2010-12-23 2012-06-28 Telefonaktiebolaget L M Ericsson (Publ) Multiple-Algorithm Congestion Management
JP5976277B2 (ja) * 2011-02-23 2016-08-23 富士通株式会社 伝送制御方法
CN103814564B (zh) * 2011-09-30 2017-10-27 英特尔公司 链路感知的应用源速率控制技术
US8711690B2 (en) * 2012-10-03 2014-04-29 LiveQoS Inc. System and method for a TCP mapper
JP6089940B2 (ja) * 2013-05-08 2017-03-08 富士通株式会社 障害判定プログラム、装置、システム、及び方法
EP3164971A1 (en) 2014-07-01 2017-05-10 Telefonaktiebolaget LM Ericsson (publ) Methods and nodes for congestion control
CN105847168B (zh) * 2015-01-12 2020-01-31 华为技术有限公司 一种数据传输的方法、网络服务器、用户终端及系统
CN106302230B (zh) * 2015-06-11 2019-11-26 华为技术有限公司 一种数据传输方法及装置
US10419968B2 (en) 2016-03-30 2019-09-17 International Business Machines Corporation Dynamic selection of TCP congestion control for improved performances
US10848602B2 (en) * 2016-07-08 2020-11-24 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for implementing congestion control negotiation
US10511521B2 (en) 2016-08-03 2019-12-17 Anchorfree Inc. System and method for virtual multipath data transport
US11296988B2 (en) * 2019-11-14 2022-04-05 Mellanox Technologies, Ltd. Programmable congestion control communication scheme
US11218413B2 (en) * 2019-11-14 2022-01-04 Mellanox Technologies, Ltd. Congestion control management method derived from packets at a network adapter
CN114726790B (zh) * 2021-01-06 2024-04-16 北京中科海网科技有限公司 一种基于传输内容大小的拥塞控制选择方法及系统
CN113556780B (zh) * 2021-07-28 2023-07-25 新华三技术有限公司 一种拥塞控制方法及装置
US11616730B1 (en) * 2021-10-01 2023-03-28 Compira Labs Ltd. System and method for adapting transmission rate computation by a content transmitter
US12369073B2 (en) * 2022-07-08 2025-07-22 Qualcomm Incorporated Congestion control algorithms
WO2024124375A1 (en) * 2022-12-12 2024-06-20 Nvidia Corporation Application programming interface to allocate fifth generation new radio (5g-nr) statically-sized linked storage
US12413520B2 (en) 2023-03-24 2025-09-09 Mellanox Technologies, Ltd Real-time performance optimization of a packet network
US12401592B2 (en) * 2023-04-04 2025-08-26 Lemon Inc. Flexible load balancing on multipath networks

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3307792B2 (ja) * 1995-04-13 2002-07-24 株式会社日立製作所 Atmスイッチおよびatm−lanにおける輻輳制御方式
JPH09186723A (ja) * 1995-12-29 1997-07-15 Hitachi Ltd ネットワーク通信処理方式
US5920705A (en) * 1996-01-31 1999-07-06 Nokia Ip, Inc. Method and apparatus for dynamically shifting between routing and switching packets in a transmission network
US5936940A (en) 1996-08-22 1999-08-10 International Business Machines Corporation Adaptive rate-based congestion control in packet networks
JPH10336202A (ja) * 1997-06-03 1998-12-18 Fuji Xerox Co Ltd データ転送装置および方法
US6192406B1 (en) 1997-06-13 2001-02-20 At&T Corp. Startup management system and method for networks
US6262976B1 (en) * 1998-09-17 2001-07-17 Ordered Networks, Inc. System and method for network flow optimization using traffic classes
US6466984B1 (en) * 1999-07-02 2002-10-15 Cisco Technology, Inc. Method and apparatus for policy-based management of quality of service treatments of network data traffic flows by integrating policies with application programs
US7369498B1 (en) * 1999-12-13 2008-05-06 Nokia Corporation Congestion control method for a packet-switched network
US6757248B1 (en) * 2000-06-14 2004-06-29 Nokia Internet Communications Inc. Performance enhancement of transmission control protocol (TCP) for wireless network applications
US7130268B2 (en) * 2000-10-17 2006-10-31 Saverio Mascolo End-to-end bandwidth estimation for congestion control in packet switching networks
US7042841B2 (en) * 2001-07-16 2006-05-09 International Business Machines Corporation Controlling network congestion using a biased packet discard policy for congestion control and encoded session packets: methods, systems, and program products
JP4126928B2 (ja) * 2002-02-28 2008-07-30 日本電気株式会社 プロキシサーバ及びプロキシ制御プログラム
US7099954B2 (en) 2002-06-27 2006-08-29 Microsoft Corporation Congestion control mechanism for streaming media
JP2004243003A (ja) * 2003-02-17 2004-09-02 Kyocera Corp 携帯端末及び無線通信システム
JP4099108B2 (ja) * 2003-06-10 2008-06-11 富士通株式会社 ネットワーク及びサーバの負荷低減ルータ
US7420991B2 (en) * 2003-07-15 2008-09-02 Qlogic, Corporation TCP time stamp processing in hardware based TCP offload
US7656799B2 (en) * 2003-07-29 2010-02-02 Citrix Systems, Inc. Flow control system architecture
US7385923B2 (en) * 2003-08-14 2008-06-10 International Business Machines Corporation Method, system and article for improved TCP performance during packet reordering
US20050114540A1 (en) * 2003-11-12 2005-05-26 International Business Machines Corporation Method and system of generically specifying congestion control and a voidance behavior
US7512066B2 (en) * 2004-03-30 2009-03-31 Hewlett-Packard Development Company, L.P. Congestion control system
JP4282556B2 (ja) * 2004-06-30 2009-06-24 日本電信電話株式会社 フローレベル通信品質管理装置と方法およびプログラム
US7577097B2 (en) * 2005-03-22 2009-08-18 Microsoft Corporation Compound transmission control protocol
US7719967B2 (en) * 2005-09-28 2010-05-18 Netapp, Inc. Cumulative TCP congestion control

Also Published As

Publication number Publication date
EP2011280A4 (en) 2009-07-22
BRPI0710571A2 (pt) 2011-08-16
KR101344153B1 (ko) 2013-12-20
RU2438162C2 (ru) 2011-12-27
CA2649375C (en) 2015-06-23
KR20080111479A (ko) 2008-12-23
EP2011280B1 (en) 2015-05-20
EP2011280A1 (en) 2009-01-07
CA2649375A1 (en) 2007-11-01
WO2007124154A1 (en) 2007-11-01
JP2009534937A (ja) 2009-09-24
JP5174807B2 (ja) 2013-04-03
US7782759B2 (en) 2010-08-24
US20070248013A1 (en) 2007-10-25
RU2008141701A (ru) 2010-04-27

Similar Documents

Publication Publication Date Title
MX2008013325A (es) Habilitar dispositivos de red para correr multiples algoritmos de control de congestion.
US10200251B2 (en) Methods and apparatus for accessing selectable application processing of data packets in an adaptive private network
US7827295B2 (en) Protocol stack
KR100899871B1 (ko) 메시지 큐들을 이용하는 메시지 전송에서 단말 대 단말서비스 품질을 용이하게 하기 위한 시스템 및 방법
TWI226174B (en) Method and apparatus to manage packet fragmentation
CN108881008B (zh) 一种数据传输的方法、装置和系统
US7680141B2 (en) Transmitter device and relay device for performing data transmission control
TW200816715A (en) Systems and methods for SAR-capable quality of service
EP2347552A2 (en) Automatic invocation of dtn bundle protocol
US7761609B1 (en) Socket level packet scheduling for connectionless protocols
CN110073644B (zh) 信息处理方法和装置
EP1763172B1 (en) Method and apparatus for network protocol performance assessment
KR20040074922A (ko) 소프트웨어 개발 환경
US8180856B2 (en) Testing a network
US8761202B2 (en) Architecture for dynamically adaptive transport protocols
CN121283889A (zh) 一种通信方法、装置、设备及存储介质
Rüngeler et al. Integration of SCTP in the OMNeT++ simulation environment
Minghao et al. Performance analysis and optimization of user space versus kernel space network application
Niamanesh et al. DRAPS: A Framework for Dynamic Reconfigurable Protocol Stacks.
Saha et al. Dynamic SLA-aware Network Slice Monitoring
JP2004253952A (ja) IPv6通信におけるパケット分割方法およびIPv6通信のパケット分割を可能としたルータ
Ghosh Towards the rapid network-wide deployment of new application specific network protocols, using application level active networking
Jahre Fighting fire with fire: Eliminating standing queues with large UDP packet floods
Erixzon DCCP-Thin in Symbian OS
SELMANOĞLU et al. WIRELESS NETWORK EMULATOR AND PACKET ANALYZER

Legal Events

Date Code Title Description
FG Grant or registration