FR2933834A1 - Procede de gestion d'une transmission de flux de donnees sur un canal de transport d'un tunnel, 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 de flux de données sur un canal de transport d'un tunnel supporté par un réseau de communication principal, la transmission de chaque flux étant effectuée sur le canal de transport selon un protocole de transport ordonnancé par paquet et avec acquittement, 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, le dispositif émetteur et le dispositif récepteur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau. Le procédé est effectué par la première tête de tunnel et comprend les étapes suivantes : détection (600) d'une perte d'un paquet sur le canal de transport du tunnel ; identification (601, 602) d'au moins un flux ayant au moins un paquet bloqué sur le canal de transport du tunnel par la perte ; pour au moins un flux identifié, génération et transmission (604, 605 ; 800, 803, 804) d'au moins un acquittement (412) vers le dispositif émetteur ayant transmis sur le tunnel un paquet bloqué par la perte.

Description

Procédé de gestion d'une transmission de flux de données sur un canal de transport d'un tunnel, 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 canal de transport d'un tunnel 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 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.

Dans l'état de l'art, 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 (en particulier la bande passante) 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. 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 Lors d'une congestion temporaire du tunnel RPV établi sur un réseau de communication étendu (appelé ci-après réseau WAN, pour Wide Area Network en anglais), comme l'Internet par exemple, la porteuse de ce tunnel (c'est-à-dire par exemple un canal de transport de ce tunnel selon le protocole TCP) utilisant un protocole de communication fiable par acquittements va entrer en retransmission automatiquement. Ceci aura pour effet de suspendre tous les flux véhiculés dans ce canal de transport du tunnel (même ceux qui ne sont pas concernés directement par la perte du paquet encapsulant (c'est-à-dire embarquant) de la porteuse du tunnel). En effet, plusieurs flux passagers peuvent être véhiculés par un même canal de transport (c'est-à-dire même session de communication) du tunnel. De plus, par construction, le protocole TCP garantit l'ordre d'arrivée des paquets et ne fournit pas par avance à l'entité réceptrice (en l'occurrence la tête de tunnel distante) les paquets du tunnel suivant le paquet perdu de ce tunnel, c'est-à-dire qu'il n'y aura pas transfert sur le réseau LAN distant des paquets passagers reçus dont le numéro de séquence de données de la porteuse est supérieur à celui correspondant au paquet perdu du tunnel. Le déblocage de ces paquets mémorisés ne s'effectuera qu'une fois le paquet perdu retransmis par la tête de tunnel émettrice et reçu par la tête de tunnel réceptrice. On s'aperçoit que la phase de retransmission du paquet perdu a nécessité une durée aller-retour ( Round-trip-Time , ou RTT, en anglais) sur le tunnel supplémentaire par rapport à la phase de transfert classique données / acquittement (DATAIACK) d'un paquet. La durée RTT sur un tunnel Internet étant très élevée (10 ou 100 fois celle d'un réseau LAN), il est évident que cette durée RTT conditionne très fortement le comportement des connexions transportées par le tunnel (c'est-à-dire passagères du tunnel) entre des clients et serveurs distants.

Ainsi, lors d'une congestion temporaire du tunnel RPV, toutes les connexions passagères sont soumises à un retard de deux fois la durée RTT du tunnel, c'est-à-dire à un retard proche de la valeur critique du temporisateur de retransmission (appelé par la suite temporisateur RTO , pour Retransmission Time Out en anglais) de ces connexions.

Selon les fluctuations de la connexion WAN, il apparaît que les serveurs TCP émettant sur la section tunnel RPV sont soumis à une expiration de leur temporisateur RTO, produisant un effondrement de leur débit d'émission. On rappelle que l'augmentation du débit de ces serveurs est directement dépendante du délai d'acheminement vers le destinataire (RTT), dans le sens où, plus le délai est important, plus long sera le temps de recouvrement du débit d'émission initial avant effondrement. De plus, malgré la prise en charge d'une retransmission au niveau du tunnel pour le paquet encapsulant perdu, une retransmission est aussi effectuée par le serveur TCP émettant le flux passager du tunnel. En conclusion, la moindre perte sur un tunnel TCP a une incidence dévastatrice sur les performances bout-en-bout des connexions TCP embarquées dans ce tunnel.

Les mécanismes PEP sont appliqués principalement au contrôle de congestion et aux problèmes de retransmission sur les différents segments réseau empruntés par une connexion de type TCP. Afin de palier au problème précité de perte de paquet encapsulant (paquet WAN) sur la porteuse (canal de transport TCP) du tunnel, les mécanismes PEP basés sur la mémorisation temporaire ( buffering en anglais) de paquets peuvent stocker plus de données dans leur mémoire cache, mais cela a un effet limité dans le temps. Tout au plus, ces mécanismes PEP peuvent retarder le phénomène de hors temps (c'est-à-dire d'expiration, ou timeout en anglais) des connexions transportées par le tunnel, mais ceci n'est pas suffisant.

Il convient donc, et c'est une préoccupation essentielle de l'invention, de remédier à ce problème d'expiration du temporisateur RTO des connexions véhiculées dans un tunnel TCP temporairement congestionné, et ainsi de proposer une méthode efficace de contrôle de gestion du débit d'émission d'un serveur TCP véhiculant un contenu numérique transitant par ce tunnel, depuis un réseau LAN local vers un réseau LAN distant. 2.2 Etat de la technique Il existe deux catégories de principes pour l'amélioration des performances TCP dans un environnement instable (tels que l'Internet ou des liens sans-fil) : des protocoles bout-en-bout ( end-to-end protocols en anglais) et des protocoles à connexion séparée ( split-connection protocols en anglais). La 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 supportant des connexions TCP clientes bout-en-bout : le principe de cette deuxième catégorie de protocoles est d'avoir une connexion propre et caractérisée pour chaque portion de réseau hétérogène.

La plupart des principes de protocole à connexion bout-en-bout 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 WAN ou des stations de base pour des réseaux sans-fil). Deux techniques connues, permettant de palier à certains effets d'une tunnellisation TCP sur TCP, sont maintenant discutées. Une première technique connue est décrite dans le document de brevet US2006/0002301 Al (INTEL CORP. US, Transferring TCP Packets ). Ce document de brevet se positionne dans le cadre d'un tunnel TCP reliant deux réseaux LAN distants, avec des connexions TCP établies entre des équipements de ces deux réseaux LAN à travers ce tunnel. Dans le but d'éviter une double retransmission des données lors d'une perte sur le tunnel (correspondant à une retransmission par la porteuse tunnel, et une autre par le flux TCP passager), il est proposé d'implémenter un mécanisme PEP de stockage temporaire sur chaque tête de tunnel, permettant de plus un échange entre les deux têtes de tunnel d'informations relatives aux paquets effectivement reçus de part et d'autre. Dans cette première technique connue, une perte sur le tunnel est cachée aux équipements des réseaux LAN par la combinaison des effets suivants : premièrement une retransmission automatique a lieu dans le tunnel pour la donnée perdue, et deuxièmement le stockage temporaire masque pour partie le délai nécessaire à cette retransmission. Ceci permet de supprimer les retransmissions bout-en-bout (flux TCP passager) au profit d'une retransmission unique par la porteuse tunnel. La mémoire cache disponible permet ainsi de gérer localement sur chaque segment réseau (réseau LAN local, réseau WAN, réseau LAN distant) les retransmissions. Ce mécanisme répond aux problèmes de performances sur le tunnel lors d'une perte sur ce tunnel (utilisation efficace de la bande passante du tunnel aux seules retransmissions nécessaires) et lors de pertes sur le réseau distant (retransmission locale). Cependant, le mécanisme proposé ne solutionne pas l'effet d'expiration du temporisateur RTO d'un réseau LAN local en attente d'un acquittement de ses données par un client distant (connecté au réseau LAN distant).

Il est vain d'espérer que la zone de stockage temporaire, comme implémentée dans la première technique connue, permette aussi de masquer une perte sur le réseau WAN en terme de délai de transmission. Tout au plus, une fluctuation du délai d'acheminement des paquets à partir de la zone de stockage temporaire (dans chaque tête de tunnel) pourrait permettre d'allonger la perception du temporisateur RTO par le serveur TCP (non documenté dans le document de brevet cité). Une seconde technique connue est décrite dans l'article IEEE suivant : TCPSMART: a technique for improving TCP performance in a spotty wide band environment , Elaoud, M. ; Ramanathan, P. (IEEE Communications, 2000. ICC 2000 ; Page(s):1783 - 1787 vol.3 ; Digital Object Identifier 10.1109/ICC.2000.853814). Cet article décrit un mécanisme PEP de type agent espion, en charge d'effectuer des retransmissions locales et une filtration des acquittements dupliqués ( duplicate ACKs ) afin d'améliorer les performances d'une connexion TCP bout-en-bout transitant sur un environnement instable (lien sans-fil où les coupures du lien sont fréquentes). Cette seconde technique connue vise à réduire le nombre d'expirations de temporisation RTO du serveur lors des coupures du lien sans fil, ces coupures empêchant alors l'arrivée des acquittements du client TCP distant. L'agent PEP, sur la station de base sans-fil, analyse chaque connexion TCP et stocke temporairement les données à émettre sur le lien sans-fil. Quand un acquittement de ces données est reçu par l'agent en provenance du client TCP distant, ces paquets sont supprimés du cache. Si aucun acquittement n'est reçu durant un certain temps, ou si une indication d'erreur est reçue (acquittements dupliqués ( duplicate ACKs , ces données sont retransmises vers le client. C'est le comportement d'un mécanisme PEP de stockage classique. Cette seconde technique connue ajoute aussi une fonctionnalité de génération d'un acquittement dupliqué ( duplicate ACK ) destiné au serveur TCP du réseau filaire, avec un champ fenêtre d'acquittement ( advertised window en anglais) à 0, dans le but de stopper l'émission du serveur TCP. Le serveur TCP se trouve alors dans un mode suspendu, en attente de nouveaux acquittements en provenance du client (avec un champ advertised window strictement supérieur à zéro) pour le libérer de ce mode. Cette seconde technique connue vise à résoudre le même problème que l'invention (à savoir éviter le phénomène d'expiration du temporisateur RTO des serveurs TCP) dans le cadre d'une communication sur un lien sans-fil discontinu, mais n'est pas adapté aux environnements des réseaux WAN où la durée RTT est bien plus importante. En effet, le principe de stopper un serveur en émission pour éviter un engorgement des mémoires tampons ( buffers ) lors de déconnexions physiques plus ou moins longues de la porteuse sans-fil semble intéressant dans le cas d'une communication sur un lien sans-fil discontinu, mais n'est pas intéressant dans le cas d'un tunnel VPN où une perte limitée à un paquet ne signifie en aucun cas un arrêt de ce tunnel (de plus, le tunnel reste actif car retransmet les données perdues). On rappelle que les vitesses d'acheminement sur un réseau WAN (sur lequel est établi le tunnel) sont bien plus faibles que sur un réseau LAN ou un réseau WLAN (pour Wireless LAN en français, ou réseau LAN sans fil en français), et que la sous-utilisation des capacités du réseau WAN est coûteuse en termes de durée d'acheminement. Comme présenté ci-dessus, les mécanismes PEP de l'art antérieur sont principalement élaborés sur le principe d'un stockage temporaire des données, ce qui implique des ressources mémoire conséquentes dans le cadre d'une transmission sur un réseau WAN (sur lequel est établi le tunnel), puisqu'il faut stocker les données sur une durée d'au moins 2 RTT. Ceci est d'autant plus dommageable pour un tunnel RPV TCP qu'il est certain que la porteuse du tunnel se charge automatiquement de la retransmission des paquets égarés sur le WAN sur lequel est établi le tunnel. Le dispositif proposé par la seconde technique connue est plus élaboré, mais n'est pas adapté à profiter le mieux possible des capacités de transmission d'un tunnel TCP sur l'Internet. Il n'existe donc pas, dans l'art antérieur, de technique peu coûteuse en termes de ressources et permettant de maîtriser le contrôle de gestion TCP interne d'un serveur TCP de manière transparente pour le serveur et le client (respectant les principes précités de connexion TCP bout-en-bout), et qui soit adaptée à des pertes sporadiques dans un tunnel VPN. 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 canal de transport d'un tunnel, permettant de contrôler la gestion du débit d'émission d'un ou plusieurs dispositifs émetteurs (serveurs TCP par exemple), lors de la détection d'une congestion sur ce tunnel (passage du tunnel en phase de retransmission suite à une perte de données et/ou lors d'une augmentation ponctuelle de la latence de ce tunnel), et permettant une limitation minimale de la bande passante du flux d'émission de ces serveurs. Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique ne nécessitant pas de modification des piles TCP/IP par exemple des dispositifs émetteurs (serveurs) et récepteurs (clients).

Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui soit entièrement transparente pour les dispositifs émetteurs (serveurs) et les dispositifs récepteurs (clients). Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui nécessite des ressources mémoires limitées.

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 de flux de données sur un canal de transport d'un tunnel supporté par un réseau de communication principal, la transmission de chaque flux étant effectuée sur ledit canal de transport selon un protocole de transport ordonnancé par paquet et avec acquittement, 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, ledit dispositif émetteur et ledit dispositif récepteur étant connectés l'un au premier sous- réseau et l'autre au second sous-réseau, ledit procédé étant effectué par ladite première tête de tunnel et comprenant les étapes suivantes : - détection d'une perte d'un paquet sur le canal de transport du tunnel ; - identification d'au moins un flux ayant au moins un paquet bloqué sur le canal de transport du tunnel par ladite perte ; - pour au moins un flux identifié, génération et transmission d'au moins un acquittement vers le dispositif émetteur ayant transmis sur le tunnel un paquet bloqué par ladite perte. Ainsi, dans ce mode de réalisation particulier, l'invention repose sur une approche tout à fait nouvelle et inventive consistant à appliquer un correctif préventif (génération d'acquittements fictifs par la tête de tunnel d'entrée de tunnel) pour éviter le phénomène d'expiration du temporisateur RTO des dispositifs émetteurs (serveurs). Ainsi, au lieu de stopper les dispositifs émetteurs, comme dans la seconde technique connue, on les laisse croire que l'acheminement des données émises est sous contrôle et qu'ils peuvent continuer à transmettre la suite des données. On sauvegarde la bande passante du tunnel pour les données utiles : annulation des retransmissions automatiques des flux passagers du tunnel (de plus, souvent en rafales).

Cette technique est entièrement transparente pour les dispositifs émetteurs (serveurs) et les dispositifs récepteurs (clients). Il n'y a pas de modification des piles protocolaires par exemple TCP/IP des dispositifs émetteurs (serveurs) et récepteurs (clients). Cette technique nécessite des ressources mémoires limitées puisqu'il n'y a pas de débordement mémoire possible (car pas de mécanisme PEP de stockage). De façon avantageuse, pour au moins un flux identifié donné, ledit au moins un acquittement généré est un acquittement du paquet qui précède le premier paquet dudit flux identifié qui est bloqué par ladite perte. Pour le flux identifié auquel appartient le paquet dont la perte a été détectée, on considère que le premier paquet bloqué par ladite perte est un paquet retransmis sur le canal de transport du tunnel suite à la détection de la perte.

Ainsi, la transmission des acquittements générés par la première tête de tunnel indique aux dispositifs émetteurs qui les reçoivent que la connexion est toujours valide et qu'il n'y a pas de problème particulier autre qu'un retard dans l'acheminement d'un paquet pour chaque flux concerné.

Avantageusement, pour au moins un flux identifié donné, ladite étape de génération et transmission d'au moins un acquittement comprend les étapes suivantes : - détermination d'une première date d'émission tl d'un premier acquittement, en fonction d'une estimation de la durée d'un temporisateur de retransmission associé au dispositif émetteur transmettant ledit flux identifié donné, et en fonction d'une date de traitement, par ladite première tête de tunnel, dudit paquet qui précède le premier paquet dudit flux identifié qui est bloqué par ladite perte ; - transmission dudit premier acquittement à ladite première date d'émission tl. De cette façon, le correctif est particularisé pour chaque dispositif émetteur. En effet, il dépend des caractéristiques du flux concerné ainsi que son activité dans le tunnel. De façon avantageuse, ladite première date d'émission tl est définie par : tl = t0 + RTO' û A, où : - t0 est ladite date de traitement, dans ladite première tête de tunnel, dudit paquet qui précède le premier paquet dudit flux identifié qui est bloqué par ladite perte ; - RTO' est ladite estimation de la durée du temporisateur de retransmission associé au dispositif émetteur transmettant ledit flux identifié donné ; - A est une marge sécuritaire prédéterminée. Ainsi, la première date tl est simple à déterminer. Avantageusement, pour au moins un flux identifié donné, ladite étape de génération et transmission d'au moins un acquittement comprend au moins une itération des étapes suivantes : - détermination d'une nouvelle date d'émission t2 d'un nouvel acquittement, définie par : t2 = tl + RTO' û A, où tl est ladite première date d'émission, pour la première itération, ou la date d'émission t2 déterminée à l'itération précédente, pour chaque itération à partir de la deuxième ; - transmission dudit nouvel acquittement à ladite date d'émission t2.

Ainsi, par mesure de précaution, on cherche à générer, dans la première tête de tunnel, au moins un autre acquittement pour un flux identifié donné. En effet, le premier acquittement généré par la première tête de tunnel permet de pallier à une simple perte de paquet sur le tunnel, mais il souhaitable d'envisager le cas où il faudra au tunnel une durée supérieure à un RTT pour se rétablir. Ainsi, chaque deuxième date t2 est simple à déterminer. A nouveau, le correctif est particularisé pour chaque dispositif émetteur. Avantageusement, on a : RTO' = 2.RTT, avec RTT une mesure d'une durée aller-retour sur le tunnel.

Ainsi, on simplifie les calculs. On notera que la durée d'un RTT entre un dispositif émetteur et un dispositif récepteur est approximée par la durée d'un RTT du tunnel, du fait que le RTT du tunnel est très supérieur au RTT d'un réseau LAN. De façon avantageuse, pour au moins un flux identifié donné, dans ladite étape de génération et transmission d'au moins un acquittement, un acquittement est généré et transmis seulement si la première condition suivante est vérifiée : le nombre de paquets dudit flux identifié donné, qui sont en transit sur le canal de transport du tunnel et bloqués par ladite perte, est supérieur à un nombre d'acquittements générés et transmis par ladite première tête de tunnel pour ledit flux identifié donné. Cette première condition assure la transparence pour le dispositif émetteur (serveur) en garantissant une conformité au protocole de transport ordonnancé par paquet et avec acquittement (par exemple le protocole TCP), puisque le dispositif émetteur ne reçoit pas plus d'acquittements que de paquets qu'il a émis (dans TCP par exemple, un acquittement ne peut être généré par le client qu'en réponse à un paquet transmis par le serveur).

Avantageusement, pour au moins un flux identifié donné, dans ladite étape de génération et transmission d'au moins un acquittement, un acquittement est généré et transmis seulement si la deuxième condition suivante est vérifiée : un nombre d'acquittements générés et transmis par ladite première tête de tunnel, pour ledit flux identifié donné, est inférieur ou égal à un seuil prédéterminé indiquant une perte de paquet au dispositif émetteur transmettant ledit flux identifié donné.

Ainsi, on évite que le dispositif émetteur (serveur) interprète la génération d'acquittements successifs générés par la première tête de tunnel comme une perte de paquet, et donc que le dispositif émetteur retransmette le paquet supposé perdu. Selon une caractéristique avantageuse, pour au moins un flux identifié donné, il comprend une étape de filtrage des acquittements provenant, via le tunnel, du dispositif récepteur dudit flux identifié donné, et pour lesquels ladite première tête de tunnel a déjà généré et transmis un acquittement. De cette façon, on gère les effets secondaires induits par la génération d'acquittements fictifs par la première tête de tunnel, afin de ne pas perturber la machine d'état de la connexion en cours, côté dispositif émetteur (serveur). Par exemple, si le dispositif récepteur (client) distant émet un vrai acquittement dupliqué ( Duplicate ACK ) dû à un dé-séquencement léger sur le réseau LAN distant, et que la première tête de tunnel a déjà généré et émis un ou deux acquittements dupliqués fictifs , il faut filtrer (c'est-à-dire détecter et détruire) ce vrai acquittement dupliqué afin que le dispositif émetteur (serveur) ne reçoive pas un troisième acquittement dupliqué qui le ferait alors se positionner dans un mode de retransmission (avec baisse du fenêtrage TCP d'émission, ce que l'on cherche à éviter !). 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 de flux de données sur un canal de transport d'un tunnel supporté par un réseau de communication principal, la transmission de chaque flux étant effectuée sur ledit canal de transport selon un protocole de transport ordonnancé par paquet et avec acquittement, 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, ledit dispositif émetteur et ledit dispositif récepteur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau. Ladite première tête de tunnel comprend : - des moyens de détection d'une perte d'un paquet sur le canal de transport du tunnel ; - des moyens d'identification d'au moins un flux ayant au moins un paquet bloqué sur le canal de transport du tunnel par ladite perte ; - des moyens de génération et transmission, pour au moins un flux identifié, d'au moins un acquittement vers le dispositif émetteur ayant transmis sur le tunnel un paquet bloqué par ladite perte.

De façon avantageuse, pour au moins un flux identifié donné, ledit au moins un acquittement généré est un acquittement du paquet qui précède le premier paquet dudit flux identifié qui est bloqué par ladite perte. Pour le flux identifié auquel appartient le paquet dont la perte a été détectée, on considère que le premier paquet bloqué par ladite perte est un paquet retransmis sur le canal de transport du tunnel suite à la détection de la perte. Avantageusement, lesdits moyens de génération et transmission d'au moins un acquittement comprennent : - des moyens de détermination, pour au moins un flux identifié donné, d'une première date d'émission tl d'un premier acquittement, en fonction d'une estimation de la durée d'un temporisateur de retransmission associé au dispositif émetteur transmettant ledit flux identifié donné, et en fonction d'une date de traitement, par ladite première tête de tunnel, dudit paquet qui précède le premier paquet dudit flux identifié qui est bloqué par ladite perte ; - des moyens de transmission dudit premier acquittement à ladite première date d'émission tl. 30 De façon avantageuse, ladite première date d'émission tl est définie par : tl = t0 + RTO' û A, où : - t0 est ladite date de traitement, dans ladite première tête de tunnel, dudit paquet qui précède le premier paquet dudit flux identifié qui est bloqué par ladite perte ; - RTO' est ladite estimation de la durée du temporisateur de retransmission associé au dispositif émetteur transmettant ledit flux identifié donné ; - A est une marge sécuritaire prédéterminée. Avantageusement, lesdits moyens de génération et transmission d'au moins un acquittement comprennent les moyens suivants, activés au moins une fois : - des moyens de détermination, pour au moins un flux identifié donné, d'une nouvelle date d'émission t2 d'un nouvel acquittement, définie par : t2 = tl + RTO' û A, où tl est ladite première date d'émission, pour la première itération, ou la date d'émission t2 déterminée à l'itération précédente, pour chaque itération à partir de la deuxième ; - des moyens de transmission dudit nouvel acquittement à ladite date d'émission t2. Avantageusement, on a : : RTO' = 2.RTT, avec RTT une mesure d'une durée aller-retour sur le tunnel. De façon avantageuse, la première tête de tunnel comprend : - des premiers moyens de vérification, pour au moins un flux identifié donné, si la première condition suivante est vérifiée : le nombre de paquets dudit flux identifié donné, qui sont en transit sur le canal de transport du tunnel et bloqués par ladite perte, est supérieur à un nombre d'acquittements générés et transmis par ladite première tête de tunnel pour ledit flux identifié donné ; - des moyens d'activation desdits moyens de génération et transmission d'au moins un acquittement, pour ledit au moins un flux identifié donné, si lesdits premiers moyens de vérification effectuent une vérification positive. Avantageusement, la première tête de tunnel comprend : - des seconds moyens de vérification, pour au moins un flux identifié donné, si la seconde condition suivante est vérifiée : un nombre d'acquittements générés et transmis par ladite première tête de tunnel, pour ledit flux identifié donné, est inférieur ou égal à un seuil prédéterminé indiquant une perte de paquet au dispositif émetteur transmettant ledit flux identifié donné ; - des moyens d'activation desdits moyens de génération et transmission d'au moins un acquittement, pour ledit au moins un flux identifié donné, si lesdits seconds moyens de vérification effectuent une vérification positive. Selon une caractéristique avantageuse, la première tête de tunnel comprend des moyens de filtrage, pour au moins un flux identifié donné, des acquittements provenant, via le tunnel, du dispositif récepteur dudit flux identifié donné, et pour lesquels ladite première tête de tunnel a déjà généré et transmis un acquittement. 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 ; - la figure 4 schématise un scénario d'application d'un mode de réalisation particulier de l'invention, en relation avec l'environnement décrit à la figure 1 ; - 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 présente un algorithme exécuté sur détection d'une erreur de transmission du tunnel, cet algorithme étant compris dans un mode de réalisation particulier du procédé correctif de l'invention ; - la figure 7 présente un algorithme exécuté sur réception d'un acquittement provenant du tunnel pour un flux TCP passager de ce tunnel, cet algorithme étant compris dans un mode de réalisation particulier du procédé correctif de 30 l'invention ; 20 25 - la figure 8 présente un algorithme pour la génération et l'émission d'un message d'acquittement vers un serveur, cet algorithme étant compris dans un mode de réalisation particulier du procédé correctif de l'invention ; - la figure 9 schématise une architecture fonctionnelle d'un système PEP d'une tête de tunnel 101 implémentant les algorithmes d'un mode de réalisation particulier de l'invention ; - 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 tête de tunnel locale 101 et une tête de tunnel distante 102, à travers un réseau de communication 107 (Internet par exemple). Ce tunnel 100 interconnecte deux réseaux locaux : LAN A 103 et 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 30 (L2TPv3)", J. Lau and ail, March 2005 et IETF RFC2246, "The TLS Protocol Version 1.0" ), - un champ d'en-tête du protocole embarqué 253 (à savoir Ethernet dans cet exemple), et 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. La figure 4 schématise un scénario d'application d'un mode de réalisation particulier de l'invention, en relation avec l'environnement décrit à la figure 1.

Les algorithmes de ce mode de réalisation particulier de l'invention sont décrits ci-après selon une mise en place sur la tête de tunnel 101. En fait, toute tête de tunnel est capable d'exécuter l'invention. Cependant, une tête de tunnel d'entrée de tunnel mettant en place les algorithmes de l'invention ne se focalisera que sur les données TCP reçues du réseau LAN local et à destination du réseau LAN distant, via le tunnel TCP.

Dans le cas représenté en figure 4, la tête de tunnel TEP 101 analyse les données TCP émises depuis le réseau LAN (local) 103 pour entrer dans le tunnel à destination du réseau LAN (distant) 104, ainsi que les acquittements reçus du réseau LAN 104 pour ces données TCP. Dans l'exemple, deux serveurs de media 110-A et 110-B sont positionnés dans le réseau LAN 103, et deux dispositifs 112-A et 112B clients de ces serveurs sont positionnés dans le réseau local 104. Dans un souci de clarté de l'explication de l'exemple, on notera que la notion d'indice d'un paquet correspond à l'ordre d'émission d'un paquet (l'indice i d'un paquet signifie que ce paquet est le iéme paquet), et n'a pas de réalité dans le protocole de communication (à la différence du numéro de séquence qui est intégré dans chaque paquet TCP). On utilisera les notations suivantes pour les paquets TCP : - paquet 410 noté i : le segment de données TCP d'indice i (c'est à dire le iéme paquet) émis par l'un des serveurs 110-A, 110-B du réseau LAN 103 pour un numéro de séquence de données n ; - paquet 413 noté Ri : segment de données TCP identique au paquet 410 de même indice i , mais qui a été retransmis avec le même numéro de séquence de données n ; - paquet 411 noté Ai : acquittement TCP d'un paquet i ou Ri pour un numéro de séquence de données n (donc, selon le protocole TCP, ce paquet 411 contient un numéro de séquence d'acquittement n+l) ; cet acquittement 411 est émis par un client du réseau LAN 104 vers un serveur du réseau LAN 103 ; - paquet 412 noté Di : acquittement TCP d'un paquet i ou Ri pour un numéro de séquence de données n (donc, selon le protocole TCP, ce paquet 411 contient un numéro de séquence d'acquittement n+l) ; cet acquittement 412 est émis par la tête de tunnel TEP 101 (selon le mécanisme de la présente invention, voir figures 6 et 8) vers un serveur du réseau LAN 103. L'acquittement 412 est un acquittement classique (pouvant être dupliqué et alors considéré comme un Duplicate ACK par le serveur) ou un acquittement sélectif SACK (ces deux types d'acquittement sont détaillés en Annexe). Une connexion classique TCP est formée de paquets i 410 qui sont acquittés par des paquets Ai 411. Dans l'exemple de la figure 4, le tunnel convoie donc des paquets de données 410 du réseau LAN 103 vers le réseau LAN 104 et des paquets d'acquittement 411 du réseau LAN 104 vers le réseau LAN 103, pour deux connexions TCP distinctes : - une connexion A, établie entre le serveur 110-A et le récepteur 112-A (les paquets de cette connexion A sont représentés par des carrés dans lesquels 25 on retrouve les notations précitées i , Ri , Ai et Di ) ; - une connexion B, établie entre le serveur 110-B et le récepteur 112-B (les paquets de cette connexion A sont représentés par des cercles dans lesquels on retrouve les notations précitées i , Ri , Ai et Di ). On considère que la tête de tunnel TEP 101 est apte à conserver les numéros de 30 séquence des paquets 410 et 411 en transit sur le tunnel (en pratique, la trace d'un 10 15 20 segment 410 d'indice i est conservée jusqu'à réception de l'acquittement 411 lui correspondant) avec une indication de temps permettant de connaître l'ordonnancement et la date d'émission sur le tunnel. De plus, une association des numéros de séquence de données est réalisée (précisé par la suite) entre les paquets de la porteuse du tunnel et les paquets des flux passagers, afin d'identifier aisément le contenu de chaque paquet de la porteuse du tunnel (paquet embarquant). A titre d'information, la tête de tunnel TEP 101 gère une table 501 des segments TCP envoyés sur le tunnel (cette table 501 est décrite ci-dessous en relation avec la figure 5).

Phase 4-1 : détection des erreurs sur le tunnel Cette phase correspond au moment de la détection d'une erreur sur le tunnel. Par exemple, trois messages d'acquittements dupliqués ( Duplicate ACKs ) 420 ont été émis par la tête de tunnel TEP 102 pour indiquer la perte d'un paquet du tunnel. Automatiquement, après réception de trois acquittements dupliqués ( Duplicate ACKs ) pour le même numéro de séquence de données k (donc, selon le protocole TCP, avec un numéro de séquence d'acquittement k+l), la couche protocolaire TCP du tunnel va retransmettre le paquet embarquant manquant. En même temps, une alerte est levée sur la tête de tunnel TEP 101 afin de déterminer la nature des données transportées par le paquet embarquant de numéro de séquence de données k.

Dans l'exemple de la figure 4, le paquet embarquant de numéro de séquence de données k correspond au paquet 410 d'indice 3 du flux 110-A vers 112-A (connexion A). Le tunnel entre donc en retransmission pour véhiculer ces données (paquet R3 ). La tête de tunnel TEP 101 détermine ensuite quels sont les segments de données 410 bloqués dans la couche protocolaire TCP de la tête de tunnel distante 102: ce sont tous les paquets 410 du réseau local 103 ayant été émis sur le tunnel après le paquet 410 d'indice 3 de la connexion A. Dans l'exemple, les paquets 410 déterminés sont les suivants : - pour la connexion A, tous les paquets d'indice supérieur à 3 ; - pour la connexion B, tous les paquets d'indice supérieur à 2 (l'indice 2 de la connexion B précédait l'envoi du paquet d'indice 3 de la connexion A).

La détection d'une erreur sur le tunnel est réalisée après la réception de trois acquittements dupliqués ( Duplicate ACKs ), c'est-à-dire après un temps aller-retour sur le tunnel (RTT du tunnel, entre la tête de tunnel TEP 101 et la tête de tunnel 102). C'est pourquoi on s'aperçoit sur la figure 4 que la transmission du paquet 413 d'indice R3 sur le tunnel (retransmission de la donnée perdue) coïncide à peu près avec la transmission dans le sens inverse vers le réseau LAN 103 des acquittements 411 pour les paquets non bloqués et reçus par les clients distants. Cela signifie donc que les futurs acquittements, pour les séquences suivantes des connexions A et B, ne seront reçus sur le réseau LAN 103 qu'après un temps aller- retour entre le serveur et le client (approximé à un autre temps aller-retour sur le tunnel, du fait que le RTT du tunnel est très supérieur au RTT de chacun des réseaux LAN 103 et 104). C'est pourquoi la Phase 4-2 suivante vise à appliquer un correctif préventif (génération d'acquittements 412 par la tête de tunnel TEP 101) pour éviter le phénomène d'expiration du temporisateur RTO des serveurs TCP 110-A et 110-B, et ce correctif sera particularisé pour chaque serveur 110-A et 110-B du réseau LAN 103. Phase 4-2 : application d'un correctif au problème d'expiration du temporisateur RTO Cette phase est décomposée en deux étapes 4-2a et 4-2b : l'une (4-2a) calcule une temporisation pour l'émission des messages d'acquittement 412 et l'autre (4-2b) génère l'envoi de ces messages d'acquittement 412 sur expiration de cette temporisation. Ainsi, pour chaque flux passager du tunnel, il est déterminé la date t0 de traitement par la tête de tunnel TEP 101 du premier paquet 410 bloqué (pour le flux concerné par la retransmission sur le tunnel, on considère que le premier paquet bloqué est le paquet 410 en retransmission). Suite à la mesure continue du RTT du tunnel, il est déterminé pour chaque flux une date tl à laquelle une émission d'un message d'acquittement 412 est programmée. Cette date tl correspond à (t0 + 2.RTT û A), où A est une marge sécuritaire de quelques millisecondes. On rappelle que la durée du temporisateur RTO de chaque serveur 110- A, 110-B est sensiblement égale à 2.RTT du tunnel, et que le correctif préventif de l'invention consiste à envoyer à chaque serveur un message d'acquittement 412 avant l'expiration du temporisateur RTO de chaque serveur, de façon à réinitialiser ce temporisateur RTO à zéro et donc éviter son expiration.

Pour cela, on enregistre une entrée dans une table de temporisation 510 (voir Figure 5) comprenant les informations nécessaires à la génération des messages d'acquittement 412 vers les serveurs 110-A et 110-B. Si le blocage perdure dans le tunnel, il est préférable de procéder aussi à la détermination d'une ou plusieurs secondes temporisation, pour déterminer une ou plusieurs dates t2 d'émission d'autres messages d'acquittement 412 vers les serveurs TCP 110-A, 110-B concernés. A la réception des véritables acquittements 410 initiés par les clients 112-A, 112-B en provenance du réseau LAN 104 distant et véhiculés par le tunnel, il est procédé à une suppression des temporisations ultérieures (pas d'envoi ultérieur de messages d'acquittement 412 générés par la tête de tunnel TEP 101).

De plus, comme présenté par la suite, il est procédé au filtrage des véritables acquittements 411 initiés par les clients 112-A, 112-B, correspondant aux acquittements 412 générés, afin de ne pas envoyer trop de messages d'acquittement. En effet, par exemple, une accumulation de trois acquittements dupliqués ( Duplicate ACKs ) conduirait le serveur à analyser qu'une erreur s'est produite sur le réseau, ce que l'on souhaite éviter. On présente maintenant, en relation avec la figure 5, différentes tables 550, 501, 510 et 520 de structures de données. Chaque flux de données est caractérisé par son adresse IP source, son port TCP source, ainsi que son adresse IP destination et son port TCP destination. Il est à noter qu'une même session TCP peut véhiculer deux flux de données car la communication TCP est bidirectionnelle. Chaque table ci-dessous est décrite à titre d'exemple non limitatif. La table 550 est la table des flux actifs sur une tête de tunnel. On entend ici par flux actif, un flux associé à une session TCP établie et non close. Cette table 550 comprend : - un champ 551 représentant, pour chaque flux, un identifiant unique affecté à ce flux et servant de référence pour les autres structures de données relatives à un flux ; - des champs 552 et 554 représentant respectivement les adresses IP source et destination de la session TCP ; - des champs 553 et 555 représentant respectivement les ports source et destination de la session TCP ; - un champ 556 correspondant au type de message d'acquittement supporté par la connexion. Par exemple, acquittement de type classique (ACK) ou acquittement de type sélectif (SACK). La table 501 représente les données relatives aux paquets TCP 410, pour chaque flux actif de la table 550, qui sont en transfert sur le tunnel. Il existe une entrée dans la table pour chaque paquet TCP d'un flux passager transféré sur le tunnel et non encore acquitté. Cette table 501 comprend : 15 - un champ 502 représentant une date tO de traitement du segment/paquet TCP par la tête de tunnel 101, comme par exemple la date d'émission du segment/paquet TCP dans le tunnel (de manière approximative, en négligeant le temps nécessaire à l'encapsulation du paquet 410, cette valeur peut être assimilée à la date de réception du paquet 410 par la tête 20 de tunnel, en provenance du réseau LAN local) - un champ 503 représentant l'identifiant de flux 551 ; - un champ 504 représentant un numéro de séquence de données n d'un paquet de flux passager , c'est-à-dire un numéro de séquence de donnée TCP (paquet TCP 410, c'est-à-dire un segment passager) reçue par la tête 25 de tunnel 101 en provenance du réseau LAN, pour le flux 551 concerné ; - un champ 505 représentant un numéro de séquence de données k d'un paquet embarquant de la porteuse du tunnel , c'est-à-dire un numéro de séquence de donnée TCP de la porteuse du tunnel (paquet embarquant) qui convoie le segment passager (paquet TCP 410) indiqué en 504. 10 La table 510 représente une table de stockage de valeurs de temporisation pour la génération ultérieure de messages d'acquittement 412. Il existe une entrée dans la table pour chaque émission programmée. Cette table 510 comprend : - un champ 512 représentant la date d'expiration (tl par exemple) à laquelle le message d'acquittement 412 doit être généré ; - un champ 513 représentant l'identifiant de flux 551 ; - un champ 514 représentant un numéro de séquence d'acquittement `j' qui acquitte le numéro de séquence de données `n' (n = j-1) enregistré dans la table 501 (champ 504) pour le même identifiant de flux (champs 503 (table501) et 551 (table550)). Donc, selon le protocole TCP, le champ 514 contient le numéro de séquence d'acquittement `j' (qui indique que le numéro de séquence de données `j-1' a été bien reçu, et que le numéro de séquence de données `j' est attendu). La table 520 représente une table de comptage des messages d'acquittement 412 générés pour chaque flux. Cette table 520 comprend : - un champ 522 représentant l'identifiant de flux 513 ; - un champ 523 représentant le numéro de séquence d'acquittement 514. En pratique, on ne conserve dans la table 520 qu'une entrée par flux 513 correspondant au dernier acquittement 412 généré (les acquittements 412 générés au préalable pour des segments antérieurs n'ont plus d'importance car ils acquittent des numéros de séquences de données plus faibles, et le présent dernier acquittement généré acquitte intrinsèquement tous les segments antérieurs selon le protocole d'acquittement ordonnancé du protocole TCP) ; - un champ 524 représentant le nombre de messages d'acquittement 412 générés par la tête de tunnel pour le numéro de séquence d'acquittement 523 précité du flux concerné 522 ; - un champ 525 représentant le nombre de messages d'acquittement 411 reçus par la tête de tunnel via le tunnel et en provenance du client distant 112-A ou 112-B, pour le numéro de séquence d'acquittement 523 précité du flux concerné 522. La figure 6 présente un algorithme exécuté sur détection d'une erreur de transmission du tunnel, cet algorithme étant compris dans un mode de réalisation particulier du procédé correctif de l'invention, implémenté sur une tête de tunnel TEP (101 par exemple). La tête de tunnel TEP 101 supervise les flux de données des connections actives qui transitent par le tunnel. De manière préférentielle, on se place dans le cadre d'une tête de tunnel TEP qui gère le routage des flux TCP passagers sur le tunnel 100, c'est-à-dire que la tête de tunnel TEP 101 sait identifier les flux TCP sur son port d'entrée qui vont transiter dans le tunnel. Par exemple, on peut raisonnablement considérer deux types de flux TCP : ceux correspondants à des transferts importants (et notamment durables) et les flux de commande (quelques messages aller-retour). Ainsi, seule la première catégorie de flux TCP est considérée par un mode de réalisation particulier de l'invention : ceci permet d'allouer une bande passante pour des flux qui peuvent en bénéficier. De tels flux sont détectables par exemple par réception par la tête de tunnel TEP de requêtes de qualité de service QoS, telles que des requêtes UPnP QoS ou SBM ou tout autre protocole QoS en activité sur l'un des réseaux LANs. Des requêtes de priorité pour des flux permettent de connaître la nature de ces flux : dans le standard IEEE802.1Q, les priorités 4 à 6 correspondent respectivement à des flux de lecture en continu ( streaming en anglais), de transferts vidéo et de transferts audio. Ces requêtes QoS embarquent toutes les références nécessaires par la suite à une identification du flux TCP (adresses source et destination, ports, protocole). Il est bien entendu que, dans l'exemple proposé, seuls les flux de protocole de transport TCP sont considérés. De plus, lors de la détection de l'ouverture d'une connexion TCP (paquet TCP avec drapeau SYN, voir Annexe), une analyse plus approfondie des protocoles applicatifs permet de connaître les caractéristiques du transfert : par exemple, un flux TCP embarquant un protocole applicatif http (253) contient des informations représentant le type de media demandé (message http GET pour une vidéo avec un MIME TYPE video/mpeg ). Ces exemples sont donnés à titre d'exemple non limitatif. On considère dans un mode particulier de l'invention que tout autre flux TCP non identifié comme précisé ci-dessus est véhiculé sur le tunnel sans contrôle de gestion par la tête de tunnel TEP 101. Ceci a l'avantage de conserver les ressources processeur et mémoire de la tête de tunnel TEP 101 disponibles pour les flux d'importance forte. Il est bien entendu que, dans une variante, le procédé de l'invention reste applicable sur tous les flux TCP qui transitent par le tunnel. Dans un autre mode de fonctionnement particulier, il est aussi procédé à la détermination du type d'acquittement usité par chaque connexion TCP. L'extension SACK (conformément au document RFC2018) utilise deux champs optionnels dans les messages TCP. Le premier est une option d'activation SACK-permitted , validée ou non dans le segment TCP SYN au démarrage de la connexion, indiquant la possibilité d'utiliser le mécanisme SACK par la suite. Le second est l'option SACK , qui est validée au cours de la transmission pour un acquittement sélectif, si autorisée lors de l'établissement de la connexion TCP. La table des flux 550 (voir figure 5) est mise à jour régulièrement à chaque ouverture/fermeture d'une nouvelle connexion TCP. De plus, la table 501 (voir figure 5) gère les segments de données et acquittements reçus par exemple par la paire client- serveur TCP (110-A et 112-A) dans le cadre de l'environnement décrit à la figure 1. La présente invention n'a pas pour objectif de revendiquer la manière de remplir la table 550. Il existe plusieurs techniques de l'art antérieur pour ceci. Pour les flux considérés, la tête de tunnel TEP 101 conserve (table 501) les numéros de séquence TCP des segments (paquets) de données (DATA) qui passent par la tête de tunnel TEP 101. C'est-à-dire qu'à tout moment, la tête de tunnel TEP 101 a connaissance du nombre ( flightsize ) de paquets envoyés dans le tunnel et non acquittés. De plus, une tête de tunnel obtient les caractéristiques du connecteur réseau ( socket en anglais) ouvert pour le canal TCP du tunnel (par exemple, en utilisant l'API Unix Socket Interface ) ce qui lui permet de connaître les erreurs sur le tunnel.

API signifie Application Programming Interface , ou interface de programmation en français. De manière préférentielle, une pile protocolaire TCP modifiée est utilisée par la tête de tunnel TEP 101 afin de remplir la table 501. Soit la pile protocolaire met à jour la table 501 directement lors de la réception, par la fonction routage de la tête de tunnel TEP 101, d'une commande d'envoi de données des flux passagers sur le tunnel. Soit une information supplémentaire sur le numéro de séquence de données TCP du tunnel est indiquée au retour de la commande d'envoi de données via l'API Unix Socket Interface , et c'est la tête de tunnel TEP elle-même qui met à jour la table 501.

Lors de la détection d'une erreur sur le tunnel, l'API Unix Socket Interface est capable d'alerter les algorithmes de l'invention, et notamment réveille l'étape 600 de la figure 6. On notera que le tunnel TCP gère de lui-même la retransmission des paquets perdus. L'étape 601 consiste à déterminer, à partir de la table 501 et en connaissance du numéro de séquence de données du paquet perdu de la porteuse TCP du tunnel (identifiant 505), le flux passager concerné (identifiant 503) et le numéro de séquence de données du paquet véhiculé 410 (numéro 504) qui était transporté par le paquet perdu de la porteuse TCP. A l'étape 602, toujours à partir de la table 501, on détermine pour chaque autre flux véhiculé sur le tunnel, le premier numéro de séquence de données émis après le paquet 410 déterminé à l'étape 601. Il s'agit des numéros de séquence de données sur lesquels va s'appliquer le principe de génération des messages de l'invention vers leurs serveurs TCP relatifs. A l'étape 603, il peut être procédé à un ordonnancement sélectif des flux TCP passagers parmi ceux éligibles tels que précisé ci-dessus, et seuls les flux sélectionnés sont considérés, un à un, pour l'exécution des étapes 604 et 605. Sinon, tous les flux déterminés précédemment sont considérés, un à un, pour l'exécution des étapes 604 et 605. Plusieurs options sont possibles pour l'ordonnancement : - les flux TCP en phase de démarrage lent ( slow start en anglais, voir en Annexe) sont considérés comme prioritaires en raison de l'accroissement plus important de leur fenêtre de congestion dans cette phase, dont on ne connaît a priori pas la limite (SSTHRESH) ; - il est préférablement écarté un flux TCP souffrant de faible fenêtrage en phase stabilisée (phase d'évitement de congestion, congestion avoidance en anglais, voir annexe). Un affaiblissement de la fenêtre n'aura que peu d'incidence ; - la valeur de la fenêtre d'acquittement ( advertized-window en anglais, voir Annexe) émise par un client permet de connaître les flux proposant la plus grande marge pour l'accroissement du débit ; - sont considérés comme prioritaires les flux ayant émis des données dans un espace de temps très proche du flux passager déterminé en 601 (c'est-à-dire subissant la retransmission sur le tunnel). On notera que le flux déterminé en 601 est le premier sur lequel vont s'appliquer les algorithmes correctifs de l'invention. Dans l'étape 604, on détermine la première date d'émission tl (première temporisation) d'un message d'acquittement 412 généré, selon l'invention, vers le serveur TCP.

Dans l'étape 605, on programme l'envoi de ce message d'acquittement 412, dans la table 510 des envois programmés. On notera la particularité de la détermination de la première date d'émission tl. Une seconde date d'émission t2 (seconde temporisation) peut éventuellement être programmée ultérieurement, comme décrit en détails en relation avec l'étape 807 de la figure 8). La première date d'émission tl d'un message d'acquittement 412, pour chaque flux passager du tunnel auquel sont appliquées les étapes 604 et 605, dépend fortement de la valeur de la mesure continue du RTT du tunnel (paramètre commun pour tous les flux passagers), ainsi que la date t0 de traitement par la tête de tunnel 101 du premier paquet bloqué du flux passager considéré (une date t0 particulière à chaque flux). Ainsi, l'activation d'une première temporisation est particularisée pour chaque flux et est coordonnée avec l'activité de ce flux afin d'être le moins intrusif possible. On rappelle que la première date d'émission tl, programmée pour la génération d'un message d'acquittement 412 (activation de l'algorithme de la figure 8) est obtenue comme suit : tl = t0 + 2.RTT ù A, où A est une marge sécuritaire de quelques millisecondes (par exemple 10% du RTT tunnel). La figure 7 présente un algorithme exécuté sur réception d'un acquittement provenant du tunnel pour un flux TCP passager de ce tunnel, cet algorithme étant compris dans un mode de réalisation particulier du procédé correctif de l'invention, implémenté sur une tête de tunnel TEP (101 par exemple). A l'étape 700, la tête de tunnel TEP 101 est alertée de la réception d'un message d'acquittement TCP d'une connexion embarquée (par exemple, en relation avec la figure 4, un acquittement 411 en provenance du client 112-A suite à l'envoi d'un segment 410 par le serveur 110-A).

Dans l'étape 701, après réception d'un acquittement 411 en provenance du client 112-A, correspondant à un ou plusieurs numéros de séquence de données de segments (paquets) 410 envoyés via le tunnel, il est procédé à une analyse de cet acquittement 411. Cet acquittement 411 peut aussi bien être classique (conformément au document RFC793) ou de type SACK (conformément au document RFC2018). Dans les deux cas, il est procédé à la détermination, pour le flux concerné, des entrées dans la table 501 ayant pour numéro de séquence de données 504 une valeur inférieure ou égale au numéro de séquence d'acquittement indiqué dans l'acquittement 411. Puis, toutes les entrées ainsi déterminées sont supprimées de la table 501. Même si l'acquittement 411 est de type SACK et indique qu'une erreur de transmission a eu lieu pour certains numéros de séquence, le numéro de séquence d'acquittement rapporté par le message de type SACK est considéré : cela signifie que tous les paquets 410 jusqu'à ce numéro (maximal) de séquence d'acquittement ont été transmis par la tête de tunnel TEP 102 sur le réseau local, mais semble-t-il avec pertes. Dans l'étape 702, une recherche dans la table 510 indique si le procédé correctif de l'invention a été mis en place (c'est-à-dire si l'étape 605 de la figure 6 a été effectuée) pour le flux concerné. C'est le cas s'il est déterminé une entrée de cette table ayant un champ 513 correspondant à l'identifiant de la connexion courante véhiculant l'acquittement 411. Si le test 702 est négatif, on passe directement à l'étape 705. Si le test 702 est positif, la recherche est affinée dans l'étape 703 en vérifiant que le numéro de séquence d'acquittement de l'acquittement 411 a un rapport avec la mesure corrective mise en place. S'il existe une entrée de la table 510 qui réponde aussi au critère de champ 514 correspondant à la séquence acquittée par l'acquittement 411, alors l'étape 704 est exécutée. Dans le cas de la mise en place de l'option SACK, le champ 514 doit être compris indifféremment dans la liste du message SACK des séquences acquittées de l'acquittement 411 (un acquittement positif correspond au cas classique où l'option SACK n'est pas utilisée) ou dans la liste (du message SACK) des séquences en erreur (dans ce cas, un segment a été perdu et alors le serveur doit être mis au courant). L'étape 704 consiste à effacer l'entrée programmée dans la liste 510 des temporisations, afin d'arrêter la mesure corrective suite à la détection de perte sur le tunnel. Puis, on passe à l'étape 705. Le test de l'étape 705 permet de savoir si une mesure corrective a été mise en place par le passé sur le flux passager courant, afin de ne pas déstabiliser cette connexion TCP suite à la génération des messages d'acquittement 412 (voir Figure 8 pour la génération). On recherche si le flux est identifié dans la table 520 de comptage des messages d'acquittement 412 générés par l'invention. Si le test 705 est négatif, on ne filtre pas l'acquittement 411 qui sera envoyé normalement sur le réseau LAN 103 (étape 708). Si le test 705 est positif, on procède au test de l'étape 706 pour savoir si l'acquittement 411 acquitte un segment pour lequel on a généré des acquittements 412 sur le réseau LAN 103. Si le test 706 est négatif, on vérifie alors (test de l'étape 707) si le message d'acquittement 411 acquitte un numéro de séquence de données supérieur au numéro de séquence de données acquitté par le numéro de séquence d'acquittement enregistré dans la table 520. En d'autres termes, on vérifie si l'acquittement 411 acquitte plusieurs segments DATA 410 y compris celui considéré dans la table 520. Si le test 707 est positif, il est procédé à la suppression de l'entrée courante dans la table 520 (étape 711), et l'acquittement 411 sera envoyé normalement sur le réseau LAN 103 (étape 708). Si le test 707 est négatif, on passe directement à l'étape 708.

Si le test 706 est positif, l'acquittement courant 411 correspond exactement à un acquittement 412 généré par l'invention (voir Figure 8). Les statistiques de réception d'un acquittement 411 sont mises à jour (champ 525 incrémenté à l'étape 709) et une vérification est effectuée pour savoir si l'acquittement 411 courant peut être relayé sans problème sur le réseau LAN 103 (test de l'étape 710).

Ainsi, tant qu'il n'a pas été reçu plus d'acquittements 411 que l'on a généré d'acquittements 412 (test 710 négatif), les acquittements 411 sont détruits (filtrage de l'étape 712). S'il y a plus d'acquittements 411 reçus (test 710 positif), cela signifie que l'invention a rétabli l'équilibre dans le nombre d'acquittements que recevra le serveur TCP 110, et que la mesure de suppression des effets secondaires induits par la génération des acquittements 412 fictifs peut être levée : passage à l'étape 711 déjà décrite ci-dessus. De manière préférentielle (non représenté sur la Figure 7), dans le cas où l'acquittement 411 est de type acquittement SACK, il est procédé de manière itérative à la suite des étapes 705 à 708 décrites ci-dessus pour chacune des séquences de données référencées dans l'acquittement 411 (acquittement positif ou non). La figure 8 présente un algorithme exécuté sur expiration d'une temporisation indiquant une première date tl (voir étapes 604 et 605 de la figure 6) pour la génération et l'émission d'un message d'acquittement 412 vers un serveur TCP local, cet algorithme étant compris dans un mode de réalisation particulier du procédé correctif de l'invention, implémenté sur une tête de tunnel TEP (101 par exemple). A l'étape 801, on détermine les entrées de la table de programmation 510 pour lesquelles une action de génération d'un acquittement 412 est nécessaire. Pour chaque entrée déterminée (test de l'étape 802), la suite d'étapes 803 à 809 est effectuée.

Dans l'étape 803, les paramètres nécessaires à la création du message d'acquittement 412 sont récupérés des différentes tables : - la table 510 indique le flux concerné (champ 513) et le numéro de séquence d'acquittement (champ 514) pour lesquels un acquittement 412 doit être généré ; - à partir de l'identifiant du flux 513 et avec la table 550, les champs 552 à 555 permettent de former l'entête IP du message, et le champ 556 indique le type d'acquittement supporté. Par défaut, le type classique selon la norme RFC793 peut être constamment utilisé, mais il est recommandé de préférer l'utilisation du support SACK lorsqu'il est supporté par le serveur. L'étape 804 crée le message d'acquittement 412 (selon l'état de l'art) et l'envoie sur le réseau local 103. L'entrée courante peut alors être supprimée de la table 510 (étape 805), et on incrémente les statistiques de génération des messages d'acquittement 412 dans la table 520 (étape 806). Si besoin, une nouvelle entrée est créée dans la table 510, avec un champ 524 à 1 et un champ 525 à 0. Par mesure de précaution, il est important de rechercher à effectuer ultérieurement une nouvelle génération de messages d'acquittement 412. En effet, la présente génération en étape 804 permet de pallier à une simple perte sur le tunnel, mais il est souhaitable d'envisager le cas où le tunnel mette plus de 1 RTT pour se rétablir. Ainsi, le test de l'étape 807 vérifie la possibilité d'une nouvelle génération d'un message d'acquittement 412 et l'étape 808 calcule alors la date t2 recommandée pour l'envoi sur le réseau LAN 103 du nouveau message d'acquittement 412. Tout d'abord, on vérifie si un message peut être généré, par les deux conditions suivantes réunies : Condition 1 : N doit être supérieur ou égal à 1 avec : N = Nb_paquet_410 ù Nb_paquet_412 ; où : Nb_paquet _410 est le nombre de paquets 410 (de numéro de séquence de données supérieur au numéro de séquence de données acquitté par le numéro de séquence d'acquittement du champ 523 de l'entrée courante de la table 520) en transit sur le tunnel, donc référencés dans la table 501 ; et Nbûpaquetû412 est le nombre de paquets d'acquittement 412 générés (valeur du champ 524 de l'entrée courante de la table 520).

En d'autres termes, la condition 1 peut aussi s'exprimer comme suit : Nbûpaquetû410 > Nbûpaquetû412. Condition 2 : Nbûpaquetû412 doit être inférieur ou égal à 3. En effet, s'il était généré plus de trois messages d'acquittement 412 identiques, alors le quatrième de ces messages d'acquittements identiques serait considéré comme le troisième acquittement dupliqué ( duplicate ACK ) et le serveur l'interpréterait comme une erreur de transmission (ce que l'on veut éviter). Si les deux conditions précitées ne sont pas vérifiées, la procédure s'achève pour l'entrée courante (retour à l'étape 802). Si les deux conditions précitées sont vérifiées, l'étape 808 est mise en oeuvre. La nouvelle date t2 à programmer pour la génération de messages d'acquittement 412 est obtenue comme suit : t2 = date courante + 2.RTT û A où A est une marge sécuritaire de quelques millisecondes (par exemple 10% du RTT tunnel), et date courante est la date de génération de l'acquittement 412 précédent (c'est-à-dire tl). Une fois la date d'émission t2 déterminée, la programmation du nouvel envoi est effectuée à l'étape 809. Comme la première date d'émission tl, la seconde date d'émission t2 d'un message d'acquittement 412, pour chaque flux passager du tunnel auquel sont appliquées les étapes 808 et 809, dépend fortement de la valeur de la mesure continue du RTT du tunnel (paramètre commun pour tous les flux passagers), ainsi que de la date tl (particulière à chaque flux). Ainsi, l'activation d'une seconde temporisation (déterminant t2) est particularisée pour chaque flux et est coordonnée avec l'activité de ce flux afin d'être le moins intrusif possible.

Il est bien entendu que tout arrêt de transmission (message TCP SYN-FIN détecté, voir Annexe) pour la connexion TCP entre un serveur 110-A, 110-B et un client 112-A, 112-B pour un flux sélectionné par les algorithmes de l'invention, arrête automatiquement la mise en place de l'algorithme de la figure 8. Pour ce faire (non représenté sur les schémas), dès l'arrêt d'une connexion TCP, les tables 550, 501, 510 et 520 sont purgées des entrées référençant la connexion TCP close. La figure 9 schématise une architecture fonctionnelle d'un système PEP d'une tête de tunnel 101 implémentant les algorithmes de l'invention. La tête de tunnel TEP 101 est formée principalement de deux ports de communication avec le réseau LAN 103 : un port d'entrée 910 et un port de sortie 920. En pratique, ces deux ports ont une même interface physique bidirectionnelle de type Ethernet (port réseau 1020 selon la Figure 10). Ces deux ports sont connectés au canal TCP 930 du tunnel reliant les deux réseaux LAN 103 et 104, et communiquent via un multiplexeur 931 en charge d'encapsuler les flux passagers dans les trames tunnels et un démultiplexeur 932 en charge de dés-encapsuler les trames transportées par la porteuse TCP du tunnel. Lors de l'arrivée de trames Ethernet du réseau LAN 103, le sélecteur de flux TCP 911 est en charge d'appliquer les mesures de sélection détaillées en relation avec l'étape 600 de la Figure 6.

Si la trame d'entrée concerne un flux TCP non sélectionné, cette trame Ethernet est fournie au multiplexeur 931 en vue d'être encapsulée et émise dans le tunnel. Si la trame d'entrée concerne un flux TCP sélectionné, l'agent 912 analyse le type de segment TCP véhiculé (DATA ou ACK), et met à jour les statistiques des tables 550 et 501.

Sur alerte par le contrôleur 940 du tunnel d'une erreur de transmission, le système PEP 913 de génération de messages d'acquittement 412 implémente l'algorithme décrit sur la figure 6. Un armement du temporisateur (table 510) interne à ce système PEP 913 permettra de réveiller la procédure de l'algorithme de la figure 8 au moment opportun.

A l'inverse, lors de la réception d'une trame du tunnel, le démultiplexeur 932 fournit la trame Ethernet d'origine au commutateur de flux 933. Le commutateur de flux 933 est alors en charge de vérifier si la trame est relative à une connexion TCP et dans le cas positif, si cette connexion TCP est surveillée (recherche de critères identiques au sélecteur de flux TCP 911). Si ce n'est pas le cas, la trame Ethernet est transmise sur le réseau local 103 via le module d'interface de sortie 936. Sinon, elle est transmise au module 934 en charge de mettre à jour les statistiques de la connexion (étape 701 de l'algorithme de la Figure 7). Le module 935 réalise la suite de l'algorithme de la Figure 7, avec notamment la capacité de filtrage (suppression) des messages 411. Toute trame Ethernet, qui ne correspond pas à un message d'acquittement 411 pour lequel un message d'acquittement 412 a déjà été transmis, sera envoyée sur le réseau LAN 103 via le module d'interface de sortie 936. Le module 935 informe aussi le système PEP 913 quant à l'activation/désactivation du temporisateur pour le message d'acquittement 411 reçu (tel que décrit en relation avec la figure 7). 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).5 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 ( Duplicate ACK ) 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 (ou duplicate ACKs 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 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. Options les plus courantes de TCP Acquittements sélectifs (SACKs, pour Selective Acknowledgments ) L'option SACK est une option du protocole TCP permettant de mettre en oeuvre une politique de retransmission sélective [RFC 2018]. Cette option vise à offrir une information plus riche pour les reprises de pertes. En effet, les acquittements ACKs positifs cumulatifs fournissent une information limitée, une source TCP n'apprend l'existence que d'une seule perte de paquet par RTT. L'extension SACK donne au 20 protocole TCP les moyens de dépasser cette limitation. Le mécanisme SACK est mis en oeuvre dès que le récepteur (client) s'aperçoit d'une rupture de séquence dans le flux TCP. Le récepteur retourne alors à l'émetteur un acquittement sélectif ( Selective ACK ) contenant le dernier numéro d'octet reçu en séquence (champ ACK traditionnel de l'entête TCP) et une liste de plages d'octets 25 contiguës correctement reçus servant à indiquer la position des dernières ruptures de séquence observées dans la fenêtre courante. Les acquittements sélectifs [selon RFC2018] permettent de pallier la perte de plusieurs segments par fenêtre sans avoir à effectuer un (ou plusieurs) allers-retours par perte. 30 Algorithme d'émission limitée ( Limited transmit en anglais) 10 15 Comme décrit plus haut, une retransmission pour un segment donné est réalisée après la réception de trois acquittements dupliqués ( duplicate ACKs ). Dans le cas où d'autre pertes ont eu lieu pour des segments suivants, cela prend un RTT de plus avant de recevoir un acquittement ACK correct avec le dernier numéro de séquence contigu reçu. Il faudra encore trois autres acquittements dupliqués ( duplicate ACKs ) pour réaliser que le segment identifié a été perdu. En fonction de la fenêtre CWND courante, il peut arriver que le serveur ne soit pas autorisé à envoyer suffisamment de segments de données pour la génération de tous les acquittements dupliqués ( duplicate ACKs ) nécessaires.

Le temporisateur de retransmission RTO va donc expirer, et le serveur entrer en mode démarrage lent ( slow start ). La norme RFC3042 ( Enhancing TCP's Loss Recovery Using Limited Transmit ) vise à réduire le nombre de ces expirations ( timeouts en anglais). L'algorithme d'émission limitée ( Limited Transmit ) recommande donc l'envoi par le serveur d'un segment de données pour chacun des deux premiers acquittements dupliqués ( duplicate ACKs ) reçus. Cette méthode augmente la probabilité d'un client de pouvoir émettre les trois acquittements dupliqués ( duplicate ACKs ) nécessaires à la notification d'une erreur. Le mécanisme d'émission limitée ( Limited Transmit ) peut être utilisé en conjonction ou isolement avec le mécanisme SACK.

Claims (20)

1. REVENDICATIONS1. Procédé de gestion d'une transmission de flux de données sur un canal de transport d'un tunnel (100) supporté par un réseau de communication principal (107), la transmission de chaque flux étant effectuée sur ledit canal de transport selon un protocole de transport ordonnancé par paquet et avec acquittement, 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 ; 110-A, 110-B) vers un dispositif récepteur (112 ; 112-A, 112-B), ledit dispositif émetteur et ledit dispositif récepteur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau, ledit procédé étant effectué par ladite première tête de tunnel (101) et étant caractérisé en ce qu'il comprend les étapes suivantes : - détection (600) d'une perte d'un paquet sur le canal de transport du tunnel ; - identification (601, 602) d'au moins un flux ayant au moins un paquet bloqué sur le canal de transport du tunnel par ladite perte ; - pour au moins un flux identifié, génération et transmission (604, 605 ; 800, 803, 804) d'au moins un acquittement (412) vers le dispositif émetteur ayant transmis sur le tunnel un paquet bloqué par ladite perte.
2. 2. Procédé selon la revendication 1, caractérisé en ce que, pour au moins un flux identifié donné, ledit au moins un acquittement généré (412) est un acquittement du paquet qui précède le premier paquet dudit flux identifié qui est bloqué par ladite perte, et en ce que, pour le flux identifié auquel appartient le paquet dont la perte a été détectée, on considère que le premier paquet bloqué par ladite perte est un paquet retransmis (413) sur le canal de transport du tunnel suite à la détection de la perte.
3. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que, pour au moins un flux identifié donné, ladite étape de génération et transmission d'au moins un acquittement (412) comprend les étapes suivantes : - détermination d'une première date d'émission tl d'un premier acquittement (412), en fonction d'une estimation de la durée d'un temporisateur de retransmission associé au dispositif émetteur transmettant ledit flux identifié donné, et en fonction d'une date de traitement, par ladite première tête de tunnel,dudit paquet qui précède le premier paquet dudit flux identifié qui est bloqué par ladite perte ; - transmission dudit premier acquittement (412) à ladite première date d'émission tl.
4. 4. Procédé selon les revendications 2 et 3, caractérisé en ce que ladite première date d'émission tl est définie par : tl = t0 + RTO' û A, où : - t0 est ladite date de traitement, dans ladite première tête de tunnel, dudit paquet qui précède le premier paquet dudit flux identifié qui est bloqué par ladite perte ; - RTO' est ladite estimation de la durée du temporisateur de retransmission associé au dispositif émetteur transmettant ledit flux identifié donné ; - A est une marge sécuritaire prédéterminée.
5. 5. Procédé selon la revendication 4, caractérisé en ce que, pour au moins un flux identifié donné, ladite étape de génération et transmission d'au moins un acquittement (412) comprend au moins une itération des étapes suivantes : - détermination d'une nouvelle date d'émission t2 d'un nouvel acquittement (412), définie par : t2 = tl + RTO' û A, où tl est ladite première date d'émission, pour la première itération, ou la date d'émission t2 déterminée à l'itération précédente, pour chaque itération à partir de la deuxième ; - transmission dudit nouvel acquittement (412) à ladite date d'émission t2.
6. 6. Procédé selon l'une quelconque des revendications 4 et 5, caractérisé en ce que : RTO' = 2.RTT, avec RTT une mesure d'une durée aller-retour sur le tunnel.
7. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que, pour au moins un flux identifié donné, dans ladite étape de génération et transmission d'au moins un acquittement (412), un acquittement est généré et transmis seulement si la première condition suivante est vérifiée : le nombre de paquets (410) dudit flux identifié donné, qui sont en transit sur le canal de transport du tunnel et bloqués par ladite perte, est supérieur à un nombre d'acquittements (412) générés et transmis par ladite première tête de tunnel pour ledit flux identifié donné.
8. 8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que, pour au moins un flux identifié donné, dans ladite étape de génération et transmission d'au moins un acquittement (412), un acquittement est généré et transmis seulement si ladeuxième condition suivante est vérifiée : un nombre d'acquittements (412) générés et transmis par ladite première tête de tunnel, pour ledit flux identifié donné, est inférieur ou égal à un seuil prédéterminé indiquant une perte de paquet au dispositif émetteur transmettant ledit flux identifié donné.
9. 9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que, pour au moins un flux identifié donné, il comprend une étape de filtrage (712) des acquittements (411) provenant, via le tunnel, du dispositif récepteur dudit flux identifié donné, et pour lesquels ladite première tête de tunnel a déjà généré et transmis un acquittement (412).
10. 10. 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, 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 à 9, lorsque ledit programme est exécuté sur un ordinateur.
11. 11. 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 à 9.
12. 12. Première tête de tunnel permettant la gestion d'une transmission de flux de données sur un canal de transport d'un tunnel (100) supporté par un réseau de communication principal (107), la transmission de chaque flux étant effectuée sur ledit canal de transport selon un protocole de transport ordonnancé par paquet et avec acquittement, ledit tunnel étant mis en oeuvre entre ladite première tête de tunnel et une seconde tête 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 ; 110-A, 110-B) vers un dispositif récepteur (112 ; 112-A, 112-B), ledit dispositif émetteur et ledit dispositif récepteur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau, ladite première tête de tunnel (101) étant caractérisée en ce qu'elle comprend : - des moyens de détection d'une perte d'un paquet sur le canal de transport du tunnel ;- des moyens d'identification d'au moins un flux ayant au moins un paquet bloqué sur le canal de transport du tunnel par ladite perte ; - des moyens de génération et transmission (604, 605 ; 800, 803, 804), pour au moins un flux identifié, d'au moins un acquittement (412) vers le dispositif émetteur ayant transmis sur le tunnel un paquet bloqué par ladite perte.
13. 13. Première tête de tunnel selon la revendication 12, caractérisée en ce que, pour au moins un flux identifié donné, ledit au moins un acquittement généré est un acquittement du paquet qui précède le premier paquet dudit flux identifié qui est bloqué par ladite perte, et en ce que, pour le flux identifié auquel appartient le paquet dont la perte a été détectée, on considère que le premier paquet bloqué par ladite perte est un paquet retransmis (413) sur le canal de transport du tunnel suite à la détection de la perte.
14. 14. Première tête de tunnel selon l'une quelconque des revendications 12 et 13, caractérisée en ce que lesdits moyens de génération et transmission d'au moins un acquittement (412) comprennent : - des moyens de détermination, pour au moins un flux identifié donné, d'une première date d'émission tl d'un premier acquittement (412), en fonction d'une estimation de la durée d'un temporisateur de retransmission associé au dispositif émetteur transmettant ledit flux identifié donné, et en fonction d'une date de traitement, par ladite première tête de tunnel, dudit paquet qui précède le premier paquet dudit flux identifié qui est bloqué par ladite perte ; - des moyens de transmission dudit premier acquittement (412) à ladite première date d'émission tl.
15. 15. Première tête de tunnel selon les revendications 13 et 14, caractérisée en ce que ladite première date d'émission tl est définie par : tl = t0 + RTO' ù A, où : - t0 est ladite date de traitement, dans ladite première tête de tunnel, dudit paquet qui précède le premier paquet dudit flux identifié qui est bloqué par ladite perte ; - RTO' est ladite estimation de la durée du temporisateur de retransmission associé au dispositif émetteur transmettant ledit flux identifié donné ; - A est une marge sécuritaire prédéterminée.
16. 16. Première tête de tunnel selon la revendication 15, caractérisé en ce que lesdits moyens de génération et transmission d'au moins un acquittement (412) comprennent les moyens suivants, activés au moins une fois : - des moyens de détermination, pour au moins un flux identifié donné, d'une nouvelle date d'émission t2 d'un nouvel acquittement (412), définie par : t2 = tl + RTO' û A, où tl est ladite première date d'émission, pour la première itération, ou la date d'émission t2 déterminée à l'itération précédente, pour chaque itération à partir de la deuxième ; - des moyens de transmission dudit nouvel acquittement (412) à ladite date d'émission t2.
17. 17. Première tête de tunnel selon l'une quelconque des revendications 15 et 16, caractérisée en ce que : RTO' = 2.RTT, avec RTT une mesure d'une durée aller-retour sur le tunnel.
18. 18. Première tête de tunnel selon l'une quelconque des revendications 12 à 17, 15 caractérisée en ce qu'elle comprend : - des premiers moyens de vérification, pour au moins un flux identifié donné, si la première condition suivante est vérifiée : le nombre de paquets (410) dudit flux identifié donné, qui sont en transit sur le canal de transport du tunnel et bloqués par ladite perte, est supérieur à un nombre d'acquittements (412) générés et 20 transmis par ladite première tête de tunnel pour ledit flux identifié donné ; - des moyens d'activation desdits moyens de génération et transmission d'au moins un acquittement, pour ledit au moins un flux identifié donné, si lesdits premiers moyens de vérification effectuent une vérification positive.
19. 19. Première tête de tunnel selon l'une quelconque des revendications 12 à 18, 25 caractérisée en ce qu'elle comprend : - des seconds moyens de vérification, pour au moins un flux identifié donné, si la seconde condition suivante est vérifiée : un nombre d'acquittements (412) générés et transmis par ladite première tête de tunnel, pour ledit flux identifié donné, est inférieur ou égal à un seuil prédéterminé indiquant une perte de 30 paquet au dispositif émetteur transmettant ledit flux identifié donné ; 10- des moyens d'activation desdits moyens de génération et transmission d'au moins un acquittement, pour ledit au moins un flux identifié donné, si lesdits seconds moyens de vérification effectuent une vérification positive.
20. 20. Première tête de tunnel selon l'une quelconque des revendications 12 à 19, caractérisée en ce qu'elle comprend des moyens de filtrage, pour au moins un flux identifié donné, des acquittements (411) provenant, via le tunnel, du dispositif récepteur dudit flux identifié donné, et pour lesquels ladite première tête de tunnel a déjà généré et transmis un acquittement (412).