FR2951044A1 - Procede et dispositif de gestion de transmission de donnees sur un lien de communication, produit programme d'ordinateur et moyen de stockage correspondants. - Google Patents

Abstract

Il est proposé un procédé de gestion de transmission de données sur un lien de communication entre un premier dispositif d'interconnexion recevant les données d'un premier sous-réseau via une interface d'entrée et un second dispositif d'interconnexion fournissant les données à un second sous-réseau via une interface de sortie. Un dispositif d'interconnexion donné parmi les premier et second dispositifs d'interconnexion effectue des étapes consistant à : - intercepter (600) un message d'établissement d'une session de communication pour les données entre un premier dispositif de communication du premier sous-réseau et un second dispositif de communication du second sous-réseau via le lien de communication ; - obtenir (605, 606) une première valeur de temps d'aller retour des données entre une interface d'entrée du premier dispositif d'interconnexion et une interface de sortie du second dispositif d'interconnexion ; - ajuster (607, 610) une valeur de facteur multiplicatif de fenêtre de congestion contenue dans le message intercepté, en fonction de la première valeur de temps obtenue ; - poursuivre la transmission (620) du message intercepté avec la valeur ajustée.

Description

Procédé et dispositif de gestion de transmission de données sur un lien de communication, produit programme d'ordinateur et moyen de stockage correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des réseaux de communication. Plus précisément, l'invention concerne une technique de gestion d'une transmission de flux de données sur un tunnel de communication établi entre deux sous-réseaux de communication. La technologie des Réseaux Privés Virtuels (RPV, ou VPN pour « Virtual Private Network » en anglais) permet de communiquer de manière transparente, en temps réel et en continu, et de manière sécurisée, entre des individus partageant un même domaine d'intérêt tout en utilisant l'infrastructure réseau Internet peu sûre mais bon marché. Pour communiquer de manière transparente et s'affranchir des adresses non routables, les RPVs utilisent une encapsulation particulière (appelée « tunnellisation », ou « tunneling » en anglais) qui crée ce que l'on appelle un tunnel de communication (ou plus généralement lien de communication). Cette opération consiste à encapsuler un protocole de niveau A (protocole embarqué ou véhiculé ou passager) dans un protocole de niveau B (protocole de transport ou véhiculant) grâce à un protocole d'encapsulation C. Ainsi, le protocole de transport B traite le protocole embarqué A comme s'il s'agissait de données utiles. La figure 3, décrite en détail par la suite, présente un exemple d'encapsulation de paquets dans un RPV de niveau 2, c'est-à-dire dans un tunnel de niveau 2 (tunnel de niveau 2 signifie que le protocole embarqué A est un protocole de la couche 2 du modèle OSI, qui décrit les services offerts par chacune de ces couches et leurs interactions). Par exemple, les techniques de tunnellisation sont utilisées pour interconnecter deux sous-réseaux locaux domestiques (appelés ci-après sous-réseaux LAN, pour « Local Area Network » en anglais) afin de créer un réseau privé virtuel (ou RPV) composé de l'union des deux sous-réseaux LAN originaux. Une configuration typique de RPV basé sur une technique de tunnellisation est illustrée sur la figure 1 (décrite en détail par la suite). Selon cette technique, le lien de communication utilisé pour interconnecter deux sous-réseaux LAN est un tunnel. Chaque sous-réseau LAN comprend un dispositif d'interconnexion, par exemple une tête de tunnel (TEP, pour « Tunnel End Point » en anglais), et une passerelle. Le tunnel est établi entre les têtes de tunnel, et chaque paquet (aussi appelé trame) à envoyer au sous-réseau LAN distant est encapsulé par la tête de tunnel connectée au sous-réseau LAN local, puis envoyé, via le tunnel, à la tête de tunnel (distante) connectée au sous-réseau LAN distant, qui va le désencapsuler et l'envoyer sur le sous-réseau LAN distant. Du point de vue des équipements des sous-réseaux LAN interconnectés par un tunnel, ils sont virtuellement connectés à un même sous-réseau LAN. Une communication entre deux équipements via le tunnel est appelée communication de bout en bout (« end-to-end communication » en anglais), car l'utilisation du tunnel est transparente pour les équipements des sous-réseaux LAN connectés. De nos jours, il existe des RPVs disposant de tunnel formé de plusieurs porteuses (ou canaux). De tels RPVs sont notamment décrits dans le document de brevet EP 2,020,799. On parle de « tunnel multi-transport » d'un tunnel qui est formé de multiples porteuses ayant des protocoles de transport distincts. Chaque tête de tunnel dispose alors d'un ensemble de porteuses ayant des caractéristiques distinctes, afin d'adapter la transmission des données d'un sous-réseau LAN à l'autre aux besoins applicatifs ainsi qu'aux variations de conditions de transmission sur le réseau fédérateur (comme internet par exemple), entre ces sous-réseaux LAN. Dans l'état de la technique, on trouve des tunnels constitués de porteuses mettant en oeuvre le protocole de transport TCP (« Transmission Control Protocol » en anglais) et de porteuses mettant en oeuvre le protocole de transport UDP (« User Datagram Protocol » en anglais). Le protocole TCP est un protocole de type ARQ (« Automatic Repeat Request », ou demande de répétition automatique) qui est basé sur des mécanismes de contrôle de congestion et de retransmission, et assure ainsi la délivrance de chaque paquet vers la destination. Le protocole UDP est un protocole beaucoup plus simple et rapide, qui ne tient pas compte de l'ordre des trames, et ne gère pas d'acquittement. 2. ARRIÈRE-PLAN TECHNOLOGIOUE Le protocole TCP est un protocole de transport « fiable », orienté connexion (« Connection-oriented » en anglais). En effet, le protocole TCP permet de transporter et de délivrer un flux de données (ou « flux d'octets », « byte-stream » en anglais) sans altérations et dans l'ordre. Le protocole TCP propose également un mécanisme de retransmission en cas de perte de données, et un mécanisme d'élimination de données dupliquées.

On note que les protocoles applicatifs FTP (protocole de transfert de fichiers, ou « File Transfer Protocol » en anglais) et HTTP (« HyperText Transfer Protocol » en anglais), utilisent les services du protocole TCP/IP. Le protocole TCP propose en outre un mécanisme de lutte contre la congestion basée sur une fenêtre d'émission flottante, appelée fenêtre de congestion (pour « Congestion window » en anglais). Cette fenêtre de congestion contient l'ensemble des trames de données pouvant être émises par un serveur TCP (par exemple connecté au sous-réseau LAN distant) et non encore acquittées par un client TCP (par exemple connecté au sous-réseau LAN local). La taille Cwnd de cette fenêtre de congestion conditionne donc le débit maximum de la session TCP en cours. En effet, pendant la session TCP le serveur TCP ne peut émettre plus de Cwnd octets sans recevoir d'acquittement de la part du client TCP, or cet acquittement ne peut intervenir avant un temps d'aller-retour, noté RTT (pour « Round Trip Time » en anglais), correspondant au temps que met un paquet de données pour arriver au récepteur (c'est-à-dire au client TCP), et à l'acquittement correspondant d'être émis en retour et d'être reçu par l'émetteur (c'est-à-dire le serveur TCP). Le débit maximum d'une session TCP peut donc être exprimée de la façon suivante : débit max= Cwnd/RTT. Le serveur TCP ne peut donc émettre plus de Cwnd/RTT octets par seconde. La taille maximale de la fenêtre de congestion de l'émetteur est déterminée par ses capacités de stockage temporaire, mais aussi, par celles du récepteur. La taille de la fenêtre de réception disponible sur le récepteur est indiquée dans chacune des trames d'acquittement émises par le récepteur, afin d'éviter que l'émetteur ne dépasse les capacités de traitement du récepteur. La taille maximale de la fenêtre de congestion conditionnant le débit maximum de la session TCP, son adaptation est donc importante pour l'obtention de bonnes performances.

A l'origine, le protocole TCP décrivait une taille de fenêtre de réception codée sur 16 bits, ce qui limitait la taille maximale à 64ko (soit 21\16 octets). L'évolution des technologies ayant entraîné une augmentation importante du débit (et un allongement du temps RTT), cette taille maximale s'est rapidement avérée trop limitée, et il a fallu l'augmenter. Pour garantir la compatibilité avec les équipements TCP déjà en service (« legacy TCP devices » en anglais), la structure de la trame TCP n'a pas été remise en cause. Les concepteurs de TCP ont ajouté une option de facteur d'échelle (« scale factor » en anglais) de fenêtre de congestion. Ce facteur d'échelle, noté « SF » dans la suite de ce document, détermine un facteur multiplicatif appliqué à la taille de fenêtre de réception disponible (le facteur multiplicatif est égale à 2ASF). Ce facteur d'échelle de fenêtre de congestion codé sur 8 bits, mais de valeur maximale actuellement limitée à 14, n'est échangé qu'une seule fois lors de l'établissement de la session TCP. Cette valeur de facteur d'échelle de fenêtre de congestion est émise par chacun des équipements participant à la session TCP. Chaque équipement reçoit donc la valeur du facteur d'échelle de fenêtre de congestion émise par l'autre équipement, et l'enregistre. Dès lors que la valeur du facteur d'échelle de fenêtre de congestion est échangée, si la taille de la fenêtre de réception disponible sur le récepteur est égale à We, la taille réelle disponible sur le récepteur est alors égale à 2ASF * We. Par exemple, si le facteur d'échelle de fenêtre de congestion est égal à 3, le facteur multiplicatif à appliquer à la taille de fenêtre de réception présentée par le récepteur est de 8 (soit 21\3). Le facteur d'échelle de fenêtre de congestion étant limité à 14, la taille de fenêtre de réception maximum est donc maintenant de 21\14 * 21\16=21\30, soit 1Go, par comparaison aux 64ko d'origine. Cette évolution du protocole TCP est décrite par la norme RFC 1323 « TCP Extensions for High Performance ». Il est important de noter qu'une session TCP permet une transmission bidirectionnelle de données entre le client TCP et le serveur TCP.

Le protocole UDP est un protocole de transport simple, sans connexion, c'est-à-dire qu'il fonctionne en mode paquet (mode « Datagram » en anglais). Ainsi, le protocole UDP permet de transporter et de délivrer un flux de données avec un débit optimal. Toutefois, le protocole UDP est « non fiable ». En effet, le protocole UDP ne prévoit pas de mécanisme pour vérifier que les paquets de données sont arrivés à destination, et ne garantit pas leur arrivée dans l'ordre. Le protocole UDP ne prévoit pas non plus de mécanisme de contrôle de flux en cas de congestion. Le protocole UDP est généralement utilisé par des applications de diffusion multimédia (audio et vidéo, etc) pour lesquelles le temps requis par le protocole TCP pour gérer les retransmissions et l'ordonnancement des paquets n'est pas disponible. Comme indiqué précédemment, le débit maximum d'une session TCP est donné par la formule suivante : débit max= Cwnd/RTT. Ainsi, lorsqu'on utilise le protocole TCP comme protocole de transport entre deux équipements reliés par un réseau possédant un temps RTT très long, le débit de la session TCP entre ces équipements est faible. En effet, si le temps RTT double, le débit est divisé par 2. Dans le cas d'une transmission à travers un tunnel, la session TCP passagère (c'est-à-dire la session de bout en bout) est encapsulée dans une nouvelle session du tunnel (TCP, UDP, ou autre). C'est cette nouvelle session qui assure la communication entre les deux têtes de tunnel, permettant ainsi de traverser un réseau de nature différente (comme l'Internet par exemple). Le temps d'aller retour RTT des informations entre deux équipements connectés à l'Internet peut être très différent suivant l'emplacement sur le réseau de ces deux équipements, et en particulier suivant le nombre de routeurs à traverser pour relier les deux équipements. A titre d'exemple, le temps RTT d'une communication entre deux équipements d'une même ville européenne sera de quelques dizaines de milliseconde, alors que le temps RTT d'une communication entre deux équipements situés sur des plaques continentales différentes sera de plusieurs centaines de milliseconde. Dans le cas de l'utilisation d'un tunnel, le problème est que, du fait de la transparence du tunnel aux applications, les équipements adaptés à une utilisation locale (c'est-à-dire adaptés pour un temps RTT très faible de l'ordre de quelques millisecondes) peuvent être utilisés avec un temps RTT beaucoup plus important que prévu. Le débit maximum est alors fortement réduit, alors que les têtes de tunnel peuvent être dimensionnées pour répondre aux contraintes de débit sur un réseau à forte latence, par exemple, avec des tailles de mémoires tampons (ou « buffers » en anglais) adaptées. Même si un serveur TCP, par exemple dimensionné pour servir plusieurs clients simultanément, possède une mémoire tampon d'émission permettant avec un temps RTT donné d'avoir un débit supérieur (débit max = buffer_size / RTT), la faible valeur de la taille (buffer_size) de la mémoire tampon de réception du client TCP limite la valeur du débit, interdisant ainsi le serveur TCP de communiquer avec le client TCP à un débit supérieur. Pour que le serveur TCP utilise pleinement sa capacité d'émission, en d'autres termes pour que le débit reste identique à celui pour lequel le serveur TCP a été conçu, il est nécessaire de modifier la taille de la fenêtre de réception publiée par le client TCP, de façon à faire croire au serveur TCP que le client TCP possède une taille de fenêtre de réception plus grande. L'ordre de grandeur de la modification (fois 10, fois 100, etc.) de la taille de fenêtre est tel que cela oblige à modifier la valeur du facteur d'échelle de fenêtre de congestion SF échangés par les équipements TCP lors de l'ouverture d'une session à travers le tunnel. La plupart des solutions d'amélioration des performances de transmission d'un flux de données selon un protocole de transport, tel que le protocole TCP, reposent sur la modification de la valeur du facteur d'échelle de fenêtre de congestion en fonction d'une valeur fixe prédéfinie.

Le document de brevet US2008/0075000 (ARRIS International) décrit un mécanisme pouvant être mis en oeuvre dans un équipement intermédiaire et permettant d'adapter la taille de la fenêtre de réception en jouant sur la valeur du facteur d'échelle de fenêtre de congestion SF contenue dans le message d'établissement de la session TCP (aussi appelé par la suite trame TCP) et sur la valeur de la taille de la fenêtre publiée par le récepteur à chaque acquittement de trame TCP. Plus précisément, sur interception d'une trame TCP de type TCP SYN, il est proposé de modifier la valeur du facteur d'échelle de fenêtre de congestion SF en utilisant une valeur prédéfinie. Il est aussi proposé de modifier la valeur de la taille de la fenêtre du récepteur dans chacune des trames d'acquittement. De cette façon, la trame TCP interceptée est modifiée avant transmission vers son destinataire. Ce document de brevet se positionne dans un contexte de fournisseur de contenu (par exemple, cas d'un streaming vidéo entre un équipement local chez un abonné et un serveur de contenu sur le WEB), ne faisant intervenir aucun tunnel de communication entre les équipements. Dans ce contexte, les abonnés se situent dans une zone géographique déterminée, et le serveur de vidéo du fournisseur de contenu aussi. Par conséquent, l'utilisation d'une valeur constante et préfixée du facteur d'échelle de fenêtre de congestion est possible. En effet, la valeur du temps RTT varie peu autour d'une valeur moyenne connue. Cette première technique connue n'est donc pas applicable dans le cas où l'on met en oeuvre un tunnel entre des équipements, du fait que les variations du temps RTT entre deux ouvertures de tunnel distinctes sont importantes. En outre, ce document de brevet ne décrit pas de méthode de détermination de la valeur du facteur d'échelle de fenêtre de congestion. Dans le document « Rate Based Satellite Control Protocol » de la société Cisco, il est proposé un routeur mettant en oeuvre une deuxième technique appelée « window stuffing », que l'on peut traduire approximativement par « gonflage de fenêtre ». Une telle technique permet, à un administrateur au moment de la configuration du tunnel de communication, de modifier la valeur du facteur d'échelle de fenêtre de congestion par l'ajout d'une valeur constante. Le routeur de Cisco est utilisé dans un contexte de tunnel établi grâce à une liaison satellite. Un tel tunnel relie des stations terrestres et est généralement établi pour une longue période (par exemple pour plusieurs mois). Le temps de transmission par satellite est uniquement fonction de la distance à parcourir par les ondes radio entre les stations terrestres et le satellite. Cette distance apparaît donc comme constante. Par conséquent, le temps RTT est sensiblement constant. L'utilisation d'une valeur constante et préfixée pour modifier le facteur d'échelle de fenêtre de congestion est donc possible. Cette deuxième technique connue n'est donc pas applicable dans le cas où les distances entre équipements peuvent variées, de fait entraînant des variations du temps RTT. En outre, ce document Cisco ne décrit pas de méthode de détermination de la valeur du facteur d'échelle de fenêtre de congestion. De plus, l'ergonomie de cette deuxième technique est limitée du fait qu'elle nécessite l'intervention d'un administrateur réseau pour déterminer la constante à appliquer sur la valeur du facteur d'échelle de fenêtre de congestion. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique.

Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique de gestion de transmission de données sur un lien de communication permettant de transmettre, avec un débit élevé, un flux de données via un lien de communication.

Un autre objectif d'au moins un mode de réalisation de l'invention est de permettre la configuration d'un dispositif serveur et d'un dispositif client, pour la transmission d'un flux de données de bout en bout, de manière adaptée au lien de communication entre ces dispositifs client et serveur, ainsi que de manière transparente pour ces dispositifs serveur et client.

Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui ne nécessite pas d'importantes ressources mémoires et de calcul. Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui soit simple à mettre en oeuvre. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion de transmission de données sur un lien de communication entre un premier dispositif d'interconnexion recevant lesdites données d'un premier sous-réseau via une interface d'entrée et un second dispositif d'interconnexion fournissant lesdites données à un second sous-réseau via une interface de sortie. Un dispositif d'interconnexion donné parmi lesdits premier et second dispositifs d'interconnexion effectue des étapes consistant à : - intercepter un message d'établissement d'une session de communication pour lesdites données entre un premier dispositif de communication du premier sous-réseau et un second dispositif de communication du second sous-réseau via ledit lien de communication ; - obtenir une première valeur de temps d'aller retour desdites données entre une interface d'entrée du premier dispositif d'interconnexion et une interface de sortie du second dispositif d'interconnexion ; - ajuster une valeur de facteur multiplicatif de fenêtre de congestion contenue dans ledit message intercepté, en fonction de la première valeur de temps obtenue ; - poursuivre la transmission du message intercepté avec la valeur ajustée. 30 Ainsi, il est proposé de prendre en compte les caractéristiques de transmission relatives au lien de communication et aux dispositifs d'interconnexion pour l'ajustement de la valeur du facteur multiplicatif (facteur d'échelle) de fenêtre de congestion. Plus précisément, il est proposé de tenir compte des temps d'aller retour dans le lien de communication et dans les dispositifs d'interconnexion. En d'autres termes, il est proposé de tenir compte d'une valeur de temps d'aller retour égale à la somme des temps de transit dans chaque dispositif d'interconnexion et dans le lien de communication. Ainsi, et contrairement aux techniques de l'état de la technique précitées, on n'utilise pas des valeurs prédéterminées (incréments fixes) pour modifier la valeur du facteur multiplicatif, mais une valeur de temps d'aller retour déterminée de manière dynamique lors de l'établissement d'une session de communication sur le lien de communication. Dans le cas où le message intercepté contient une valeur existante de facteur multiplicatif de fenêtre de congestion, l'invention propose de modifier cette valeur existante, en fonction de la valeur de temps d'aller retour déterminée. Dans le cas où le message intercepté ne contient aucune valeur de facteur multiplicatif de fenêtre de congestion, l'invention propose de créer une telle valeur à partir de la valeur de temps d'aller retour déterminée.

Par exemple, le lien de communication est un tunnel de communication, un brin réseau, un câble ou une succession de câbles avec répéteurs, ou un lien radio. Par exemple, les dispositifs d'interconnexion sont des têtes de tunnel, des bridges, des routeurs, ou des adaptateurs de medium. Ainsi, il est possible d'utiliser un tunnel de communication entre des équipements adaptés à une utilisation locale, tout en gardant un débit optimal (c'est-à- dire proche de celui observé en utilisation locale). Par ailleurs, dans un mode de réalisation particulier, la technique de l'invention est très peu coûteuse puisque la modification de la valeur du facteur multiplicatif s'effectue uniquement lors de l'établissement d'une session de communication sur le lien de communication (et pas à chaque paquet). De plus, dans un mode de réalisation particulier, l'interception du message d'établissement de session de communication se fait à moindre coût par analyse d'un seul bit. De façon avantageuse, le dispositif d'interconnexion donné effectue une étape consistant à obtenir une deuxième valeur de temps d'aller retour desdites données entre le premier dispositif de communication, second dispositif de communication respectivement, et le premier dispositif d'interconnexion, second dispositif d'interconnexion respectivement. L'étape consistant à ajuster la valeur du facteur multiplicatif s'effectue en fonction d'un rapport entre la première valeur de temps obtenue et ladite deuxième valeur de temps obtenue.

Ainsi, il est proposé de tenir compte des temps d'aller retour sur les premier et second sous-réseaux. L'utilisation d'un tel rapport de temps d'aller retour permet une adaptation dynamique de la valeur du facteur multiplicatif à n'importe quelle configuration de réseau. Avantageusement, le dispositif d'interconnexion donné effectue des étapes consistant à : - déterminer une direction de transmission dudit message intercepté ; - déterminer une direction de transmission desdites données ; - comparer la direction de transmission des données et la direction de transmission du message intercepté ; et la valeur de facteur multiplicatif de fenêtre de congestion contenue dans ledit message intercepté est ajustée si la direction de transmission des données et la direction de transmission du message intercepté sont différentes. Dans le cas particulier de l'établissement d'une session de communication TCP, deux messages TCP SYN(Req) et TCP SYN ACK participent à l'établissement de la session TCP. Ainsi, dans ce cas particulier, la détermination et la comparaison des directions de transmission des données et du message intercepté permettent de ne faire l'ajustement de la valeur du facteur multiplicatif que sur l'un des deux messages TCP SYN(Req) et TCP SYN ACK. En effet, la plupart des sessions TCP bien que permettant une transmission bidirectionnelle, ne sont utilisées que pour transmettre des données dans un seul sens. Cela évite donc de réserver inutilement des ressources sur une tête de tunnel.

Ainsi, la mise en oeuvre du procédé selon l'invention permet une grande réactivité et une économie de ressources de traitement (puisqu'un seul des deux messages TCP SYN(Req) et TCP SYN ACK est modifié). Si la direction de transmission du flux de données est identique à celle du message intercepté, alors il est inutile de modifier la valeur du facteur multiplicatif puisque dans ce cas le flux de données va être reçu par l'équipement qui a émis le message d'établissement de session. Ainsi, le premier dispositif d'interconnexion libère le message intercepté. Le message libéré est donc transmis vers l'autre dispositif d'interconnexion sans modification de la valeur du facteur multiplicatif.

Avantageusement, le dispositif d'interconnexion donné effectue une étape consistant à détecter que le message intercepté provient du sous-réseau auquel est connecté le dispositif d'interconnexion donné. Si le message intercepté provient du sous-réseau auquel est connecté le dispositif d'interconnexion donné, le dispositif d'interconnexion donné effectue des étapes consistant à : - déterminer au moins un protocole de transport des données utilisé sur le lien de communication pour transmettre lesdites données ; - dans le cas où le protocole de transport déterminé est un protocole de transport avec acquittement des données, déterminer une valeur maximale de facteur multiplicatif de fenêtre de congestion, en fonction d'une capacité de stockage de données dudit premier dispositif d'interconnexion destinée à stocker lesdites données avant transmission sur le lien de communication ; - comparer la valeur ajustée et la valeur maximale ; - dans le cas où la valeur ajustée est supérieure à la valeur maximale, poursuivre la transmission du message intercepté avec la valeur maximale, sinon poursuivre la transmission du message intercepté avec la valeur ajustée. Ainsi, dans le cas où le mode de transport est, par exemple, du type TCP, il est proposé d'ajuster la valeur du facteur multiplicatif, en fonction des ressources mémoires disponibles au niveau du dispositif d'interconnexion qui va émettre les données. Ceci permet donc d'éviter tout risque d'engorgement au niveau de ce dispositif d'interconnexion. En effet, si la nouvelle taille de fenêtre de congestion est supérieure à la taille de l'espace mémoire, comprise dans le dispositif d'interconnexion qui va émettre les données et disponible pour la transmission de ces données, alors on limite la taille de fenêtre de congestion à cette taille d'espace mémoire disponible pour la transmission des données. De façon avantageuse, le dispositif d'interconnexion donné effectue des étapes consistant à, dans le cas où plusieurs protocoles de transport ont été déterminés dont au moins un est un protocole de transport avec acquittement des données et au moins un est un protocole de transport sans acquittement des données : - obtenir un ratio entre une quantité de données transmis en utilisant le(s) protocole(s) de transport avec acquittement des données et une quantité de données transmis en utilisant le(s) protocole(s) de transport sans acquittement des données ; - déterminer ladite valeur maximale de facteur multiplicatif de fenêtre de congestion, en fonction en outre dudit ratio obtenu. Ainsi, si plusieurs protocoles de transport (une partie sur UDP et une partie sur TCP ou plus généralement, une partie en utilisant un protocole de transport sans acquittement ni retransmission des données, tel que UDP, et le reste en utilisant un protocole de transport avec acquittement et retransmission des données, tel que TCP) sont utilisés, alors on prend en compte un ratio qui représente le pourcentage du flux transmis en utilisant le protocole TCP (ou plus généralement, en utilisant un protocole de transport avec acquittement et retransmission des données). Selon une caractéristique avantageuse, si le message intercepté ne provient pas du sous-réseau auquel est connecté le dispositif d'interconnexion donné, le dispositif d'interconnexion donné effectue des étapes consistant à : - obtenir une valeur initiale de facteur multiplicatif de fenêtre de congestion ; - déterminer une valeur maximale de facteur multiplicatif de fenêtre de congestion, en fonction d'une capacité de stockage de données dudit second dispositif d'interconnexion destinée à stocker lesdites données avant transmission sur le sous-réseau auquel est connecté ledit dispositif d'interconnexion donné ; - comparer la valeur initiale obtenue et la valeur maximale ; - dans le cas où la valeur initiale obtenue est supérieure à la valeur maximale, poursuivre la transmission du message intercepté avec la valeur maximale, sinon poursuivre la transmission du message intercepté avec la valeur initiale obtenue. Une trame d'établissement de session venant du lien de communication peut avoir déjà été modifiée par l'autre dispositif d'interconnexion. Ainsi, dans un tel cas, il est proposé de diminuer la valeur du facteur multiplicatif pour tenir compte de la mémoire disponible au niveau du dispositif d'interconnexion qui met en oeuvre l'invention. Dans un mode de réalisation préférentiel, le lien de communication est un tunnel, et chaque dispositif d'interconnexion est une tête de tunnel. Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur. Ce produit programme d'ordinateur comprend des instructions de code de programme pour la mise en oeuvre du procédé précité (dans l'un quelconque de ses différents modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation, l'invention concerne un moyen de stockage lisible par ordinateur, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé précité (dans l'un quelconque de ses différents modes de réalisation). Dans un autre mode de réalisation, il est proposé un dispositif de gestion de transmission de données sur un lien de communication entre un premier dispositif d'interconnexion recevant lesdites données d'un premier sous-réseau via une interface d'entrée et un second dispositif d'interconnexion fournissant lesdites données à un second sous-réseau via une interface de sortie, le dispositif de gestion étant compris dans un dispositif d'interconnexion donné parmi lesdits premier et second dispositifs d'interconnexion. Le dispositif de gestion comprend : - des moyens d'interception d'un message d'établissement d'une session de communication pour lesdites données entre un premier dispositif de communication du premier sous-réseau et un second dispositif de communication du second sous-réseau via ledit lien de communication ; - des moyens d'obtention d'une première valeur de temps d'aller retour desdites données entre une interface d'entrée du premier dispositif d'interconnexion et une interface de sortie du second dispositif d'interconnexion ; - des moyens d'ajustement d'une valeur de facteur multiplicatif de fenêtre de congestion contenue dans ledit message intercepté par lesdits moyens d'interception, en fonction de la première valeur de temps obtenue par lesdits moyens d'obtention ; - des moyens de poursuite de la transmission du message intercepté avec la valeur ajustée. Avantageusement, le dispositif de gestion comprend des moyens de mise en oeuvre des étapes du procédé de gestion tel que décrit précédemment, dans l'un quelconque de ses différents modes de réalisation. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : - la figure 1 illustre schématiquement une configuration typique d'un réseau privé virtuel pour la mise en oeuvre de l'invention selon un mode de réalisation particulier ; - la figure 2 illustre schématiquement un exemple de modèle en couche classique d'une tête de tunnel dans laquelle est mis en oeuvre le procédé selon un mode de réalisation particulier ; - la figure 3 illustre schématiquement un exemple de format classique d'une trame Ethernet véhiculant un paquet tunnel de niveau 2 ; - la figure 4 présente un exemple d'échange de messages entre un client TCP et un serveur TCP lors de l'établissement d'une session TCP, et un exemple d'échange de données entre ces mêmes client et serveur TCP ; - la figure 5 illustre un exemple de transmission d'un flux de données à travers un tunnel de communication, selon un mode de réalisation particulier de l'invention ; - la figure 6 présente les étapes principales d'un algorithme de gestion de transmission de données, selon un mode de réalisation particulier de l'invention ; et - la figure 7 illustre schématiquement un dispositif selon un mode de réalisation particulier de l'invention. 6. DESCRIPTION DÉTAILLÉE La figure 1 illustre schématiquement, selon un mode de réalisation particulier de l'invention, une configuration typique de réseau privé virtuel (VPN pour « Virtual Private Network » en anglais) mettant en oeuvre un tunnel 100 de communication entre une première tête de tunnel locale 101 et une seconde tête de tunnel distante 102, à travers un réseau de communication 107, comme Internet par exemple. Ce tunnel 100 interconnecte un premier sous-réseau de communication 103 et un second sous-réseau de communication 104, encore appelés respectivement LAN A 103 et LAN B 104. Le premier sous-réseau LAN A 103 et le second sous-réseau LAN B 104 comportent chacun un équipement d'accès Internet haut débit de type passerelle Internet domestique (ou « Home Gateway » en anglais) (référencés respectivement 105 et 106), pouvant intégrer un pare-feu (ou « Firewall » en anglais) (référencés respectivement 105a et 106a), des équipements de type PC 109 et 111, des serveurs 110 et 113 permettant le stockage et le partage des media numériques (de type audio, vidéo, photo), ainsi que des équipements de restitution des médias numériques 108 et 112. Une tête de tunnel peut être un équipement dédié (comme illustré sur la figure 1) ou bien être intégrée dans un équipement audiovisuel comme un téléviseur numérique. Elle peut aussi être présente dans un équipement de type PC sous la forme d'un programme réalisant les fonctions associées à celle-ci. Une fois le tunnel 100 établi, les équipements 108, 109, et 110, connectés au premier sous-réseau LAN A 103, sont capables de communiquer avec les équipements 111, 112 et 113, connectés au second sous-réseau LAN B 104. Par exemple, le client local 108 connecté au premier sous-réseau LAN A 103 peut communiquer avec le serveur local 113 connecté au second sous-réseau LAN B 104. Sur cette figure 1 est représenté un réseau de communication simple avec un seul tunnel, mais il est bien entendu qu'une même tête de tunnel peut être amenée à gérer plusieurs tunnels (à destination d'autant de têtes de tunnel) pour interconnecter un premier sous-réseau LAN à plusieurs autres sous-réseaux LAN. En outre, dans un souci de simplification, n'ont pas été représentés les équipements d'infrastructure dans le réseau Internet tels que les routeurs Internet. En relation avec la figure 2, on présente maintenant le cheminement d'une trame Ethernet issue d'un des équipements 108, 109, 110, connectés au premier sous-réseau LAN A 103, et entrant dans le tunnel 100 pour y être acheminée jusqu'au second sous-réseau LAN B 104. Pour ce faire, on utilise un modèle en couches décrivant les couches de protocoles nécessaires à la mise en oeuvre de ce tunnel 100. Dans ce modèle ne sont pas représentés les éléments de protocole nécessaire aux fonctions autres que la mise en oeuvre du tunnel. Par exemple, ne sont pas représentés les éléments de protocole associés à une architecture UPnP (pour « Universal Plug and Play » en anglais) lorsqu'une première tête de tunnel 101 est intégrée dans un équipement UPnP. La première tête de tunnel 101 comporte une interface physique Ethernet 208 qui remet les trames Ethernet issues des équipements 108, 109, 110 à la couche liaison 207 pour routage : vers la couche réseau 206, pour les trames Ethernet à destination de l'équipement comportant la tête de tunnel, ou vers la couche de pont (« bridge » en anglais) 209, pour les autres trames Ethernet. La couche de pont 209 réalise les opérations classiques d'un pont Ethernet telles que le filtrage des trames Ethernet et le relais de ces trames vers le ou les port(s) Ethernet de sortie approprié(s). Sur le pont sont attachées une interface Ethernet 207 et au moins une interface virtuelle 210 simulant un contrôleur Ethernet. Une interface virtuelle 210 est créée pour chaque tunnel instancié par l'application 200 à qui elle remet les trames Ethernet qui doivent transiter sur les tunnels respectivement instanciés. D'une manière générale, le protocole d'encapsulation du tunnel représenté par l'application 200 réalise les opérations nécessaires à la mise en oeuvre de chaque tunnel, parmi lesquelles on trouvera notamment la configuration, le filtrage et l'encapsulation, c'est-à-dire la formation d'un paquet tunnel, et l'extraction d'une trame. Dans un mode de réalisation particulier, l'application 200 met en oeuvre des étapes pour l'établissement d'une session TCP qui sont détaillées ci-après en relation avec la figure 4.

Les trames reçues de l'interface virtuelle 210, après traitement par l'application 200, sont remises sous la forme d'un paquet à travers une interface applicative 201 (ou « socket » en anglais) à un protocole de transport fiable TCP 203 ou non fiable UDP 205, respectivement sécurisés par les protocoles SSL 202 et DTLS 204. Après traitement par un protocole de transport pour former un paquet tunnel, celui-ci est transmis à la couche réseau 206. Le datagramme IP ainsi formé avec le paquet tunnel peut ensuite être transmis sur le sous-réseau LAN à travers les couches liaison 207 et physique 208. La réception d'une trame en provenance du tunnel 100 suivra dans la tête de tunnel 101 le cheminement inverse à celui présenté ci-dessus.

La figure 3 présente un exemple de format classique d'une trame Ethernet 260, transitant par exemple sur le premier sous-réseau LAN A 103 de la figure 1 entre la première tête de tunnel 101 et la passerelle domestique 105. Cette trame Ethernet 260 peut être transmise vers le second sous-réseau LAN B 104 via Internet ou être reçue du second sous-réseau LAN B 104 via Internet. Cette trame Ethernet 260 comprend un champ d'en-tête Ethernet 261, un premier datagramme IP 262 véhiculant lui-même un paquet tunnel 250 de niveau 2, et un champ FCS 263 (pour « Frame Check Sequence » en anglais, ou « séquence de contrôle de trame » en français). Le paquet tunnel 250 comporte quatre parties : - un champ d'en-tête du protocole de transport 251 (à savoir TCP ou UDP dans cet exemple) ; - un champ d'en-tête du protocole d'encapsulation 252 (à savoir L2TP ou TLS dans cet exemple, qui sont décrits notamment dans les documents suivants : « IETF RFC3931, "Layer two tunneling protocol û version 3 (L2TPv3)", J. Lau and ail, March 2005 » et « IETF RFC2246, "The TLS Protocol Version 1.0" » ; - un champ d'en-tête du protocole embarqué 253 (à savoir Ethernet dans cet exemple) ; et - un champ de données utiles 254, qui comporte un second datagramme IP complet si aucune fragmentation n'a été opérée lors de son transit depuis l'équipement source. La figure 4 illustre un exemple d'échange de messages entre un client TCP 301, par exemple, connecté au premier sous-réseau LAN A 103, et un serveur TCP 302, par exemple, connecté au second sous-réseau LAN B 104. Plus précisément, la figure 4 illustre un exemple d'échange de messages entre le client TCP et le serveur TCP lors de l'établissement d'une session TCP à travers le tunnel 100, et un exemple d'échange de données entre ces mêmes client et serveur TCP. Dans cet exemple de réalisation, le client 301 transmet vers le serveur 302 un message d'établissement de session TCP, référencé TCP SYN(Req) 303. En réponse à cette requête TCP SYN(Req) 303, le serveur 302 transmet vers le client 301 un message d'acquittement TCP SYN ACK 304, indiquant que le serveur 302 accepte d'ouvrir une session TCP. Enfin, le client 301 transmet vers le serveur 302 un message d'acquittement ACK 305, indiquant que le client 301 a bien reçu le message d'acquittement TCP SYN ACK 304. Une fois ces échanges effectués, une session TCP est établie entre le client 301 et le serveur 302. Du fait que la session TCP est bidirectionnelle le client 301 et le serveur 302 peuvent tous deux transmettre et recevoir des flux de données via le tunnel 100. Dans l'exemple de la figure 4, après l'établissement de la session TCP, le serveur 302 transmet vers le client 301 un flux de données TCP DATA 306. Sur réception de ce flux de données TCP DATA 306, le client 301 transmet vers le serveur 302 un message d'acquittement ACK 307. On discute ci-après, pour différents cas d'application, de l'importance de la prise en compte de la direction réelle du flux de données dans le processus de détermination de la trame TCP (message TCP SYN(Req) ou TCP SYN ACK) dans laquelle la valeur du facteur d'échelle de fenêtre de congestion doit être modifiée.

Dans un premier cas d'application illustré par la figure 4, le flux de données TCP DATA 306 est transmis depuis le serveur 302 vers le client 301. Par exemple dans ce premier cas, le serveur 302 est un serveur « http » fournissant un flux vidéo. Ainsi, pour permettre au serveur 302 de transmettre un flux de données au débit souhaité, malgré le temps RTT de la communication entre le client 301 et le serveur 302, au moins l'une des têtes de tunnel 101 et 102 doit déclarer au serveur 302 que le client 301 possède une fenêtre de réception de taille plus grande que celle préalablement déclarée par le client 301. Pour ce faire, la tête de tunnel considérée modifie la valeur du facteur d'échelle de fenêtre de congestion contenue dans le message TCP SYN(Req) émis par le client 301, avant de transmettre celui-ci vers le serveur 302. Le message TCP SYN(Req) avec la valeur du facteur d'échelle de fenêtre de congestion modifiée est ensuite reçu par le serveur 302. Le serveur 302 enregistre la valeur du facteur d'échelle de fenêtre de congestion telle que modifiée par la tête de tunnel considérée, et dès lors voit une fenêtre de réception, au niveau du client 301, plus grande qu'elle ne l'est en réalité, ce qui lui permet de transmettre ses données à un débit plus élevé.

Dans un second cas d'application (non illustré), par exemple dans le cas d'un transfert utilisant le protocole FTP en mode actif, on a une phase de communication entre un client au sens FTP et un serveur au sens FTP. A l'issue de cette phase de communication, basée sur le protocole TCP, une session FTP est établie entre le client FTP et le serveur FTP. Par la suite, à chaque fois qu'un transfert de données entre le serveur FTP et le client FTP est nécessaire, une nouvelle session TCP est établie pour prendre en charge ce transfert. Or, en mode actif, c'est le serveur FTP qui prend le rôle de client TCP, et qui est à l'origine du message d'établissement de session TCP. On note que dans le mode passif, c'est l'inverse le client FTP qui est à l'origine du message d'établissement de session TCP. En conséquence, lors d'un transfert de données FTP en mode actif, le flux de données est émis par le client TCP à destination du serveur TCP. Dans ce cas, il faut donc modifier la valeur du facteur d'échelle de fenêtre de congestion contenue dans le message TCP SYN ACK pour faire croire au client TCP que le serveur TCP possède une fenêtre de réception de taille plus grande. Ainsi, il est avantageux de prendre en compte la direction réelle du flux de données, et donc de déterminer les rôles de client et serveur au sens donnée, et pas seulement le rôle client ou serveur au sens TCP.

Comme décrit ci-après, la technique de l'invention, dans un mode de réalisation particulier, prévoit de prendre en compte la direction de transmission du message d'établissement de session TCP et la direction de transmission du flux de données pour déterminer dans lequel des messages TCP SYN(Req) et TCP SYN ACK la valeur du facteur d'échelle de fenêtre de congestion doit être modifiée. La figure 5 illustre un exemple de transmission d'un flux de données à travers un tunnel de communication. Sur la figure 5, le flux de données transmis depuis le serveur TCP 110 jusqu'au client TCP 112 est représenté par le trait pointillé, référencé 410.

Les paquets de données émis par le serveur TCP 110 à destination du client TCP 112, transitent via le premier sous-réseau LAN A 103, puis arrivent à la première tête de tunnel 101, via une interface d'entrée 1011, où ils sont stockés dans une première zone de stockage temporaire 401 en attendant que l'ordonnanceur 403 les traitent pour générer une trame 250 telle que décrite en relation avec la figure 3. La trame générée 250 est stockée dans une deuxième zone de stockage temporaire 402 avant son émission à destination de la seconde tête de tunnel 102. Dans l'exemple illustré, l'émission de la trame 250 à destination de la seconde tête de tunnel 102 se fait en réalité via le premier sous-réseau LAN A 103 et la passerelle 105 (représentée sur la figure 1), puis via la passerelle 106 (représentée sur la figure 1) et le second sous-réseau LAN B 104. Par souci de clarté, ces étapes n'ont pas été représentées sur la figure 5. De même, le chemin de données dans le sens client TCP 112 vers le serveur TCP 110 n'a pas été représenté. Lors de la réception d'une trame en provenance de la première tête de tunnel 101, la seconde tête de tunnel 102 stocke la trame reçue dans une troisième zone de stockage temporaire 404 en attendant que l'ordonnanceur 406 la traite pour en extraire la trame originale encapsulée. Une fois traitée, la trame dès-encapsulée est stockée dans une quatrième zone de stockage temporaire 405 avant d'être émise, via une interface de sortie 1021, sur le second sous-réseau LAN B 104 à destination du client TCP 112. Comme illustré sur la figure 5, il existe différents temps d'aller retour entre les différents équipements du réseau. On note RTT2 le temps d'aller retour entre le serveur TCP 110 et l'interface d'entrée 1011 de la première tête de tunnel 101. On note RTT3 le temps d'aller retour entre le client TCP 112 et l'interface de sortie 1021 de la seconde tête de tunnel 102. On note que les temps d'aller retour RTT2 et RTT3 sont, dans l'exemple proposé, de même ordre de grandeur RTTLAN. On note RTT1 le temps d'aller retour entre le premier sous-réseau LAN A 103 et le second sous-réseau LAN B 104, c'est-à-dire entre l'interface d'entrée 1011 de la première tête de tunnel 101 et l'interface de sortie 1021 de la seconde tête de tunnel 102. Contrairement à la première technique connue précitée, la technique de l'invention propose de prendre en compte la latence induite par les temps de stockage dans les zones 401, 402, 403, et 404, ainsi que les temps de traitement par les ordonnanceurs 403 et 406, pour déterminer une nouvelle valeur de facteur d'échelle de fenêtre de congestion. Dans le cas d'un réseau utilisant un tunnel de communication pour relier les sous-réseaux (cas illustré sur la figure 5), le temps d'aller retour RTT sur ce réseau est égal à la somme des temps d'aller retour RTT1, RTT2 et RTT3. Dans le cas d'un réseau utilisant un fil ou un commutateur de paquet (« packet switch » en anglais) à la place d'un tunnel de communication, le temps d'aller retour RTT sur ce réseau est égal à la somme des temps d'aller retour RTT2 et RTT3. En effet, la latence induite par le fil ou le commutateur reliant les sous-réseaux LAN A et B est négligeable. La formule donnant le débit maximum (Throughput.) sur un réseau s'écrit comme suit : Throughput maX = Wnd * 2'Fo RTT (1) 30 où - RTT est le temps d'aller retour sur le réseau ; - Wnd est la taille de la fenêtre de réception publiée par le client TCP. On considère que cette taille est inférieure à celle de la fenêtre d'émission du serveur TCP ; et - SFo est le facteur d'échelle de fenêtre de congestion original échangé lors de l'ouverture de la session TCP. Dans un mode de réalisation particulier, le temps d'aller retour RTTLAN (RTT2 et RTT3) est déterminé par analyse du trafic LAN par la tête de tunnel.

Pour déterminer la valeur de RTTLAN correspondant au temps d'aller retour entre une tête de tunnel, et un équipement de son sous-réseau local, la tête de tunnel détecte une première trame TCP en provenance du sous-réseau disant à destination de l'équipement (typiquement, cette première trame peut correspondre à une trame SYN REQ, ou SYN ACK), puis compte le temps qui s'écoule entre l'instant de détection de ladite première trame TCP, et l'instant de détection par la même tête de tunnel d'une seconde trame TCP générée par l'équipement local et contenant un acquittement de la dite première trame TCP. Dans une variante de réalisation, les temps d'aller retour RTT2 et RTT3 sont déterminés par l'envoi d'une commande de type « ping » depuis chaque tête de tunnel vers l'équipement connecté à son sous-réseau local parmi le serveur TCP 110 et le client TCP 112. Dans un premier mode de réalisation particulier, le temps d'aller retour RTT1 est obtenu par les têtes de tunnel en utilisant une interface API (« Application Programming Interface » en anglais) selon le protocole TCP (tel que décrit dans la norme RFC) fournissant cette information pour la session tunnel établie. Dans un second mode de réalisation particulier, le temps d'aller retour RTT1 est mesuré par les têtes de tunnel. La mesure de RTT1 peut être réalisée par une tête de tunnel, en mesurant le temps qui s'écoule entre l'émission d'une trame TCP à destination de la tête de tunnel distante, et l'acquittement de cette trame par la tête de tunnel distante. Cette mesure peut être réalisée sur une quelconque trame TCP de la porteuse TCP du tunnel (y compris les trames de demande d'établissement de la porteuse TCP). Pour obtenir un débit identique dans le cas d'un réseau utilisant un tunnel de communication et dans le cas d'un simple réseau LAN (RTT1 très supérieur à RTTLAN généralement constaté sur un réseau LAN ; par exemple, RTT1 est de l'ordre de plusieurs centaines de millisecondes et RTTLAN est simplement de l'ordre de plusieurs millisecondes), la condition suivante doit être vérifiée : Wnd * 2sFo Wnd * 2sFo+SFa max RTT 2+RTT 3 RTTi+RTT 2+RTT 3 (2) SFa max correspond à la valeur du facteur d'échelle de fenêtre de congestion à ajouter à la valeur du facteur d'échelle de fenêtre de congestion d'origine pour que le débit du cas d'un réseau utilisant un tunnel soit identique à celui du cas d'un simple réseau LAN. La valeur SFa max est une valeur entière.

Ainsi, la formule donnant la valeur SFa max s'écrit comme suit : RTT ~ (3) SFamax= logz +1 +1 RTT z+RTT 3 Comme indiqué précédemment, le protocole TCP, dans sa version actuelle,

impose une valeur maximale de facteur d'échelle de fenêtre de congestion de 14. Ainsi, quelle que soit la valeur SFa max calculée, la somme de la valeur du facteur d'échelle de fenêtre de congestion original SFo et la valeur SFa max calculée ne peut pas dépasser 14.

Ainsi, on détermine de manière dynamique une valeur de facteur d'échelle de fenêtre de congestion (SFa max) à ajouter à la valeur du facteur d'échelle de fenêtre de congestion d'origine, en fonction d'un rapport de temps d'aller retour.

Comme on le verra ci-après, si le protocole TCP est utilisé pour transporter le flux de données via le tunnel, alors les quantités de mémoire disponibles dans les zones de stockage temporaires 401, 402, 403 et 404 doivent être prises en compte pour

déterminer la valeur optimale du facteur d'échelle de fenêtre de congestion. En effet, pour le cas d'un tunnel avec une porteuse TCP, si l'on veut éviter tout risque d'engorgement au niveau des têtes de tunnel, il faut s'assurer que la taille des zones de stockage temporaires 402 et 404 est au moins égale à la nouvelle taille de fenêtre de réception maximum (soit Wnd*2^(SFo+SFa max)). En revanche, pour le cas d'un tunnel

avec une porteuse UDP, ces contraintes de quantité de mémoire disponible n'existent pas. Enfin, pour le cas d'un tunnel multi-porteuse (utilisant à la fois une porteuse TCP et une porteuse UDP), il faut prendre en compte, pour chaque session TCP passagère, la décision prise par le moteur de décision du tunnel quant à l'aiguillage sur une porteuse TCP ou UDP des paquets du flux TCP passager courant (détaillé ci-après en relation

avec la figure 6).

La figure 6 présente un organigramme d'un algorithme de gestion de transmission de données, selon un mode de réalisation particulier de l'invention. Cet algorithme est mis en oeuvre par une tête de tunnel telle que décrite ci-dessus en relation avec la figure 5.

Dans une première étape 600, la tête de tunnel intercepte un message provenant du sous-réseau LAN auquel est elle connectée ou du tunnel de communication, c'est-à-dire d'un sous-réseau LAN distant. La tête de tunnel détermine si le message intercepté est un message participant à l'établissement d'une session TCP. Pour ce faire, la tête de tunnel lit le bit SYN du message intercepté. Si le bit SYN est à 1, alors il s'agit d'un message participant à l'établissement d'une session TCP, c'est-à-dire un message de type TCP SYN(Req) ou de type TCP SYN ACK, et on passe à l'étape 601, sinon la tête de tunnel poursuit la transmission du message intercepté (étape 620). A l'étape 601, la tête de tunnel détermine la direction de transmission du message intercepté. A cette même étape 601, la tête de tunnel détecte un flux de données et détermine la direction de transmission de ce flux de données. La tête de tunnel peut déterminer la direction de transmission d'un flux de données de plusieurs façons. Par exemple, la tête de tunnel peut utiliser des informations relatives à la nature des différents équipements (serveur FTP, médiaplayer, etc.) du sous-réseau LAN auquel elle est connectée. De telles informations sont par exemple fournies par un utilisateur.

Dans un autre exemple, la tête de tunnel peut utiliser des informations générées par des mécanismes d'administration, comme par exemple selon le standard UPnP (pour « Universal Plug and Play). La détection des équipements audio-video selon le standard audio et vidéo UPnP AV (pour UPnP Audio and Video) est réalisée par exemple selon le principe d'annonce du protocole UPnP. En effet, le standard UPnP prévoit la transmission, à chaque équipement conforme au standard UPnP, d'une requête conforme au protocole SSDP (pour « Simple Service Discovery Protocol » qui est un protocole de découverte automatique du standard UPnP) qui vise à obtenir régulièrement des informations concernant les équipements UPnP présents localement dans un réseau. Il utilise le protocole UDP en diffusion (« broadcast » en anglais) sur le port 1900 pour la découverte automatique.

Un exemple d'un message de recherche d'un équipement serveur de media (« UPnP MediaServer » en anglais) peut présenter la structure suivante: M-SEARCH * HTTP/1.1 MX: 10 ST: urn: schemas-upnp-org : service:MediaS erver: 1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" Un exemple de réponse au message précédent, émis par un équipement serveur de media (« UPnP MediaServer »), peut présenter la structure suivante : NOTIFY * HTTP/1.1 NT: urn: schemas-upnp-org:device:MediaServer: 1 USN: uuid:63albdf9-dfef-4680-bb24-c809f4f4f239::urn:schemas-upnp- org:device:MediaServer: l NTS: ssdp:alive SERVER: Windows NT/5.0, UPnP/1.0, Intel CLR SDK/1.0 LOCATION: http://172.20.3.120:64648/ HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=1800 Content-Length: 0 L'accès au champ LOCATION fournit des indications sur l'adresse de cet équipement. Il existe d'autres types d'équipements audiovisuels selon le protocole UPnP AV qui sont par exemple identifiés par les nommages d'équipements (« MediaPlayer », « MediaRenderer », etc.). Dans un autre exemple, pour déterminer la direction de transmission du flux de 25 données, la tête de tunnel peut mettre en oeuvre un mécanisme permettant d'analyser les trames du flux à un niveau plus élevé que le niveau transport (typiquement, le niveau applicatif ou niveau 7 dans le modèle OSI en 7 couches). En particulier, on peut déterminer si une session FTP, ou http est en cours entre les deux équipements mis en jeux par le flux de données détecté à l'étape 601. Pour déterminer si une session FTP ou 30 http est en cours entre deux équipements, à chaque ouverture de session TCP entre deux équipements (un sur chaque LAN), une tête de tunnel peut par exemple considérer les 10 15 20 numéros de ports utilisés (typiquement 20, ou 21 pour FTP et 80 pour http), et stocker temporairement en mémoire le fait qu'une session FTP ou http est en cours entre deux équipements. A l'étape 602, la tête de tunnel compare la direction de transmission du flux de données avec celle du message intercepté. Si la direction de transmission du flux de données est identique à celle du message intercepté, alors il est inutile de modifier la valeur du facteur d'échelle de fenêtre de congestion puisque dans ce cas le flux de données va être reçu par l'équipement qui a émis le message d'établissement de session TCP. Le message est ensuite transmis vers le récepteur (étape 620) sans modification de la valeur du facteur d'échelle de fenêtre de congestion. En revanche, si la direction de transmission du flux de données est en sens inverse à celle du message intercepté, alors on passe à l'étape 603. A l'étape 603, la tête de tunnel obtient un facteur d'échelle de fenêtre de congestion original, noté « SFo », qui est contenu dans un champ « Scale factor compris dans le message intercepté. Dans le cas où ce champ « Scale factor » est absent de la trame, la valeur du facteur d'échelle de fenêtre de congestion original SFo est égale à « ». A l'étape 604, la tête de tunnel détermine si le message intercepté provient du sous-réseau LAN auquel elle est connectée ou du tunnel de communication, c'est-à-dire d'un sous-réseau LAN distant. Si le message intercepté provient du sous-réseau LAN auquel elle est connectée, alors la tête de tunnel effectue les étapes 605 à 607 décrites ci-après, sinon (c'est-à-dire si le message intercepté provient d'un sous-réseau LAN distant) la tête de tunnel effectue les étapes 608 et 609 décrites ci-après. Comme on le verra par la suite, à l'issue des étapes 605 à 607 la valeur du facteur d'échelle de fenêtre de congestion peut être augmentée, tandis que à l'issue des étapes 608 et 609 la valeur du facteur d'échelle de fenêtre de congestion peut être diminuée. A l'étape 605, la tête de tunnel détermine la valeur SFa max du facteur d'échelle de fenêtre de congestion à ajouter pour obtenir le débit de transmission souhaité, au moyen de la formule (3) présentée ci-dessus.

A l'étape 606, la tête de tunnel détermine une valeur SFbuff qui correspond au facteur d'échelle de fenêtre de congestion maximum que la tête de tunnel 101 peut supporter compte tenu de la capacité de stockage disponible de la mémoire tampon d'émission (c'est-à-dire la zone de stockage temporaire référencée 402 sur la figure 5) compris dans la tête de tunnel. Pour ce faire, à l'étape 606 la tête de tunnel détermine le mode de transport du flux de données à travers le tunnel de communication. Si simplement le protocole de transport UDP (ou plus généralement un protocole de transport sans acquittement ni retransmission des données) est utilisé, alors il n'y a pas lieu de tenir compte des ressources de stockage disponibles dans la mémoire tampon d'émission 402. En revanche, si simplement le protocole de transport TCP (ou plus généralement un protocole de transport avec acquittement et retransmission des données) est utilisé, alors l'espace de stockage disponible dans la mémoire tampon d'émission 402 doit être tel qu'il permet de stocker un nombre Buff=Wnd*2^(SFo+SFa max) de données, où « Wnd » est la taille de la fenêtre maximale contenue dans le message intercepté. Si l'espace de stockage disponible est suffisant pour stocker un nombre Buff de données, alors celui-ci est réservé et la valeur SFbuff est égale à la somme des valeurs SFo (obtenue à l'étape 603) et SFa max (obtenue à l'étape 605). En revanche, si l'espace de stockage disponible n'est pas suffisant, alors la valeur SFbuff est telle que : SFbuff = log2(Buff)-log2(Wnd)-SFo où Buff est la quantité de mémoire disponible dans la mémoire tampon d'émission 402 de la tête de tunnel. Dans le cas où cette valeur SFbuff est inférieure à 1, la valeur SFbuff prend la valeur « 1 ». Si plusieurs protocoles de transport (une partie sur UDP et une partie sur TCP ou plus généralement, une partie en utilisant un protocole de transport sans acquittement ni retransmission des données, tel que UDP, et le reste en utilisant un protocole de transport avec acquittement et retransmission des données, tel que TCP) sont utilisés, alors on prend en compte un ratio K qui représente le pourcentage du flux transmis en utilisant le protocole TCP (ou plus généralement, en utilisant un protocole de transport avec acquittement et retransmission des données). Dans ce cas, l'espace de stockage disponible dans la mémoire tampon d'émission 402 doit être tel qu'il permet de stocker un nombre Buff de données tel que : Buff=Wnd*2^(SFo+SFa max)*1/k. Si l'espace de stockage disponible est suffisant pour stocker un nombre Buff de données, alors celui-ci est réservé et la valeur SFbuff est égale à la somme des valeurs SFo et SFa max. En revanche, si l'espace de stockage disponible n'est pas suffisant, alors la valeur SFbuff est telle que : SFbuff = log2(Buff*k)-log2(Wnd)-SFo où Buff est la quantité de mémoire disponible dans la mémoire tampon d'émission 402 de la tête de tunnel. Dans le cas où cette valeur SFbuff est inférieure à 1, la valeur SFbuff prend la valeur « 1 ». A l'étape 607, la tête de tunnel détermine la valeur optimale du facteur d'échelle de fenêtre de congestion SF de fenêtre de congestion. Ainsi, à cette étape 607 la tête de tunnel compare la valeur (SFo+SFa max) et la valeur SFbuff déterminée à l'étape 606, et sélectionne parmi ces deux valeurs celle qui est la plus petite. Puis, on passe à l'étape 610. A l'étape 608 (cas où le message intercepté provient d'un sous-réseau LAN distant), la tête de tunnel détermine une valeur SFbuff qui correspond au facteur d'échelle de fenêtre de congestion maximum que la tête de tunnel 102 peut supporter compte tenu de la capacité de stockage de la mémoire tampon de réception (c'est-à-dire la zone de stockage temporaire référencée 404 sur la figure 5) compris dans la tête de tunnel du sous-réseau distant. Dans le présent cas, il est important de noter que la valeur du facteur d'échelle de fenêtre de congestion contenue dans le message intercepté a déjà pu être augmentée par l'autre tête de tunnel du sous-réseau distant. Il convient donc de ne pas l'augmenter à nouveau. En revanche, il peut être utile de la diminuer pour tenir compte de la mémoire 402 disponible pour la transmission de données sur la tête de tunnel 102. A cette étape 608 la tête de tunnel détermine le ou les protocole(s) de transport du flux de données utilisé(s) pour transmettre le flux de données via le tunnel de communication.

Si seulement le protocole de transport de type UDP (ou plus généralement un protocole de transport sans acquittement ni retransmission des données) est utilisé, alors il n'y a pas lieu de tenir compte des ressources de stockage disponibles dans la mémoire tampon de réception 404. En effet, le protocole UDP ne prévoit aucun mécanisme de contrôle de flux en cas de congestion. En revanche, si seulement le protocole de transport TCP (ou plus généralement un protocole de transport avec acquittement et retransmission des données) est utilisé, alors l'espace de stockage disponible dans la mémoire tampon de réception 404 doit être tel qu'il permet de stocker un nombre Buff de données, tel que : Buff=Wnd*(2^SFo) où « Wnd » est la taille de la fenêtre maximale contenue dans le message intercepté. Si l'espace de stockage disponible est suffisant pour stocker un nombre Buff de données, alors celui-ci est réservé et la valeur SFbuff est égale à la valeur SFo (obtenue à l'étape 603). En revanche, si l'espace de stockage disponible n'est pas suffisant, alors la valeur SFbuff est telle que : SFbuff = log2(Buff)-log2(Wnd) où Buff est la quantité de mémoire disponible dans la mémoire tampon de réception 404 de la tête de tunnel 102 du sous-réseau local distant. Dans le cas où cette valeur SFbuff est inférieure à 1, la valeur SFbuff prend la valeur « 1 ». Si plusieurs protocoles de transport (une partie sur UDP et une partie sur TCP ou plus généralement, une partie en utilisant un protocole de transport sans acquittement ni retransmission des données, tel que UDP, et le reste en utilisant un protocole de transport avec acquittement et retransmission des données, tel que TCP) sont utilisés, alors on prend en compte un ratio K qui représente le pourcentage du flux transmis en utilisant le protocole TCP (ou plus généralement, en utilisant un protocole de transport avec acquittement et retransmission des données). Dans ce cas, l'espace de stockage disponible dans la mémoire tampon de réception 404 doit être tel qu'il permet de stocker un nombre Buff de données, tel que : Buff=Wnd*(2^SFo)* 1/k Si l'espace de stockage disponible est suffisant pour stocker ce nombre Buff de données, alors celui-ci est réservé et la valeur SFbuff est égale à la valeur SFo. En revanche, si l'espace de stockage disponible n'est pas suffisant, alors la valeur SFbuff est telle que : SFbuff = log2(Buff*k)-log2(Wnd)-SFo où Buff est la quantité de mémoire disponible dans la mémoire tampon de réception 404 de la tête de tunnel. Dans le cas où cette valeur SFbuff est inférieure à 1, la valeur SFbuff prend la valeur « 1 ». A l'étape 609, la tête de tunnel détermine la valeur du facteur d'échelle de fenêtre de congestion SF à appliquer. Ainsi, à cette étape 609 la tête de tunnel compare la valeur SFo et la valeur SFbuff déterminée à l'étape 608, et sélectionne parmi ces deux valeurs celle qui est la plus petite. Puis, on passe à l'étape 610. A l'étape 610, la tête de tunnel modifie la valeur du facteur d'échelle de fenêtre de congestion contenue dans le message intercepté, c'est-à-dire remplace la valeur courante du facteur d'échelle de fenêtre de congestion avec celle sélectionnée à l'issue de l'étape 607 ou 609.

Selon un mode de réalisation particulier, si le message intercepté ne comprend pas de champ « Scale factor » (dans les options TCP), celui-ci est ajouté. Le champ « Scale factor » ajouté contient la valeur de facteur d'échelle de fenêtre de congestion sélectionnée à l'issue de l'étape 607 ou 609. Puis, la tête de tunnel corrige le code CRC (pour « Cyclic Redundancy Code ») du message intercepté, avant transmission. Enfin, à l'étape 620, la tête de tunnel poursuit la transmission du message intercepté. La figure 7 illustre une configuration schématique d'un dispositif de communication générique 1000 adapté pour mettre en oeuvre un mode de réalisation particulier du procédé de l'invention. Par exemple, la première tête de tunnel 101 ou la seconde tête de tunnel 102 précitée en relation avec la figure 1, est identique au dispositif générique 1000. Ce dispositif générique 1000 peut notamment être connecté à tout moyen de stockage d'images, de vidéos, ou de sons reliés à une carte graphique et délivrant au dispositif générique 1000 des données multimédia.

Le dispositif générique 1000 comporte un bus de communication 1002 auquel sont reliés : - une unité centrale de traitement 1003 (qui est par exemple un microprocesseur référencé CPU) ; - une mémoire morte 1004 référencée ROM, pouvant comporter un ou des programme(s) selon l'invention ; - une mémoire vive 1006 (mémoire cache référencée RAM), comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution du ou des programme(s) précité(s) ; - une interface de communication 1018 reliée à au moins deux sous-réseaux de communication 1020, par exemple le premier sous-réseau LAN 103 ou le second sous-réseau LAN 104, l'interface étant apte à transmettre et à recevoir des données avec ces sous-réseaux. Le dispositif générique 1000 comprend également (mais ceci est optionnel) : - un écran 1008 permettant de visualiser des données et/ou servir d'interface graphique avec l'administrateur réseau qui pourra interagir avec le ou les programmes selon l'invention, à l'aide d'un clavier 1010 ou tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 1011 ou un crayon optique, - un disque dur 1012 pouvant comporter le ou les programme(s) précité(s) ; - un lecteur de disque externe 1014, permettant par exemple de lire une clé USB 1016. Le bus de communication 1002 permet la communication et l'interopérabilité entre les différents moyens inclus dans le dispositif générique 1000 ou reliés à ce dispositif. De manière plus générale, grâce au bus de communication 1002, l'unité centrale 1003 est susceptible de communiquer des instructions à tout moyen inclus dans le dispositif générique 1000, directement ou par l'intermédiaire d'un autre moyen inclus dans le dispositif générique. Le code exécutable de chaque programme précité permettant au dispositif générique 1000 de mettre en oeuvre un mode de réalisation particulier de l'invention, peut être stocké dans une mémoire non volatile, par exemple le disque dur 1012, la mémoire morte 1004 ou la clé USB 1016. L'unité centrale 1003 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programme(s) selon un mode de réalisation particulier de l'invention. Lors de la mise sous tension, le ou les programmes qui sont stockés dans la mémoire non volatile précitée (1012, 1004 ou 1016) sont transférés dans la mémoire vive 1006 qui contiendra alors le code exécutable du ou des programme(s) selon un mode de réalisation de l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de ce mode de réalisation particulier du procédé selon l'invention. Il convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques, par exemple figé dans un circuit intégré à application spécifique (ASIC).

On notera que l'invention ne se limite pas à une implantation purement matérielle mais qu'elle peut aussi être mise en oeuvre sous la forme d'une séquence d'instructions d'un programme informatique ou toute forme mixant une partie matérielle et une partie logicielle. Dans le cas où l'invention est implantée partiellement ou totalement sous forme logicielle, la séquence d'instructions correspondante pourra être stockée dans un moyen de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce moyen de stockage étant lisible partiellement ou totalement par un ordinateur ou un microprocesseur.

Claims (10)

1. REVENDICATIONS1. Procédé de gestion de transmission de données sur un lien de communication entre un premier dispositif d'interconnexion recevant lesdites données d'un premier sous-réseau (103) via une interface d'entrée et un second dispositif d'interconnexion (102) fournissant lesdites données à un second sous-réseau (104) via une interface de sortie, le procédé étant caractérisé en ce qu'un dispositif d'interconnexion donné parmi lesdits premier et second dispositifs d'interconnexion effectue des étapes consistant à : - intercepter (600) un message d'établissement d'une session de communication pour lesdites données entre un premier dispositif de communication du premier sous-réseau et un second dispositif de communication du second sous-réseau via ledit lien de communication ; - obtenir (605, 606) une première valeur de temps d'aller retour desdites données entre une interface d'entrée du premier dispositif d'interconnexion et une interface de sortie du second dispositif d'interconnexion ; - ajuster (607, 610) une valeur de facteur multiplicatif de fenêtre de congestion contenue dans ledit message intercepté, en fonction de la première valeur de temps obtenue ; - poursuivre la transmission (620) du message intercepté avec la valeur ajustée.
2. 2. Procédé selon la revendication 1, caractérisé en ce que le dispositif d'interconnexion donné effectue une étape consistant à obtenir (605) une deuxième valeur de temps d'aller retour (RTT2, RTT3) desdites données entre le premier dispositif de communication, second dispositif de communication respectivement, et le premier 25 dispositif d'interconnexion, second dispositif d'interconnexion respectivement, et en ce que l'étape consistant à ajuster la valeur du facteur multiplicatif s'effectue en fonction d'un rapport entre la première valeur de temps obtenue et ladite deuxième valeur de temps obtenue.
3. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que 30 le dispositif d'interconnexion donné effectue des étapes consistant à : - déterminer (601) une direction de transmission dudit message intercepté ; 15 20- déterminer une direction de transmission desdites données ; - comparer (602) la direction de transmission des données et la direction de transmission du message intercepté ; et en ce que la valeur de facteur multiplicatif de fenêtre de congestion contenue dans ledit message intercepté est ajustée si la direction de transmission des données et la direction de transmission du message intercepté sont différentes.
4. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que le dispositif d'interconnexion donné effectue une étape consistant à détecter (604) que le message intercepté provient du sous-réseau auquel est connecté le dispositif d'interconnexion donné, et en ce que, si le message intercepté provient du sous-réseau auquel est connecté le dispositif d'interconnexion donné, le dispositif d'interconnexion donné effectue des étapes consistant à : - déterminer (606) au moins un protocole de transport des données utilisé sur le lien de communication pour transmettre lesdites données ; - dans le cas où le protocole de transport déterminé est un protocole de transport avec acquittement des données, déterminer (606) une valeur maximale (SFbuff) de facteur multiplicatif de fenêtre de congestion, en fonction d'une capacité de stockage de données (402) dudit premier dispositif d'interconnexion destinée à stocker lesdites données avant transmission sur le lien de communication ; - comparer (607) la valeur ajustée et la valeur maximale ; - dans le cas où la valeur ajustée est supérieure à la valeur maximale, poursuivre (620) la transmission du message intercepté avec la valeur maximale, sinon poursuivre (620) la transmission du message intercepté avec la valeur ajustée.
5. 5. Procédé selon la revendication 4, caractérisé en ce que le dispositif d'interconnexion donné effectue des étapes consistant à, dans le cas où plusieurs protocoles de transport ont été déterminés dont au moins un est un protocole de transport avec acquittement des données et au moins un est un protocole de transport sans acquittement des données : - obtenir un ratio (K) entre une quantité de données transmis en utilisant le(s) protocole(s) de transport avec acquittement des données et une quantité dedonnées transmis en utilisant le(s) protocole(s) de transport sans acquittement des données ; - déterminer ladite valeur maximale (SFbuff) de facteur multiplicatif de fenêtre de congestion, en fonction en outre dudit ratio obtenu.
6. 6. Procédé selon l'une quelconque des revendications 4 et 5, caractérisé en ce que, si le message intercepté ne provient pas du sous-réseau auquel est connecté le dispositif d'interconnexion donné, le dispositif d'interconnexion donné effectue des étapes consistant à : - obtenir (603) une valeur initiale (SFo) de facteur multiplicatif de fenêtre de congestion ; - déterminer (608) une valeur maximale (SFbuff) de facteur multiplicatif de fenêtre de congestion, en fonction d'une capacité de stockage de données (404) dudit second dispositif d'interconnexion destinée à stocker lesdites données avant transmission sur le sous-réseau auquel est connecté ledit dispositif d'interconnexion donné ; - comparer (609) la valeur initiale obtenue et la valeur maximale ; - dans le cas où la valeur initiale obtenue est supérieure à la valeur maximale, poursuivre (620) la transmission du message intercepté avec la valeur maximale, sinon poursuivre (620) la transmission du message intercepté avec la valeur initiale obtenue.
7. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que le lien de communication est un tunnel, et chaque dispositif d'interconnexion est une tête de tunnel.
8. 8. Produit programme d'ordinateur, caractérisé en ce qu'il comprend des 25 instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 7, lorsque ledit programme est exécuté sur un ordinateur.
9. 9. Moyen de stockage lisible par ordinateur, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé selon au moins une des revendications 1 à 7. 30
10. 10. Dispositif de gestion de transmission de données sur un lien de communication entre un premier dispositif d'interconnexion recevant lesdites données d'un premier 15 20sous-réseau (103) via une interface d'entrée et un second dispositif d'interconnexion (102) fournissant lesdites données à un second sous-réseau (104) via une interface de sortie, le dispositif de gestion étant compris dans un dispositif d'interconnexion donné parmi lesdits premier et second dispositifs d'interconnexion, le dispositif de gestion étant caractérisé en ce qu'il comprend : - des moyens d'interception d'un message d'établissement d'une session de communication pour lesdites données entre un premier dispositif de communication du premier sous-réseau et un second dispositif de communication du second sous-réseau via ledit lien de communication ; - des moyens d'obtention d'une première valeur de temps d'aller retour desdites données entre une interface d'entrée du premier dispositif d'interconnexion et une interface de sortie du second dispositif d'interconnexion ; - des moyens d'ajustement d'une valeur de facteur multiplicatif de fenêtre de congestion contenue dans ledit message intercepté par lesdits moyens d'interception, en fonction de la première valeur de temps obtenue par lesdits moyens d'obtention ; - des moyens de poursuite de la transmission du message intercepté avec la valeur ajustée.