FR2935576A1 - Procede de gestion d'une transmission de flux de donnees sur un tunnel multi-canal, tete de tunnel, produit programme d'ordinateur et moyen de stockage correspondants. - Google Patents

Abstract

Il est proposé un procédé de gestion d'une transmission hybride d'un flux de données sur un tunnel multi-canal, le tunnel étant mis en oeuvre entre des première et seconde têtes de tunnel connectées respectivement à des premier et second sous-réseaux, chaque flux étant transmis depuis un dispositif émetteur vers un dispositif récepteur, une transmission hybride sur un tunnel multi-canal étant une transmission utilisant au moins deux canaux dont au moins un canal implémente un mécanisme d'acquittement et de retransmission. Le procédé est effectué par la première tête de tunnel et comprend des étapes consistant à : - détecter (30) que le flux est un flux à risque, un flux à risque étant un flux subissant une transmission hybride sur le tunnel, et pour laquelle au moins un canal se trouve dans un état de retransmission ; - sur réception (10), pour le flux, d'au moins un acquittement comprenant une indication qu'une donnée n'a pas encore été reçue par le dispositif récepteur, envoyer le(les) acquittement(s) vers le dispositif émetteur, l'envoi d'au moins un acquittement étant retardé (40) d'un délai déterminé compté à partir d'un instant auquel l'acquittement retardé a été reçu par la première tête de tunnel.

Description

Procédé de gestion d'une transmission de flux de données sur un tunnel multi-canal, tête de tunnel, 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 multi-canal supporté par un réseau de communication principal. La démocratisation d'Internet haut débit d'une part et l'apparition d'équipements audiovisuels grand public ayant une connectivité réseau d'autre part vont créer de nouveaux comportements des utilisateurs. Parmi ces nouveaux comportements, il fait peu de doute que nous verrons apparaître des individus appartenant à des groupes de personnes ayants des domaines d'intérêts communs (loisirs, famille...) que nous pourrions appeler en liaison permanente . Ceux-ci établiront des connections quasi permanentes avec les autres individus d'un même domaine d'intérêt en établissement des communications audio et/ou vidéo et partageant des informations de tout type (audio, vidéo, photo, texte ...). La technologie des Réseaux Privés Virtuels (RPV, ou VPN pour Virtual Private Network en anglais) offre une solution intéressante pour répondre à cette attente. En effet, elle permet de communiquer de manière transparente, en temps réel 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. 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). La tunnellisation peut être utilisée pour transporter un protocole réseau sur un réseau qui ne le supporte pas. Elle peut aussi être utilisée pour fournir différents types de fonctionnalités RPV, comme par exemple l'adressage privé. Les techniques de tunnel sont aujourd'hui de plus en plus utilisées par des fonctionnalités client d'accès à distance, et des interconnexions de réseaux locaux domestiques (appelés ci-après réseaux LAN, pour Local Area Network en anglais). Dans la suite de la description, on considère, à titre d'exemple uniquement, les tunnels de niveau 2 ou 3, pour lesquels le niveau du protocole de transport B dans le modèle OSI est égal à celui de la couche de transport (couche de niveau 4 dans le modèle OSI). Il est bien entendu que le cadre de la présente invention n'est nullement limitatif, et que le niveau du protocole de transport B dans le modèle OSI peut être inférieur (cas d'un tunnel avec porteuse Ethernet) ou supérieur (cas d'un tunnel avec porteuse HTTP). Les techniques de tunnellisation sont fréquemment utilisées pour interconnecter deux réseaux LAN afin de créer un réseau privé virtuel (ou RPV) composé de l'union des deux réseaux LAN originaux. Les RPVs sécurisés incluent un algorithme de cryptographie et d'authentification pour garantir le secret des données transportées. 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). Dans cet exemple, les têtes de tunnel (TEP, pour Tunnel End Point en anglais) ne sont pas intégrées aux passerelles. Le tunnel est établi entre deux têtes de tunnel, et chaque paquet (aussi appelé trame) envoyé à un équipement connecté au réseau LAN distant est encapsulé par la tête de tunnel connectée au réseau LAN local, puis envoyé via le tunnel à la tête de tunnel (distante) connectée au réseau LAN distant, qui va la dés-encapsuler et l'envoyer sur le réseau LAN distant. Du point de vue des équipements des réseaux LAN interconnectés par un tunnel, ils sont virtuellement connectés à un même 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 réseaux LAN connectés.

De nos jours, on voit émerger des RPVs disposant de techniques de connexions multiples, c'est-à-dire un tunnel formé de plusieurs porteuses ou canaux. Cette technique permet de choisir un premier protocole de transport, par exemple pour les données de contrôle, et un second protocole de transport, par exemple pour les données utiles, les deux types de données passant dans la même tête de tunnel. Il existe de multiples autres possibilités quant au choix du protocole de transport pour les flux applicatifs passagers (par exemple en fonction des priorités des flux passagers, etc). On parle alors de canal virtuel d'un tunnel qui est formé de multiples canaux physiques ayant des protocoles de transport propres, sachant que seule la tête de tunnel a connaissance de ces canaux physiques. Le choix du protocole de transport peut donc être optimisé sur chacun des deux canaux. Dans la suite, on désigne ce type de tunnel sous le terme de tunnel multicanal. Dans l'état de la technique, on utilise principalement le protocole IP ( Internet Protocol en anglais) (couche 3) ou les protocoles TCP ( Transmission Control Protocol en anglais) / UDP ( User Datagram Protocol en anglais) (couche 4). Les technologies de tunnellisation basées sur IP ne pouvant pas prendre en compte de mécanisme de traduction d'adresse réseau (NAT, pour Network Address Translation en anglais), et n'étant pas entièrement compatibles avec la configuration de tunnellisation typique de la figure 1, on considère (à titre d'exemple uniquement) dans la suite de la description des solutions basées sur la couche 4 (couche de transport), c'est-à-dire sur le protocole TCP ou UDP. Tel qu'expliqué dans l'Annexe, qui présente les principes de fonctionnement du protocole TCP, le protocole TCP (défini par la norme RFC793 de l'IETF) 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. Comme précisé précédemment, le protocole TCP a été conçu pour être flexible et fonctionner dans une large variété d'environnements de communication réseau, incluant des liens lents et rapides, avec une latence élevée ou des liens avec des taux d'erreurs variables. Bien que le protocole TCP fonctionne pour différents environnements, ces performances sont affectées par les caractéristiques de chaque lien de communication utilisé. Les performances du protocole TCP en termes de consommation de bande passante souffrent dans des environnements avec des délais d'acheminement longs et/ou possédant un taux d'erreur élevé. Un concept de mandataire avancé (ou PEP, pour Proxy Enhanced Protocol en anglais), basé sur la norme RFC 3135, peut être utilisé pour améliorer les performances des infrastructures de communication. La norme RFC 3135 décrit différents types de mécanismes d'amélioration de transmission de flux de données (aussi appelés mécanismes PEP par la suite), embarqués dans des équipements réseau sur le chemin d'acheminement d'un flux TCP entre un serveur et un client. Les mécanismes PEP tels que décrits dans la norme RFC 3135 sont particularisés pour chaque environnement afin d'agir sur le contrôle de congestion de flux TCP en conséquence. Dans le cas de l'Internet, les connexions normalement sont de type best effort , c'est-à-dire que ces connexions font tout ce qui est possible pour acheminer les informations jusqu'à leur destination, mais sans garantir un certain niveau de qualité de service (QoS, pour Quality of Service en anglais). Ainsi, dans le cadre de communication RPV, la couche de transport du tunnel est soumise à de fortes fluctuations des capacités de transmission.

Les flux TCP passagers de ce tunnel implémentent classiquement un contrôle de congestion de bout-en-bout, c'est-à-dire que les deux dispositifs en communication coopèrent dans la détermination du débit auquel doivent être envoyées les données du dispositif serveur (aussi appelé par la suite dispositif émetteur) vers le dispositif client (aussi appelé par la suite dispositif récepteur). Cependant, le dispositif émetteur ne dispose pas des informations relatives aux conditions de transport du flux sur le tunnel, celui-ci étant transparent du point de vue des dispositifs émetteur et récepteur. Les informations obtenues grâce au contrôle de congestion de bout-en-bout mis en place avec le dispositif récepteur peuvent alors conduire à des décisions, prises par le dispositif émetteur, inadaptées aux conditions de transport sur le tunnel et résulter dans un accroissement de consommation de bande passante par des retransmissions inutiles ou une sous-exploitation de la bande passante disponible.

Des mécanismes PEP peuvent être mis en place afin d'influencer le contrôle de congestion des flux TCP passagers du tunnel en correspondance avec les limitations intrinsèques de ce tunnel à un instant donné. 2. ARRIÈRE-PLAN TECHNOLOGIQUE 2.1 Description du problème L'utilisation d'un tunnel multi-canal modifie les hypothèses sur lesquelles a été conçu le protocole TCP. En particulier, lorsqu'un flux TCP traverse un tunnel multicanal, il ne connaît pas la façon dont le tunnel va transmettre ses trames. Lorsque la tête de tunnel décide d'utiliser plusieurs canaux simultanément pour transmettre les trames d'un flux, il peut en résulter un fort désordonnancement des trames à la réception. Prenons le cas d'un flux TCP entre deux équipements (110 et 112) transmis par un tunnel multi-canal 100 en utilisant un canal A implémentant des mécanismes de retransmission (comme TCP), et un canal B sans mécanismes de retransmission (comme UDP). Une telle transmission est appelée transmission hybride dans la suite de la description. Un flux transmis selon un tel procédé est alors appelé flux hybride dans la suite de la description. Dans le cas d'une transmission hybride, si une retransmission survient sur le canal A, toutes les trames en transit dans ce canal se trouvent bloquées en attente de réception de la trame retransmise. Pendant ce temps, les trames émises sur le canal B elles, ne subissent pas de ralentissement, et vont donc arriver avant les trames bloquées dans le canal A. Vu de l'équipement d'arrivée 112, cela va se traduire par un désordonnancement des trames du flux hybride. Par exemple, si sur dix trames numérotées de 1 à 10 émises par un équipement 110, les trames paires sont envoyées via le canal A et les trames impaires envoyées via le canal B (critère arbitraire à titre d'exemple), si la trame 4 est retransmise sur le canal A, l'ordre d'arrivée sur l'équipement terminal 112 peut être : 1,2,3,5,7,9,4,6,8,10. Dans ce cas, l'arrivée des trames 5, 7 et 9 va déclencher de la part de l'équipement 112 l'envoi de trois acquittements dupliqués (aussi appelés Dup Acks pour Duplicate Acknowledgements en anglais ; voir annexe) indiquant l'attente du paquet 4.

A la réception de ces trois acquittements dupliqués ( de flux passager ), l'équipement 110 va retransmettre la trame 4, ce qui est inutile. En effet, la trame 4 n'a pas été perdue, mais a été retardée par rapport à certaines trames suivantes, et est reçue par le dispositif récepteur postérieurement aux trames 5, 7 et 9. Une telle retransmission a aussi pour conséquence, côté dispositif émetteur (serveur), une réduction de la fenêtre d'émission associée à ce flux. En conséquence, le débit du flux tel qu'émis par l'équipement 110 diminue. Le problème est donc de trouver un moyen d'éviter ou limiter les retransmissions inutiles d'un flux donné subissant un désordonnancement de trames, lorsqu'au moins deux canaux d'un tunnel de communication sont utilisés pour le transport du flux (dit flux passager) d'un premier à un second sous-réseau. 2.2 Etat de la technique Il existe différents principes d'amélioration des performances TCP dans un environnement instable (tels que les communications sur l'Internet ou par liaisons sans- fil), selon la catégorie de protocole utilisé : des protocoles bout-en-bout ( end-to-end protocole en anglais), pour lesquels les dispositifs intermédiaires sur le chemin de transmission entre le dispositif émetteur et le dispositif récepteur sont transparents, et des protocoles à connexion séparée ( split-connection protocols en anglais), pour lesquels la connexion entre le dispositif émetteur et le dispositif récepteur est une succession de connexions sur le chemin de transmission entre le dispositif émetteur et le dispositif récepteur. Les dispositifs intermédiaires (d'infrastructure) ne sont alors plus transparents. Cette deuxième catégorie ne peut pas être considérée pour notre problème car ces protocoles cassent le principe intrinsèque à la tunnellisation qui a pour objectif de rendre transparente la présence du tunnel pour les équipements des sous-réseaux que le tunnel relie, afin que ceux-ci ne soient perçus que comme un unique réseau (par exemple de type Ethernet). La plupart des solutions d'amélioration des performances de transmission d'un flux de données selon un protocole par acquittement, tel que le protocole TCP, reposent sur l'adjonction d'un agent spécialisé de type PEP (ou Performance Enhanced Proxy ) sur l'équipement d'infrastructure séparant les réseaux de types hétérogènes (typiquement des têtes de tunnel pour des réseaux de communication étendus (ou WAN, pour Wide Area Network en anglais) ou des stations de base pour des réseaux sans-fil). Le document de brevet US2005/0180327 (IBM) décrit une technique visant à réduire les effets du mécanisme de retransmission rapide ( Fast Retransmit en anglais), c'est-à-dire la retransmission d'une trame suite à la réception de trois acquittements dupliqués ( Dup Acks ) résultant d'un désordonnancement persistant sur l'Internet. Le principe proposé est de modifier le comportement de la pile TCP de l'équipement récepteur. Lors de la détection d'un désordonnancement, l'envoi d'un acquittement dupliqué ( Dup Ack ) par l'équipement récepteur est retardé d'une durée prédéterminée, et si la donnée attendue arrive dans l'intervalle, aucun acquittement dupliqué n'est envoyé. Cette technique connue n'est cependant pas optimale. Un premier inconvénient de cette technique connue est que la prise en compte du désordonnancement ne se fait qu'après constatation (détection) d'un désordonnancement. En effet, l'équipement récepteur agit dans un premier temps normalement : il envoie des acquittements dupliqués ( Dup Acks ) non retardés à chaque fois qu'il reçoit une donnée mais qu'elle ne correspond pas à celle attendue. Puis, après avoir envoyé trois acquittements dupliqués (ce qui provoque une retransmission de la donnée par l'équipement émetteur), il reçoit la donnée en double, ce qui lui prouve qu'elle n'avait pas été perdue, mais qu'il s'agissait uniquement d'un désordonnancement. L'équipement émetteur a donc retransmis inutilement la donnée. C'est seulement après avoir constaté ce désordonnancement qu'il démarre le mécanisme de retard. Un second inconvénient de cette technique connue est que tous les acquittements dupliqués ( Dup Acks ) sont retardés d'une valeur fixe et prédéterminée. Il conviendrait d'optimiser le retard appliqué à chaque acquittement dupliqué. Un troisième inconvénient de cette technique connue est qu'elle n'est pas transparente pour l'équipement récepteur puisqu'elle est implémentée sur celui-ci, et non pas sur un équipement du chemin réseau (comme une tête de tunnel). 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 d'une transmission de flux de données sur un tunnel multi-canal, permettant de prendre en compte les caractéristiques du tunnel multi-canal et en particulier d'anticiper sur des problèmes de désordonnancement particulièrement importants lors de l'utilisation d'un tunnel multi-canal, et donc éviter toute retransmission inutile de donnée par le dispositif émetteur. Dans au moins un mode de réalisation de l'invention, un objectif est d'éviter une retransmission inutile d'une donnée par un dispositif émetteur, dans le cas où une succession d'acquittements dupliqués ( Dup Acks ) ne serait que la conséquence d'une retransmission sur un canal fiable d'un tunnel. Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique qui soit transparente pour les dispositifs émetteurs et les dispositifs récepteurs des flux empruntant le tunnel multi-canal, et ne nécessitant pas par exemple de modification de la mise en oeuvre des protocoles de communication (tels que les piles TCP/IP) par ces dispositifs. 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.

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 et peu coûteuse. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion d'une transmission hybride d'un flux de données sur un tunnel multi-canal, ledit tunnel étant mis en oeuvre entre des première et seconde têtes de tunnel connectées respectivement à des premier et second sous-réseaux, chaque flux étant transmis depuis un dispositif émetteur vers un dispositif récepteur, une transmission hybride sur un tunnel multi-canal étant une transmission utilisant au moins deux canaux dont au moins un canal implémente un mécanisme d'acquittement et de retransmission, ledit procédé étant effectué par ladite première tête de tunnel et étant caractérisé en ce qu'il comprend des étapes consistant à : - détecter que ledit flux est un flux à risque, un flux à risque étant un flux subissant une transmission hybride sur le tunnel, et pour laquelle au moins un canal se trouve dans un état de retransmission ; - sur réception, pour ledit flux, d'au moins un acquittement comprenant une indication qu'une donnée n'a pas encore été reçue par le dispositif récepteur, envoyer le(les) acquittement(s) vers le dispositif émetteur, l'envoi d'au moins un acquittement étant retardé d'un délai déterminé compté à partir d'un instant auquel l'acquittement retardé a été reçu par la première tête de tunnel. Ainsi, dans ce mode de réalisation particulier, l'invention repose sur une approche tout à fait nouvelle et inventive consistant à appliquer, par anticipation (puisqu'on détermine que la situation dans laquelle se trouve le tunnel multi-canal va générer un désordonnancement sur un flux), des mécanismes de retardement de transmission vers le dispositif émetteur d' acquittement(s) de flux en provenance du dispositif récepteur. La détermination d'un flux à risque de désordonnancement permet d'éviter les retransmissions inutiles, y compris la première. Pour mémoire, dans la technique connue précitée (document de brevet US2005/0180327), la première retransmission inutile n'est pas évitée puisque c'est elle qui déclenche la mise en place des mécanismes de retardement d'acquittement. La technique de l'invention étant mise en oeuvre dans la première tête de tunnel, elle est transparente pour les dispositifs émetteurs et les dispositifs récepteurs des flux empruntant le tunnel multi-canal. En outre, elle est simple à mettre en oeuvre, peu coûteuse et ne nécessite pas d'importantes ressources mémoires. De façon avantageuse, le procédé comprend une étape consistant à compter un nombre d'acquittements reçus comprenant une indication qu'une même donnée n'a pas encore été reçue par le dispositif récepteur. En outre, l'envoi d'au moins un acquittement est retardé lorsque ledit nombre d'acquittements est supérieur ou égal à un premier seuil représentatif d'une perte de donnée entre ledit dispositif émetteur et ledit dispositif récepteur.

Le premier seuil est par exemple égal à trois (cas du protocole TCP, qui prévoit que trois acquittements dupliqués ( Dup Acks ) indiquent une perte de trame et provoquent une retransmission par le dispositif émetteur). Dans ce cas, seul le troisième acquittement dupliqué de flux est retardé. Pour mémoire, dans la technique connue précitée (document de brevet US2005/0180327), les trois premiers acquittements dupliqués sont transmis sans être retardés (ce qui provoque une retransmission de la donnée par le dispositif émetteur), puis tous les acquittements dupliqués ( Dup Acks ) sont retardés d'une valeur fixe et prédéterminée. Avantageusement, ledit délai est déterminé en fonction d'une estimation d'une durée d'attente avant retransmission d'une donnée, ladite durée étant fonction du dispositif émettant ladite donnée et du flux auquel ladite donnée appartient.

Ainsi, l'utilisation d'un délai variable en fonction d'une estimation d'une durée d'attente avant retransmission d'une donnée (durée d'attente qui est associée au dispositif émetteur et dont l'estimation est notée RTOe), permet à l'invention de fonctionner, quels que soient les réseaux que traverse ce tunnel (adaptabilité à la latence variable d'un réseau à l'autre). En particulier, l'invention va automatiquement s'adapter à la durée d'aller-retour (RTT) entre le dispositif émetteur et le dispositif récepteur. La prise en compte de cette durée permet d'éviter que le retardement des acquittements dupliqués ( Dup Ack ) ne débouche sur une expiration de la temporisation de retransmission du dispositif émetteur, ce qui serait pire qu'une retransmission de type fast retransmit . En effet, dans le cas d'une retransmission pour cause d'expiration de temporisation, la fenêtre de congestion ( congestion window en terminologie anglaise adaptée à TCP) est ramenée à 1 au lieu d'être simplement divisée par 2. Avantageusement, ledit délai est en outre déterminé en fonction d'un instant de passag dans la première tête de tunnel de la donnée indiquée, dans l'acquittement, comme étant non reçue. Ainsi, grâce à l'information d'instant de passage d'une donnée dans la tête de tunnel et à destination du tunnel, il est possible de déterminer avec précision, à l'arrivée de l'acquittement de cette donnée en provenance du tunnel, le temps d'aller-retour de cette donnée entre la première tête de tunnel et le dispositif récepteur. Cette valeur permet alors une estimation du temps réel aller-retour de la donnée entre le dispositif émetteur et le dispositif récepteur.

De façon avantageuse, le délai déterminé, noté Re, est défini par : Re = RTOt1RRe, - (T - T0) - Ô, où : - RTOtunnel est ladite estimation d'une durée d'attente avant retransmission d'une donnée, pour ledit flux, cette estimation correspondant à une durée d'attente avant retransmission d'une donnée sur le tunnel ; - TO est ledit instant de passage dans la première tête de tunnel ; - T est ledit instant auquel l'acquittement retardé a été reçu par la première tête de tunnel ; - Ô est une marge sécuritaire prédéterminée. Ainsi, la durée du retard appliqué est particularisée en fonction du dispositif émetteur. En effet, ce retard dépend des caractéristiques du flux concerné ainsi que son activité dans le tunnel. Avantageusement, l'étape consistant à détecter que ledit flux est un flux à risque comprend une étape consistant à détecter que l'un des canaux de la transmission hybride 15 dudit flux se trouve dans un état de retransmission, du fait : - de l'expiration 'une durée prédéterminée d'attente avant retransmission d'une donnée par ladite première tête de tunnel sur ledit canal ; ou - de la réception, sur ledit canal, d'un nombre d'acquittements comprenant une indication qu'une même donnée n'a pas encore été reçue par ladite seconde tête 20 de tunnel, ledit nombre étant supérieur ou égal à un second seuil représentatif d'une perte de donnée entre ladite première tête de tunnel et ladite seconde tête de tunnel. Ainsi, on prend en compte deux causes de retransmission pour les canaux du tunnel, qui sont par exemple prises en compte par le protocole TCP. 25 De façon avantageuse, le procédé comprend une étape consistant à supprimer l'acquittement retardé avant l'expiration dudit délai déterminé, en cas de réception d'un acquittement comprenant une indication qu'une donnée a été reçue par le dispositif récepteur, ladite donnée correspondant à la donnée indiquée comme étant non reçue dans l'acquittement retardé. 10 30 Ainsi, on évite l'envoi vers le dispositif émetteur d'un acquittement de flux qui aurait eu pour conséquence une retransmission de trame par le dispositif émetteur. 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, éventuellement totalement ou partiellement amovible, 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 mode de réalisation particulier de l'invention, il est proposé une première tête de tunnel permettant la gestion d'une transmission hybride d'un flux de données sur un tunnel multi-canal, ledit tunnel étant mis en oeuvre entre ladite première tête de tunnel et une seconde tête de tunnel connectées respectivement à des premier et second sous-réseaux, chaque flux étant transmis depuis un dispositif émetteur vers un dispositif récepteur, une transmission hybride sur un tunnel multi-canal étant une transmission utilisant au moins deux canaux dont au moins un canal implémente un mécanisme d'acquittement et de retransmission. Ladite première tête de tunnel comprend : - des moyens de détection, permettant de détecter que ledit flux est un flux à risque, un flux à risque étant un flux subissant une transmission hybride sur le tunnel, et pour laquelle au moins un canal se trouve dans un état de retransmission ; - des moyens d'envoi, permettant, sur réception, pour ledit flux, d'au moins un acquittement comprenant une indication qu'une donnée n'a pas encore été reçue par le dispositif récepteur, d'envoyer le(les) acquittement(s) vers le dispositif émetteur, l'envoi d'au moins un acquittement étant retardé d'un délai déterminé 30 compté à partir d'un instant auquel l'acquittement retardé a été reçu par la première tête de tunnel. De façon avantageuse, la première tête de tunnel comprend des moyens de comptage, permettant de compter un nombre d'acquittements reçus comprenant une indication qu'une même donnée n'a pas encore été reçue par le dispositif récepteur. En outre, lesdits des moyens d'envoi permettent de retardé l'envoi d'au moins un acquittement lorsque ledit nombre d'acquittements est supérieur ou égal à un premier seuil représentatif d'une perte de donnée entre ledit dispositif émetteur et ledit dispositif récepteur.

Avantageusement, ledit délai est déterminé en fonction d'une estimation d'une durée d'attente avant retransmission d'une donnée, ladite durée étant fonction du dispositif émettant ladite donnée et du flux auquel ladite donnée appartient. Avantageusement, ledit délai est en outre déterminé en fonction d'un instant de passage dans la première tête de tunnel de la donnée indiquée, dans l'acquittement, comme étant non reçue. De façon avantageuse, le délai déterminé, noté Re, est défini par : Re = RTOt1RRe, - (T - TO) - Ô, où : - RTOtunnel est ladite estimation d'une durée d'attente avant retransmission d'une donnée, pour ledit flux, cette estimation correspondant à une durée d'attente avant retransmission d'une donnée sur le tunnel ; - TO est ledit instant de passage dans la première tête de tunnel ; - T est ledit instant auquel l'acquittement retardé a été reçu par la première tête de tunnel ; - Ô est une marge sécuritaire prédéterminée.

Avantageusement, lesdits moyens de détection, permettant de détecter que ledit flux est un flux à risque, comprennent des moyens de détection, permettant de détecter que l'un des canaux de la transmission hybride dudit flux se trouve dans un état de retransmission, du fait : - de l'expiration d'une durée prédéterminée d'attente avant retransmission d'une donnée par ladite première tête de tunnel sur ledit canal ; ou - de la réception, sur ledit canal, d'un nombre d'acquittements comprenant une indication qu'une même donnée n'a pas encore été reçue par ladite seconde tête de tunnel, ledit nombre étant supérieur ou égal à un second seuil représentatif d'une perte de donnée entre ladite première tête de tunnel et ladite seconde tête de tunnel. De façon avantageuse, la première tête de tunnel comprend des moyens de suppression, permettant de supprimer l'acquittement retardé avant l'expiration dudit délai déterminé, en cas de réception d'un acquittement comprenant une indication qu'une donnée a été reçue par le dispositif récepteur, ladite donnée correspondant à la donnée indiquée comme étant non reçue dans l'acquittement retardé. 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 une configuration typique de réseau privé virtuel (VPN) mettant en oeuvre un tunnel ; - la figure 2 présente un exemple de modèle en couche classique d'une tête de tunnel dans laquelle peut être mis en oeuvre le procédé selon l'invention ; - la figure 3 présente un exemple de format classique d'une trame Ethernet véhiculant un paquet tunnel de niveau 2 ; - les figures 4a et 4b décrivent la mise en oeuvre d'un mode de réalisation particulier de l'invention au sein d'une tête de tunnel multi-canal ; - la figure 5 présente différentes tables de structures de données, selon un mode de réalisation particulier de l'invention ; - la figure 6 détaille l'étape 30 de la figure 4a (algorithme permettant de déterminer quels sont les flux à risque) ; - la figure 7 détaille l'étape 40 de la figure 4a (algorithme de détermination de la nécessité de retarder un acquittement de flux passager ) ; - les figures 8a et 8b décrivent les mécanismes de mise à jour de l'historique, permettant de maintenir à jour les tables 510 et 520 de la figure 5 ; 20 25 30 - la figure 9 détaille l'étape 409 de la figure 7 (algorithme de retardement d'un acquittement de flux passager ) ; et - la figure 10 illustre une configuration schématique d'un dispositif de communication générique adapté pour mettre en oeuvre un mode de réalisation particulier de l'invention. 6. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. La figure 1 illustre une configuration typique de réseau privé virtuel (VPN) mettant en oeuvre un tunnel 100 entre une première tête de tunnel 101 et une seconde tête de tunnel 102, à travers un réseau de communication 107 (Internet par exemple). Ce tunnel 100 interconnecte deux réseaux locaux : réseau LAN A 103 et réseau LAN B 104. Chacun des réseaux LAN 103 et 104 comporte un équipement d'accès Internet haut débit (passerelle domestique, ou Home Gateway , pouvant intégrer un pare-feu ( Firewall 105 et 106, 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 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 que le tunnel 100 est établi, les équipements 108, 109, et 110, connectés au réseau LAN A 103, sont capables de communiquer avec les équipements 111, 112 et 113, connectés au réseau LAN B 104. Par exemple, le client 108 connecté au réseau LAN A 103 peut communiquer avec le serveur 113 connecté au réseau LAN B 104. Dans cette figure 1, on a 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 réseau LAN à plusieurs autres 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, nous allons maintenant décrire le cheminement d'une trame Ethernet issue d'un des équipements 108, 109, 110 (connectés au réseau LAN B 103) et qui va entrer dans le tunnel 100. Pour ce faire, on va utiliser un modèle en couche 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écessaires 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 lorsqu'une tête de tunnel 101 est intégrée dans un équipement UPnP. La 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 ) 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 (formation d'un paquet tunnel) et l'extraction d'une trame.

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 ( socket en anglais) 201 à un protocole de transport fiable TCP 203 ou non fiable UDP 205, respectivement sécurisés par les protocoles SSL 202 et DTLS 204. On entend par protocole ou mode de transport fiable, un protocole ou mode de transport pour lequel un dispositif émetteur d'une trame ou paquet de données obtient une information de délivrance de la trame ou du paquet de données à un dispositif récepteur. La caractéristique principale d'un tel mode est l'assurance de la délivrance de la trame ou de la donnée, et non la latence de transfert entre le dispositif émetteur et le dispositif récepteur. Par la suite, on entendra par canal fiable, un canal de transport de données d'un tunnel entre deux sous-réseaux (aussi appelés réseaux locaux LANs) utilisant un protocole de transport de données (ces données pouvant elles-mêmes être des paquets ou trames selon un protocole de transport déterminé) fiable. Après traitement par un protocole de transport pour former le paquet tunnel 250 (figure 3), on passe celui-ci à la couche réseau 206. Le datagramme IP ainsi formé avec le paquet tunnel peut maintenant être transmis sur le 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 le cheminement inverse de celui présenté ci-dessus. La figure 3 présente un exemple de format classique d'une trame Ethernet (référencée 260), transitant par exemple sur le réseau LAN A 103 de la figure 1, et qui comporte : - un champ d'en-tête Ethernet (référencé 261), - un premier datagramme IP (référencé 262) véhiculant lui-même un paquet tunnel de niveau 2 (référencé 250), et - un champ FCS ( Frame Check Sequence , ou séquence de contrôle de trame ) (référencé 263). 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 RFC 2246, "The TLS Protocol Version 1.0" ), - un champ d'en-tête du protocole embarqué 253 (à savoir Ethernet dans cet exemple), et enfin - un champ de données utilisateurs 254, qui lui-même comporte un second datagramme IP complet si aucune fragmentation n'a été opérée lors de son transit depuis l'équipement source. Les figures 4a et 4b décrivent la mise en oeuvre d'un mode de réalisation particulier de l'invention au sein d'une première tête de tunnel multi-canal, qui communique via un tunnel multi-canal avec une seconde tête de tunnel multi-canal. On appelle tête de tunnel locale la tête de tunnel mettant en oeuvre les étapes de l'algorithme considéré. On appelle tête de tunnel distante la tête de tunnel avec laquelle la tête de tunnel locale a établi le tunnel par lequel est transporté le flux considéré.

On présente maintenant en détail la figure 4a, qui décrit le traitement par une tête de tunnel d'une trame reçue par un canal du tunnel. L'étape 10 reçoit une trame sur l'un des canaux constituant le tunnel. L'étape 30 détermine, par analyse de la trame reçue du tunnel, quels sont les flux qui ont un risque élevé de subir un désordonnancement de leurs trames. Ces flux sont appelés par la suite flux à risque .Cette étape va permettre de traiter différemment les flux traversant le tunnel. Cette étape 30 sera décrite en détail dans la figure 6. L'étape 35 effectue une opération de dés-encapsulation. Cette opération permet d'extraire de la trame tunnel 260 la trame originale passagère (253+254) telle que reçue depuis le réseau LAN distant par la tête de tunnel distante.

L'étape 40 applique un mécanisme de retardement des acquittements des flux passagers à risque déterminés à l'étape 30. Le retardement des acquittements de flux passager permet d'éviter les retransmissions inutiles pour ce flux passager, ainsi que les réductions de la fenêtre de transmission qui en découlent, dans le cas de forts désordonnancements résultant d'une retransmission sur un des canaux d'un flux hybride . On appelle flux hybride un flux transmis sur un tunnel en utilisant au moins deux canaux dont au moins un canal implémente des mécanismes d'acquittement et de retransmission. L'étape 40 sera décrite en détail dans la figure 7.

L'étape 50 transmet sur le réseau LAN local la trame passagère éventuellement modifiée (suppression de l'acquittement), ou retardée (tel que décrit en relation avec les figures 7 et 9). On présente maintenant en détail la figure 4b, qui décrit les mécanismes mis en oeuvre par une tête de tunnel pour le traitement d'une trame reçue du réseau LAN local et destinée à être transmise sur le tunnel. L'étape 60 écoute le réseau LAN local, et capture une trame destinée à un équipement du réseau LAN distant. L'étape 70 sélectionne le canal sur lequel doit être transmise la trame. Cette sélection est exécutée en fonction de critères prédéterminés de répartition des données dans les canaux du tunnel. L'étape 80 ajoute la donnée courante à l'historique horodaté (table 510), et met à jour la nature (hybride ou non) du flux courant (table 520). On appelle flux courant le flux dont est issue la trame reçue à l'étape 60. L'étape 80 est détaillée sur la figure 8a.

Cette étape permet de caractériser les flux passagers (ce qui permettra un traitement différencié), et permet d'avoir la datation du moment où la trame a été traitée par la tête de tunnel (ce moment est aussi appelé par la suite instant de passage dans la tête de tunnel ), ce qui permettra de calculer la durée du retard à appliquer à l'étape 50. Le traitement auquel il est fait référence est par exemple celui mis en oeuvre à la réception de la trame depuis le réseau LAN local, ou celui mis en oeuvre à la transmission de la trame sur le tunnel, ou tout autre traitement prédéterminé effectué par la tête de tunnel sur la trame. L'étape 90 est le miroir de l'étape 35. Cette étape insère la trame du flux passager dans la partie donnée 254 de la trame tunnel 250.

L'étape 95 transmet la trame constituée à l'étape 90 sur le canal sélectionné à l'étape 70. La figure 5 décrit les structures de données qui vont être utilisées lors de la mise en oeuvre de l'invention. Cette figure est composée de trois tables référencées 500, 510 et 520.

La table 500 des canaux décrit les informations relatives aux canaux constituant le tunnel multi-canal. Pour chaque canal, la table 500 contient la valeur des colonnes suivantes : - la colonne 501 contient l'identifiant unique du canal, que l'on nommera ID canal dans la suite ; - la colonne 502 indique si le canal est fiable, c'est-à-dire si le canal implémente un protocole disposant de mécanismes d'acquittement et de retransmission de données ; - les colonnes 503 et 504 contiennent les ports source et destination de chaque canal. Cette paire de ports permet d'identifier de façon unique un canal du tunnel ; - la colonne 505 contient le dernier numéro d'acquittement compris dans le dernier acquittement de tunnel valide reçu ; - la colonne 506 contient un compteur permettant de déterminer le nombre d'acquittements dupliqués (c'est-à-dire de Dup Ack) reçus pour le numéro d'acquittement 505 (0 indique qu'aucun acquittement dupliqué de tunnel a été reçu pour le numéro d'acquittement stipulé en colonne 505, 1 indique qu'il a été reçu un acquittement dupliqué de tunnel pour le numéro d'acquittement stipulé en colonne 505, etc.). - la colonne 507 indique si au moins une retransmission de donnée (suite à un problème tel que la perte d'un paquet par exemple) est en cours sur le canal. Cette colonne n'a pas de signification lorsque le canal identifié n'implémente pas de protocole disposant de mécanisme d'acquittement et de retransmission.

La table 510 décrit la structure d'une table permettant de stocker un historique horodaté des trames envoyées à travers le tunnel, par la tête de tunnel où cette table est mise en oeuvre et qui ne sont pas encore acquittées par la tête de tunnel distante. Cette table représente l'ensemble des données que l'on appelle en cours de transmission sur le tunnel . Cette table contient les colonnes suivantes : - la colonne 511 contient un horodatage du moment (date t0 ) auquel la trame a été traitée par la tête de tunnel locale (par exemple horodatage de l'instant de réception de la trame depuis le réseau LAN local, ou instant de transmission de la trame sur le tunnel, ou tout autre instant où un traitement prédéterminé est effectué par la tête de tunnel sur la trame) ; - la colonne 512 contient un identifiant du flux passager auquel appartient cette trame. Cet identifiant correspond à la colonne 521 de la table 520 ; - la colonne 513 contient le numéro de séquence de données du premier octet de donnée de la trame ; - la colonne 514 contient l'identifiant unique du canal qui a effectivement été utilisé pour transmettre cette trame sur le tunnel. La table 520 décrit une structure de données adaptée au stockage des informations de flux passager , permettant de décrire les flux passagers actifs sur le tunnel. On entend ici par flux actifs, des flux de données correspondant à des sessions ouvertes et non closes, entre un dispositif émetteur situé sur un premier réseau LAN et un dispositif récepteur sur un second réseau LAN, lequel est interconnecté au premier grâce au tunnel. La création et la suppression de ligne dans cette table se fait par supervision des ouvertures de sessions entre dispositifs émetteurs et récepteurs (établissement en trois temps tels que décrit en Annexe) et respectivement fermetures de sessions entre dispositifs émetteurs et récepteurs des réseaux LAN A 103 et B 104. La table 520 contient les colonnes suivantes : - la colonne 521 contient un identifiant unique du flux passager ; - la colonne 522 contient l'adresse IP du dispositif émetteur (champ adresse source de l'entête IP des trames du flux passager) ; - la colonne 523 contient le numéro de port source associé au flux passager (champ port source de l'entête du protocole de transport (couche 4 du modèle OSI)) ; - la colonne 524 contient l'adresse IP du dispositif récepteur (champ adresse destination de l'entête IP des trames du flux passager) ; - la colonne 525 contient le numéro de port destination associé au flux passager (champ port destination de l'entête du protocole de transport (couche 4 du modèle OSI)) ; - la colonne 526 contient le numéro d'acquittement compris dans le dernier acquittement valide reçu pour le flux passager considéré. - la colonne 527 est un compteur indiquant le nombre d'acquittements dupliqués (c'est-à-dire de Dup Ack) reçus pour le numéro d'acquittement stipulé en colonne 526 (0 indique qu'aucun acquittement dupliqué de flux passager a été reçu pour le numéro d'acquittement stipulé en colonne 505, 1 indique qu'il a été reçu un acquittement dupliqué de flux passager pour le numéro d'acquittement stipulé en colonne 505, etc.) ; - la colonne 528 indique si le flux passager est un flux hybride ; - la colonne 529 indique si le flux est un flux à risque , c'est-à-dire s'il existe un risque élevé de désordonnancement sur le flux considéré.

La figure 6 détaille l'étape 30 de la figure 4a. Elle décrit l'algorithme permettant de déterminer quels sont les flux à risque, c'est-à-dire les flux qui présentent un risque élevé de désordonnancement de trames. Cet algorithme peut être déclenché par deux événements extérieurs différents. Un premier événement est une expiration (étape 320) de la temporisation de retransmission (RTO) d'un canal du tunnel donné. Cette temporisation est notée RTOt1RRe, par la suite. Cet évènement peut être remonté par l'API ( Application Programming Interface , ou interface de programmation en français) du connecteur réseau ( socket en anglais) utilisé pour le contrôle du canal donné. Après l'étape 320, l'étape 305 est exécutée.

Un deuxième événement est la réception (étape 301), sur un canal donné, d'une trame contenant un acquittement valide (bit ACK de l'entête TCP à 1) en référence à une trame (de tunnel) précédemment transmise sur le canal donné, selon le protocole implémenté par le canal donné. Dans la suite, nous appellerons acquittement de tunnel (ou ACK de tunnel ) une telle trame. Après l'étape 301, l'étape 302 est exécutée.

L'étape 302 détermine si un tel acquittement de tunnel a déjà été reçu, c'est-à-dire si l'acquittement reçu est un Dup Ack (acquittement dupliqué). Un acquittement de tunnel déjà reçu est appelé Dup Ack de tunnel ( Dup Ack pour Duplicated Acknowledgement en anglais, ou acquittement dupliqué en français).

Pour ce faire, l'étape 302 compare le numéro d'acquittement, contenu dans l'acquittement de tunnel reçu, avec celui contenu dans le champ 505 de la table 500. Si les numéros d'acquittement sont identiques, nous sommes en présence d'un Dup Ack de tunnel , et l'étape 303 est exécutée. Sinon, l'étape 3091 est exécutée. L'étape 303 incrémente le nombre de Dup Ack de tunnel reçus sur ce canal (champs 506 de la table 500). L'étape 304 détermine si le nombre de Dup Ack de tunnel reçus (champs 506 de la table 500) est supérieur à deux. En effet, ce nombre, s'il dépasse deux, signifie que la pile de protocole TCP de la tête de tunnel doit retransmettre la donnée (qu'elle considère comme perdue). Si l'étape 304 est positive, l'étape 305 est exécutée, et positionne le champ 507 de la table des canaux 500 à vrai pour indiquer que le canal sur lequel l'acquittement a été reçu entre dans un état de retransmission. Sinon (étape 304 négative) le processus est terminé. L'étape 306 détermine quels sont les flux hybrides actifs sur le canal donné. Pour cela, l'étape 306 détermine quels sont les flux en cours sur le canal donné, en examinant la table 510. Puis, on regarde pour chacun desdits flux, dans la table 520, si le champ 528 est à vrai. L'étape 307 sélectionne un à un tous les flux déterminés à l'étape 306, et exécute l'étape 308 pour chacun. L'étape 308 positionne le champ 529 de la table des flux 520 à vrai pour indiquer que le flux considéré est un flux à risque (c'est-à-dire un flux qui a un risque élevé de subir un désordonnancement). Si l'étape 302 est négative, nous sommes simplement en présence de l'acquittement de tunnel d'une nouvelle donnée reçue par la tête de tunnel distante. Dans ce cas, l'étape 3091 est exécutée.

L'étape 3091 réévalue la valeur de la temporisation de retransmission du tunnel RTOt1RRe,. en fonction du temps mis par la trame tunnel (acquittée par l'acquittement de tunnel reçu) pour être acquittée, ainsi que de la valeur du temps d'aller-retour du tunnel RTTtä 1Re, (se référer à la norme RFC 2581 pour la description de la relation entre RTT et RTO). L'étape 321 met à jour la valeur du champ 505 avec la valeur du numéro d'acquittement contenu dans l'acquittement de tunnel reçu, puis positionne le champ 506 à 0 pour indiquer qu'aucun Dup Ack de tunnel n'a encore été reçu pour cette donnée.

L'étape 310 détermine si le canal donné est dans un état de retransmission. Pour cela, elle examine la valeur du champ 506 de la table des canaux 500. La réception d'un nouvel acquittement de tunnel (nouveau, par opposition à un Dup Ack de tunnel ) indique une fin de retransmission, puisque la donnée retransmise a été correctement reçue (acquittée). Si l'étape 310 est positive, l'étape 311 est exécutée. Sinon le processus est terminé. L'étape 311 positionne le champ 507 de la table des canaux à faux pour indiquer que le canal donné n'est pas ou plus dans un état de retransmission. L'étape 312 détermine l'ensemble des flux à risque sur le canal donné. Pour cela, elle analyse la table 510 et sélectionne l'ensemble des flux ayant des trames en cours de transmission sur le canal. Puis, cette étape détermine parmi les flux précédemment sélectionnés ceux dont le champ 529 de la table des flux 520 est à vrai. L'étape 313 sélectionne un à un tous les flux déterminés à l'étape 312, et exécute l'étape 314 pour chacun. L'étape 314 positionne le champ 529 de la table des flux 520 à faux pour indiquer que le flux considéré n'est pas ou plus un flux à risque (c'est-à-dire est un flux qui n'a pas ou plus un risque élevé de subir un désordonnancement). La figure 7 détaille l'étape 40 de la figure 4a. Elle décrit le mécanisme d'analyse des trames (type trame 254) des flux passagers afin de déterminer s'il est nécessaire de retarder un éventuel acquittement de flux passager présent dans la trame.

L'étape 401 détermine, par analyse du champ Ack de l'entête TCP de la trame d'un flux passager donné, si la trame du flux contient un acquittement. Si l'étape 401 est positive, l'étape 402 est exécutée, sinon l'étape 410 est exécutée. L'étape 402 détermine si l'acquittement de flux passager reçu a déjà été reçu (il s'agirait alors d'un Dup Ack de flux passager ). Pour cela, cette étape compare le numéro d'acquittement compris dans l'acquittement de flux passager reçu avec le dernier numéro d'acquittement 526 de la table 520 pour le flux passager. Si l'étape 402 est positive, l'étape 406 est exécutée, sinon l'étape 403 est exécutée. L'étape 403 est effectuée en cas de réception d'un nouvel acquittement de flux passager (nouveau, par opposition à un Dup Ack de flux passager ). En conséquence, elle met à jour les champs 526 et 527 de la table des flux 520 pour le flux passager donné. Cette étape remet donc le compteur 527 à 0 pour indiquer que l'on a l'acquittement de flux passager pour la première fois (pas de Dup Ack de flux passager ), et insère le numéro d'acquittement de la trame dans le champ 526.

L'étape 309 met à jour la table 510 qui contient l'historique des transmissions en cours dans le tunnel. En effet, la réception d'un acquittement de flux passager indique que la donnée a été correctement reçue par l'équipement récepteur et n'est donc plus en cours de transmission sur le tunnel (on ne peut en effet pas se baser sur les acquittements de tunnel , car les trames de flux passager transmises sur un canal ne possédant pas de mécanismes de retransmission ne sont pas acquittées). L'étape 309 met aussi à jour la table 520 qui indique pour chaque flux passager actif sur le tunnel si ce flux est hybride ou non. Le détail de cette double mise à jour est décrit sur la figure 8b. L'étape 405 annule la temporisation de retard, pour le flux passager, activée à l'étape 4101 de la figure 9, annulant ainsi l'émission d'un troisième Dup Ack de flux passager qui aurait eu pour conséquence une retransmission par le dispositif émetteur. L'étape 406 incrémente le nombre d'acquittements dupliqués ou Dup Ack reçus avec ce numéro d'acquittement de flux passager (champ 527 de la table 520).

L'étape 407 détermine (par examen du champ 529 de la table 520), si le flux passager possède un risque élevé de désordonnancement de trames. Si l'étape 407 est positive, l'étape 408 est exécutée, sinon, l'étape 410 est exécutée. L'étape 408 détermine si le nombre de Dup Acks de flux passager reçus (champ 527 de la table des flux 520) est supérieur à deux. Si c'est le cas, la transmission de cet acquittement de flux passager sur le réseau LAN, à destination du dispositif émetteur du flux passager donné, générerait une retransmission de la part de l'équipement émetteur et réduirait sa fenêtre d'émission. Prenant en compte le fait que le flux passager donné possède un risque élevé de désordonnancement de trames (étape 407 positive), l'invention va retarder l'émission du troisième Dup Ack pour ce flux passager pour laisser le temps au canal en état de retransmission, de retransmettre la donnée concernée. En conséquence, si l'étape 408 est positive, l'étape 409 sera exécutée, sinon l'étape 410 sera exécutée. L'étape 409 retarde l'envoi sur le réseau LAN de l'acquittement de flux passager reçu via le tunnel. Les détails de cette étape sont donnés à la figure 9. L'étape 410 est exécutée dans les cas où le retard d'un acquittement de flux passager n'est pas nécessaire (étape 401, 402, 407 ou 408 négative). L'étape 410 envoie sur le réseau LAN local la trame originale passagère (la trame passagère est la trame 254 encapsulée dans la trame tunnel 260) telle qu'elle a été reçue par la tête de tunnel distante depuis le réseau LAN distant. Les figures 8a et 8b décrivent les mécanismes de mise à jour de l'historique, permettant de maintenir à jour la table 510 des trames non acquittées par la tête de tunnel distante et la table 520 indiquant la nature (hybride ou non) des flux passagers. L'évolution du contenu de ces tables 510 et 520 est contrôlée par deux évènements : l'envoi d'une trame sur le tunnel (cas de la figure 8a), et la réception de son acquittement en provenance de la tête de tunnel distante (cas de la figure 8b). La figure 8a détaille l'étape 80 de la figure 4b. Cette figure décrit les mécanismes mis en oeuvre lors de l'émission d'une trame sur un canal du tunnel.

A l'émission d'une trame donnée sur un canal du tunnel, une ligne est ajoutée à l'historique (table 510) des trames non acquittées par la tête de tunnel distante, et la nature (hybride ou non) du flux auquel appartient la trame est réévaluée. L'étape 81 ajoute une ligne dans la table 510 pour la nouvelle trame transmise.

L'étape 81 valorise : - le champ 511 avec un horodatage ; - le champ 512 avec l'identifiant du flux (champ 521 de la table des flux 520) de la trame donnée ; - le champ 513 avec le numéro de séquence issu de l'entête de la trame donnée ; - le champ 514 avec l'identifiant du canal (champ 501 de la table 500) sélectionné pour l'émission de la trame donnée lors de l'étape 70. L'étape 82 détermine si le flux de la trame donnée est actuellement identifié comme hybride (en examinant le champ 528 de la table des flux 520 pour ce flux). Si l'étape 82 est négative, l'étape 83 est exécutée, sinon l'algorithme s'achève. L'étape 83 détermine si le fait de transmettre la trame donnée sur le canal sélectionné à l'étape 70 fait passer le statut du flux considéré de non hybride à hybride . Pour cela, l'étape 83 parcourt la table 510 à la recherche d'une trame, du flux passager considéré, qui soit en cours de transmission sur un canal dont le type (champ canal fiable 502) est différent de celui associé au canal valorisé à l'étape 81. Si l'étape 83 est positive, le flux passager considéré devient hybride , et l'étape 84 est exécutée. L'étape 84 positionne le champ 528 de la table des flux 520 à vrai pour indiquer que le flux considéré est hybride. Cette étape positionne également le champ 529 de la table des flux 520 à vrai si au moins un des canaux utilisés pour la transmission des trames du flux passager considéré est en cours de retransmission. Pour cela, l'étape 84 examine le champ 507 de la table 500 pour chaque canal utilisé pour la transmission des trames du flux passager considéré.

La figure 8b détaille l'étape 309 de la figure 7. Cette figure décrit les mécanismes mis en oeuvre lors de la réception d'une trame d'acquittement (acquittement de flux passager ) provenant de la tête de tunnel distante. A chaque réception d'un acquittement de trame de flux passager par la tête de tunnel distante, la table 510 est mise à jour, et le statut (hybride ou non) du flux passager considéré est réévalué (table 520). L'étape 3092 met à jour la table 510 en supprimant la ligne correspondant à l'identifiant de flux (champ 512) et au numéro de séquence (champ 513) auxquels correspondent respectivement l'identifiant de flux et le numéro d'acquittement de la trame d'acquittement reçu (on rappelle que le numéro d'acquittement envoyé par un dispositif de communication suite à la réception d'un segment de données est égal au numéro de séquence du segment acquitté, incrémenté de 1). L'étape 3093 détermine si le flux, auquel appartient les données acquittées par la trame d'acquittement reçue, est hybride (utilisation du champ 528 de la table 520). Si l'étape 3093 est positive, l'étape 3094 est exécutée, sinon l'algorithme s'achève. L'étape 3094 détermine si le flux courant est encore de nature hybride. Pour cela, l'étape 3094 recherche dans la table 510 s'il reste encore des trames du flux courant en cours de transmission sur des canaux de type différents. Si ce n'est pas le cas, le flux courant n'est plus de nature hybride, et l'étape 3095 est effectuée.

L'étape 3095 positionne le champ 528 de la table des flux 520 à faux pour indiquer que le flux n'est pas hybride. La figure 9 détaille l'étape 409 de la figure 7. La figure 9 décrit le mécanisme mis en oeuvre lors de la réception d'une trame passager comprenant un acquittement de flux passager valide. L'objectif est d'éviter une retransmission inutile dans le cas où une succession d'acquittements dupliqués ( Dup Acks ) pour un flux passager reçue par une tête de tunnel ne serait que la conséquence d'un blocage partiel (dû à une retransmission sur un canal fiable du tunnel) d'un flux hybride. Lors de l'étape 4091, on stocke l'acquittement de flux passager reçu (c'est-à-dire celui contenu dans la trame passager reçue) dans une mémoire tampon ( buffer en anglais) (cette mémoire tampon est en fait un élément d'une liste, car on a potentiellement besoin d'autant de mémoires tampons qu'il y a de flux actifs sur le tunnel). Si l'acquittement de flux passager donné est inclus dans une trame de données, seule la partie acquittement est sauvegardée (entête TCP), le reste étant émis immédiatement sur le réseau LAN lors de l'étape 4098, puis l'étape 4092 est exécutée.

Dans un mode de réalisation alternatif, lors de l'étape 4091, si l'acquittement de flux passager donné est déjà dans la mémoire tampon (4ème Dup-Ack ou plus...), l'acquittement n'est pas stocké, et c'est l'étape 4097 qui est exécutée (ce qui permet de préserver de la mémoire), sinon l'étape 4092 est exécutée. L'étape 4092 calcule le retard Re à appliquer à cet acquittement de flux passager (ce retard Re est compté à partir d'un instant auquel cet acquittement a été reçu par la tête de tunnel locale) pour qu'il soit envoyé avant expiration de la temporisation de retransmission de l'équipement émetteur (la valeur estimée de cette temporisation par la tête de tunnel locale est notée RTOe par la suite) pour le flux passager considéré. Pour ce faire, l'étape 4092 applique la formule suivante : Re = RTOtunnel - (T - TO) - Ô Où: • RTOtunnel est la valeur estimée par la tête de tunnel locale, à l'étape 3091, de la temporisation de retransmission (RTO) du tunnel ; • TO est le temps auquel a été envoyée la donnée qui a le numéro de séquence le plus élevé et qui est non encore acquittée pour le flux courant (cette valeur est déterminée par l'examen de la table 510, et correspond à l'horodatage le plus ancien de la table 510 pour le flux courant) ; • T est le temps auquel a été reçu l'acquittement ; il peut être considéré que T prend la valeur de l'horodatage courant si le temps écoulé entre la réception de l'acquittement et le traitement effectué à l'étape 4092 est négligeable au regard des paramètres ci-dessus permettant la détermination de Re ; • Ô est une marge sécuritaire. Comme valeur typique, on pourrait prendre Ô=2ms, ce qui est en général supérieur à une durée d'aller-retour (RTT) moyenne sur un réseau LAN (notée RTT1 ). Une telle marge sécuritaire permet donc à l'acquittement d'arriver avant l'expiration de la temporisation de retransmission 25 30 mise en oeuvre par le dispositif émetteur pour le flux passager considéré. En effet, on peut estimer que la durée de la temporisation RTOe est à peu près égale à (RTOt ne, + 4*RTT1an). En conséquence, le dispositif émetteur reçoit l'acquittement ( de flux passager ) d'une donnée après une durée égale à (RTT,an+RTOtä,ne,- Ô) après l'émission de la donnée, ce qui laisse une marge de 3*RTT1an+ Ô (RTT,an pouvant être très faible) avant l'expiration de la temporisation de retransmission du dispositif émetteur du flux passager considéré. Puis les étapes 4093 à 4096 d'une part, et 4097 à 4098 d'autre part, sont exécutées dans deux processus indépendants. En d'autres termes, les étapes 4093 à 4096 d'une part et 4097 à 4098 d'autre part s'exécutent en parallèle. L'étape 4093 démarre la temporisation, d'une valeur égale au retard Re déterminé pour le flux considéré. L'étape 4094 attend l'expiration de la temporisation Re armée à l'étape 4093. À l'expiration de la temporisation Re, l'étape 4095 est exécutée. L'étape 4095 détermine si la temporisation Re a été annulée (lors de l'étape 405 de la figure 7). Si l'étape 4095 est négative, l'étape 4096 est exécutée, sinon l'algorithme s'achève. L'étape 4096 émet, sur le réseau LAN, l'acquittement de flux passager stocké. L'étape 4097, qui est exécutée en parallèle de l'étape 4093, positionne le champ Ack de l'entête de la trame reçue à 0, pour indiquer que la trame ne possède pas d'acquittement valide. Seule la partie donnée de la trame reçue sera donc interprétée par l'équipement émetteur.

L'étape 4098 envoie la trame reçue, sans que celle-ci ne contienne d'acquittement valide. Il est à noter que si la trame reçue ne contient qu'un acquittement et ne contient pas de donnée, les étapes 4097 et 4098 ne seront pas exécutées.. La figure 10 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 de la technique de l'invention. Par exemple, la tête de tunnel 101 ou 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 le ou les programme(s) précité(s) ; - 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 réseaux de communication distribué 1020 (par exemple, cas de la figure 1, le réseau local 103/104 et l'Internet 107), l'interface étant apte à transmettre et à recevoir des données avec ces 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 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 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 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).

ANNEXE : RAPPELS SUR LE PROTOCOLE TCP Le protocole TCP (pour Transmission Control Protocol , tel que défini par la norme RFC 793) est un protocole de type ARQ qui a été créé dans le but d'assurer des transferts de données sur l'Internet selon des critères forts de vitesse et qualité. Au moins deux mécanismes sont utilisés pour gérer l'excès de trafic arrivant sur un récepteur : le premier consiste à utiliser des mémoires tampon de réception, et le second met en place un contrôle de flux. Le protocole TCP permet d'assurer le transfert des données de façon fiable, bien qu'il utilise le protocole IP, qui n'intègre aucun contrôle de livraison de datagramme. En effet, le protocole TCP possède un système d'accusé de réception, aussi appelé système d'acquittement ( acknowledgement en anglais ou ACK), permettant au client (aussi appelé dispositif client ou machine réceptrice) et au serveur (aussi appelé dispositif serveur ou machine émettrice) de s'assurer de la bonne réception mutuelle des données. Lors de l'émission d'un segment de données (aussi appelé paquet de données), un numéro d'ordre de données (appelé aussi numéro de séquence de données) est associé. A la réception d'un segment de données, la machine réceptrice va retourner un segment de données dont le drapeau ACK est à 1 (afin de signaler qu'il s'agit d'un accusé de réception) accompagné d'un numéro d'accusé de réception (aussi appelé numéro de séquence d'acquittement) égal au numéro de séquence de données du segment reçu incrémenté de 1. En effet, le numéro de séquence d'acquittement correspond au numéro de séquence de données du prochain segment attendu (et non le numéro de séquence de données du dernier segment reçu). Etant donné que ce processus de communication, qui se fait grâce à une émission de données et d'un accusé de réception, est basé sur un numéro d'ordre (ou numéro de séquence) de données, il faut que les machines émettrice et réceptrice (serveur et client respectivement) connaissent le numéro d'ordre initial de l'autre machine (appelé Initial Sequence Number en anglais ou ISN). Établissement d'une connexion L'établissement d'une connexion TCP s'effectue en trois temps : - dans un premier temps, le client envoie un segment de données comportant le drapeau SYN (ou message SYN) pour signaler qu'il s'agit d'un segment de synchronisation, avec son numéro de séquence de données initial (ISN = x) ; - dans un second temps, le serveur reçoit le segment de synchronisation provenant du client, puis lui envoie un accusé de réception, c'est-à-dire un segment de données dont le drapeau ACK est à 1 et le drapeau SYN est à 1 comprenant son propre numéro de séquence de données (ISN = y), mais il doit également acquitter le paquet précédent, ce qu'il fait avec un numéro d'accusé de réception (numéro de séquence d'acquittement) qui contient le numéro d'ordre (numéro de séquence de données) initial du client, incrémenté de 1 (ack = x + 1) ; - dans un troisième temps, le client transmet au serveur un accusé de réception, c'est-à-dire un segment dont le drapeau ACK est à 1, dont le drapeau SYN est à 0, car il ne s'agit plus d'un segment de synchronisation. Son numéro d'ordre (numéro de séquence de données) est incrémenté (seq = x + 1) et le numéro d'accusé de réception (numéro de séquence d'acquittement) représente le numéro d'ordre (numéro de séquence de données) initial du serveur incrémenté de 1 (ack = y + 1) . Une fois achevée cette phase nommée three-way handshake , les deux applications sont en mesure d'échanger les octets qui justifient l'établissement de la connexion. Le contrôle de flux gère l'allocation de ressources au niveau du destinataire, telles que la mémoire et le processus. En général, conformément au contrôle de flux, la destination fixe une limite au débit de transmission mis en oeuvre par toutes les sources qui envoient des données à la destination. Les sources et les destinations coordonnent le transfert de données grâce à un échange de messages comprenant des requêtes et des accusés de réception. Avant que la source commence à envoyer des paquets, elle envoie une requête à la destination visant à obtenir la permission de commencer la transmission. En réponse à cette requête, la destination envoie un message comprenant une identification du nombre de paquets que la source peut transmettre à la destination sans autorisation supplémentaire. Ce nombre est communément appelé "taille de fenêtre". Alors, la source transmet le nombre de paquets autorisés à la destination et attend que la destination vérifie leur réception. Après que la destination a reçu avec succès un paquet, elle envoie un message en retour à la source comprenant un accusé de réception (acquittement) indiquant que le paquet a été reçu avec succès et, dans certains cas, autorisant la source à envoyer un autre paquet. De cette façon, le nombre de paquets sur le réseau transitant depuis la source vers la destination ne dépasse jamais la taille de fenêtre autorisée. On distinguera par la suite différentes appellations pour les fenêtres TCP : - fenêtre TCP ( TCP window en anglais) : la valeur initiale validée lors de l'établissement de la connexion, qui est la valeur maximale admise durant toute la durée de la connexion ; - fenêtre de congestion ( CWND ou Congestion window en anglais) : la valeur de fenêtre courante émise depuis le serveur dans un paquet TCP en destination du client ; - fenêtre d'acquittement ( acknowledge-window ou advertized- window en anglais) : la valeur de fenêtre envoyée dans un paquet TCP ACK vers le serveur, qui indique l'occupation mémoire dans le client ; - fenêtre glissante ( sliding window en anglais) : la valeur de fenêtre interne à un serveur lui permettant de connaître le nombre de données à transmettre depuis l'arrivée du dernier segment TCP d'acquittement.

Une grande taille de fenêtre TCP encourage l'émission. Si le nombre de données reçues est supérieur à ce que la fenêtre indique, les données hors fenêtre seront rejetées. Cette déperdition entraîne un grand nombre de retransmissions et surcharge inutilement le réseau et les TCP. L'usage d'une petite taille de fenêtre morcelle le débit en ajoutant un certain retard supplémentaire au temps de boucle (RTT), mais en limitant la surcharge du réseau due aux retransmissions. L'ouverture d'une toute petite fenêtre réduit aussi les performances en augmentant le poids des en-têtes par rapport aux données. Même avec la mise en place de ces mécanismes, dans un réseau occupé, plusieurs sources envoient simultanément des flux dans le réseau à plus d'une destination. Si trop de tels flux convergent vers un unique routeur dans un laps de temps trop court, alors la capacité limitée en mémoire tampon de ce routeur n'est pas capable de traiter ce volume de flux et ce routeur va rejeter ou détruire une partie des paquets. Lorsqu'une telle situation se produit, le réseau est dit congestionné. Lorsqu'une telle situation se produit, les transferts dans le réseau ralentissent considérablement et le débit du réseau chute. Du fait que certaines ressources du réseau sont dédiées à la mise en oeuvre de retransmissions, au moment où le réseau connaît une surcharge, il existe un risque substantiel d'occurrence de propagations de congestions et de blocage du réseau tout entier. La valeur du champ TCP MSS ( Maximum Segment Size en anglais, ou taille de segment maximale ) indique la quantité maximale de données TCP par datagramme IP que le système local peut accepter. Lorsqu'il est envoyé, le datagramme IP peut être fragmenté en plusieurs paquets. Théoriquement, cette valeur peut atteindre la valeur de 65495, cependant une valeur aussi importante n'est jamais mise en oeuvre. Typiquement, un système terminal utilise l'interface MTU (pour outgoing interface Maximum Transfer Unit ) à laquelle est retranchée la valeur 40 comme sa valeur de champ TCP MSS. Par exemple, une valeur de champ TCP MSS pour le protocole Ethernet est 1460 (1500 - 40 = 1460). La valeur du champ TCP MSS est renseignée dans les paquets qui servent à établir la connexion qui sont les paquets qui contiennent le signal SYN. Chaque coté envoie sa propre valeur de champ TCP MSS. Il n'est pas requis que chaque coté utilise la même valeur de champ TCP MSS, mais chaque coté ne peut pas envoyer plus de données que ce qui est autorisé par le poste distant. La valeur du champ TCP MSS est envoyée à la taille de segment maximale (MSS) de l'option de l'entête TCP. On peut noter que la valeur par défaut de la taille de la mémoire tampon de l'interface de connexion diffère beaucoup en fonction de l'implémentation. Les anciennes implémentations dérivées de Berkeley imposent des valeurs par défaut des mémoires tampon TCP de réception et d'envoi à 4KB, alors que les systèmes plus récents mettent en oeuvre des valeurs plus importantes (jusqu'à 64KB). Par exemple, dans WINDOWS XP (marque déposée), la valeur actuelle de la taille de fenêtre en réception s'ajuste automatiquement en fonction des incréments pairs de la taille maximale de segment (MSS) négociée pendant l'établissement de la connexion TCP. Contrôle du flux Le protocole TCP utilise plusieurs algorithmes pour gérer sa congestion, plus particulièrement un algorithme de démarrage lent ( slow start en anglais) et un algorithme d'évitement de congestion ( congestion avoidance en anglais). Chacun de ces algorithmes gère le débit d'émission du serveur en manipulant une fenêtre de congestion ( congestion window , ou CWND) qui limite le nombre d'octets non acquittés en transit à un instant donné. Le débit possible de TCP pour une valeur de fenêtre de congestion donnée est déterminé par la vitesse à laquelle les acquittements sont reçus. Le temps pour recevoir un acquittement après l'émission d'une donnée est appelé TCP Round Trip Time (RTT).

Lors du démarrage d'une connexion, l'algorithme de démarrage lent ( slowstart ) est mis en place pour accroître rapidement la fenêtre de congestion (CWND) dans le souci d'atteindre la valeur de la bande passante le plus vite possible. La variable SSTHRESH ( steady-state Threshold ) est maintenue par le serveur afin de distinguer les deux phases. Lorsque l'émetteur conclut à une perte d'un segment, il traite cette information comme un signal implicite d'une surcharge réseau et décroît rapidement la fenêtre de congestion. Après avoir déduit approximativement le seuil SSTHRESH d'engorgement du réseau, TCP procède à la mise en place de l'algorithme d'évitement de congestion ( congestion avoidance ) qui accroît la valeur de la fenêtre de congestion plus lentement afin d'occuper la bande passante additionnelle disponible.

Durant la phase de démarrage lent ( slow-start ) (au démarrage de la connexion ou après dépassement de temps (timeout)), l'émetteur démarre avec un fenêtrage CWND de 1 MSS, et CWND augmente de 1*MSS après chaque réception d'acquittement. La fenêtre de congestion CWND est approximativement doublée à chaque RTT (croissance exponentielle). Durant la phase d'évitement de congestion ( congestion-avoidance ), l'accroissement de CWND est limité à 1*MSS par RTT (croissance additive). Une baisse des performances est notée dans les réseaux Internet où l'on peut constater un délai long de propagation qui empêche la fenêtre de transmission d'envoyer des nouveaux segments rapidement (les acquittements déterminent l'augmentation de la fenêtre de transmission et ils arrivent après un long délai). Détection de congestion et acquittements dupliqués ( Dup Acks ) Pour une connexion TCP, si l'équipement serveur reçoit de multiples acquittements ACK avec un numéro de séquence d'acquittement identique, on parle d'acquittements dupliqués (aussi appelés Dup Ack , pour duplicate Acknowledgements en anglais). Le serveur retransmet alors le segment de données correspondant au numéro de séquence de données spécifié. Même si le serveur ne reçoit pas d'acquittement dupliqué ( duplicate ACK ), dans le cas où il ne reçoit pas non plus d'autres acquittements ACK (avec un autre numéro de séquence d'acquittement) durant une période de temps déterminée après l'émission d'un segment de données, le serveur retransmet ce segment de données non acquitté.

Typiquement, le client TCP émet un acquittement dupliqué ( duplicate ACK ) lors de la réception désordonnée d'un segment de données (c'est-à-dire lorsqu'il reçoit un segment de données avec un numéro de séquence de données supérieur au numéro de séquence de données attendu). Le but de l'acquittement dupliqué ( duplicate ACK ) est d'informer le serveur qu'un segment de données a été reçu en désordre et de lui indiquer quel est le numéro de séquence de données qui était attendu. Une salve d'acquittements dupliqués ( duplicate ACKs ) est le résultat de segments de données perdus et/ou un ré-ordonnancement de segments de données sur le chemin de transmission. Algorithmes de retransmission rapide ( Fast Retransmit ) et de reprise rapide ( Fast Recovery ) Le protocole TCP utilise un algorithme (mécanisme) de retransmission rapide ( Fast Retransmit en anglais, décrit par le standard Internet IETF RFC2581) pour rapidement détecter et réagir aux pertes de paquets identifiées par la réception d'acquittements dupliqués ( duplicate ACKs ). L' algorithme Fast Retransmit considère l'arrivée de trois acquittements dupliqués ( duplicate ACKs ) (en fait quatre acquittements ACKs identiques sans autre acquittement indiquant la régularisation du problème supposé) comme une indication qu'un segment de données a été perdu. Si moins de trois acquittements dupliqués ( duplicate ACKs ) sont reçus, on considère qu'il s'agissait d'un court problème de désordonnancement de paquets qui a été résolu et suivi de l'acquittement ACK pour le segment concerné). A la réception de ces trois acquittements dupliqués ( duplicate ACKs ), le serveur va retransmettre le segment de donnée manquant sans attendre une expiration de son temporisateur de retransmission (RTO, pour Retransmission Time Out en anglais). Ensuite, un algorithme de reprise rapide ( Fast Recovery en anglais) est démarré pour gérer la transmission des données nouvelles jusqu'à la réception d'un acquittement ACK non dupliqué. Comme le client TCP ne peut émettre un acquittement dupliqué ( duplicate ACK ) qu'à l'arrivée d'un autre segment de données, cela signifie qu'un segment de données (mais pas celui escompté) a quand même été reçu et ne consomme plus de ressource sur le réseau. Il y a donc toujours une activité sur le réseau et le serveur TCP peut continuer à transmettre de nouveaux segments de données (la transmission se continue avec une fenêtre de congestion CWND réduite). Les deux algorithmes précités ( Fast Retransmit et Fast Recovery ) sont mis en place conjointement de la façon suivante sur le serveur TCP : 1. A la réception d'un troisième acquittement dupliqué ( duplicate ACK ), la valeur SSTHRESH est modifiée pour ne pas dépasser la valeur maximale suivante : SSTHRESH = max (FlightSize / 2, 2*MSS) où : - la valeur flightsize donne une estimation des paquets en transit dont le serveur n'a pas encore reçu l'acquittement du client ; - la valeur MSS indique la quantité maximale de données TCP par datagramme IP que le système local peut accepter sur le chemin de transmission. 2. Retransmission du segment considéré perdu et mise à jour de la fenêtre de congestion CWND à (SSTHRESH + 3*MSS). Ceci permet d'augmenter la fenêtre de congestion du nombre de segments (3) partis sur le réseau et reçus correctement par le client. 3. Pour chaque nouvel acquittement dupliqué ( duplicate ACK ) reçu par le serveur, accroissement de la fenêtre de congestion CWND de 1*MSS. 20 25 5 10 4. Transmission d'un segment de données, si autorisé par la nouvelle valeur de la fenêtre de congestion CWND et par la valeur de la fenêtre d'acquittement ( advertised window ) indiquée par le client. 5. Lors de la réception du prochain acquittement ACK qui acquitte la réception par le client du segment de données à l'origine de la retransmission, abaissement de la fenêtre de congestion CWND à la valeur SSTHRESH calculée en 1. Ce message d'acquittement ACK est bien sûr arrivé avant 1 RTT après la retransmission (voire beaucoup plus tôt si l'origine du problème était une délivrance désordonnée des segments de données vers le client). On est alors en phase d'évitement de congestion ( congestion avoidance ) car le débit de TCP est abaissé à la moitié du débit quand la perte a eu lieu.

Claims (16)

1. REVENDICATIONS1. Procédé de gestion d'une transmission hybride d'un flux de données sur un tunnel multi-canal (100), ledit tunnel étant mis en oeuvre entre des première et seconde têtes de tunnel (101, 102) connectées respectivement à des premier et second sous- réseaux (103, 104), chaque flux étant transmis depuis un dispositif émetteur (110) vers un dispositif récepteur (112), une transmission hybride sur un tunnel multi-canal étant une transmission utilisant au moins deux canaux dont au moins un canal implémente un mécanisme d'acquittement et de retransmission, ledit procédé étant effectué par ladite première tête de tunnel (101) et étant caractérisé en ce qu'il comprend des étapes consistant à : - détecter (30) que ledit flux est un flux à risque, un flux à risque étant un flux subissant une transmission hybride sur le tunnel, et pour laquelle au moins un canal se trouve dans un état de retransmission ; - sur réception (10), pour ledit flux, d'au moins un acquittement comprenant une indication qu'une donnée n'a pas encore été reçue par le dispositif récepteur, envoyer (4096) le(les) acquittement(s) vers le dispositif émetteur, l'envoi d'au moins un acquittement étant retardé (4093, 4094) d'un délai déterminé compté à partir d'un instant auquel l'acquittement retardé a été reçu par la première tête de tunnel.
2. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend une étape consistant à : - compter un nombre d'acquittements reçus comprenant une indication qu'une même donnée n'a pas encore été reçue par le dispositif récepteur ; et en ce que, l'envoi d'au moins un acquittement est retardé lorsque ledit nombre d'acquittements est supérieur ou égal à un premier seuil représentatif d'une perte de donnée entre ledit dispositif émetteur et ledit dispositif récepteur.
3. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ledit délai est déterminé en fonction d'une estimation d'une durée d'attente avant retransmission d'une donnée, ladite durée étant fonction du dispositif émettant ladite donnée et du flux auquel ladite donnée appartient.
4. 4. Procédé selon la revendication 3, caractérisé en ce que ledit délai est en outre déterminé en fonction d'un instant de passage dans la première tête de tunnel de la donnée indiquée, dans l'acquittement, comme étant non reçue.
5. 5. Procédé selon la revendication 4, caractérisé en ce que le délai déterminé, noté Re, est défini par : Re = RTO,ne, - (T - TO) - Ô, où : - RTOtunnel est ladite estimation d'une durée d'attente avant retransmission d'une donnée, pour ledit flux, cette estimation correspondant à une durée d'attente avant retransmission d'une donnée sur le tunnel ; - TO est ledit instant de passage dans la première tête de tunnel ; - T est ledit instant auquel l'acquittement retardé a été reçu par la première tête de tunnel ; - Ô est une marge sécuritaire prédéterminée.
6. 6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite étape consistant à détecter (30) que ledit flux est un flux à risque comprend une étape consistant à détecter que l'un des canaux de la transmission hybride dudit flux se trouve dans un état de retransmission, du fait : - de l'expiration (320) d'une durée prédéterminée d'attente avant retransmission d'une donnée par ladite première tête de tunnel sur ledit canal ; ou - de la réception, sur ledit canal, d'un nombre d'acquittements comprenant une indication qu'une même donnée n'a pas encore été reçue par ladite seconde tête de tunnel, ledit nombre étant supérieur ou égal à un second seuil représentatif d'une perte de donnée entre ladite première tête de tunnel et ladite seconde tête de tunnel.
7. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comprend une étape (405) consistant à supprimer l'acquittement retardé avant l'expiration (4094) dudit délai déterminé, en cas de réception d'un acquittement comprenant une indication qu'une donnée a été reçue par le dispositif récepteur, ladite donnée correspondant à la donnée indiquée comme étant non reçue dans l'acquittement retardé.
8. 8. 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 parun processeur, caractérisé en ce qu'il comprend des 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, éventuellement totalement ou partiellement amovible, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre du procédé selon au moins une des revendications 1 à 7.
10. 10. Première tête de tunnel (101) permettant la gestion d'une transmission hybride d'un flux de données sur un tunnel multi-canal (100), ledit tunnel étant mis en oeuvre entre ladite première tête de tunnel (101) et une seconde tête de tunnel (102) connectées respectivement à des premier et second sous-réseaux (103, 104), chaque flux étant transmis depuis un dispositif émetteur (110) vers un dispositif récepteur (112), une transmission hybride sur un tunnel multi-canal étant une transmission utilisant au moins deux canaux dont au moins un canal implémente un mécanisme d'acquittement et de retransmission, ladite première tête de tunnel (101) étant caractérisée en ce qu'elle comprend : - des moyens de détection, permettant de détecter que ledit flux est un flux à risque, un flux à risque étant un flux subissant une transmission hybride sur le tunnel, et pour laquelle au moins un canal se trouve dans un état de retransmission ; - des moyens d'envoi, permettant, sur réception, pour ledit flux, d'au moins un acquittement comprenant une indication qu'une donnée n'a pas encore été reçue par le dispositif récepteur, d'envoyer le(les) acquittement(s) vers le dispositif émetteur, l'envoi d'au moins un acquittement étant retardé d'un délai déterminé compté à partir d'un instant auquel l'acquittement retardé a été reçu par la première tête de tunnel.
11. 11. Première tête de tunnel selon la revendication 10, caractérisée en ce qu'elle comprend : - des moyens de comptage, permettant de compter un nombre d'acquittements reçus comprenant une indication qu'une même donnée n'a pas encore été reçue par le dispositif récepteur ; 25 30et en ce que lesdits des moyens d'envoi permettent de retardé l'envoi d'au moins un acquittement lorsque ledit nombre d'acquittements est supérieur ou égal à un premier seuil représentatif d'une perte de donnée entre ledit dispositif émetteur et ledit dispositif récepteur.
12. 12. Première tête de tunnel selon l'une quelconque des revendications 10 et 11, caractérisée en ce que ledit délai est déterminé en fonction d'une estimation d'une durée d'attente avant retransmission d'une donnée, ladite durée étant fonction du dispositif émettant ladite donnée et du flux auquel ladite donnée appartient.
13. 13. Première tête de tunnel selon la revendication 12, caractérisée en ce que ledit délai est en outre déterminé en fonction d'un instant de passage dans la première tête de tunnel de la donnée indiquée, dans l'acquittement, comme étant non reçue.
14. 14. Première tête de tunnel selon la revendication 13, caractérisée en ce que le délai déterminé, noté Re, est défini par : Re = RTOt11111e, - (T - TO) - Ô, où : - RTOtunnel est ladite estimation d'une durée d'attente avant retransmission d'une donnée, pour ledit flux, cette estimation correspondant à une durée d'attente avant retransmission d'une donnée sur le tunnel ; - TO est ledit instant de passage dans la première tête de tunnel ; - T est ledit instant auquel l'acquittement retardé a été reçu par la première tête de tunnel ; - Ô est une marge sécuritaire prédéterminée.
15. 15. Première tête de tunnel selon l'une quelconque des revendications 1 à 14, caractérisée en ce que lesdits moyens de détection, permettant de détecter que ledit flux est un flux à risque, comprennent des moyens de détection, permettant de détecter que l'un des canaux de la transmission hybride dudit flux se trouve dans un état de retransmission, du fait : - de l'expiration (320) d'une durée prédéterminée d'attente avant retransmission d'une donnée par ladite première tête de tunnel sur ledit canal ; ou - de la réception, sur ledit canal, d'un nombre d'acquittements comprenant une indication qu'une même donnée n'a pas encore été reçue par ladite seconde tête de tunnel, ledit nombre étant supérieur ou égal à un second seuil représentatifd'une perte de donnée entre ladite première tête de tunnel et ladite seconde tête de tunnel.
16. 16. Première tête de tunnel selon l'une quelconque des revendications 10 à 15, caractérisée en ce qu'elle comprend des moyens de suppression, permettant de supprimer l'acquittement retardé avant l'expiration dudit délai déterminé, en cas de réception d'un acquittement comprenant une indication qu'une donnée a été reçue par le dispositif récepteur, ladite donnée correspondant à la donnée indiquée comme étant non reçue dans l'acquittement retardé.