ES2902497T3 - Método para regular la velocidad de flujos de datos - Google Patents

Método para regular la velocidad de flujos de datos Download PDF

Info

Publication number
ES2902497T3
ES2902497T3 ES16759533T ES16759533T ES2902497T3 ES 2902497 T3 ES2902497 T3 ES 2902497T3 ES 16759533 T ES16759533 T ES 16759533T ES 16759533 T ES16759533 T ES 16759533T ES 2902497 T3 ES2902497 T3 ES 2902497T3
Authority
ES
Spain
Prior art keywords
data
network
network equipment
rate
stream
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES16759533T
Other languages
English (en)
Inventor
John Burnette
Ben Hadorn
Jeffrey Harrang
David Gibbons
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Opanga Networks LLC
Original Assignee
Opanga Networks LLC
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 Opanga Networks LLC filed Critical Opanga Networks LLC
Application granted granted Critical
Publication of ES2902497T3 publication Critical patent/ES2902497T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/25—Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0882—Utilisation of link capacity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0888—Throughput
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/29—Flow control; Congestion control using a combination of thresholds

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Un método, que comprende: examinar un primer paquete de datos transmitido desde un primer equipo de red a un segundo equipo de red, estando el primer equipo de red y el segundo equipo de red ubicados de forma remota uno con respecto a otro y enlazados por al menos una red; determinar un flujo de datos del primer paquete de datos; determinar un tipo de flujo de datos del flujo de datos; cuando el tipo de flujo de datos es un primer tipo, permitir que el primer paquete de datos se transmita al segundo equipo de red sin realizar un proceso de gestión de flujo; y cuando el tipo de flujo de datos es un segundo tipo, seleccionar el primer paquete de datos para el proceso de gestión de flujo, en donde el proceso de gestión de flujo comprende: determinar un caudal de entrega del flujo de datos a través de una trayectoria de flujo de datos (506), teniendo la trayectoria de flujo de datos una pluralidad de nodos de red y siendo una conexión compartida entre el segundo equipo de red y el primer equipo de red, relacionado el caudal de entrega con una tasa de transferencia de datos al segundo equipo de red desde el primer equipo de red a través de la trayectoria de flujo de datos; detectar una congestión de red en la trayectoria de flujo de datos comparando el caudal de entrega determinado con una capacidad de caudal de datos de pico esperada para un paquete de datos transmitido al segundo equipo de red desde el primer equipo de red (508); y regular la velocidad de una transmisión de una pluralidad de paquetes de datos por el primer equipo de red al segundo equipo de red cuando se detecta una congestión de red en la trayectoria de flujo de datos (510).

Description

DESCRIPCIÓN
Método para regular la velocidad de flujos de datos
Referencias cruzadas a solicitudes relacionadas
Esta solicitud reivindica la prioridad para y el beneficio de la Solicitud Provisional de EE. UU. n.° 62/127.753, presentada el 3 de marzo de 2015, la Solicitud Provisional de EE. UU. n.° 62/207.529, presentada el 20 de agosto de 2015, y la Solicitud Provisional de EE. UU. n.° 62.277.320, presentada el 11 de enero de 2016.
Antecedentes
Una entrega eficiente de contenido de datos por paquetes a usuarios de una red de acceso de último kilómetro compartida se puede lograr mediante un equilibrado adecuado de la capacidad de tráfico de red, el volumen de tráfico de usuario y la calidad de usuario global de la experiencia proporcionada a los usuarios a través de aplicaciones que transportan tráfico a través de la red. A medida que aumentan los volúmenes de tráfico y no se mantiene este equilibrio, entonces o bien construir la red se vuelve demasiado costoso o bien los usuarios padecen un servicio deficiente.
Uno de los problemas crecientes que afrontan las redes de datos de hoy en día (que pueden incluir redes inalámbricas, cableadas y/o de fibra) es la carga impuesta a estas redes de datos como resultado de que, a través de estas redes, se transmitan por secuencias, o se entreguen de otro modo, archivos de contenido grande. Un contenido de medios "grande" tiene la característica distintiva de consumir cantidades significativas de tiempo y recursos de red durante su entrega a o desde un dispositivo de usuario final. Comúnmente, las redes de acceso de consumidor están diseñadas para la entrega de ráfagas cortas de datos y el uso de recursos de la red y no están previstas para un uso continuo a largo plazo, tal como la transmisión por secuencias de contenido de medios (por ejemplo, audio, vídeo y/u otros tipos de datos de contenido). Está reconocido ampliamente que la transmisión por secuencias de contenido de medios es un desafío principal para los ingenieros de tráfico de red que intentan satisfacer las demandas de uso de pico de muchos usuarios con unos recursos de red limitados. El resultado habitual de una adopción de transmisión por secuencias generalizada es una congestión de red, que a menudo se pone de manifiesto por una respuesta de red lenta para todos los usuarios y sus aplicaciones.
Durante períodos de pico del uso de red (por ejemplo, cuando se está transmitiendo a través de la red un volumen grande de contenido de medios y/u otros tipos de datos), la capacidad de la red para retransmitir datos de forma rápida y eficiente desde un sistema de red a otro sistema de red queda degradada severamente. Es decir, a medida que más y más usuarios de red se conectan a la red para descargar unas cantidades grandes de datos, la competición por la cantidad finita de ancho de banda de red y de recursos (por ejemplo, estaciones base, encaminadores, servidores, bases de datos, y así sucesivamente) disponibles da como resultado, invariablemente, que cada usuario de red experimente unos servicios degradados (por ejemplo, velocidades de carga y de descarga más lentas, interrupciones de entrega de datos y de transmisión por secuencias).
Se puede hallar un ejemplo de la técnica anterior en el documento US2014/269319.
Sumario
Un método, que comprende: examinar un primer paquete de datos transmitido desde un primer equipo de red a un segundo equipo de red, estando el primer equipo de red y el segundo equipo de red ubicados de forma remota uno con respecto a otro y enlazados por al menos una red; determinar un flujo de datos del primer paquete de datos; determinar un tipo de flujo de datos del flujo de datos; cuando el tipo de flujo de datos es un primer tipo, permitir que el primer paquete de datos se transmita al segundo equipo de red sin realizar un proceso de gestión de flujo; y cuando el tipo de flujo de datos es un segundo tipo, seleccionar el primer paquete de datos para el proceso de gestión de flujo, comprendiendo el proceso de gestión de flujo: determinar un caudal de entrega del flujo de datos a través de una trayectoria de flujo de datos, teniendo la trayectoria de flujo de datos una pluralidad de nodos de red y siendo una conexión compartida entre el segundo equipo de red y el primer equipo de red, relacionado el caudal de entrega con una tasa de transferencia de datos al segundo equipo de red desde el primer equipo de red a través de la trayectoria de flujo de datos; detectar una congestión de red en la trayectoria de flujo de datos comparando el caudal de entrega determinado con una capacidad de caudal de datos de pico esperada para un paquete de datos transmitido al segundo equipo de red desde el primer equipo de red; y regular la velocidad de una transmisión de una pluralidad de paquetes de datos por el primer equipo de red al segundo equipo de red cuando se detecta una congestión de red en la trayectoria de flujo de datos.
Breve descripción de los dibujos
La figura 1A ilustra un entorno de red de ejemplo.
La figura 1B ilustra otro entorno de red de ejemplo.
La figura 2A es un diagrama de bloques de un sistema de gestión de transporte.
La figura 2B es un diagrama de bloques de un sistema de gestión de transporte.
La figura 2C es un diagrama de bloques de un sistema de gestión de transporte.
La figura 2D es un diagrama de bloques de un sistema de gestión de transporte.
La figura 3 es un diagrama de bloques de un equipo de usuario.
La figura 4 es un diagrama de flujo lógico de alto nivel de un proceso.
La figura 5A es un diagrama de flujo lógico de alto nivel de un proceso para seleccionar un flujo de datos para su gestión y para regular la velocidad del flujo de datos.
La figura 5B es un diagrama de flujo lógico de alto nivel de un proceso para seleccionar un flujo de datos para su gestión y para regular la velocidad del flujo de datos.
La figura 6A es un diagrama de flujo lógico de alto nivel de un proceso para gestionar el caudal de entrega de un flujo de datos.
La figura 6B es un diagrama de flujo lógico de alto nivel de un proceso para determinar un caudal de entrega de un flujo de datos seleccionado y determinar si hay una congestión de red.
La figura 7A es un diagrama de flujo lógico de alto nivel de un proceso para gestionar el caudal de entrega de un flujo de datos.
La figura 7B es un diagrama de flujo lógico de alto nivel de un proceso para determinar un caudal de entrega de un segmento de archivo asociado con un flujo de datos seleccionado y determinar si hay una congestión de red.
La figura 8 es un diagrama de flujo lógico de alto nivel de un proceso para interaccionar con un agente.
Descripción detallada
En el presente documento se describen sistemas y métodos para seleccionar un flujo de datos que atraviesa una o más redes de datos para su gestión y que se puede haber determinado que usan unas cantidades significativas de recursos de red. Los sistemas y métodos se pueden diseñar para, tras detectar una congestión de red, regular la velocidad de la entrega del flujo de datos reduciendo la tasa de entrega (o la tasa de datos objetivo) del flujo de datos al destino. En algunos casos, los sistemas pueden incluir un sistema de gestión de transporte, mientras que, en otros casos, los sistemas pueden incluir el sistema de gestión de transporte y un sistema de detección de flujo. En algunas realizaciones, los sistemas y métodos se pueden implementar en algún lugar a lo largo de una trayectoria de flujo de datos entre un primer equipo de red, tal como un servidor de contenido, y un segundo equipo de red, tal como un equipo de usuario. Para los fines de la descripción siguiente, un flujo de datos se puede definir como un flujo de paquetes de datos asociados con un archivo de datos particular, tal como un archivo de contenido de medios, que se transmite desde un origen de red particular a un destino de red particular.
En algunos ejemplos, los sistemas y métodos pueden entregar contenido de datos por paquetes a través de redes de acceso compartido de una manera que distribuye de manera más uniforme a lo largo del tiempo un tráfico de usuario agregado, por ejemplo, moviendo el tráfico desde tiempos de congestión de red de cuello de botella a momentos adyacentes posteriores de capacidad de red excedente. El efecto neto de esta redistribución de tráfico puede reducir los intervalos de uso de pico y la congestión (cuando la red es incapaz de suministrar una capacidad de caudal suficiente para todos los usuarios), lo que puede dar como resultado una utilización de red agregada permitida más alta antes de que la calidad de servicio de red se degrade para usuarios finales de las redes de acceso compartido.
Para los fines de la descripción siguiente, se entiende que la expresión "capacidad de red excedente" (por ejemplo, capacidad en reposo) significa capacidad de red compartida (por ejemplo, ancho de banda de red, recursos de red) que puede ser usada por, por ejemplo, un sistema de gestión de transporte que transfiere algunos o todos los datos de contenido de transmisión por secuencias a través de una red, pero que por lo demás, en ausencia de un uso de este tipo, permanece sin usar. En otras palabras, se puede considerar que "la capacidad de red excedente" es ancho de banda de red (o recursos de red) disponible que rebasa la carga o demanda de tráfico de red agregada actual. Por ejemplo, si la capacidad de tráfico de red es X y la carga de tráfico de red agregada actual es Y, entonces la capacidad excedente disponible es X - Y, en donde Y no puede ser más grande que X. Uno de los objetivos de usar la capacidad de red excedente es usar alguna o toda la capacidad excedente X - Y para transferir contenido, incluyendo contenido de transmisión por secuencias, lo que implica que si la capacidad excedente (X - Y) es cero, entonces la transferencia se ralentiza o se detiene y cede el canal al tráfico de otros usuarios que comparten la misma red. Cuando la capacidad excedente ( X- Y) de una red es cero o se aproxima a cero, se considera que la red está "congestionada" (es decir, congestión de red).
En algunos casos, la capacidad de red excedente en redes de datos de múltiples usuarios compartidas es transitoria y puede fluctuar aleatoriamente de un momento a otro. Además, el uso de capacidad excedente, como se define, es distinto de un reparto equitativo o uso compartido similarmente competitivo de capacidad de red (por ejemplo, cuando la carga de tráfico agregado supera el límite de capacidad de red X, entonces cada uno de N usuarios que comparten la red recibe una cuota X / N de la capacidad de red).
Cuando una red de datos está congestionada, habitualmente la tasa a la que los paquetes de datos (por ejemplo, los flujos de datos) que atraviesan la red se degradará, dando como resultado un caudal de datos inferior al óptimo. Una de las causas de congestión de red es la presencia o existencia de "flujos elefantes" u otros tipos de flujos que son relativamente onerosos en cuanto a su uso de recursos de red que incluyen una capacidad de caudal compartida. Los ejemplos de flujos elefantes incluyen, por ejemplo, flujos de datos por paquetes asociados con contenido de medios (por ejemplo, archivos de vídeo y/o de audio) que usan fracciones grandes de ancho de banda de red. En algunos casos, un flujo elefante se puede definir como un flujo de datos que consume una porción de ancho de banda de red total que es mayor que algún nivel umbral. En otros casos, un flujo elefante se puede definir como un flujo de datos que tiene una tasa de datos que supera alguna cantidad umbral. En otros casos más, un flujo elefante se puede definir como un flujo de datos que persiste durante más tiempo que una duración umbral. Por supuesto, los valores del nivel umbral y la cantidad umbral pueden ser una elección de diseño basándose en un número de factores que incluyen, por ejemplo, los tipos de redes de datos implicadas, el número de usuarios finales, el ancho de banda de red total, y así sucesivamente.
La figura 1A ilustra un entorno de red 100 de ejemplo de acuerdo con una realización. Como se ilustra, el entorno de red 100 incluye un sistema de gestión de transporte 102a*, un equipo de usuario 104, un servidor de contenido 106, una red de datos 108 y una red de datos 110. Obsérvese que, en lo sucesivo, "*" representa un comodín. Por tanto, las referencias siguientes al sistema de gestión de transporte 102a*, por ejemplo, se pueden referir al sistema de gestión de transporte 102a* de la figura 1A, así como al sistema de gestión de transporte 102a' de la figura 2A o al sistema de gestión de transporte 102a" de la figura 2B, que son dos implementaciones diferentes del sistema de gestión de transporte 102a* de la figura 1A. Aunque no se ilustra explícitamente en la figura 1A, uno o más equipos de usuario 104 adicionales y uno o más servidores de contenido 106 adicionales pueden interaccionar con la red de datos 108 y/o la red de datos 110.
En un ejemplo, el equipo de usuario 104 puede ser un ordenador de escritorio, una estación de trabajo, un descodificador de salón, una estación de trabajo, un dispositivo informático móvil tal como un teléfono inteligente o un ordenador de tipo tableta, un dispositivo informático ponible tal como un reloj inteligente o unas gafas de realidad aumentada, o similares.
En un ejemplo, el servidor de contenido 106 puede ser, por ejemplo, un servidor que proporciona contenido de medios tal como archivos de vídeo y/o de audio y/o archivos de datos a otros nodos de red, incluyendo, por ejemplo, el equipo de usuario 104.
Las dos redes de datos 108 y 110 se pueden usar como trayectorias para intercambiar datos, en forma de paquetes de datos, entre el equipo de usuario 104, el sistema de gestión de transporte 102a* y el servidor de contenido 106. Por ejemplo, cuando se está descargando un archivo de contenido de medios, tal como un archivo de vídeo o de audio, desde el servidor de contenido 106 al equipo de usuario 104, el archivo de contenido de medios se puede encaminar desde el servidor de contenido 106 al equipo de usuario 104 a través del sistema de gestión de transporte 102a* y a través de las redes de datos 108 y 110. Por ejemplo, el servidor de contenido 106 puede transmitir un archivo de contenido de medios al equipo de usuario 104 a través de las redes de datos 108 y 110 transmitiendo paquetes de datos con encabezamientos que incluyen la dirección de red (por ejemplo, dirección de IP de protocolo de Internet) del equipo de usuario 104 como el destino. En una realización, las dos redes de datos 108 y 110 pueden ser dos redes distintas o pueden ser parte de una única red funcional grande.
La red de datos 108 puede ser una red de acceso (AN) que enlaza comunicativamente el sistema de gestión de transporte 102a* con el equipo de usuario 104. Por ejemplo, en algunos casos, la red de datos 108 puede ser una red de acceso celular móvil, tal como una red de segunda generación (2G), una red de tercera generación (3G), una red de evolución a largo plazo (LTE), una red de quinta generación (5G) y similares. En algunos casos, la red de datos 108 puede incluir una colección medular de subnodos que están enlazados con una red de acceso de radio (RAN). En algunos casos, porciones de las redes de datos 108, 110, 114 pueden ser una red de área local o un centro de datos, por ejemplo, una red de área local de interfaz de pasarela de servicio (SGi-LAN) o una red de área local de interfaz de pasarela (Gi-LAN) ubicada en la frontera de una red móvil.
En algunos ejemplos, la red de datos 110 que enlaza el servidor de contenido 106 con el sistema de gestión de transporte 102a* puede ser una red de área extensa (WAN), que, para fines de ilustración, se puede considerar que es Internet.
En algunos ejemplos, se puede suponer que al menos una porción seleccionada del tráfico de datos por paquetes entre el servidor de contenido 106 y el equipo de usuario 104 pasa a través de, o está en línea con, el sistema de gestión de transporte 102a*. Con el fin de facilitar el tráfico a través del sistema de gestión de transporte 102a*, en un ejemplo, la ubicación física del sistema de gestión de transporte 102a* puede estar en el punto o puntos de agregación de tráfico de frontera que conectan la red de datos 108 (por ejemplo, una red de acceso tal como una red celular o de Wi-Fi) con la red de datos 110 (por ejemplo, WAN). Por ejemplo, en redes móviles convencionales del Proyecto de Asociación de 3a generación (3GPP), el punto agregado puede ser parte de la SGi-LAN, que se conecta al elemento medular de Pasarela de red de datos (p Dn ) (o, como alternativa, a la Pasarela de nodo de soporte de GPRS (GGSN) de Pasarela y Gi-LAN) y hacia fuera a Internet. Sin embargo, en otros ejemplos, el sistema de gestión de transporte 102a* puede estar ubicado en alguna otra parte. En algunas realizaciones, el sistema de gestión de transporte 102a* puede ser parte de una Red de Entrega de Contenido (CDN) que atiende a uno o más AN.
Las figuras 2A y 2B ilustran dos implementaciones diferentes del sistema de gestión de transporte 102a* de la figura 1A, que se ilustran como el sistema de gestión de transporte 102a' en la figura 2A y como el sistema de gestión de transporte 102a" en la figura 2B. Como se ilustra en la figura 2A, el sistema de gestión de transporte 102a' incluye una interfaz de red 202 (por ejemplo, una tarjeta de interfaz de red o "NIC"), uno o más procesadores 204, una cola 206 (por ejemplo, una memoria intermedia), un detector de flujo 166 y un almacenamiento 208 (por ejemplo, una memoria volátil y/o no volátil incluyendo, por ejemplo, memoria de acceso aleatorio (RAM), memoria de solo lectura (ROM), memoria flash, memoria de disco, y así sucesivamente) que están enlazados entre sí a través de un bus 210. El almacenamiento 208 puede almacenar una o más aplicaciones 214 (por ejemplo, instrucciones legibles por ordenador) y una o más directivas 216 para seleccionar y/o determinar qué flujos de datos por paquetes se deberían gestionar.
El detector de flujo 166 se puede diseñar para, entre otras características, supervisar una pluralidad de flujos de datos y para seleccionar uno o más de los flujos de datos para su procesamiento/gestión adicional basándose en las una o más de las directivas 216 almacenadas en el almacenamiento 208 o desde otros orígenes. En diversas realizaciones, el detector de flujo se puede implementar usando circuitería personalizada (por ejemplo, un circuito integrado específico de la aplicación o ASIC), o empleando una combinación de circuitería personalizada y software ejecutado por circuitería programable tal como uno o más procesadores.
Como se ilustra adicionalmente en la figura 2A, el sistema de gestión de transporte 102a' incluye además un gestor de flujo 212a, que se puede diseñar para, entre otras funciones, medir un desempeño de entrega (por ejemplo, caudal de entrega o algún otro parámetro de entrega) de un flujo de datos (es decir, flujo de datos por paquetes). El gestor de flujo 212a detecta si la red está congestionada basándose, al menos en parte, en el desempeño de entrega medido del flujo de datos, y regula la velocidad del flujo de datos, en respuesta a detectar una congestión de red, ajustando la entrega del flujo de datos al destino (por ejemplo, el equipo de usuario 104) con el fin de reducir la tasa de entrega del flujo de datos. En la figura 2A, el gestor de flujo 212a es implementado por los uno o más procesadores 204 (u otra circuitería programable) que ejecutan una o más instrucciones de programación legibles por ordenador (por ejemplo, la aplicación 214). El gestor de flujo 212a, el gestor de flujo 212b de la figura 2B y el detector de flujo 166 de la figura 1B son unidades lógicas que están diseñadas para realizar las diversas funcionalidades que se van a describir en el presente documento.
La figura 2B ilustra otra implementación del sistema de gestión de transporte 102a* de la figura 1A, ilustrado en la figura 2B como el sistema de gestión de transporte 102a". El sistema de gestión de transporte 102a" ilustrado en la figura 2B incluye algunos de los mismos componentes que el sistema de gestión de transporte 102a' de la figura 2A. A diferencia del gestor de flujo 212a de la figura 2A, sin embargo, el gestor de flujo 212b ilustrado en la figura 2B se puede implementar usando circuitería personalizada en lugar de implementarse usando uno o más procesadores 204 que ejecutan software (por ejemplo, instrucciones de programación legibles por máquina). En otros ejemplos más, el gestor de flujo 212* de la figura 2a o 2B se puede implementar usando una combinación de circuitería personalizada y software ejecutado por circuitería programable (por ejemplo, el procesador 204).
La figura 1B ilustra otro entorno de red 150 de ejemplo de acuerdo con una realización. Como se ilustra, el entorno de red 150 incluye un sistema de gestión de transporte 102b* que está diseñado para gestionar flujos de datos entre dos equipos de red (por ejemplo, el equipo de usuario 104 y el servidor de contenido 106) de forma similar al sistema de gestión de transporte 102a* de la figura 1A). Las figuras 2C y 2D ilustran dos implementaciones diferentes del sistema de gestión de transporte 102b* de la figura 1B, que se ilustra en la figura 2C como el sistema de gestión de transporte 102b' y en la figura 2D como el sistema de gestión de transporte 102b".
El sistema de gestión de transporte 102b* de la figura 1B (es decir, el sistema de gestión de transporte 102b' de la figura 2C o el sistema de gestión de transporte 102b' de la figura 2D) incluye componentes similares a los incluidos en el sistema de gestión de transporte 102a* de la figura 1A (es decir, el sistema de gestión de transporte 102a' de la figura 2A o el sistema de gestión de transporte 102a" de la figura 2D). Sin embargo, a diferencia del sistema de gestión de transporte 102a* ilustrado en las figuras 1A, 2A y 2B, el sistema de gestión de transporte 102b* de la figura 1B, 2C y 2D no incluye un detector de flujo 166. En su lugar, el detector de flujo 166 puede ser parte de un dispositivo de red separado, denominado en el presente documento sistema de detección de flujo 112.
El sistema de detección de flujo 112 incluye una interfaz de red 160, uno o más procesadores 162 (por ejemplo, unidad central de procesamiento (CPU), unidad de procesamiento gráfico (GPU), y así sucesivamente), un almacenamiento 164 (por ejemplo, memoria volátil y/o no volátil) y un detector de flujo 166. El detector de flujo 11 se puede diseñar para, entre otras funciones, supervisar y/o muestrear tráfico de datos entre el servidor de contenido 106 y el equipo de usuario 104 a través de las redes de datos 108, 110 y 115, de forma similar al detector de flujo 166 de las figuras 2A y 2B. El sistema de detección de flujo 112 y el sistema de gestión de transporte 102b* de la figura 1B pueden estar enlazados con una red de datos 114 que, en algunas realizaciones, puede ser una Red de Área Local o una Red Definida por Software, tal como una red o redes compuestas por colecciones de hardware interconectadas directamente de encaminadores, conmutadores, pasarelas y similares. En algunas realizaciones, las tres redes de datos 108, 110 y 114 pueden ser una única red funcional.
En un ejemplo, flujos de datos por paquetes selectivos pueden ser identificados para su procesamiento adicional por el sistema de detección de flujo 112 basándose en directivas o plantillas configuradas que caracterizan los flujos de datos que recorren las redes de datos 108, 110 y 114. Por ejemplo, el sistema de detección de flujo 112 puede emplear el detector de flujo 166 para medir el caudal promedio, el volumen de datos entregado, la duración y otras características del flujo de datos con el fin de clasificar el flujo como un flujo elefante, que es un tipo relativamente oneroso de flujo de datos debido a su uso relativamente grande y desproporcionado de recursos de red que incluye una capacidad de caudal compartida.
Los tipos de flujo específicos (por ejemplo, flujos elefantes) de paquetes que fluyen a través de las redes de datos 108, 110 y 114 se determinan basándose, por ejemplo, en los encabezamientos de capa de transporte y de red de paquetes componentes de los paquetes, que pueden incluir, por ejemplo, combinaciones de direcciones de origen y de destino de IP, puertos de origen y de destino de protocolo de control de transporte (TCP) o de Protocolo de Datagramas de Usuario (UDP), protocolos (por ejemplo, IPv4), etiquetas de flujo (por ejemplo, IPv6), indicadores, campos de encabezamiento de ampliación, y así sucesivamente. Es decir, diferentes paquetes se identifican como pertenecientes al mismo flujo de datos (o flujo virtual), por ejemplo, procesando los encabezamientos de los paquetes para determinar que los paquetes tienen, por ejemplo, los mismos puertos de origen y de destino, protocolo, etiquetas de flujo, campos de encabezamiento de ampliación, y así sucesivamente. Una vez que se ha identificado un flujo de datos (es decir, un flujo de datos por paquetes), se averigua la cantidad de datos que es transportada por el flujo de datos identificado con el fin de determinar si el flujo de datos es un flujo elefante.
En algunos ejemplos, un flujo de datos se identifica como un flujo elefante muestreando paquetes de una combinación agregada de uno o más flujos y seleccionando un flujo que supera una tasa de datos umbral medida dentro de una duración de muestreo definida. En otros ejemplos, un flujo de datos se identifica como un flujo elefante muestreando y seleccionando un flujo que supera un umbral de duración de actividad continua que se puede definir midiendo un número de tasas de datos consecutivas, o una secuencia de tasas de datos, cada una de las cuales supera una tasa de datos umbral. En otros ejemplos más, un flujo de datos se identifica como un flujo elefante muestreando aleatoriamente solo algunos de los paquetes de una combinación agregada de uno o más flujos y seleccionando un flujo que supera una probabilidad de detección relativa que indica un uso relativamente desproporcionado de la banda ancha de tráfico agregado. En otros ejemplos más, estos métodos se pueden usar en combinación o con otros métodos similares.
En algunos casos, cuando se cifran o se ofuscan las cabidas útiles de datos por paquetes de capa de transporte o de red, los encabezamientos de cabida útil se pueden procesar/examinar con el fin de identificar paquetes que pertenecen al mismo flujo de datos por paquetes. En otros casos, en donde las cabidas útiles de datos por paquetes son legibles, la información en las cabidas útiles de paquetes de red o de transporte se pueden procesar/examinar para ayudar adicionalmente a identificar paquetes asociados con un flujo de datos particular o un tipo de flujo de datos particular (por ejemplo, una transmisión por secuencias de vídeo).
En algunos ejemplos, una vez que el sistema de detección de flujo 112 ha identificado un flujo elefante u otro flujo que puede ser oneroso, el sistema de detección de flujo 112 puede desencadenar una reconfiguración de la lógica de reenvío de paquetes en la red de datos 114 de tal modo que paquetes en el flujo de datos identificado se dirigen para que pasen a través del sistema de gestión de transporte 102b* en la trayectoria de extremo a extremo entre el origen (por ejemplo, un servidor de contenido 106) y el destino (por ejemplo, 104). Por ejemplo, el sistema de detección de flujo 112 puede comunicar las características del flujo oneroso a uno o más encaminadores y conmutadores que incluyen la red de datos 114. En consecuencia, se pueden usar reglas de reenvío o de conmutación configuradas dinámicamente para dirigir paquetes posteriores en el mismo flujo de datos para que pasen a través del sistema de gestión de transporte 102b* en la trayectoria de extremo a extremo de los paquetes, por ejemplo, usando los principios de Interconexión en Red Definida por Software. En otros ejemplos, sin embargo, el sistema de gestión de transporte 102b* se puede incluir en la trayectoria de extremo a extremo, de acuerdo con unas reglas por defecto, y el sistema de detección de flujo 112 puede simplemente notificar, al sistema de gestión de transporte 102b*, flujos detectados que coinciden con una o más plantillas de clasificación de tal modo que los flujos detectados se procesan (por ejemplo, regulando la velocidad de la tasa de flujo para reducir la tasa de entrega de los flujos) mientras que otros flujos de tráfico se pueden reenviar sin procesamiento.
En algunos casos, un flujo puede ser unidireccional (por ejemplo, un flujo o bien de enlace ascendente o bien de enlace descendente) o puede ser bidireccional al emparejarse con permitir el sentido opuesto (por ejemplo, paquetes con direcciones de red de origen y de destino intercambiadas, direcciones de puerto intercambiadas, etiqueta de flujo común, etc.) pertenecientes a un par en comunicación de puntos de extremo de conexión. En algunos ejemplos, ambos sentidos de un par de flujo bidireccional se pueden dirigir al sistema de gestión de transporte 102b*.
En algunos ejemplos, el sistema de detección de flujo 112 y el sistema de gestión de transporte 102b* pueden ser elementos funcionales distintos como se muestra en la figura 1B, o se pueden combinar en una única unidad funcional como se ilustra en la figura 1A.
La figura 3 es un diagrama de bloques del equipo de usuario 104 de acuerdo con un ejemplo. El equipo de usuario 104, que en algunos casos puede ser un dispositivo informático móvil o un ordenador de escritorio, puede incluir una interfaz de red 302 (por ejemplo, una NIC), uno o más procesadores 304, una interfaz de usuario 306 (por ejemplo, incluyendo un visualizador, altavoces, teclado, ratón, y así sucesivamente) y un almacenamiento 308 (por ejemplo, una memoria volátil y/o no volátil), que están acoplados entre sí a través del bus 310. El almacenamiento 308 puede almacenar una o más aplicaciones 314 y uno o más archivos 316 (por ejemplo, archivos de contenido de medios tales como archivos de audio y/o de vídeo). En algunos ejemplos, los uno o más procesadores 304 pueden ejecutar una o más instrucciones legibles por ordenador (por ejemplo, una aplicación 314) para implementar un agente 312 que se puede diseñar para facilitar las diversas funcionalidades realizadas por el sistema de gestión de transporte 102* de las figuras 1A, 1B, 2A, 2B, 2C y 2D.
La figura 4 ilustra un proceso para seleccionar y gestionar un flujo de datos de acuerdo con una realización. En algunas implementaciones, el proceso 400 puede ser implementado por, por ejemplo, un gestor de flujo 212* (véanse las figuras 2A, 2B, 2C y 2D) y un detector de flujo 166 (véanse las figuras 1B, 2A y 2B). El proceso 400 comienza en 402, cuando un flujo de datos es seleccionado para su gestión por, por ejemplo, un detector de flujo 166, de entre una pluralidad de flujos de datos que atraviesan una o más redes de datos. El flujo de datos que se selecciona se puede transmitir desde un origen, tal como el servidor de contenido 106, a un destino, tal como el equipo de usuario 104. En algunos casos, el flujo de datos se puede seleccionar basándose en una determinación de que el flujo de datos es un flujo elefante (por ejemplo, un flujo de datos que consume una porción de ancho de banda de red que es mayor que un nivel umbral o que tiene una tasa de datos que supera una cantidad umbral). En un ejemplo, el flujo de datos se puede seleccionar, adicionalmente o como alternativa, determinando el origen del flujo de datos. Por ejemplo, flujos de datos que se determina que han tenido su origen en direcciones de origen afiliadas a proveedores de contenido específicos, tales como proveedores de contenido de vídeo, se pueden seleccionar automáticamente para su gestión.
En 404, una congestión de red es detectada por, por ejemplo, el gestor de flujo 212*. Se pueden emplear diversas técnicas con el fin de detectar una congestión de red. Por ejemplo, en algunas implementaciones, una congestión de red se puede detectar determinando el desempeño de entrega del flujo de datos seleccionado. Esto se logra permitiendo que paquetes asociados con el flujo de datos seleccionado atraviesen la red tan rápido como lo permite la red con el fin de estimar un caudal de entrega actual para el flujo de datos seleccionado. Con el fin de estimar con precisión el caudal de entrega del flujo de datos seleccionado, se pueden supervisar los acuses de recibo (por ejemplo, paquetes de ACK) que son transmitidos por el destino (por ejemplo, el equipo de usuario 104) en respuesta a recibir con éxito paquetes. Entonces se puede determinar que la red está congestionada si el caudal de entrega estimado es menor que el "caudal de pico" para el flujo de datos seleccionado, lo que, en algunos casos, se puede haber detectado previamente para el flujo de datos seleccionado. En una realización, un caudal de entrega es una cantidad estimada de datos que se entregan a un destino por unidad de tiempo, mientras que el caudal de pico puede ser el caudal de entrega estimado (por ejemplo, filtrado o promediado) más alto basándose en una o más estimaciones de caudal de entrega anteriores de este tipo para el flujo de datos seleccionado. El caudal de pico es el caudal de entrega estimado (por ejemplo, filtrado o promediado) más alto para una o más estimaciones de caudal de entrega anteriores de este tipo para otros flujos de datos. El caudal de entrega estimado más alto se puede haber estimado basándose en mantenimiento de picos, análisis basado en percentiles, caudal de datos filtrado y/o caudal de datos promediado. En algunos casos, el caudal de pico puede ser notificado por el agente 312. En otros casos, el caudal de pico puede ser estimado por el gestor de flujo 212*. En otros casos más, el caudal de pico puede ser estimado por otros elementos de red.
Es decir, cuando un flujo de datos para un archivo de medios está atravesando una red, el caudal del flujo de datos fluctuará con frecuencia dependiendo de la congestión/capacidad de red disponible. En puntos en el tiempo en los que hay capacidad de red sobrante (por ejemplo, sin congestión), los paquetes asociados se entregarán al destino (por ejemplo, el equipo de usuario 104) a una tasa máxima u óptima, que se denomina en el presente documento caudal de pico. En un punto concreto en el tiempo en el que se detecta que el flujo de datos no se está entregando al destino a niveles de caudal de pico, se puede determinar que la red está congestionada. En algunos ejemplos, la detección de la congestión de red puede incluir determinar el nivel de congestión de red basándose, por ejemplo, en el desempeño de entrega determinado del flujo de datos seleccionado.
En 406, basándose en la congestión de red detectada, el flujo de datos seleccionado es regulado en velocidad por, por ejemplo, el gestor de flujo 212* con el fin de reducir la tasa de entrega del flujo de datos al destino. En algunos ejemplos, la tasa de entrega del flujo de datos se puede reducir añadiendo latencias entre los paquetes a transmitir al destino. Por ejemplo, con el fin de reducir la tasa de entrega, se pueden añadir una o más latencias entre una transmisión de dos o más paquetes del flujo de datos a transmitir al destino. Las cantidades de las una o más latencias a añadir se pueden basar, por ejemplo, en el desempeño de entrega determinado del flujo o el nivel de congestión de red. Datos asociados con el flujo de datos se pueden almacenar en memoria intermedia en una cola (por ejemplo, la cola 306 del sistema de gestión de transporte 102*). En un ejemplo, una tasa de entrega se puede definir como la cantidad de datos enviados por el sistema de transporte 102* para un flujo en un intervalo de tiempo seleccionado para lograr una tasa de datos objetivo promedio a lo largo del intervalo de tiempo. Como se usa en el presente documento, la expresión "regulación de velocidad" o "regulado en velocidad" se refiere a un funcionamiento de red en el que una tasa de datos objetivo se ajusta dinámicamente, es decir, se aumenta o se disminuye, de acuerdo con condiciones de red. En una realización, la tasa de datos objetivo se ajusta dinámicamente para no superar el reparto equitativo de TCP asignado. En una realización, una tasa de datos objetivo se puede definir como una tasa que disminuye en proporción a la diferencia numérica entre el caudal estimado actual del flujo y el caudal de pico. Debido a que esta diferencia numérica varía continuamente debido a condiciones de red fluctuantes, la tasa de datos objetivo también se ajusta dinámicamente (por ejemplo, de forma continua o frecuente).
Las figuras 5A y 5B ilustran dos procesos 500 y 550 que son dos implementaciones diferentes del proceso 400 de la figura 4 de acuerdo con algunas realizaciones. Los procesos 500 y 550 pueden ser implementados por el gestor de flujo 212* de la figura 2A, 2B, 2C o 2D y el detector de flujo 166 de la figura 1B, 2A o 2B.
En algunos casos, un único flujo lógico puede estar asociado con dos o más flujos de capa de transporte que tienen el equipo de usuario 104 como un punto de extremo. Un tráfico agregado a partir del único flujo lógico puede ser gestionado por, por ejemplo, el gestor de flujo 212* de acuerdo con las operaciones ilustradas en la figura 5A o 5B. Por ejemplo, una aplicación que se ejecuta en el equipo de usuario 104 puede crear múltiples flujos de protocolo de control de transporte/protocolo de Internet (TCP/IP) que la aplicación puede usar para enviar y recibir datos. Asociando y gestionando el único flujo lógico que incluye el tráfico de los múltiples flujos de TCP/IP, las operaciones ilustradas en la figura 5A o 5B se pueden realizar de una forma por equipo de usuario y/o por aplicación de usuario. En algunas realizaciones, se puede usar la 4-tupla de TCP/IP (dirección de origen (SA), dirección de destino (DA), puerto de origen (SP), puerto de destino (DP)) e ID de protocolo, o (SA, DA, etiqueta de flujo) de cada flujo para agrupar flujos que comparten una dirección de IP de equipo de usuario común, un ID de protocolo o combinaciones de estos. En otras realizaciones, se puede usar un ID único del equipo de usuario 104 que se sabe que está asociado con una dirección de IP para agrupar múltiples flujos de TCP/IP en un único flujo lógico.
La figura 5A ilustra un proceso 500 para seleccionar un flujo de datos para su gestión y para regular la velocidad del flujo de datos de acuerdo con una realización. El proceso 500 se puede implementar independientemente de si se encriptan o no se encriptan las cabidas útiles de capa de red o de transporte de los paquetes que se gestionan. El proceso 500 comienza en 502, cuando unos flujos de datos que atraviesan una o más redes son supervisados por, por ejemplo, un detector de flujo 166. En algunas implementaciones, esto se puede lograr supervisando los flujos de capa de red (por ejemplo, de IP) y los de capa de transporte (por ejemplo, de t Cp , de UDP) (por ejemplo, las porciones de TCP/IP de paquetes) que pasan a través del sistema de gestión de transporte 102* de la figura 1A o 1B (o el sistema de detección de flujo 112 de la figura 1B). En algunos casos, la operación de supervisión 502 puede incluir la inspección de capas superiores (por ejemplo, la capa de HTTP o de aplicación).
Basándose en un conjunto de directivas de clasificación de flujos, el detector de flujo 166 puede seleccionar un flujo de datos particular para una inspección más detallada y para su gestión en 504. Por ejemplo, el detector de flujo 166 puede determinar que un flujo satisface los criterios de directiva de un flujo elefante. En otro ejemplo, asumiendo que se emplea TCP/IP, el detector de flujo 166 puede determinar que las direcciones de red de IP de destino de múltiples paquetes de flujo están asociadas con un proveedor comercial importante de contenido de transmisión por secuencias de vídeo en línea basándose en una toma de contacto realizada cuando se establece una conexión de TCP de 3 vías. La 4-tupla de TCP/IP (SA, DA, SP, DP) de retorno y el ID de protocolo de la conexión se pueden registrar de tal modo que el detector de flujo 166 puede detectar e inspeccionar paquetes de entrada (de w An a AN) que pertenecen al flujo de TCP/IP establecido.
En algunos casos, la capa de red de conexión de interés se puede tunelizar dentro de uno o más protocolos de encapsulación de los paquetes que se inspeccionan, lo que puede requerir que el detector de flujo 166 retire los uno o más protocolos de encapsulación con el fin de inspeccionar una de la información de red de acuse de recibo, de protocolo, de origen y de destino. Cuando no lo impide el cifrado, en algunas realizaciones, la operación de supervisión 502 también puede incluir la inspección de capas superiores (por ejemplo, la capa de HTTP o de aplicación).
En 504, el detector de flujo 166 puede identificar o seleccionar un flujo de datos que se va a procesar y a gestionar adicionalmente. Cuando el detector de flujo 166 está ubicado en el sistema de detección de flujo 112 (véase la figura 1B), el detector de flujo 166 puede dirigir los paquetes del flujo (y los paquetes de flujo de paquetes de retorno asociados) al sistema de gestión de transporte 102*. Como alternativa, el detector de flujo 166 puede señalizar al sistema de gestión de transporte 102* que comience a gestionar el flujo cuando no se requiere una redirección de tráfico (por ejemplo, los flujos de datos ya se están dirigiendo a través del sistema de gestión de transporte 102*). Si el detector de flujo 166 no identifica o selecciona un flujo de datos para su procesamiento y gestión adicional, el proceso 500 vuelve a 502.
En 506, un desempeño de entrega del flujo de datos seleccionado es medido por, por ejemplo, un gestor de flujo 212* de un sistema de gestión de transporte 102*. En algunas realizaciones, el gestor de flujo 212* puede medir el desempeño de entrega supervisando el desempeño de entrega del flujo de datos seleccionado durante una fase de medición. En una realización de una fase de medición, se puede usar un volumen de datos de un flujo y la temporización de la entrega del volumen de los datos enviados por el sistema de gestión de transporte 102* al equipo de usuario 104 para determinar el caudal de entrega promedio.
En algunos ejemplos, se pueden inferir la temporización y el desempeño de entrega al receptor (por ejemplo, el equipo de usuario 104) del flujo de datos seleccionado (que puede ser el flujo de datos para un segmento de archivo) cuando el gestor de flujo 212* reenvía uno o más paquetes de datos. Por ejemplo, el desempeño (por ejemplo, el caudal) de entrega al receptor del flujo de datos se puede averiguar contando el número de bytes de salida enviados al receptor en un intervalo de tiempo conocido que puede ser suficiente para establecer condiciones de estado estacionario en la red (por ejemplo, la red de datos 108) que conecta el sistema de gestión de transporte 102* y el receptor (por ejemplo, el equipo de usuario 104). En estas realizaciones, puede no confirmarse que los bytes en los paquetes de datos de salida se entregan al receptor, lo que puede introducir errores en el desempeño de entrega determinado, pero estos errores pueden permanecer pequeños en muchos casos y, por lo tanto, se pueden ignorar. Este método se puede usar, por ejemplo, usando capas de protocolo de transporte u otras que no soportan, o complican, la detección por el gestor de flujo 212* de información de paquetes de acuse de recibo (ACK) de retorno desde el receptor del flujo (por ejemplo, UDP).
En algunos ejemplos, la expresión "estado estacionario", como se usa en el presente documento, se puede hacer en referencia a flujos de datos y/o tasas de entrega que se logran una vez que ha pasado un período de incremento inicial (por ejemplo, el intervalo de tiempo inicial cuando una transmisión de paquetes de datos de un flujo se incrementa). Por ejemplo, durante una fase de medición de un flujo, el caudal del flujo podría fluctuar (por ejemplo, empezando de manera relativamente lenta y logrando entonces una tasa promedio sostenida después de un cierto intervalo). Si la fase de medición no es lo bastante larga o no excluye, por ejemplo, el intervalo de incremento inicial, entonces esta puede ser insuficiente para establecer un estado estacionario. Una transmisión de paquetes de datos a través de, por ejemplo, redes móviles, a menudo no será capaz de alcanzar unas condiciones de estado estacionario después de transmitir uno o unos pocos paquetes de datos. De hecho, el establecimiento de un estado estacionario puede llevar uno o unos pocos segundos, durante los cuales se envían muchos paquetes de datos, y perdurando múltiples intervalos de tiempo de viaje de ida y vuelta (de emisor a receptor y a emisor). Por lo tanto, una forma de definir una medición de estado estacionario se puede definir como la medición de flujo tomada una vez que ha pasado un cierto intervalo de tiempo (por ejemplo, intervalo de tiempo de incremento). Otra forma de definir una medición que ha logrado un estado estacionario es una en la que el intervalo de tiempo de medición se aumenta a un nivel suficiente de tal modo que la medición no cambia significativamente con mediciones adicionales.
En algunos casos, la temporización y el desempeño de entrega de los paquetes de datos en el flujo de datos seleccionado se pueden averiguar y/o confirmar inspeccionando los paquetes de ACK (por ejemplo, unos ACK de TCP) de retorno transmitidos por el receptor en respuesta a recibir los paquetes de capa de transporte (o de otra capa de protocolo) del flujo de datos que son recibidos por el receptor. Por ejemplo, en algunas realizaciones, el gestor de flujo 212* puede comenzar la operación de medición de desempeño de entrega 506 usando la temporización del número de paquetes enviados y con acuse de recibo dentro de un intervalo de tiempo definido o un volumen fijo o umbral de bytes de datos enviados y con acuse de recibo. En algunos casos, el acuse de recibo de paquetes recibidos puede implicar la inspección por el gestor de flujo 212* de cabidas útiles o encabezamientos de capas superiores/inferiores y/o de paquetes tunelizados de enlace ascendente de los paquetes de segmentos de archivo (por ejemplo, cabidas útiles o encabezamiento de capa Física, de Enlace de Datos, de Red, de Transporte, de Sesión, de Presentación o de Aplicación).
El desempeño de entrega de flujos de datos a uno o más receptores que comparten la misma red que se conecta al sistema de gestión de transporte 102* se puede usar para inferir el desempeño de entrega entre el sistema de gestión de transporte 102* y el receptor objetivo (por ejemplo, el equipo de usuario 104). Por ejemplo, el gestor de flujo 212* puede determinar el desempeño de entrega de flujo de datos a un primer receptor (por ejemplo, un primer equipo de usuario) y, si se sabe que un segundo receptor (por ejemplo, un segundo equipo de usuario) está funcionando en la misma red compartida (por ejemplo, el mismo enlace de radio de estación base de servicio), el desempeño de entrega para un flujo concurrente al segundo receptor se puede inferir sin necesidad de llevar a cabo una operación de medición separada sobre el flujo de datos del segundo receptor. El gestor de flujo 212* determina que el primer y el segundo receptores comparten una estación base, por ejemplo, basándose en información de red que enlaza la dirección de iP o de red actual del receptor con el ID de estación base de servicio. Este método se puede usar, por ejemplo, para capas de protocolo de transporte u otras que pueden dificultar que el gestor de flujo 212* lleve a cabo una fase de medición separada precisa de los flujos (por ejemplo, de UDP) del segundo receptor.
Manteniendo un registro de los desempeños de caudal observados de pico de múltiples flujos de datos de una red, el gestor de flujo 212* puede detectar flujos con un caudal más lento que el de pico en 510 y, por lo tanto, puede inferir una congestión de red, por ejemplo, a partir de flujos de tráfico en competición que comparten un enlace de red de cuello de botella.
Este método para determinar un desempeño de entrega de red de estado estacionario de múltiples flujos de datos puede depender de un volumen de datos entregado medido que es de una longitud suficiente para abarcar intervalos de tiempo de entrega de muchos viajes de ida y vuelta con el fin de lograr una estimación estable de la capacidad de caudal de la red. Cuando esto no es posible, el gestor de flujo 212* puede, en algunas realizaciones, usar valores promediados o filtrados del caudal medido para detectar una congestión.
Por ejemplo, en algunas realizaciones, el desempeño de caudal observado de pico se puede determinar a través de una ponderación estadística de uno o más valores medidos de múltiples flujos de datos tales como la determinación de percentiles, promedios, promedios ponderados, promedios móviles y similares. En otras realizaciones, el caudal de pico se puede determinar basándose en información conocida con respecto a uno o más de los segmentos de red entre el origen y el destino de contenido de los flujos de tráfico, por ejemplo, el caudal máximo de uno o más segmentos de red de cuello de botella.
En 508, se realiza una determinación en cuanto a si hay una congestión de red. El gestor de flujo 212* puede realizar una determinación de este tipo comparando el caudal actual del flujo de datos seleccionado con el caudal de pico. Si el caudal actual es igual a o mayor que el caudal de pico, el proceso 400 vuelve a 506, en donde se continúa midiendo el desempeño de entrega de los datos. Si, por otro lado, el caudal actual es menor que el caudal de pico, entonces se determina que la red está congestionada. Después de que se haya detectado una congestión de red en 508, entonces el gestor de flujo 212* entra en un modo de funcionamiento de regulación de velocidad en el que, en 510, se regula dinámicamente la velocidad del flujo de datos identificado.
En algunos ejemplos, la regulación de velocidad dinámica del flujo de datos seleccionado se puede lograr, por ejemplo, disminuyendo o aumentando de forma continua o incremental la tasa de entrega de los paquetes de datos que se transmiten al receptor. Por ejemplo, el gestor de flujo 212* puede reducir la tasa de entrega del flujo de datos seleccionado al receptor añadiendo, por ejemplo, latencias entre paquetes transmitidos al receptor al menos hasta que se haya logrado un caudal promedio objetivo para el intervalo de regulación de velocidad. Después de que se haya ajustado la tasa de entrega del flujo de datos, el proceso 500 puede volver a 506, en donde se mide de nuevo el desempeño de entrega del flujo de datos.
Con el fin de reducir la tasa de entrega del flujo de datos seleccionado, en algunos ejemplos, los paquetes de capa de red entrantes (por ejemplo, IP) desde el servidor de contenido de aguas arriba 106 se ponen en cola (por ejemplo, se almacenan en memoria intermedia) en el sistema de gestión de transporte 102* y, entonces, se retransmiten a través de la red de paquetes 108 (por ejemplo, una red de acceso) de acuerdo con una directiva de tasa objetivo. En algunos casos, la directiva de tasa objetivo puede ser una función recíproca de la congestión detectada (por ejemplo, disminuir la tasa objetivo a medida que aumenta la congestión y aumentar la tasa objetivo a medida que disminuye la congestión). Bajo una directiva de este tipo, puede no requerirse una regulación de velocidad (por ejemplo, ralentizar o reducir la tasa de entrega) si no se detecta una congestión o si la congestión detectada es más baja que algún umbral. En algunas realizaciones, dependiendo del nivel de congestión detectado, la tasa objetivo se calcula de tal modo que el caudal de tasa objetivo es más bajo que la tasa que se observó previamente que la red (por ejemplo, la red de paquetes 108) era capaz de soportar cuando uno o varios segmentos de archivo se entregaron sin una latencia de regulación de velocidad añadida.
En algunos ejemplos, la regulación de velocidad se puede implementar retardando el envío de una unidad de datos (por ejemplo, un paquete de IP) de tal modo que la tasa de transmisión promedio es consistente con un nivel objetivo. Por ejemplo, si la capacidad de caudal de interfaz física de la interfaz de salida (por ejemplo, de red móvil) orientada hacia AN (de red de acceso) del sistema de gestión de transporte 102* es de 100 Mbps, y cada tamaño de paquete de datos (por ejemplo, la cabida útil de TCP) es de 1500 bytes, entonces se pueden enviar dos paquetes puestos en cola de forma consecutiva en 2 * 1500 * 8 / 100E6 = 240E-6 s. Si, por ejemplo, se desea una tasa de regulación de velocidad objetivo de 600000 bps, entonces se puede insertar un retardo entre la transmisión de los pares de paquetes de 39,76E-3 s (o, en algunas realizaciones, enviar un paquete 1500B cada 20 ms como promedio). En algunos casos, se pueden emplear algoritmos convencionales para controlar el retardo para lograr una tasa de transmisión objetivo y características de ráfaga (por ejemplo, limitación de tasa de cubo de testigos). En algunos ejemplos, el retardo adicional insertado se puede incrementar desde cero a lo largo de varios períodos de tiempo de viaje de ida y vuelta (RTT) de capa de transporte con el fin de dar al Protocolo de Capa de Transporte de emisión (por ejemplo, TCP) una oportunidad para adaptarse a la regulación de velocidad de tasa de una forma más gradual.
En algunos ejemplos, la regulación de velocidad se puede realizar considerando los datos entregados más recientemente que se transmitieron al destino (por ejemplo, el equipo de usuario 104) sin latencia de regulación de velocidad añadida, de tal modo que los datos combinados entregados sin y con latencia de regulación de velocidad se pueden entregar a una tasa promedio que logra un nivel objetivo de tasa de transmisión. Se puede entender que la duración del intervalo de regulación de velocidad o el caudal regulado del intervalo de regulación de velocidad, o ambos, se pueden variar con el fin de lograr el nivel objetivo de tasa de transmisión.
En algunos ejemplos, el caudal regulado del intervalo de regulación de velocidad puede ser constante, de tal modo que al menos se continúa entregando un caudal mínimo para el flujo regulado en velocidad durante el intervalo de regulación de velocidad y, entonces, se calcula y se establece el intervalo de regulación de velocidad variable con el fin de lograr el nivel objetivo de tasa de transmisión, teniendo en cuenta los datos entregados más recientemente que se transmitieron sin una latencia de regulación de velocidad añadida. En otras realizaciones, la longitud del intervalo de regulación de velocidad puede ser constante y, entonces, se determina el caudal de regulación de velocidad regulado variable con el fin de lograr el nivel objetivo de tasa de transmisión, teniendo en cuenta los datos entregados más recientemente que se transmitieron sin una latencia de regulación de velocidad añadida. En otros ejemplos más, tanto el caudal regulado del intervalo de regulación de velocidad como la longitud del intervalo de regulación de velocidad pueden ser variables y determinarse de acuerdo con una directiva. Por ejemplo, establecer una tasa de caudal de regulación de velocidad regulado fija (por ejemplo, una tasa de caudal constante de 250 kilobits/segundo) para el intervalo de regulación de velocidad y ajustar la duración de tiempo del intervalo de regulación de velocidad siempre que la longitud ajustada (que se puede calcular basándose en la tasa de caudal promedio objetivo) del intervalo de regulación de velocidad no supere un máximo umbral (por ejemplo, 5 segundos); de lo contrario, la longitud del intervalo de regulación de velocidad se establece en el máximo umbral y el caudal de regulación de velocidad regulado se establece (por ejemplo, se ajusta) para lograr el nivel objetivo de tasa de transmisión.
En algunos ejemplos, la regulación de velocidad del flujo de datos identificado se puede lograr reteniendo y retardando temporalmente, en el sistema de gestión de transporte 102*, solicitudes de contenido que son transmitidas por el equipo de usuario 104 al servidor de contenido 106. En este método de regulación de velocidad, el gestor de flujo 212* examina las solicitudes de contenido (por ejemplo, GET de HTTP) y puede retardar el reenvío de las solicitudes al servidor de contenido 106 durante un intervalo de espera de acuerdo con el nivel de congestión medido actual para el equipo de usuario 104 solicitante.
En algunos ejemplos, puede funcionar una disciplina de cola de paquetes (por ejemplo, primero en entrar, primero en salir - FIFO) en el sistema de gestión de transporte 102* y se puede imponer una profundidad de cola permitida máxima para limitar la latencia de puesta en cola permitida máxima antes de que tenga lugar una pérdida de paquetes (por ejemplo, se pueden descartar paquetes de entrada cuando la cola está llena). De hecho, en algunos ejemplos del modo de regulación de velocidad, el sistema de gestión de transporte 102* puede funcionar de forma similar a un encaminador de paquetes de capa de red pero cuya capacidad de caudal de interfaz de salida se ajusta para un flujo de acuerdo con el nivel de congestión en el cuello de botella de red de aguas abajo. De esta manera, el sistema de gestión de transporte 102* puede desplazar volúmenes de tráfico entregados a intervalos de tiempo cuando una congestión no está presente o se reduce, y quitar tráfico de la red de datos 108 durante intervalos de congestión. En algunos ejemplos, el sistema de gestión de transporte 102* puede usar un marcado de paquetes, por ejemplo, Notificación de Congestión Explícita (ECN) de paquetes de Capa de Red (por ejemplo, IP) para señalar al emisor una congestión en lugar de, o además de, descartes de paquete o latencia insertada.
En algunos ejemplos de un modo de regulación de velocidad, el caudal de entrega de segmentos de archivo puede no reflejar cómo de rápido la red de datos 108 podría entregar paquetes si una latencia adicional no fuera introducida entre transmisiones de paquetes por el sistema de gestión de transporte 102*. En consecuencia, para estimar el estado real de la congestión de red de aguas abajo, el gestor de flujo 212* puede permitir periódicamente que uno o más segmentos de archivo recorran el sistema de gestión de transporte 102* sin añadir latencia de regulación de velocidad como se describirá adicionalmente en el presente documento.
La figura 5B ilustra un proceso 550 para seleccionar un flujo de datos para su gestión y para regular la velocidad del flujo de datos de acuerdo con una realización. Como se ha indicado anteriormente, el proceso 550 puede ser implementado por el gestor de flujo 212* de la figura 2A, 2B, 2C o 2D y el detector de flujo 166 de la figura 1B, 2A o 2B. En algunas realizaciones, el proceso 550 puede ser particularmente aplicable cuando no se encriptan las cabidas útiles de capa de red o de transporte. Como se ilustra, el proceso 550 incluye operaciones que son iguales o similares a algunas de las operaciones incluidas en el proceso 500 de la figura 5A. Por ejemplo, las operaciones 552, 554, 558 y 560 de la figura 5B emulan sustancialmente las operaciones 502 (por ejemplo, supervisar flujos de datos), 504 (determinar si gestionar la entrega de un flujo de datos), 508 (por ejemplo, determinar si hay una congestión de red) y 510 (por ejemplo, regular la velocidad del flujo de datos) de la figura 5A.
El proceso 550 comienza en 552, cuando los flujos de capa de red (por ejemplo, de IP) y de capa de transporte (por ejemplo, de TCP, de UDP) (por ejemplo, las porciones de TCP/IP de paquetes) que pasan a través del sistema de gestión de transporte 102* de la figura 1A o 1B (o el sistema de detección de flujo 112 de la figura 1B) son supervisados por, por ejemplo, un detector de flujo 166. En algunos casos, la supervisión de flujos puede incluir la inspección de capas superiores (por ejemplo, capa de HTTP o de aplicación) con el fin de determinar, por ejemplo, un flujo de paquetes para un archivo de contenido de medios que se transmite desde un origen (por ejemplo, el servidor de contenido 106) a un destino (por ejemplo, el equipo de usuario 104). La supervisión de flujos puede implicar adicionalmente medir el volumen de datos que se transmiten mediante un flujo de datos, la tasa de transmisión de datos del flujo de datos, y así sucesivamente.
En 554, el detector de flujo 166 puede identificar o seleccionar un flujo de datos que se va a procesar y a gestionar adicionalmente. Cuando el detector de flujo 166 está ubicado en un sistema de detección de flujo 112 (véase la figura 1B), el detector de flujo 166 puede dirigir los paquetes del flujo (y los paquetes de flujo de paquetes de retorno asociados) al sistema de gestión de transporte 102*. Como alternativa, cuando no se requiere una redirección de tráfico (por ejemplo, los flujos de datos ya se están dirigiendo a través del sistema de gestión de transporte 102*), el detector de flujo 166 puede señalizar al sistema de gestión de transporte 102* que comience a gestionar el flujo. Si no se identifica o selecciona flujo de datos alguno para su procesamiento y gestión adicional, el proceso 550 vuelve a 552.
En 556, el gestor de flujo 212* detecta una solicitud de segmento de archivo (por ejemplo, una solicitud de descarga de archivo) desde el destino (por ejemplo, el equipo de usuario 104). Por ejemplo, esto se puede lograr directamente, inspeccionando la cabida útil de capa de aplicación (por ejemplo, GET de HTTP), o indirectamente, comparando patrones de paquetes de datos heurísticos (por ejemplo, "huellas dactilares") de paquetes de enlace ascendente y de enlace descendente, por ejemplo, con direcciones de red de servidor de contenido y combinaciones de puertos de capa de transporte, ID de protocolo, etiquetas de flujo, y así sucesivamente, conocidos, dentro de intervalos de tiempo definibles, para volúmenes fijos o umbral de bytes de datos, o combinaciones distinguibles de estos. Detectando una solicitud de segmento de archivo, el sistema de gestión de transporte 102* puede averiguar que está a punto de comenzar una descarga de archivo.
En algunos casos (por ejemplo, cabidas útiles de TCP cifradas), una detección fiable de una solicitud de conexión solo puede tener lugar algún tiempo después de que hayan empezado a fluir datos de descarga en respuesta a una solicitud (por ejemplo, el volumen o patrón de datos de enlace descendente que fluyen confirma que se realizó una solicitud de archivo). Algunas realizaciones pueden emplear otros métodos para detectar que una descarga de archivo está en curso.
En 558, una determinación es realizada por, por ejemplo, el gestor de flujo 212*, en cuanto a si hay una congestión de red. En una realización, el gestor de flujo 212* puede emplear una diversidad de técnicas para determinar el estado de congestión de la red de datos 108 entre el sistema de gestión de transporte 102* y el equipo de usuario 104. En algunos casos, por ejemplo, el tamaño del segmento de archivo a descargar y la temporización de la entrega del segmento de archivo se pueden usar para determinar el caudal de entrega promedio.
En algunos ejemplos, la temporización y el desempeño de entrega al receptor del segmento de archivo se pueden inferir mediante el reenvío de uno o más segmentos de archivo por el gestor de flujo 212*, por ejemplo, tan rápido como lo permite la red. En otras realizaciones, la temporización y el desempeño de entrega del segmento de archivo se pueden confirmar adicionalmente inspeccionando los paquetes de ACK (por ejemplo, ACK de TCP) de retorno correspondientes a los paquetes de capa de transporte (o de otra capa de protocolo) del segmento de archivo enviado por el sistema de gestión de transporte 102*. Por ejemplo, en algunas realizaciones, el gestor de flujo 212* puede comenzar la determinación de estado de congestión usando la temporización del número de paquetes enviados y con acuse de recibo dentro de un intervalo de tiempo definido o un volumen fijo o umbral de bytes de datos enviados y con acuse de recibo. En algunos casos, el acuse de recibo de paquetes recibidos puede implicar la inspección por el gestor de flujo 212* de cabidas útiles o encabezamientos de capas superiores/inferiores y/o de paquetes tunelizados de enlace ascendente de los paquetes de segmentos de archivo (por ejemplo, cabidas útiles de capa o encabezamientos de capa Física, de Enlace de Datos, de Red, de Transporte, de Sesión, de Presentación o de Aplicación).
Manteniendo un registro del desempeño de caudal observado de pico durante un flujo de datos particular, el gestor de flujo 212* puede detectar transferencias de segmentos de archivo durante el flujo de datos con un caudal más lento que el de pico y, por lo tanto, puede inferir una congestión de red como resultado de, por ejemplo, flujos de tráfico en competición que comparten un enlace de red de cuello de botella.
Este método para determinar una congestión de red puede requerir que el tamaño de segmento de archivo entregado sea de una longitud suficiente que abarque intervalos de tiempo de entrega de muchos tiempos de viaje de ida y vuelta con el fin de lograr una estimación estable de la capacidad de caudal de red. Cuando este no es el caso, el gestor de flujo 212* puede, en algunas realizaciones, usar valores promediados o filtrados de caudales medidos de múltiples segmentos de archivo para detectar una congestión.
Por ejemplo, en algunas realizaciones, el desempeño de caudal observado de pico se puede determinar a través de estadísticas de uno o más valores medidos tales como percentiles, promedios, promedios ponderados, promedios móviles y similares. En algunas realizaciones, el caudal de pico se puede determinar basándose en información conocida con respecto a uno o más de los segmentos de red entre el origen y el destino de los flujos de tráfico, por ejemplo, el caudal máximo de uno o más segmentos de red de cuello de botella. Comparando el caudal actual con el caudal de pico, se puede realizar una determinación en cuanto a si hay una congestión de red. Si no se detecta congestión de red alguna (por ejemplo, el caudal actual es igual o sustancialmente igual al caudal de pico) en 558, el proceso 550 vuelve a 556 para detectar otra solicitud de segmento de archivo. Por otro lado, si se detecta una congestión de red en 558, entonces el sistema de gestión de transporte 102* entra en un modo de funcionamiento de regulación de velocidad en el que, en 560, se regula dinámicamente la velocidad del flujo de datos identificado o seleccionado.
Como se ha descrito anteriormente, la regulación de velocidad de un flujo de datos puede implicar ajustar, de forma continua o incremental, hacia abajo, la tasa de entrega del flujo de datos. Después de que se haya ajustado la tasa de entrega del flujo de datos, el proceso 550 puede volver a 556, en la que se puede detectar otra solicitud de segmento de archivo. Este proceso (por ejemplo, 556, 558 y 560) de detectar una solicitud de segmento de archivo, determinar una congestión de red y regular la velocidad del flujo de datos se puede repetir hasta que se haya descargado todo el archivo en el destino.
La figura 6A ilustra un proceso para gestionar el caudal de entrega de un flujo de datos de acuerdo con una realización. En algunos casos, el proceso 600 puede corresponder generalmente a 506, 508 y 510 de la figura 5A. En una realización, el proceso 600 puede ser implementado por el gestor de flujo 212* de la figura 2A, 2B, 2C o 2D. El proceso 600 se puede implementar incluso si el gestor de flujo 212* del sistema de gestión de transporte 102* es incapaz de supervisar e inspeccionar solicitudes de entrega de segmento de archivo y respuestas correspondientes desde, por ejemplo, servidores de contenido (por ejemplo, es incapaz de leer información contenida dentro de la capa de protocolo de aplicación).
El proceso 600 comienza en 602 cuando se determina el caudal de entrega de un flujo de datos seleccionado (seleccionado, por ejemplo, a través de las operaciones 502 y 504 de la figura 5A). Como se describirá adicionalmente en el presente documento, el caudal de entrega del flujo de datos seleccionado se puede determinar usando una o más técnicas disponibles para determinar un caudal de entrega, tales como contar, durante un intervalo de tiempo, el número de paquetes de datos del flujo de datos seleccionado que el sistema de gestión de transporte 102* es capaz de enviar al equipo de usuario 104 y que es permitido por la red de acceso (por ejemplo, la red de datos 108). Se pueden emplear otras técnicas con el fin de estimar el caudal de entrega del flujo de datos seleccionado en otros ejemplos.
En 604, se realiza una determinación en cuanto a si existe una congestión de red entre el sistema de gestión de transporte 102* y el equipo de usuario 104. En una realización, esto puede implicar comparar el caudal de entrega determinado actualmente con el caudal de pico histórico para el flujo de datos seleccionado asociado con el segmento de archivo que se descarga al equipo de usuario 104. Si no se detecta una congestión de red, el proceso 600 vuelve a 602, de lo contrario, el proceso 600 se desplaza a 606. Obsérvese que se proporcionarán a continuación detalles específicos relacionados con 602 y 604 con referencia al proceso 650 de la figura 6B.
En 606, se calcula un caudal de entrega objetivo basándose en el nivel de congestión de red determinado en 604. En una realización, el caudal de entrega objetivo estimado es un caudal menor que el caudal de pico para el flujo de datos seleccionado. Y, en la mayoría de los casos, el caudal de entrega objetivo es menor que el caudal determinado en 602. En un ejemplo, el caudal de entrega objetivo se puede calcular basándose, al menos en parte, en el nivel determinado de congestión de red.
En 608, la entrega del flujo de datos seleccionado al destino (por ejemplo, el equipo de usuario 104) se reanuda entregando el flujo de datos seleccionado al destino usando una tasa de caudal de entrega que coincide con la tasa de caudal de entrega objetivo calculada. La entrega del flujo de datos seleccionado puede continuar al menos hasta que se haya interrumpido el flujo de datos (por ejemplo, cuando no hay más datos que entregar), lo que, en algunos casos, se puede basar en un tiempo de espera después de pausas de entrega de datos o en la observación de una anulación de conexión de flujo (por ejemplo, una toma de contacto de 4 vías de TCP), un restablecimiento de conexión, un tiempo de espera de actividad de flujo o una indicación similar de que el flujo ya no está activo.
En 610, datos a partir del flujo de datos seleccionado recibidos por el sistema de gestión de transporte 102* se almacenan en memoria intermedia (por ejemplo, se ponen en cola) en, por ejemplo, la cola 206 del sistema de gestión de transporte 102*.
En 612, se regula la velocidad de la entrega del flujo de datos seleccionado al destino ajustando el flujo de los datos almacenados en memoria intermedia almacenados en el sistema de gestión de transporte 102* al destino (por ejemplo, el equipo de usuario 104) para lograr el caudal de entrega objetivo.
En 614, se realiza una determinación en cuanto a si es necesario actualizar la estimación de congestión de red (como se estima en 604). Si no es necesaria actualización alguna de este tipo, entonces el proceso 600 vuelve a 608. Por otro lado, si es necesario actualizar la estimación de congestión de red, entonces el proceso 600 vuelve a 602. Volviendo a 602, se puede realizar una determinación en cuanto a un nivel de congestión de red nuevo o actualizado, que se puede usar entonces con el fin de ajustar la tasa de entrega del flujo de datos al destino.
El proceso desencadena periódicamente (por ejemplo, cada N-ésimo segmento de archivo entregado, después de un intervalo o intervalos de tiempo predeterminados, o después de que se haya entregado una cantidad umbral de datos) una actualización de (por ejemplo, un muestreo de paquetes no regulados en velocidad para determinar) el estado de congestión de la red de datos 108 entre el sistema de gestión de transporte 102* y el destino provocando una salida de la entrega de modo de regulación de velocidad del flujo de datos seleccionado, y siguiendo un bucle de vuelta al comienzo del proceso 600.
En algunos ejemplos, las condiciones que pueden influir en si es necesaria una actualización de la congestión estimada de la red incluyen, por ejemplo, si otras conexiones desde otros terminales de equipo de usuario en comunicación con el sistema de gestión de transporte 102* han notificado recientemente acerca del estado de congestión de la misma red de datos 108 o una porción de caudal de cuello de botella de la misma. Sin embargo, los ejemplos pueden usar otras condiciones para influir en si es necesaria una actualización.
Haciendo referencia a la figura 6B, que ilustra un proceso 650 para determinar un caudal de entrega de un flujo de datos seleccionado y determinar si hay una congestión de red de acuerdo con una realización. El proceso 650 corresponde generalmente a las operaciones 602 y 604 de la figura 6A. En algunos ejemplos, el proceso 650 puede ser implementado por el gestor de transporte 102* de la figura 2A, 2B, 2C o 2D. El proceso 650 comienza cuando se mide, en 652, un flujo de datos seleccionado (como se selecciona, por ejemplo, mediante las operaciones 502 y 504 de la figura 5A). En algunas realizaciones, la medición del flujo de datos seleccionado puede implicar contar los paquetes asociados con el flujo de datos seleccionado que son enviados por el sistema de gestión de transporte 102* al equipo de usuario 104.
En 654, se inicia un temporizador. Una vez que se ha iniciado el temporizador, el sistema de gestión de transporte 102* (y, más particularmente, el gestor de flujo 212*) continúa contando los paquetes asociados con el flujo de datos seleccionado que están siendo enviados por el sistema de gestión de transporte 102*. El recuento puede continuar al menos hasta que se hayan enviado y/o entregado datos suficientes para lograr una estimación de estado estacionario fiable del caudal de entrega de red de aguas abajo. Esta determinación se puede basar en el tiempo transcurrido, la tasa de entrega, el número de ciclos de ACK de Capa de Transporte, el volumen de datos entregados, y así sucesivamente, o cualquier combinación de los mismos.
En 658, se calcula y se registra el caudal de entrega actual. En una realización, el cálculo se puede basar en las mediciones de flujo de datos realizadas en 656.
En 660, se realiza una determinación en cuanto a si se debería actualizar el caudal de pico para el flujo de datos seleccionado. Obsérvese que, en algunos casos, un caudal de pico se asociará con un flujo de datos específico. Por ejemplo, cuando se está descargando un flujo de datos asociado con un archivo de contenido de medios al equipo de usuario 104, el caudal de entrega del flujo de datos puede oscilar enormemente dependiendo de una congestión de red y de otras condiciones de red (por ejemplo, la relación de señal a ruido o SNR, ubicaciones de nodo de red, intensidades de señal, y así sucesivamente). El caudal del flujo de datos oscilará desde un caudal de pico que puede corresponder a la situación en la que no hay congestión de red alguna a un caudal mucho más bajo cuando, por ejemplo, la red está sustancialmente congestionada. Por lo tanto, puede que sea necesario actualizar el caudal de pico en cualquier punto dado en el tiempo si se detecta un pico nuevo mientras se está entregando el flujo de datos al destino.
Si se realiza una determinación de que es necesario actualizar el caudal de pico para el flujo de datos seleccionado, entonces el caudal de pico se actualiza en 662. Por otro lado, si no es necesaria actualización alguna, entonces el proceso 650 se desplaza a 664, en donde se realiza una determinación en cuanto a si hay una congestión de red. En un ejemplo, una congestión de red se puede identificar cuando el caudal calculado cae por debajo del caudal de pico (que, de nuevo, se puede restablecer de forma continua o periódica para evitar estimaciones obsoletas de la capacidad de entrega de red en un funcionamiento no congestionado).
Si no se detecta congestión de red alguna, entonces el proceso 650 vuelve a 654 al menos hasta que se haya interrumpido el flujo de datos (por ejemplo, no hay más datos que entregar). Por otro lado, si se detecta una congestión de red, entonces una determinación es realizada por el sistema de gestión de transporte 102* (y, más particularmente, el gestor de flujo 212*) de que la red de datos 108 entre el sistema de gestión de transporte 102* y el equipo de usuario 104 está, de hecho, congestionada.
Durante la fase de medición del proceso 650 (por ejemplo, las operaciones 652, 654 y 656), el flujo de datos supervisado o muestreado puede, o no, ser continuo. Puede haber situaciones en las que el servidor de contenido 106 y/o el equipo de usuario 104 hayan provocado una interrupción en el flujo de datos seleccionado. Por ejemplo, una aplicación de reproductor de medios podría llenar su memoria intermedia de reproducción en tiempo de ejecución y pausar temporalmente sus solicitudes de datos desde un servidor de transmisión por secuencias de vídeo. En un escenario de este tipo, la fase de medición podría determinar una estimación artificialmente baja del desempeño de entrega de red para el flujo de datos. En consecuencia, una fase de medición puede ir precedida de una fase de incremento (por ejemplo, como parte de 602) para garantizar que el flujo de datos está activo antes de proceder con la medición. La fase de incremento en algunas realizaciones puede persistir hasta que se haya alcanzado un volumen umbral de datos, un tiempo de actividad umbral o una combinación de estos criterios o unos similares para el flujo. Se puede volver a entrar en la fase de incremento siempre que se detecte inactividad para el flujo de datos.
La figura 7A ilustra un proceso para gestionar el caudal de entrega de un flujo de datos de acuerdo con una realización. En algunos casos, el proceso 700 puede corresponder generalmente a 556, 558 y 560 de la figura 5B. En una realización, el proceso 600 puede ser implementado por el gestor de flujo 212* de la figura 2A, 2B, 2C o 2D. En algunos casos, el proceso 700 puede ser particularmente útil cuando el gestor de flujo 212* del sistema de gestión de transporte 102* es capaz de detectar e inspeccionar solicitudes de entrega de segmento de archivo y respuestas correspondientes desde, por ejemplo, servidores de contenido (por ejemplo, es capaz de leer información sin cifrar contenida dentro de la capa de protocolo de aplicación).
El proceso 700 comienza en 702 cuando se determina el caudal de entrega para un segmento de archivo que se está entregando al destino (por ejemplo, el equipo de usuario 104) y que está asociado con un flujo de datos seleccionado (como se selecciona, por ejemplo, a través de las operaciones 552 y 554 de la figura 5B). En algunas realizaciones, el segmento de archivo se está retransmitiendo al equipo de usuario 104 a través del sistema de gestión de transporte 102* en respuesta a una solicitud de segmento de archivo (por ejemplo, una Solicitud de Intervalo de Bytes de HTTP) que se envía desde el equipo de usuario 104 al servidor de contenido 106. La solicitud de segmento de archivo puede ser detectada por el sistema de gestión de transporte 102*. La entrega consiguiente del segmento de archivo (sin intervención de regulación de velocidad) se puede usar para sondear el caudal de red de aguas abajo a medida que este pasa a través del sistema de gestión de transporte 102* usando un proceso como se ilustra, por ejemplo, en la figura 7B.
En 704, se realiza una determinación en cuanto a si existe una congestión de red entre el sistema de gestión de transporte 102* y el equipo de usuario 104. En una realización, esto puede implicar comparar el caudal de entrega determinado actualmente con el caudal de pico histórico para el flujo de datos seleccionado asociado con el segmento de archivo que se descarga al equipo de usuario 104. Si no se detecta congestión de red alguna, el proceso 700 vuelve a 702, de lo contrario, el proceso 7600 se desplaza a 706. Obsérvese que se proporcionarán a continuación detalles específicos relacionados con 702 y 704 con referencia al proceso 750 de la figura 7B.
En 706, se calcula un caudal de entrega objetivo basándose en el nivel de congestión de red determinado en 704. En una realización, el caudal de entrega objetivo estimado será un caudal menor que el caudal de pico para el flujo de datos seleccionado. Y, en la mayoría de los casos, el caudal de entrega objetivo será menor que el caudal determinado en 702. En una realización, el caudal de entrega objetivo se puede calcular basándose, al menos en parte, en el nivel determinado de congestión de red.
En 708, se detecta una solicitud de segmento de archivo asociada con el flujo de datos seleccionado y que es enviada por el equipo de usuario 104.
En 710, datos asociados con el segmento de archivo solicitado y que son recibidos por el sistema de gestión de transporte 102* se almacenan en memoria intermedia (por ejemplo, se ponen en cola) en, por ejemplo, la cola 206 del sistema de gestión de transporte 102*.
En 712, se regula la velocidad de la entrega al destino (por ejemplo, el equipo de usuario 104) de los datos asociados con el segmento de archivo solicitado ajustando el flujo de los datos almacenados en memoria intermedia almacenados en el sistema de gestión de transporte 102* para lograr el caudal de entrega objetivo.
En 714, se realiza una determinación en cuanto a si es necesario actualizar la estimación de congestión de red. Si no es necesaria actualización alguna de este tipo, entonces el proceso 700 vuelve a 708. En algunos casos, la solicitud de segmento de archivo que se puede haber detectado originalmente en 708 puede ser para todo el archivo, en cuyo caso, el proceso 700 sigue un bucle de vuelta a 710 para continuar la entrega del archivo cuando no se requiere una actualización de congestión (por ejemplo, no son necesarias las operaciones 702 y 704). Por otro lado, si es necesario actualizar la estimación de congestión de red, entonces el proceso 700 vuelve a 702. Volviendo a 702, se puede realizar una determinación en cuanto a un nivel de congestión de red nuevo o actualizado, que se puede usar entonces con el fin de ajustar la tasa de entrega del flujo de datos al destino.
Como se describe con respecto a 714 de la figura 7A, se pueden considerar diversos factores cuando se determina cuándo actualizar la estimación de congestión de red. Por ejemplo, la estimación de congestión de red se puede actualizar, en algunos casos, periódicamente (por ejemplo, cada N-ésimo segmento de archivo entregado, después de un intervalo o intervalos de tiempo predeterminados, o después de que se haya entregado una cantidad umbral de datos).
En algunos ejemplos, las condiciones que pueden influir en si es necesaria una actualización de la congestión estimada de la red incluyen, por ejemplo, si otras conexiones desde otros terminales de equipo de usuario en comunicación con el sistema de gestión de transporte 102* han notificado recientemente acerca del estado de congestión de la misma red de datos 108 o una porción de caudal de cuello de botella de la misma. Sin embargo, los ejemplos pueden usar otras condiciones para influir en si es necesaria una actualización.
La figura 7B ilustra un proceso 750 para determinar un caudal de entrega de un segmento de archivo asociado con un flujo de datos seleccionado y para determinar si hay una congestión de red de acuerdo con una realización. El proceso 750 corresponde generalmente a las operaciones 702 y 704 de la figura 7A. En algunas realizaciones, el proceso 750 puede ser implementado por el gestor de transporte 102* de la figura 2A, 2B, 2C o 2D. El proceso 750 comienza cuando se detecta, en 752, una solicitud de segmento de archivo (por ejemplo, una Solicitud de Intervalo de Bytes de HTTP) asociada con un flujo de datos seleccionado (un flujo de datos como se selecciona, por ejemplo, mediante las operaciones 552 y 554 de la figura 5B).
En 754, se inicia un temporizador. Una vez que se ha iniciado el temporizador, el sistema de gestión de transporte 102* (y, en particular, el gestor de flujo 212*) puede supervisar el flujo de datos seleccionado hasta que el sistema de gestión de transporte 102* haya detectado en 756 una solicitud de segmento de archivo posterior transmitida por el destino (por ejemplo, el equipo de usuario 104). En algunas realizaciones, la supervisión del flujo de datos seleccionado puede implicar, por ejemplo, supervisar en busca de paquetes de ACK de retorno transmitidos por el destino (por ejemplo, el equipo de usuario 104) tras una entrega/recepción con éxito de paquetes de segmentos de archivo desde el sistema de gestión de transporte 102*
En 758, se calcula y se registra el caudal para el segmento de archivo solicitado. En algunos casos, el caudal se puede calcular averiguando la cantidad de datos asociados con el segmento de archivo solicitado que se entregó al equipo de usuario 104 durante un intervalo de tiempo entre el inicio del temporizador y cuando se detectó la solicitud de segmento de archivo posterior en 756. Dividiendo la cantidad de datos entregada por el intervalo de tiempo, se puede calcular un caudal.
En algunos ejemplos, si el sistema de gestión de transporte 102* puede identificar el paquete de inicio y el paquete final de la respuesta de segmento de archivo, entonces, determinando la cantidad de tiempo que transcurre entre la recepción del paquete de inicio y el paquete final, se puede usar, como alternativa (por ejemplo, tamaño_segmento_archivo/intervalo_tiempo), para medir directamente el caudal de aguas abajo del segmento de archivo, sin que sea necesario hacer referencia a la temporización de las órdenes de solicitud de segmento de archivo. Se pueden usar métodos similares para subdividir la entrega en segmentos de archivo en escenarios en los que puede tener lugar una única solicitud de archivo de todo el archivo.
En 760, se realiza una determinación en cuanto a si se debería actualizar el caudal de pico para el flujo de datos seleccionado. Obsérvese que, en algunos casos, un caudal de pico se asociará con un flujo de datos específico. Por ejemplo, cuando se está descargando un flujo de datos asociado con un archivo de contenido de medios al equipo de usuario 104, el caudal de entrega del flujo de datos puede oscilar enormemente dependiendo de una congestión de red y de otras condiciones de red (por ejemplo, la relación de señal a ruido o SNR, ubicaciones de nodo de red, intensidades de señal, y así sucesivamente). El caudal del flujo de datos oscilará desde un caudal de pico que puede corresponder a la situación en la que no hay congestión de red alguna a un caudal mucho más bajo cuando, por ejemplo, la red está sustancialmente congestionada. Por lo tanto, puede que sea necesario actualizar el caudal de pico en cualquier punto dado en el tiempo si se detecta un pico nuevo mientras se está entregando el flujo de datos al destino.
Si se realiza una determinación de que es necesario actualizar el caudal de pico para el flujo de datos seleccionado, entonces el caudal de pico se actualiza en 762. Por otro lado, si no es necesaria actualización alguna, entonces el proceso 750 se desplaza a 764, en donde se realiza una determinación en cuanto a si hay una congestión de red. En una realización, una congestión de red se puede identificar cuando el caudal calculado cae por debajo del caudal de pico (que, de nuevo, se puede restablecer de forma continua o periódica para evitar estimaciones obsoletas de la capacidad de entrega de red en un funcionamiento no congestionado).
Si no se detecta una congestión de red, entonces el proceso 750 vuelve a 754 al menos hasta que se haya interrumpido el flujo de datos (por ejemplo, no hay más datos que entregar). Por otro lado, si se detecta una congestión de red, entonces una determinación es realizada por el sistema de gestión de transporte 102* (y, más particularmente, el gestor de flujo 212*) de que la red de datos 108 entre el sistema de gestión de transporte 102* y el equipo de usuario 104 está, de hecho, congestionada.
En algunos ejemplos, la determinación de congestión se puede ver afectada por el tipo de red, información de anexión de red (por ejemplo, ID de estación base, ID de célula) si tal información está disponible para el sistema de gestión de transporte 102*.
El sistema de gestión de transporte 102* puede usar métodos alternativos para detectar una congestión tales como calcular el tiempo de viaje de ida y vuelta (RTT) de aguas abajo de segmentos/ACK de Capa de Transporte y observar tasas de cambio del RTT (por ejemplo, que aumenta cuando una congestión aumenta). El procesamiento de RTT y de ACK se puede implementar usando capas de protocolo que no sean la Capa de Transporte (por ejemplo, TCP o UDP).
En algunos casos, el segmento de archivo solicitado que se va a entregar al equipo de usuario 104 tiene un tamaño de datos suficientemente grande que habilita una estimación de estado estacionario estable del caudal de entrega de red de aguas abajo en 758. Esta determinación se puede basar en el tiempo transcurrido total, el número de ciclos de ACK de Capa de Transporte de emisor/receptor secuenciales, el volumen de datos entregados o criterios similares. Sin embargo, este requisito puede no ser necesario en otros casos.
En algunos casos, el estado estacionario solo se puede lograr después de que la máquina de estados de control de congestión de protocolo de capa de transporte haya enviado muchos paquetes de datos. En general, un único segmento o unos pocos segmentos de Capa de Transporte pueden no ser suficientes. Dependiendo del protocolo de sesión de entrega, puede ser suficiente una única respuesta de segmento de archivo o pueden ser necesarios múltiples ciclos de solicitud/respuesta secuenciales, en los que se pueden promediar o filtrar las mediciones de caudal de entrega de respuesta. Por ejemplo, en protocolos de medios de transmisión por secuencias modernos, a menudo se realiza una solicitud de archivo para un "fragmento" de datos de vídeo codificado (por ejemplo, 128 kilobytes) que a menudo, pero no siempre, es lo bastante grande para permitir una estimación estable de la capacidad de caudal de estado estacionario de red.
Una vez que se ha establecido un estado estacionario, el caudal medido se puede calcular en 758 y la estimación de caudal de pico se puede actualizar, si es necesario, en 762.
Si se detecta una congestión de red de aguas abajo en 764 y 766, entonces el sistema de gestión de transporte 102* puede funcionar con respecto al flujo de datos seleccionado en un modo de regulación de velocidad (por ejemplo, las operaciones 710 y 712 ilustradas en la figura 7A).
Como se ha descrito con brevedad anteriormente, en algunas realizaciones, el equipo de usuario 104 puede emplear un agente 312. El agente 312 puede ser un agente de software implementado por uno o más procesadores 304 (u otros tipos de circuitería programable) que ejecutan una o más instrucciones legibles por máquina. En otra realización, el agente 312 puede residir en otros elementos de red (por ejemplo, una estación base, un controlador de estación base, y así sucesivamente) que pueden estar asociados con la red de acceso (por ejemplo, la red de datos 108) que interconectan el equipo de usuario 104.
En algunos ejemplos, el agente 312 puede ayudar al sistema de gestión de transporte 102* con ciertas operaciones y tareas tales como la identificación de terminales (por ejemplo, la identificación de equipos de usuario) y la notificación de estado de red. Adicionalmente, el agente 312 puede ayudar al sistema de gestión de transporte 102* con otras operaciones y tareas.
La figura 8 ilustra un proceso para interaccionar con un agente de acuerdo con una realización. En algunas realizaciones, el proceso 800 puede ser implementado por un sistema de gestión de transporte 102*.
El proceso 800 comienza cuando el sistema de gestión de transporte 102* registra un agente 312. El registro del agente 312 se puede basar en un identificador único (UI) de agente (por ejemplo, una identidad de equipo de estación móvil internacional (IMEI) del agente) y una dirección de datos de red actual (por ejemplo, IP) del equipo de usuario correspondiente asociado con el agente, con el fin de ayudar con el descubrimiento de flujos de datos (que pueden existir, por ejemplo, entre el equipo de usuario 104 y servidores de contenido remotos). El registro también puede permitir el establecimiento de una conexión de datos de control entre el equipo de usuario 104 y el sistema de gestión de transporte 102*, facilitando de ese modo la capacidad de mensajes "de inserción". El registro se puede repetir siempre que el equipo de usuario 104 se ponga en línea, cambie su dirección de datos de red, cambie el tipo de red de servicio, y así sucesivamente.
En 804, el sistema de gestión de transporte 102* (o el sistema de detección de flujo 112) puede detectar el inicio de una sesión de entrega de archivos desconocidos. Durante el registro, el agente y el sistema de gestión de transporte 102* pueden intercambiar cierta información, tal como la dirección de IP del equipo de usuario 104 asociado con el agente 312.
En 806, la identidad del agente 312 asociado con la sesión de entrega de archivos desconocidos se determina inspeccionando los paquetes de la sesión de entrega de archivos. Por ejemplo, el equipo de usuario 104 (que puede estar asociado adicionalmente con un agente 312 particular) asociado con la entrega del archivo desconocido se puede detectar, en algunos casos, inspeccionando cabidas útiles de aplicación de paquetes de TCP/IP (por ejemplo, que se identifican con la dirección de IP del equipo de usuario 104 como es notificado por el agente 312 durante el registro).
En 808, el sistema de gestión de transporte 102* puede señalizar al equipo de usuario 104 que induzca al agente 312 a comenzar a notificar información que puede ser útil para el sistema de gestión de transporte 102* en la gestión de flujos de datos al equipo de usuario 104. En algunas realizaciones, la información que se puede notificar incluye una o más de la calidad de enlace de radio actual (por ejemplo, en términos de capacidad de caudal máxima) que se puede determinar y notificar periódicamente, el tipo de red actual (por ejemplo, Tercera Generación (3G), Acceso por Paquetes de Alta Velocidad (HSPA), Evolución a Largo Plazo (LTE), Fidelidad Inalámbrica (Wi-Fi), y así sucesivamente), la ubicación de anexión actual (por ejemplo, Identificación de Estación Base (BSID), ID de Célula, latitud/longitud, Sistema de Posicionamiento Global (GPS), Identificación de Conjunto de Servicios (SSID), y así sucesivamente), el operador de servicio actual (por ejemplo, "XYZ Inalámbrico"), el estado de recursos de dispositivo de usuario (por ejemplo, batería baja, estado de movilidad, estado de procesador), estado de aplicación de dispositivo de usuario (por ejemplo, "Aplicación de Reproductor de Medios XYZ activa"), y así sucesivamente.
En 810, el sistema de gestión de transporte 102* puede detectar el final de la sesión de entrega de archivos. En 812, el sistema de gestión de transporte 102*, después de detectar el final de la sesión de entrega de archivos, puede señalizar al equipo de usuario 104 que interrumpa la notificación. En algunas realizaciones, el agente 312 puede dejar de notificar de forma independiente (basándose, por ejemplo, en cambios en el tipo de red, batería baja, sin sesiones de datos activas, entrada en modo avión, y así sucesivamente).
En algunos ejemplos, el agente 312 puede realizar, adicionalmente o como alternativa, su propia evaluación de la capacidad de caudal de la red (por ejemplo, entre el equipo de usuario 104 asociado y un origen de entrega de datos remoto, o para una estación base que atiende a una colección de terminales de equipo de usuario) que también se podría notificar al sistema de gestión de transporte 102*. En tales escenarios, el sistema de gestión de transporte 102* puede usar las notificaciones desde el agente 312 para determinar una congestión en lugar de, o además de, su propia evaluación de una congestión de red.
En algunos ejemplos, puede ser posible dividir la trayectoria de conexión de capa de transporte entre el emisor (por ejemplo, el servidor de contenido 106) y el receptor (por ejemplo, el equipo de usuario 104) en dos trayectorias en el sistema de gestión de transporte 102*. En la versión de única trayectoria por defecto, la regulación de velocidad por el sistema de gestión de transporte 102* puede alterar la temporización de los segmentos de capa de transporte (variación de RTT) como un mecanismo de control previsto para modular la tasa del tráfico afectado. Algunos algoritmos de control de congestión de transporte (por ejemplo, evitación de congestión de TCP) pueden responder de manera ineficiente a cambios escalonados grandes en el RTT de extremo a extremo. Dividir la trayectoria en dos trayectorias separadas con máquinas de estado de capa de transporte independientes puede ser una forma de realizar una regulación de velocidad sin interferir con el algoritmo de control de congestión de TCP, mientras se sigue permitiendo que un sistema de gestión de transporte 102* module la tasa de caudal de extremo a extremo de unas conexiones de capa de transporte separadas.
En algunas situaciones, el sistema de gestión de transporte 102* puede no ser capaz de detectar de forma fiable unos ACK de recepción de paquete (por ejemplo, UDP sin acuse de recibo con cabidas útiles cifradas) que proceden del receptor del flujo. Esto puede complicar la determinación de una congestión de red y el desempeño de entrega de flujos de tráfico por el sistema de gestión de transporte 102*. En estas situaciones, el sistema de gestión de transporte 102* se puede diseñar para funcionar con el fin de hacer que el destino (por ejemplo, el equipo de usuario 104) transmita paquetes de ACK en un flujo de una de varias formas.
Por ejemplo, el sistema de gestión de transporte 102* puede, en algunas realizaciones, inyectar paquetes de capa de transporte (por ejemplo, de TCP) adicionales, después de cada uno de uno o más paquetes de UDP enviados en un flujo de capa de transporte, con el fin de que el agente 312 que recibe tales paquetes diese acuse de recibo de los paquetes de TCP insertados. Los paquetes de TCP inyectados se pueden dirigir al agente 312 en lugar de a la aplicación de destino de paquetes de UDP en el mismo equipo de usuario 104. La recepción con éxito de los uno o más paquetes de UDP por el equipo de usuario 104 puede ser inferida entonces por el sistema de gestión de transporte 102* tras recibir los ACK de TCP correspondientes. En otros ejemplos, el sistema de gestión de transporte 102* puede establecer indicadores o insertar campos de ampliación en los encabezamientos o cabidas útiles de los paquetes de flujo de transporte (por ejemplo, UDP) sin acuse de recibo, u otra capa de protocolo, que hacen que el equipo de usuario 104 de recepción o la aplicación 314 dé acuse de recibo de la recepción del paquete de flujo de transporte o que indican que se ha recibido el paquete de flujo de transporte.
En otras situaciones (por ejemplo, UDP o TCP), el sistema de gestión de transporte 102* puede funcionar en un modo que no requiere detectar unos ACK de recepción de paquete desde el receptor del flujo, o que no requiere los agentes 312.

Claims (15)

REIVINDICACIONES
1. Un método, que comprende:
examinar un primer paquete de datos transmitido desde un primer equipo de red a un segundo equipo de red, estando el primer equipo de red y el segundo equipo de red ubicados de forma remota uno con respecto a otro y enlazados por al menos una red;
determinar un flujo de datos del primer paquete de datos;
determinar un tipo de flujo de datos del flujo de datos;
cuando el tipo de flujo de datos es un primer tipo, permitir que el primer paquete de datos se transmita al segundo equipo de red sin realizar un proceso de gestión de flujo; y
cuando el tipo de flujo de datos es un segundo tipo, seleccionar el primer paquete de datos para el proceso de gestión de flujo,
en donde el proceso de gestión de flujo comprende:
determinar un caudal de entrega del flujo de datos a través de una trayectoria de flujo de datos (506), teniendo la trayectoria de flujo de datos una pluralidad de nodos de red y siendo una conexión compartida entre el segundo equipo de red y el primer equipo de red, relacionado el caudal de entrega con una tasa de transferencia de datos al segundo equipo de red desde el primer equipo de red a través de la trayectoria de flujo de datos;
detectar una congestión de red en la trayectoria de flujo de datos comparando el caudal de entrega determinado con una capacidad de caudal de datos de pico esperada para un paquete de datos transmitido al segundo equipo de red desde el primer equipo de red (508); y
regular la velocidad de una transmisión de una pluralidad de paquetes de datos por el primer equipo de red al segundo equipo de red cuando se detecta una congestión de red en la trayectoria de flujo de datos (5l0).
2. El método de la reivindicación 1, en donde el segundo tipo de tipo de flujo de datos incluye un flujo elefante que consume una porción más grande de ancho de banda de red que un nivel umbral, tiene una tasa de datos que supera una cantidad umbral, persiste durante más tiempo que una cantidad umbral de tiempo, o una combinación de los mismos.
3. El método de la reivindicación 1, en donde se determina que el tipo de flujo de datos del flujo de datos es el segundo tipo basándose en un origen del primer paquete de datos.
4. El método de la reivindicación 1, en donde el proceso de gestión de flujo es realizado por un tercer equipo de red que está ubicado de forma remota con respecto al primer equipo de red, y en donde el primer equipo de red es un proveedor de contenido.
5. El método de la reivindicación 1, en donde el proceso de gestión de flujo es realizado por un gestor de transporte en un tercer equipo de red.
6. El método de la reivindicación 1, que comprende además:
determinar la capacidad de caudal de datos de pico esperada usando uno o más paquetes de acuse de recibo, ACK, transmitidos por el segundo equipo de red en respuesta a que el segundo equipo de red reciba uno o más paquetes de datos desde el primer equipo de red.
7. El método de la reivindicación 6, que comprende además:
inducir al segundo equipo de red a transmitir los uno o más paquetes de ACK.
8. El método de la reivindicación 1, en donde regular la velocidad de la entrega del flujo de datos al segundo equipo de red reduciendo una tasa a la que el flujo de datos se está entregando al segundo equipo de red comprende: almacenar en memoria intermedia la pluralidad de paquetes de datos con el primer paquete de datos en una cola.
9. El método de la reivindicación 1, en donde regular la velocidad de la entrega de la pluralidad de paquetes de datos incluye añadir una o más latencias entre una transmisión de paquetes de datos de la pluralidad de paquetes de datos antes de que los paquetes de datos de la pluralidad de paquetes de datos se transmitan al segundo equipo de red.
10. El método de la reivindicación 1, en donde la capacidad de caudal de datos de pico esperada es un caudal de referencia determinado basándose en un paquete de datos que se entregó al segundo equipo de red desde el primer equipo de red en un momento anterior.
11. El método de la reivindicación 10, que comprende además:
actualizar el caudal de referencia con el caudal de entrega del primer paquete de datos si el caudal de entrega del primer paquete de datos es mayor que el caudal de referencia;
en donde el caudal de referencia actualizado se usa como la capacidad de caudal de datos de pico esperada en un proceso de gestión de flujo posterior.
12. El método de la reivindicación 1, en donde el tipo de flujo de datos del segundo tipo incluye flujos de datos que incluyen datos de un archivo de medios.
13. El método de la reivindicación 1, en donde el primer paquete de datos y la pluralidad de paquetes de datos que se regulan en velocidad incluyen datos para un mismo archivo de medios.
14. El método de la reivindicación 1, en donde el segundo equipo de red es un dispositivo móvil y la trayectoria de flujo de datos incluye un enlace inalámbrico.
15. El método de la reivindicación 1, en donde regular la velocidad de la transmisión de la pluralidad de paquetes de datos comprende regular la velocidad de la transmisión de la pluralidad de paquetes de datos de acuerdo con un nivel de congestión de la trayectoria de flujo de datos.
ES16759533T 2015-03-03 2016-03-03 Método para regular la velocidad de flujos de datos Active ES2902497T3 (es)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201562127753P 2015-03-03 2015-03-03
US201562207529P 2015-08-20 2015-08-20
US201662277320P 2016-01-11 2016-01-11
PCT/US2016/020774 WO2016141239A1 (en) 2015-03-03 2016-03-03 Systems and methods for pacing data flows

Publications (1)

Publication Number Publication Date
ES2902497T3 true ES2902497T3 (es) 2022-03-28

Family

ID=56848671

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16759533T Active ES2902497T3 (es) 2015-03-03 2016-03-03 Método para regular la velocidad de flujos de datos

Country Status (7)

Country Link
US (4) US10270700B2 (es)
EP (1) EP3266170B1 (es)
JP (1) JP6672340B2 (es)
KR (2) KR102583750B1 (es)
CN (1) CN107637032A (es)
ES (1) ES2902497T3 (es)
WO (1) WO2016141239A1 (es)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2499237A (en) * 2012-02-10 2013-08-14 Ibm Managing a network connection for use by a plurality of application program processes
WO2015077504A1 (en) * 2013-11-20 2015-05-28 Opanga Networks, Inc. Fractional pre-delivery of content to user devices
CA2952988C (en) 2014-08-26 2023-03-21 Ctera Networks, Ltd. Method and system for routing data flows in a cloud storage system
US9813299B2 (en) * 2016-02-24 2017-11-07 Ciena Corporation Systems and methods for bandwidth management in software defined networking controlled multi-layer networks
EP3513594B1 (en) * 2016-09-13 2024-01-17 Opanga Networks, Inc. Directed handover of elephant flows
US11805034B1 (en) 2016-12-07 2023-10-31 Reservoir Labs, Inc. Systems and methods for detecting large network flows
ES2963965T3 (es) 2017-04-28 2024-04-03 Opanga Networks Inc Sistema y procedimiento de seguimiento de nombres de dominio para la gestión de redes
US11095535B2 (en) 2017-08-15 2021-08-17 Gigamon Inc. Adaptive and flexible packet sampling
US10972358B2 (en) 2017-08-30 2021-04-06 Citrix Systems, Inc. Inferring congestion and signal quality
US11153175B2 (en) * 2017-10-16 2021-10-19 International Business Machines Corporation Latency management by edge analytics in industrial production environments
JP6928256B2 (ja) * 2017-11-02 2021-09-01 富士通株式会社 パケット解析プログラム、パケット解析装置、及び、パケット解析方法
US10778568B2 (en) * 2017-12-05 2020-09-15 Mellanox Technologies, Ltd. Switch-enhanced short loop congestion notification for TCP
CN108227614A (zh) * 2018-01-25 2018-06-29 郑州云海信息技术有限公司 一种基于fpga的数据流控制模块、控制方法及电路
WO2019148041A1 (en) 2018-01-26 2019-08-01 Opanga Networks, Inc. Systems and methods for identifying candidate flows in data packet networks
US10924418B1 (en) * 2018-02-07 2021-02-16 Reservoir Labs, Inc. Systems and methods for fast detection of elephant flows in network traffic
KR20200124761A (ko) * 2018-03-23 2020-11-03 오팡가 네트웍스, 인크. 가상 네트워크 환경에서 조정된 데이터 공유
JP7198102B2 (ja) * 2019-02-01 2022-12-28 日本電信電話株式会社 処理装置及び移動方法
US20220183023A1 (en) * 2019-04-01 2022-06-09 Telefonaktiebolaget Lm Ericsson (Publ) Methods and Arrangements for Managing Round Trip Time Associated with Provision of a Data Flow via a Multi-Access Communication Network
US11115294B2 (en) 2019-05-07 2021-09-07 Gigamon Inc. Automatic dynamic determination of data traffic sampling policy in a network visibility appliance
EP3942749A4 (en) 2019-05-23 2023-06-07 Hewlett Packard Enterprise Development LP OPTIMIZED ADAPTIVE ROUTING TO REDUCE THE NUMBER OF JUMPS
KR102622252B1 (ko) * 2019-05-27 2024-01-08 삼성에스디에스 주식회사 콘텐츠 전송 장치 및 방법
CN112566145A (zh) * 2019-09-25 2021-03-26 深圳市中兴微电子技术有限公司 一种拥塞控制的方法、装置、计算机存储介质及终端
US11432313B2 (en) * 2020-05-29 2022-08-30 Apple Inc. Detecting cellular network bottlenecks through analysis of resource allocation patterns
TWI763261B (zh) * 2021-01-19 2022-05-01 瑞昱半導體股份有限公司 數據流分類裝置
US11838209B2 (en) * 2021-06-01 2023-12-05 Mellanox Technologies, Ltd. Cardinality-based traffic control
KR102471228B1 (ko) * 2022-04-04 2022-11-28 서울대학교산학협력단 네트워크의 패킷 흐름에 대한 공격성 파라미터 동적 제어 방법 및 장치
US20230397047A1 (en) * 2022-06-07 2023-12-07 Microsoft Technology Licensing, Llc Alleviating cell congestion in wireless networks

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3558044B2 (ja) * 2001-02-09 2004-08-25 日本電気株式会社 パケット転送レート監視制御装置、方法、及びプログラム
JP3853784B2 (ja) * 2003-12-19 2006-12-06 エヌ・ティ・ティ・アドバンステクノロジ株式会社 データ通信管理方法
US7436773B2 (en) * 2004-12-07 2008-10-14 International Business Machines Corporation Packet flow control in switched full duplex ethernet networks
JP4328794B2 (ja) * 2006-10-19 2009-09-09 株式会社エヌ・ティ・ティ・ドコモ 通信システム、通信装置、及び送信制御方法
JP4942040B2 (ja) * 2007-07-18 2012-05-30 国立大学法人電気通信大学 通信装置および通信方法
US7822855B2 (en) * 2008-10-15 2010-10-26 Patentvc Ltd. Methods and systems combining push and pull protocols
JP5036743B2 (ja) * 2009-02-20 2012-09-26 日本電信電話株式会社 フロー制御方法とシステムおよびプログラム
US8886790B2 (en) * 2009-08-19 2014-11-11 Opanga Networks, Inc. Systems and methods for optimizing channel resources by coordinating data transfers based on data type and traffic
US8340105B2 (en) * 2009-12-18 2012-12-25 Alcatel Lucent Coordination independent rate adaptation deployment methods and systems
CN102598628A (zh) * 2010-03-15 2012-07-18 莫维克网络公司 用于多媒体传送的自适应分块和内容感知同步设备及方法
US9124515B2 (en) * 2010-11-22 2015-09-01 Hewlett-Packard Development Company, L.P. Elephant flow detection in a computing device
EP2698159A4 (en) * 2011-04-12 2014-11-05 Sawai Seiyaku Kk PITAVASTATE-CONTAINING PREPARATION AND METHOD OF MANUFACTURING THEREOF
US20140026931A1 (en) * 2012-07-26 2014-01-30 Yu Chieh LEE Pivot mechanism and tent frame using same
US9197568B2 (en) * 2012-10-22 2015-11-24 Electronics And Telecommunications Research Institute Method for providing quality of service in software-defined networking based network and apparatus using the same
US9185015B2 (en) * 2013-02-19 2015-11-10 Broadcom Corporation Application aware elephant flow identification
US20140237118A1 (en) * 2013-02-19 2014-08-21 Broadcom Corporation Application Aware Elephant Flow Management
US9769074B2 (en) * 2013-03-15 2017-09-19 International Business Machines Corporation Network per-flow rate limiting
US10536861B2 (en) * 2013-04-19 2020-01-14 Linear Technology Corporation Monitoring of channel stability and interference in wireless networks
US9380489B2 (en) * 2013-07-18 2016-06-28 Verizon Patent And Licensing Inc. Dynamic network traffic analysis and traffic flow configuration for radio networks
US9331943B2 (en) * 2013-09-10 2016-05-03 Robin Systems, Inc. Asynchronous scheduling informed by job characteristics and anticipatory provisioning of data for real-time, parallel processing
US9560549B2 (en) * 2014-09-05 2017-01-31 Cisco Technology, Inc. Reporting of aggregated RAN congestion information
KR101753269B1 (ko) * 2014-09-11 2017-07-05 광주과학기술원 이동통신망을 이용하는 방송시스템 및 방송서비스 제공방법

Also Published As

Publication number Publication date
WO2016141239A1 (en) 2016-09-09
EP3266170B1 (en) 2021-10-20
EP3266170A1 (en) 2018-01-10
KR102583750B1 (ko) 2023-09-26
KR102536208B1 (ko) 2023-05-25
EP3266170A4 (en) 2018-10-17
US10834002B2 (en) 2020-11-10
CN107637032A (zh) 2018-01-26
US20190215273A1 (en) 2019-07-11
KR20230074841A (ko) 2023-05-31
KR20180004401A (ko) 2018-01-11
US20160261510A1 (en) 2016-09-08
US11546268B2 (en) 2023-01-03
JP2018507666A (ja) 2018-03-15
US20210021532A1 (en) 2021-01-21
US10270700B2 (en) 2019-04-23
US20230122266A1 (en) 2023-04-20
JP6672340B2 (ja) 2020-03-25

Similar Documents

Publication Publication Date Title
ES2902497T3 (es) Método para regular la velocidad de flujos de datos
Jiang et al. Understanding bufferbloat in cellular networks
US9866492B2 (en) Localized congestion exposure
ES2714023T3 (es) Guiado de caudal basado en información detallada de plano de usuario
US11677665B2 (en) Systems and methods for identifying candidate flows in data packet networks
ES2675198T3 (es) Método y sistema para detección de congestión cooperativa en redes celulares
CN104704783A (zh) Tcp映射的***和方法
Heusse et al. Two-way TCP connections: old problem, new insight
Szilágyi et al. LTE user plane congestion detection and analysis
Kumar et al. Device‐centric data reordering and buffer management for mobile Internet using Multipath Transmission Control Protocol
US20130051257A1 (en) Scheduling of Packets at Cellular Base Stations
JP2012134907A (ja) Ｔｃｐ転送装置およびそのプログラム
Jowkarishasaltaneh An SDN-based Network Layer Solution to Improve the Fairness and Throughput of Multi-path TCP