FR2858144A1 - Procede pour evaluer la bande passante disponible d'un canal de transmission lors d'une transmission de donnees entre un emetteur et un recepteur a travers ledit canal et dispositif d'emission pour la mise en oeuvre du procede - Google Patents

Procede pour evaluer la bande passante disponible d'un canal de transmission lors d'une transmission de donnees entre un emetteur et un recepteur a travers ledit canal et dispositif d'emission pour la mise en oeuvre du procede Download PDF

Info

Publication number
FR2858144A1
FR2858144A1 FR0350358A FR0350358A FR2858144A1 FR 2858144 A1 FR2858144 A1 FR 2858144A1 FR 0350358 A FR0350358 A FR 0350358A FR 0350358 A FR0350358 A FR 0350358A FR 2858144 A1 FR2858144 A1 FR 2858144A1
Authority
FR
France
Prior art keywords
delay
loop delay
transmitter
available bandwidth
window
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.)
Pending
Application number
FR0350358A
Other languages
English (en)
Inventor
Amine Lamani
Joel Penhoat
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.)
Orange SA
Original Assignee
France Telecom SA
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 France Telecom SA filed Critical France Telecom SA
Priority to FR0350358A priority Critical patent/FR2858144A1/fr
Priority to EP04767689A priority patent/EP1649666A2/fr
Priority to PCT/FR2004/001865 priority patent/WO2005011229A2/fr
Publication of FR2858144A1 publication Critical patent/FR2858144A1/fr
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/11Identifying congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • H04L47/193Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/27Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/28Flow control; Congestion control in relation to timing considerations
    • H04L47/283Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Landscapes

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

Abstract

La transmission utilise une méthode dite de "fenêtre glissante" selon laquelle l'émetteur (4) est autorisé à envoyer vers le récepteur (2) plusieurs paquets de données, contenus dans la fenêtre, avant de recevoir un accusé de réception pour l'un au moins de ces paquets, et fait avancer la fenêtre, afin d'émettre les paquets suivants, au fur et à mesure qu'il reçoit les accusés de réception. Dans ce procédé,- l'émetteur (4) mesure un délai de boucle correspondant à la durée entre l'envoi d'un paquet de données et la réception d'un accusé de réception correspondant, à des instants d'échantillonnage successifs, afin de détecter l'état du délai de boucle,- si, après une période de stabilité du délai de boucle, l'émetteur (4) détecte une augmentation progressive dudit délai, il signale que le débit de données est supérieur à la bande passante disponible,- si, après une période de stabilité du délai de boucle, l'émetteur (4) détecte une diminution progressive dudit délai, il signale que le débit de données est inférieur à la bande passante disponible.

Description

L'invention concerne un procédé pour évaluer la bande passante disponible
d'un canal de transmission lors d'une transmission de données entre un émetteur et un récepteur à travers ledit canal, ladite transmission utilisant une méthode dite de "fenêtre glissante" et un dispositif d'émission pour la mise en oeuvre du procédé.
D'emblée, on notera que par les termes "bande passante disponible" on entend désigner la quantité de données pouvant être transmise par unité de temps, c'est-à-dire le débit, à travers le canal de transmission.
Lors d'une transmission de paquets de données à travers un réseau, un protocole de contrôle de flux vérifie généralement le bon acheminement des paquets de 10 données entre l'émetteur et le récepteur. Sur l'Internet, le protocole de contrôle de flux le plus largement utilisé est le protocole TCP (Transfer Control Protocol), lequel s'assure de la bonne réception des paquets de données émis par un mécanisme d'accusé de réception. Ce mécanisme fonctionne de la manière suivante: L'émetteur attribue un numéro de séquence à chaque octet d'un paquet de données émis. A la réception de ce 15 paquet, le récepteur retourne à l'émetteur un accusé de réception "ACK" accompagné du numéro de séquence du prochain octet attendu. Afin de limiter le nombre d'accusés de réception, il est connu d'utiliser un mécanisme d'acquittement cumulatif consistant à émettre des accusés de réception "ACK" confirmant chacun la bonne réception de plusieurs paquets de données. Dans ce cas, chaque accusé de réception est accompagné 20 du numéro de séquence du prochain octet attendu et signale à l'émetteur que tous les précédents paquets de données ont bien été reçus.
De plus, pour chaque paquet de données émis, l'émetteur déclenche une horloge de temporisation de retransmission mémorisant un délai de retransmission "RTO" (Retransmission Time Out). Si, à l'expiration du délai de retransmission RTO, 25 l'émetteur n'a pas reçu d'accusé de réception pour un paquet préalablement émis, il le transmet une nouvelle fois. Ce délai de retransmission RTO est calculé, à l'aide d'un algorithme, en fonction d'un délai de boucle "RTT" (Round Trip Time), encore appelé délai aller-retour, correspondant à la durée moyenne entre l'émission d'un paquet aller et la réception d'un accusé de réception retour. Si le récepteur reçoit des paquets non 30 successifs, cela est signalé à l'émetteur par l'arrivée d'accusés de réception dupliqués.
Parallèlement, un mécanisme de fenêtre glissante est utilisé afin d'autoriser l'émetteur à émettre plusieurs paquets de données avant de recevoir un accusé de réception. En définitive, la taille de la fenêtre fixe un nombre de paquets pouvant être transmis sans avoir besoin d'accusé de réception. Cette fenêtre se déplace au fur et à 5 mesure que les accusés de réception sont reçus. Ainsi, à la réception de chaque accusé de réception, l'émetteur supprime les paquets transmis et acquittés dans sa mémoire tampon d'émission et fait avancer sa fenêtre afin d'émettre les paquets suivants.
De plus, la taille de la fenêtre est dynamique. Au départ, elle est fixée à un seul paquets, voire à quelques paquets (généralement quatre au plus), puis elle augmente au 10 fur et à mesure que les accusés de réception sont reçus, d'abord de façon exponentielle, jusqu'à un seuil prédéfmini appelé "ssthresh" (Slow Start Threshold), puis de façon linéaire. A la réception de chaque accusé de réception, la fenêtre d'émission non seulement avance, de façon à ce que les paquets suivants soient émis, mais augmente également. La taille de la fenêtre croît ainsi jusqu'à une limite supérieure de congestion 15 dont la valeur dépend de la bande passante disponible du canal de transmission. La bande passante disponible, autrement dit le débit de données maximal admissible en émission, dépend essentiellement de la capacité maximale théorique du canal et du trafic de données réel à travers ce canal. Lorsque la fenêtre est trop large (débit trop important compte tenu de la bande passante disponible), il y a congestion, ce qui se 20 traduit par la perte de paquets de données. Deux cas sont alors envisageables: a) l'émetteur reçoit une notification de perte provenant du récepteur ou b) le délai de retransmission RTO expire avant réception d'un accusé de réception.
Dans le cas a), selon le protocole TCP, la taille de la fenêtre est divisée par 25 deux, puis demeure stable pendant un courte période avant de recommencer à croître de manière linéaire jusqu'à atteindre à nouveau une limite supérieure de congestion.
Dans le cas b), selon le protocole TCP, la taille de la fenêtre est réduite à un seul paquet et le seuil "ssthresh" est fixé à la moitié de la taille de la fenêtre au moment où la congestion a été détectée. La taille de la fenêtre recommence à croître de façon exponentielle jusqu'au seuil "ssthresh" puis de façon linéaire jusqu'à atteindre à nouveau une limite supérieure de congestion.
Dans les deux cas a) et b), la détection d'une congestion s'effectue donc a posteriori, par détection de la perte de paquets de données. La taille de la fenêtre est 5 alors brutalement réduite et il faut un certain laps de temps pour qu'elle redevienne optimale eu égard à la bande passante disponible. Ce temps de reprise réduit considérablement le débit de données moyen en émission et est d'autant plus grand que le délai de boucle est important.
La présente invention vise à estimer la bande passante disponible d'un canal de 10 transmission afin de prévoir le cas échéant les congestions.
A cet effet, l'invention concerne un procédé pour évaluer la bande passante disponible d'un canal de transmission lors d'une transmission de données entre un émetteur et un récepteur, à travers ledit canal, la transmission utilisant une méthode dite de "fenêtre glissante" selon laquelle l'émetteur est autorisé à envoyer vers le récepteur 15 plusieurs paquets de données, contenus dans la fenêtre, avant de recevoir un accusé de réception pour l'un au moins de ces paquets, et fait avancer la fenêtre, afin d'émettre les paquets suivants, au fur et à mesure qu'il reçoit les accusés de réception, procédé dans lequel: - l'émetteur mesure un délai de boucle correspondant à la durée entre l'envoi 20 d'un paquet de données et la réception d'un accusé de réception correspondant, à des instants d'échantillonnage successifs, afin de détecter l'état du délai de boucle, - si, après une période de stabilité du délai de boucle, l'émetteur détecte une augmentation progressive dudit délai, il signale que le débit de données est supérieur à la bande passante disponible, si, après une période de stabilité du délai de boucle, l'émetteur détecte une diminution progressive dudit délai, il signale que le débit de données est inférieur à la bande passante disponible.
Par augmentation, ou diminution, "progressive", on entend désigner une augmentation, ou une diminution, régulière et continue, par opposition à une 30 augmentation, ou une diminution, brusque généralement suivie d'un retour à une valeur normale du délai de boucle. La "bande passante disponible" représente la quantité de données maximale que l'émetteur peut émettre vers le récepteur par unité de temps, c'est-à-dire le débit de données maximal admissible, à travers le canal de transmission.
L'invention consiste donc à observer l'évolution du délai de boucle, mesuré 5 dans l'art antérieur dans le seul but de calculer le délai de retransmission, afin d'en déduire la disponibilité de la bande passante du canal de transmission.
Avantageusement, - pour chaque instant d'échantillonnage, l'émetteur mesure une erreur de délai de boucle correspondant à l'écart entre les deux derniers échantillons de délai de boucle 10 et calcule un cumul d'erreurs en additionnant les erreurs de délai de boucle sur les N derniers échantillons de délai de boucle, - si l'émetteur détecte que les N dernières erreurs de délai de boucle et le cumul d'erreurs sont compris entre -St et S', S représentant un seuil de tolérance, il 2 2 2 enregistre provisoirement le délai de boucle, - si le délai de boucle demeure sensiblement constant pendant une durée supérieure à un seuil prédéterminé, l'émetteur détecte un état de stabilité du délai de boucle.
Le cumul des erreurs permet de quantifier l'évolution du délai de boucle, autrement dit de mesurer la quantité d'augmentation ou de diminution du délai de 20 boucle.
De préférence, la durée seuil est égale au délai de boucle enregistré. Ainsi, on observe un état de stabilité du délai de boucle sur une période au moins égale au délai de boucle lui-même.
Avantageusement, si, après une période de stabilité du délai de boucle, 25 l'émetteur détecte que Ci)I pour la première fois à l'instant tx, i) à partir de l'instant tx,, pour chaque instant d'échantillonnage t1, l'émetteur calcule le cumul d'erreurs Ci en additionnant toutes les erreurs mesurées à partir de cet instant tx jusqu'à l'instant d'échantillonnage ti, et ii) si l'émetteur détecte que C>)Sc, Sc représentant un seuil critique, il signale que le débit de données est supérieur à la bande passante disponible.
Avantageusement encore, si, après une période de stabilité du délai de boucle, --st l'émetteur détecte que Ci (-t pour la première fois à l'instant ty, '2 s i) à partir de l'instant ty, pour chaque instant d'échantillonnage ti, l'émetteur calcule le cumul d'erreurs Ci en additionnant toutes les erreurs mesurées à partir de cet instant tx jusqu'à l'instant d'échantillonnage ti, et ii) s'il détecte que Ci (-Se, il signale que le débit de données est inférieur à la bande passante disponible.
De préférence, lorsque le délai de boucle est stable, la taille de la fenêtre augmentant au fur et à mesure que l'émetteur reçoit des accusés de réception, l'émetteur enregistre la valeur stable du délai de boucle et la taille maximale de la fenêtre observée pour cette valeur stable du délai de boucle. L'émetteur peut ainsi mémoriser un ou plusieurs couple(s) comprenant chacun une valeur stable RTTn de délai de boucle et la 15 valeur maximale de taille de fenêtre W,,max observée lorsque le délai de boucle est stable et vaut RTTn et qu'il n'y a, par conséquent, pas de risque de congestion.
L'invention concerne également un dispositif d'émission pour la mise en oeuvre du procédé précédemment défini, comprenant - des moyens d'émission à travers un canal de transmission, utilisant une 20 méthode dite de "fenêtre glissante", agencés pour envoyer plusieurs paquets de données, contenus dans la fenêtre, avant de recevoir un accusé de réception pour l'un au moins de ces paquets et pour faire avancer la fenêtre afin d'émettre les paquets suivants, et - des moyens pour mesurer un délai de boucle correspondant à la durée entre 25 l'envoi d'un paquet de données et la réception d'un accusé de réception correspondant, à des instants d'échantillonnage successifs, dispositif caractérisé par le fait qu'il comprend des moyens pour évaluer la bande passante disponible du canal de transmission agencés pour détecter i) soit une augmentation progressive du délai de boucle suivant une période de stabilité dudit délai, ii) soit une diminution progressive du délai de boucle suivant une période de stabilité dudit délai, et pour signaler aux moyens d'émission, dans le cas i), que le débit de données est supérieur à la bande passante disponible et, dans le cas ii), que le débit de données est inférieur à la bande passante disponible.
L'invention sera mieux comprise à l'aide de la description suivante d'un mode de réalisation particulier du procédé pour évaluer la bande passante disponible d'un 10 canal de transmission et du dispositif pour la mise en oeuvre de ce procédé, selon l'invention, en référence aux dessins annexés sur lesquels: - la figure 1 représente une vue schématique d'un réseau de communication, d'un fournisseur d'accès au réseau, avec un serveur accélérateur de débit, un terminal de communication et un canal de transmission entre le serveur et le terminal; - la figure 2 représente un schéma bloc fonctionnel du serveur accélérateur de débit de la figure 1; la figure 3 représente une succession de paquets de données transmis ou à transmettre par le serveur accélérateur de débit de la figure 1 et une fenêtre d'émission de ces paquets; - les figures 4A et 4B représentent respectivement le délai de boucle et le débit de données mesurés lors d'une transmission à travers le canal de transmission de la figure 1; les figures 5A et 5B représentent respectivement les erreurs de délai de boucle et le cumul de ces erreurs, calculés à partir des échantillons de délai de boucle 25 mesurés (figure 4A); - la figure 6A et 6B représentent l'évolution du délai de boucle mesuré (figure 4A) respectivement en début de transmission et à un instant auquel la bande passante est réduite.
Sur la figure 1, on a représenté un réseau de communication 1, en l'espèce 30 l'Internet, et un terminal de communication client 2 connecté à l'Internet 1 par l'intermédiaire d'un fournisseur d'accès ISP (Internet Service Provider) 3. Le fournisseur d'accès 3 intègre un serveur accélérateur de débit 4, encore appelé serveur "proxy". La référence 5 désigne le canal de transmission entre le terminal de communication 2 et le serveur accélérateur de débit 4. Dans l'exemple particulier de la description, le canal de transmission 5 est une liaison TCP (Transfer Control Protocol) par voie satellite.
Le protocole TCP de contrôle de flux, utilisé sur le canal de transmission 5, permet de contrôler le bon acheminement de paquets de données entre le serveur 4 et le terminal client 2, à l'aide d'un mécanisme d'accusé de réception cumulatif fonctionnant de la manière suivante: L'émetteur TCP attribue un numéro de séquence à chaque octet 10 d'un paquet de données émis. Après avoir reçu plusieurs paquets transmis par l'émetteur TCP, le récepteur TCP renvoie à l'émetteur TCP un accusé de réception "ACK" accompagné du numéro de séquence du prochain octet attendu et confirmant ainsi la bonne réception de tous les paquets précédant cet octet.
De plus, si, à l'expiration d'un délai de retransmission "RTO" (Retransmission 15 Time Out) prédéterminé, l'émetteur TCP n'a pas reçu d'accusé de réception pour un paquet préalablement émis, il le transmet une nouvelle fois vers le récepteur TCP. Ce délai de retransmission RTO est calculé par l'émetteur TCP, à l'aide d'un algorithme, en fonction d'un délai de boucle "RTT" (Round Trip Time) correspondant à la durée moyenne entre l'émission d'un paquet aller et la réception d'un accusé de réception 20 retour.
L'émetteur TCP utilise également un mécanisme de "fenêtre d'émission glissante" l'autorisant à émettre plusieurs paquets de données, contenus dans la fenêtre, avant de recevoir un accusé de réception. Par sa taille, la fenêtre d'émission fixe un nombre de paquets pouvant être transmis sans avoir besoin d'accusé de réception (voir 25 figure 3). Cette fenêtre se déplace et augmente au fur et à mesure que l'émetteur TCP reçoit les accusés de réception. Ainsi, à la réception de chaque accusé de réception, l'émetteur TCP fait avancer sa fenêtre d'émission afin d'émettre les paquets suivants et augmente la taille de la fenêtre. Au départ, la fenêtre d'émission contient un paquet, voire quelques paquets (généralement pas plus de quatre), et augmente d'abord de façon 30 exponentielle jusqu'à un seuil prédéfini appelé "ssthresh" (Slow Start Threshold), puis de façon linéaire jusqu'à une limite optimale au-delà de laquelle il y a congestion, ce qui se traduit par la perte de paquets de données. Sur la figure 3, on a représenté une succession 6 de paquets de données numérotés de 11 à 24 et une fenêtre glissante d'émission 7 à un instant donné. Sur cette figure 3, on peut classer les paquets de données de la manière suivante: - paquets envoyés et acquittés 61: n Il à 13 paquets envoyés et non acquittés 62: n 14 à 16 - paquets devant être envoyés 63: n 17 à 21 - paquets non autorisés à être envoyés 64: n 22 à 24 Le dernier acquittement reçu "ACK" 60, de valeur 14, a confirmé la réception de tous les paquets de données précédant le paquet n 14. Le bord gauche de la fenêtre 7 est donc positionné juste avant le paquet n 14. L'émetteur TCP n'est autorisé à envoyer que les paquets contenus dans la fenêtre d'émission (numérotés de 14 à 21) sans recevoir d'accusé de réception. Sur la figure 3, on voit que le prochain paquet que 15 l'émetteur TCP va émettre est le n 17. Pour être autorisé à émettre les paquets suivants, non contenus dans la fenêtre 7 telle que représentée sur la figure 3 (c'est-à-dire les paquets n 22 et suivants), l'émetteur TCP doit recevoir un nouvel accusé de réception ACK de valeur strictement supérieure à 14 et faire glisser sa fenêtre 7 vers la droite (dans le sens de la flèche 8) , de manière à positionner le bord gauche de la fenêtre 7 20 juste avant le paquet dont le numéro correspond à la valeur de l'accusé de réception reçu. Par exemple, si le prochain accusé de réception a la valeur 16, le bord gauche de la fenêtre 7 est déplacé dans le sens de la flèche 8 de manière à être positionné juste avant le paquet n 16. En outre, en même temps qu'il déplace la fenêtre 7, l'émetteur TCP augmente la taille de la fenêtre 7. Par exemple, si la phase dans laquelle il se trouve 25 permet à l'émetteur TCP d'augmenter la taille de la fenêtre 7 d'un paquet à la réception de chaque accusé de réception, la nouvelle fenêtre 7 contient alors neuf paquets.
L'émetteur TCP représenté sur la figure 2 est le serveur accélérateur de débit 4. Il comprend, de façon connue, un module 40 d'émission de paquets de données, un module 41 de réception d'accusés de réception, un module 42 de calcul du délai de 30 retransmission RTO et une horloge 43 de temporisation de retransmission.
Le module d'émission 40 est agencé pour émettre des paquets de données en utilisant la méthode de la "fenêtre glissante d'émission" précédemment explicitée (voir figure 3). Il est donc autorisé à envoyer plusieurs paquets de données, contenus dans la fenêtre d'émission, avant de recevoir un accusé de réception. Au fur et à mesure de la 5 réception des accusés de réception, signalés par le module de réception 41, le module d'émission 40, d'une part, fait avancer la fenêtre glissante d'émission et, d'autre part, calcule et met à jour la taille de cette fenêtre. On rappelle ici que, selon le protocole TCP, la taille de la fenêtre, fixée au départ à un paquet, voire à quelques paquets (quatre au plus), augmente, dans un premier temps, de façon exponentielle jusqu'à un 10 seuil "ssthresh" (Slow Start Threshold), puis, dans un second temps, de façon linéaire.
Le module 41 de réception d'accusés de réception, interposé entre le module de calcul 42 et le module d'émission 40, est agencé pour recevoir et traiter les accusés de réception "ACK" et pour transmettre aux autres modules des informations utiles, fournies par les accusés de réception, pour mettre à jour des variables d'état d'émission 15 telles que notamment le délai de retransmission RTO, le délai de boucle RTT, la taille W de la fenêtre glissante d'émission et le seuil "ssthresh".
Le module 42 de calcul du délai de retransmission RTO est agencé pour calculer le délai de retransmission RTO à l'aide d'un algorithme prévu par le protocole TCP, à partir du délai de boucle. On rappelle ici que le délai de boucle correspond à la 20 durée moyenne entre l'envoi d'un paquet de données aller et la réception d'un accusé de réception retour. En fonctionnement, le module de calcul 42 mesure le délai de boucle RTT à des instants d'échantillonnage ti successifs, lisse les échantillons de délai de boucle mesurés RTTi de telle sorte que: SRTT1 = (1- a).SRTT, + o. RTT, avec a =-, où SRRTi représente la valeur lissée de l'échantillon RTTi du délai de boucle (Smoothed Round Trip Time) mesuré à l'instant ti. Il calcule ensuite le délai de retransmission RTO à partir du délai de boucle mesuré et lissé, à l'aide de l'algorithme du protocole TCP. Pour plus de renseignements à ce sujet, le lecteur est invité à se reporter notamment au document RFC2988 de l'IETF (Internet Engineering Task Force). Le délai de retransmission RTO ainsi calculé est fourni à l'horloge 43.
L'horloge 43 de temporisation de retransmission, reliée au module de calcul du délai de retransmission RTO et au module d'émission 40, est agencée pour commander 5 la retransmission d'un paquet de données si, à l'expiration du délai de retransmission RTO, l'émetteur TCP n'a pas encore reçu d'accusé de réception pour ce paquet.
L'émetteur TCP 4 comprend en outre un module 44 d'évaluation de la bande passante disponible du canal de transmission 5 et une mémoire 45.
La mémoire 45, reliée au module d'évaluation 44 et au module d'émission 40, 10 est destinée à mémoriser un ou plusieurs couples de valeurs (RTTn, Wnmax), comprenant chacun une valeur stable de délai de boucle et la taille maximale de la fenêtre glissante d'émission observée lorsque le délai de boucle est stable et vaut RTTn.
Le module d'évaluation 44 est interposé entre le module 42 de calcul du délai de retransmission et le module d'émission 40. En cours d'émission, le module 15 d'évaluation 44 observe l'état du délai de boucle mesuré et lissé par le module de calcul 42 afin de détecter i) soit un état de stabilité du délai de boucle, ii) soit une augmentation progressive du délai de boucle, apparaissant à la suite d'une période de stabilité dudit délai, iii) soit une diminution progressive du délai de boucle, apparaissant à la suite d'une période de stabilité dudit délai.
On rappelle ici que par les termes augmentation/diminution "progressive", on entend désigner une augmentation/diminution régulière et continue, par opposition à une augmentation/diminution brusque.
Dans le cas i), pour chaque valeur stable RTTn du délai de boucle, le module d'évaluation 44 enregistre dans la mémoire 45 le couple de valeurs {RTT,, Wn, max} contenant la valeur stable du délai de boucle RTT, et la taille maximale de la fenêtre glissante d'émission observée lorsque le délai de boucle est stable et vaut RTTn.
Dans le cas ii), le module d'évaluation 44 signale au module d'émission 40 que 30 le débit de données en émission est supérieur à la bande passante disponible.
Dans le cas iii), le module d'évaluation 44 signale au module d'émission 40 que le débit de données en émission est inférieur à la bande passante disponible.
La méthode de détection de l'état du délai de boucle (stabilité, augmentation progressive ou diminution progressive) par le module d'évaluation 44 est décrite ci5 après dans la description du procédé.
Le procédé qui va maintenant être décrit permet d'évaluer la bande passante disponible du canal de transmission 5 entre le serveur accélérateur de débit 4 et le terminal 2, lors d'une transmission de données du serveur 4 vers le terminal 2.
Lors d'une transmission de données du serveur 4, émetteur TCP, vers le 10 terminal 2, récepteur TCP, le module de calcul 42 du serveur 4 mesure et lisse le délai de boucle à des instants d'échantillonnage successifs ti. On rappelle ici que "SRTTi" (Smoothed Round Trip Time) représente la valeur de l'échantillon d'indice i du délai de boucle mesuré à l'instant ti et lissé.
A partir des échantillons de délai de boucle mesurés et lissés SRTTi, fournis 15 par le module de calcul 42, pour chaque instant d'échantillonnage ti, le module d'évaluation 44 calcule - une erreur de délai de boucle ei égale à l'écart entre les deux derniers échantillons de délai de boucle mesurés et lissés SRTTi et SRTT-1, autrement dit: ei = SRTTi -SRTTl et - un cumul d'erreurs Ci en additionnant les erreurs de délai de boucle sur les N derniers échantillons de délai de boucle mesurés et lissés, autrement dit: i Ci = ôej j=i-N+l Cas A Si le module d'évaluation 44 détecte que les N dernières erreurs de délai de 25 boucle ej Vj e [i - N + 1, i] et le cumul d'erreurs (Ci) sont compris entre - Se et S', 2 2 SI représentant un seuil de tolérance, autrement dit que i) - ' Ci-2 et 2 e2 ii) (e- < t--, Vj E [i - N + 1, i], 2 '2 alors il enregistre provisoirement le délai de boucle. La valeur enregistrée du délai de boucle est ici égale à la moyenne des N derniers échantillons de délai de boucle. 5 On pourrait envisager de déterminer le délai de boucle par une autre méthode consistant par exemple à retenir la valeur du dernier échantillon mesuré et lissé SRTTi et à ne la remplacer par une autre valeur d'échantillon SRTTj que si la différence entre les deux échantillons SRTTi et SRTTj est supérieure à un seuil de tolérance prédéfini. Si le délai de boucle demeure sensiblement constant pendant une durée au moins égale à une durée 10 seuil, ici égale au délai de boucle lui-même, le module d'évaluation 44 détecte un état de stabilité du délai de boucle. Cas B
Si, après une période de stabilité du délai de boucle, le module d'évaluation 44 détecte que Ci) SI pour la première fois à l'instant tx, '2 i) à partir de l'instant tx, pour chaque instant d'échantillonnage ti, le module d'évaluation 44 calcule le cumul d'erreurs Ci en additionnant toutes les erreurs ej mesurées à partir de cet instant tx,, et jusqu'à l'instant t;, et ii) si le module d'évaluation 44 détecte que Ci)Sc (So représentant un seuil critique), le délai de boucle est dans un état d'augmentation progressive. Le module d'évaluation 44 signale alors au module d'émission 40 que le débit de données en émission est supérieur à la bande passante disponible. Cas C
Si, après une période de stabilité du délai de boucle, le module d'évaluation 44
-S
détecte que Ci ( - ' pour la première fois à l'instant ty, i) à partir de l'instant ty, pour chaque instant d'échantillonnage ti, le module d'évaluation 44 calcule le cumul d'erreurs Ci en additionnant toutes les erreurs ej mesurées à partir de cet instant ty et jusqu'à l'instant ti, et ii) si le module d'évaluation 44 détecte que Ci (-Se, le délai de boucle est dans un état de diminution progressive. Le module d'évaluation 44 signale alors au module d'émission 40 que le débit de données en émission est inférieur à la bande passante disponible.
Dans les autres cas que les cas A, B et C explicités ci-dessus, le délai de boucle est dans un état non identifiable pouvant correspondre à une période d'instabilité.
Dans les cas B et C, selon que le débit de données en émission est supérieur ou inférieur à la bande passante disponible, le serveur 4 peut prendre diverses mesures appropriées consistant - à diminuer ou à stabiliser la taille de la fenêtre, afin d'éviter une congestion, ou - à augmenter la taille de la fenêtre, afin d'augmenter le débit de données à travers le canal 5 du serveur 4 vers le terminal client 2.
Dans le cas où l'émetteur TCP 4 a préalablement observé et mémorisé un délai de boucle stable, de valeur RTT., et une valeur maximale Wn max pour la taille de la fenêtre d'émission, il peut décider de modifier la valeur du seuil "ssthresh" afin que 20 ssthresh = a.W,,nmax avec (x proche de la valeur 1 mais strictement inférieur à 1. A titre 7 3 d'exemple, on peut prendre a = - ou a =-. Une seuil "ssthresh" proche de la valeur 8 4 maximale Wn,max permet une augmentation plus rapide de la taille de lafenêtre jusqu'à une valeur optimale compte tenu de la bande passante disponible.
Lorsque le délai de boucle est stable et vaut RTTn, au fur et à mesure de la 25 réception des accusés de réception, la taille Wn de la fenêtre d'émission augmente et le module d'évaluation 44 la met à jour dans la mémoire 45. Cela permet au serveur 4 de mémoriser, pour chaque valeur stable RTT, du délai de boucle, le couple de valeurs (RTTn,Wnmax) contenant la valeur stable du délai de boucle RTT,, et la taille maximale de la fenêtre d'émission observée pour cette valeur RTT, du délai de boucle. Le module d'évaluation 44 dispose ainsi de la bande passante disponible, valant n"a, pour cette RTT,, valeur RTTn du délai de boucle. Si, après une période de stabilité durant laquelle le délai de boucle vaut RTT., le délai de boucle passe dans un état d'augmentation progressive, alors que la taille de la fenêtre continue parallèlement à augmenter comme cela est 5 prévu par le protocole TCP, l'émetteur pourra limiter la taille de la fenêtre à la valeur Wn,max, et par conséquent le débit de données, afin d'éviter une congestion. En outre, si le délai de boucle varie de manière aléatoire en raison de perturbations (et non en raison du fait que le débit de données s'approche de la bande passante disponible du canal de transmission 5), ce couple (RTTn,Wn,max) constitue un point de référence pour la reprise 10 de la transmission.
A titre d'exemple illustratif, on va maintenant décrire le processus d'évaluation de la charge du canal de transmission 5 lors d'une transmission de données par liaison satellite du serveur 4 vers le terminal 2, au cours de laquelle la bande passante disponible sur le canal de transmission 5 est brutalement réduite. Pour cette évaluation, 15 on prend: -N -5, - St = 100 ms et - Sc = 200 ms.
Les figures 4A et 4B représentent respectivement le délai de boucle lissé (en 20 ms) et le débit de données (en kbits/s) à travers le canal de transmission 5, mesurés entre les instants t2 = 70 s et t3 = 85 s. Les figures 5A et 5B représentent respectivement les erreurs de délai de boucle ei (en ms) et le cumul d'erreurs Ci (en ms), entre les instants t2 = 70s et t3 = 85s, calculés à partir des échantillons du délai de boucle représentés sur la figure 4A. Les figures 6A et 6B représentent respectivement 25 l'évolution du délai de boucle en début de transmission, entre l'instant tO = 38s (début de la transmission) et tl = 55s, et au moment d'une réduction de la bande passante disponible, entre les instants t2 et t3. Sur la figure 6A, on peut observer que le délai de boucle est instable en début de transmission puis se stabilise à la valeur SRTTl=560 ms.
Cet état de stabilité est détecté par le processus d'évaluation à l'instant t5 = 46 s.
Comme on peut le voir sur la figure 4B, le débit de données à travers le canal de transmission 5 vaut initialement 1000 kbits/s puis est brutalement réduit à 500 kbits/s, à l'instant t4 = 76,6s, en raison d'une réduction de la bande passante disponible.
Sur la figure 6B, on peut observer que le délai de boucle, qui vaut initialement 5 SRTT1=560 ms, augmente progressivement à compter de l'instant t4 de réduction brutale du débit, jusqu'à une valeur SRTT2=1130 ms.
Sur la figure SA, on peut observer une augmentation momentanée des erreurs de délai de boucle ei, faiblement perceptible, peu après l'instant t4 de réduction de la bande passante. En revanche, la figure 5B fait apparaître de façon parfaitement distincte 10 une pic d'augmentation du cumul d'erreurs Ci, peu après l'instant t4. Un tel pic d'augmentation signale une augmentation progressive du délai de boucle. Grâce au processus d'évaluation préalablement décrit, l'augmentation progressive du délai de boucle corrélative à la réduction de la bande passante disponible, est détectée à l'instant t6=77s.
Dans la description qui précède, l'évaluation de la bande passante disponible est réalisée dans le serveur 4 afin d'optimiser le débit de données dans le sens descendant (du serveur 4 vers le terminal client 2). On pourrait envisager d'évaluer la bande passante disponible dans le terminal client 2, afin d'optimiser le débit de données dans le sens montant (du terminal client 2 vers le serveur 4), ou encore, dans le cas 20 d'une transmission de données entre deux terminaux, dans chaque terminal émetteur.
L'invention s'applique non seulement aux réseaux satellites mais également à tout autre type de réseau, et plus particulièrement aux réseaux à long délai de boucle (de plusieurs centaines de millisecondes), par exemple les réseaux GPRS ou plus particulièrement les réseaux LFN (Long Fat Network). 25

Claims (7)

Revendications
1. Procédé pour évaluer la bande passante disponible d'un canal de transmission (5) lors d'une transmission de données entre un émetteur (4) et un 5 récepteur (2), à travers ledit canal (5), la transmission utilisant une méthode dite de "fenêtre glissante" selon laquelle l'émetteur (4) est autorisé à envoyer vers le récepteur (2) plusieurs paquets de données, contenus dans la fenêtre (7), avant de recevoir un accusé de réception pour l'un au moins de ces paquets, et fait avancer la fenêtre (7), afin d'émettre les paquets suivants, au fur et à mesure qu'il reçoit les accusés de réception, 10 procédé dans lequel: - l'émetteur (4) mesure un délai de boucle correspondant à la durée entre l'envoi d'un paquet de données et la réception d'un accusé de réception correspondant, à des instants d'échantillonnage successifs (ti), afin de détecter l'état du délai de boucle, - si, après une période de stabilité du délai de boucle, l'émetteur (4) détecte une 15 augmentation progressive dudit délai, il signale que le débit de données est supérieur à la bande passante disponible, - si, après une période de stabilité du délai de boucle, l'émetteur (4) détecte une diminution progressive dudit délai, il signale que le débit de données est inférieur à la bande passante disponible.
2. Procédé selon la revendication 1, dans lequel - pour chaque instant d'échantillonnage (ti), l'émetteur (4) mesure une erreur de délai de boucle (ei) correspondant à l'écart entre les deux derniers échantillons de délai de boucle (SRTTi et SRTTi1) et calcule un cumul d'erreurs (Ci) en additionnant les 25 erreurs de délai de boucle sur les N derniers échantillons de délai de boucle, - si l'émetteur (4) détecte que les N dernières erreurs de délai de boucle (ej Vje [i - N + 1, i]) et le cumul d'erreurs (C) sont compris entre S' et ' , 2 2 2 représentant un seuil de tolérance, il enregistre provisoirement le délai de boucle, - si le délai de boucle demeure sensiblement constant pendant une durée supérieure à un seuil prédéterminé, l'émetteur (4) détecte un état de stabilité du délai de boucle.
3. Procédé selon la revendication 2, dans lequel la durée seuil est égale au délai de boucle enregistré.
4. Procédé selon l'une des revendications 2 et 3, dans lequel si, après une période de stabilité du délai de boucle, l'émetteur (4) détecte que C, )> t pour la première fois à l'instant tx, i) à partir de l'instant tx, pour chaque instant d'échantillonnage ti, l'émetteur (4) calcule le cumul d'erreurs Ci en additionnant toutes les erreurs ej mesurées à partir de cet instant tx jusqu'à l'instant d'échantillonnage ti, et ii) si l'émetteur (4) détecte que Ci)Sc, Sc représentant un seuil critique, il 15 signale que le débit de données est supérieur à la bande passante disponible.
5. Procédé selon l'une des revendications 2 à 4, dans lequel si, après une --st période de stabilité du délai de boucle, l'émetteur (4) détecte que C, ( -'- pour la première fois à l'instant ty, i) à partir de l'instant ty, pour chaque instant d'échantillonnage ti, l'émetteur (4) calcule le cumul d'erreurs Ci en additionnant toutes les erreurs ej mesurées à partir de cet instant tx jusqu'à l'instant d'échantillonnage ti, et ii) s'il détecte que C (-S, il signale que le débit de données est inférieur à la bande passante disponible.
6. Procédé selon l'une des revendications 2 à 5, dans lequel, lorsque le délai de boucle est stable, la taille de la fenêtre augmentant au fur et à mesure que l'émetteur (4) reçoit des accusés de réception, l'émetteur (4) enregistre la valeur stable du délai de boucle et la taille maximale de la fenêtre observée pour cette valeur stable du délai de boucle.
7. Dispositif d'émission pour la mise en oeuvre du procédé de la revendication 1, comprenant - des moyens (40) d'émission à travers un canal de transmission, utilisant une méthode dite de "fenêtre glissante", agencés pour envoyer plusieurs paquets de données, contenus dans la fenêtre, avant de recevoir un accusé de réception pour l'un au moins de ces paquets et pour faire avancer la fenêtre afin d'émettre les paquets suivants, 10 et - des moyens (42) pour mesurer un délai de boucle correspondant à la durée entre l'envoi d'un paquet de données et la réception d'un accusé de réception correspondant, à des instants d'échantillonnage successifs, dispositif caractérisé par le fait qu'il comprend des moyens (44) pour évaluer la 15 bande passante disponible du canal de transmission agencés pour détecter i) soit une augmentation progressive du délai de boucle suivant une période de stabilité dudit délai, ii) soit une diminution progressive du délai de boucle suivant une période de stabilité dudit délai, et pour signaler aux moyens d'émission (40), dans le cas i), que le débit de données est supérieur à la bande passante disponible et, dans le cas ii), que le débit de données est inférieur à la bande passante disponible.
FR0350358A 2003-07-21 2003-07-21 Procede pour evaluer la bande passante disponible d'un canal de transmission lors d'une transmission de donnees entre un emetteur et un recepteur a travers ledit canal et dispositif d'emission pour la mise en oeuvre du procede Pending FR2858144A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR0350358A FR2858144A1 (fr) 2003-07-21 2003-07-21 Procede pour evaluer la bande passante disponible d'un canal de transmission lors d'une transmission de donnees entre un emetteur et un recepteur a travers ledit canal et dispositif d'emission pour la mise en oeuvre du procede
EP04767689A EP1649666A2 (fr) 2003-07-21 2004-07-15 Procede pour evaluer la bande passante disponible d'un canal de transmission lors d'une transmission de donnees et dispositif d'emission pour la mise en oeuvre du procede
PCT/FR2004/001865 WO2005011229A2 (fr) 2003-07-21 2004-07-15 Procédé pour évaluer la bande passante disponible d'un canal de transmission lors d'une transmission de données et dispositif d'émission pour la mise en couvre du procédé

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0350358A FR2858144A1 (fr) 2003-07-21 2003-07-21 Procede pour evaluer la bande passante disponible d'un canal de transmission lors d'une transmission de donnees entre un emetteur et un recepteur a travers ledit canal et dispositif d'emission pour la mise en oeuvre du procede

Publications (1)

Publication Number Publication Date
FR2858144A1 true FR2858144A1 (fr) 2005-01-28

Family

ID=33561187

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0350358A Pending FR2858144A1 (fr) 2003-07-21 2003-07-21 Procede pour evaluer la bande passante disponible d'un canal de transmission lors d'une transmission de donnees entre un emetteur et un recepteur a travers ledit canal et dispositif d'emission pour la mise en oeuvre du procede

Country Status (3)

Country Link
EP (1) EP1649666A2 (fr)
FR (1) FR2858144A1 (fr)
WO (1) WO2005011229A2 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101163238B (zh) * 2007-07-20 2010-12-01 中兴通讯股份有限公司 一种平滑实现实时转播/直播的流媒体服务方法
CN112068997B (zh) * 2020-09-09 2023-12-19 恒生电子股份有限公司 数据备份方法、装置、设备及存储介质
CN115250288A (zh) * 2022-07-18 2022-10-28 国仪量子(合肥)技术有限公司 数据通信方法、下位机、上位机、数据传输系统和介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0415843A2 (fr) * 1989-08-30 1991-03-06 Digital Equipment Corporation Méthode pour éviter la congestion dans un réseau d'ordinateurs basé sur le délai

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2249152C (fr) * 1998-09-30 2003-07-08 Northern Telecom Limited Appareil et methode de gestion de largeur de bande pour connexion par paquets

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0415843A2 (fr) * 1989-08-30 1991-03-06 Digital Equipment Corporation Méthode pour éviter la congestion dans un réseau d'ordinateurs basé sur le délai

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"DYNAMIC COMPUTATION OF TCP MAXIMUM WINDOW SIZE FOR DIRECTLY CONNECTED HOSTS", IBM TECHNICAL DISCLOSURE BULLETIN, IBM CORP. NEW YORK, US, vol. 37, no. 4A, 1 April 1994 (1994-04-01), pages 601 - 607, XP000446797, ISSN: 0018-8689 *
STEVENS W R: "TCP/IP Illustrated, Volume 1 The Protocols, TCP TIMEOUT AND RETRANSMISSION", TCP/IP ILLUSTRATED. VOL. 1: THE PROTOCOLS, PROFESSIONAL COMPUTING SERIES, READING, MA: ADDISON WESLEY, US, vol. 1, 1994, pages 297 - 337, XP002223116, ISBN: 0-201-63346-9 *
STEVENS W. R.: "TCP/IP Illustrated, Volume 1 The Protocols, Bulk Data Throughput (Section 20.7)", TCP/IP ILLUSTRATED. VOL. 1: THE PROTOCOLS, PROFESSIONAL COMPUTING SERIES, ADDISON WESLEY, vol. 1, February 2000 (2000-02-01), READING, MA, US, pages 289 - 292, XP002277438 *
TANENBAUM S: "Computer Networks, THE TRANSPORT LAYER", COMPUTER NETWORKS, LONDON: PRENTICE-HALL INTERNATIONAL, GB, 1996, pages 536 - 542, XP002233582, ISBN: 0-13-394248-1 *
V. PAXSON, M. ALLMAN: "RFC 2988: Computing TCP's Retransmission Timer", RFC 2988 IETF NETWORK WORKING GROUP, November 2000 (2000-11-01), pages 1 - 8, XP002277547, Retrieved from the Internet <URL:ftp://ftp.rfc-editor.org/> [retrieved on 20040421] *

Also Published As

Publication number Publication date
EP1649666A2 (fr) 2006-04-26
WO2005011229A3 (fr) 2005-05-19
WO2005011229A2 (fr) 2005-02-03

Similar Documents

Publication Publication Date Title
US6445681B1 (en) Method for measuring delay parameters in a network
EP1382219B1 (fr) Procédé et dispositif pour l&#39;estimation robuste en temps réel de bande passante de goulot d&#39;étranglement
EP1217778B1 (fr) Procédé et dispositif de communication de données avec demande de répétition automatique
EP1351469B1 (fr) Transmission à destinations multiples utilisant des connections plannifiées selon des contraintes de fenêtres temporelles
US5802106A (en) Method for rapid data rate detection in a packet communication environment without data rate supervision
US6078919A (en) Method and apparatus for delivery of data over a network based on determination of network parameters
US20020044528A1 (en) Flow control method and apparatus
FR2805112A1 (fr) Procede et unite de controle de flux d&#39;une connexion tcp sur un reseau a debit controle
WO2003030469A2 (fr) Procede pour ameliorer les performances d&#39;un protocole de transmission utilisant un temporisateur de retransmission
EP2862324B1 (fr) Procede et dispositif d&#39;estimation rapide et peu intrusive de la bande passante disponible entre deux n uds ip
RU2695093C2 (ru) Способ для выполнения проверки пропускной способности связи от первой сетевой станции до второй сетевой станции в сети связи, соответствующие устройства для выполнения этапов способа и соответствующие компьютерные программы
FR2922391A1 (fr) Procede et dispositif de transmission de donnees
EP1330071A2 (fr) Système de gestion de réseau ou de services pour la détermination de la synchronisation entre deux flots de paquets
FR2858144A1 (fr) Procede pour evaluer la bande passante disponible d&#39;un canal de transmission lors d&#39;une transmission de donnees entre un emetteur et un recepteur a travers ledit canal et dispositif d&#39;emission pour la mise en oeuvre du procede
US20140317196A1 (en) Method and arrangement for the supervision of transactions in a peer-to-peer overlay network
EP1668869B1 (fr) Procede pour adapter un seuil d&#39;evitement de congestion en fonction de la charge du reseau et dispositif d&#39;emission associe
EP1745603B8 (fr) Procede et dispositif d&#39;emission de paquets de donnees
EP1424832A1 (fr) Dispositif de mesures de bout en bout d&#39;informations de reseau
WO2023195171A1 (fr) Système de communication, répéteur, procédé de communication et support lisible par ordinateur non transitoire
FR3059185A1 (fr) Procede et circuit de dectection de congestion
WO2004091140A2 (fr) Dispositif de mesure de qualite de service et utilisation d’un tel dispositif dans un reseau de transmission de donnees en temps reel
GB2588930A (en) Multimedia system &amp; method
Hristov et al. Simulation and evaluation of the bandwidth estimation algorithm with various types of filters
WO2007101962A1 (fr) Mécanisme de régulation multicouches du débit d&#39;un flux de données tcp dans un réseau haut débit ethernet full duplex
WO2001020857A1 (fr) Procede pour reduire la congestion dans un reseau