Brevet FR2906425A1 — publié le 20080328

PROCÉDÉ D'OPTIMISATION DU CONTRâLE DU TRAFIC DANS UN RÉSEAU DE TÉLÉCOMMUNICATION PAR PAQUETS DESCRIPTION DOMAINE TECHNIQUE L'invention se situe dans le domaine des télécommunications et concerne plus spécifiquement un procédé d'optimisation du contrôle du trafic dans un réseau de télécommunication par paquets comportant au moins un terminal émetteur, au moins un terminal récepteur, et un régulateur de trafic agencé entre le terminal émetteur et le terminal récepteur, lesdits terminaux émetteur et récepteur échangeant des segments de paquets de données via une liaison orientée connexion mettant en oeuvre un protocole de transport à accusé de réception. L'invention concerne également un dispositif d'optimisation du contrôle du trafic dans un tel réseau de télécommunication, et une unité de traitement associée au régulateur de trafic dudit dispositif. L'invention concerne également un logiciel stocké sur ladite unité de traitement comportant des instructions pour mettre en oeuvre le procédé selon l'invention. ÉTAT DE LA TECHNIQUE ANTÉRIEURE Les protocoles orientés connexion connus, tels que TCP (pour Transmission Control Protocol) et SCTP (pour Stream Control Transport Protocol) par exemple, permettent un échange point à point garanti de 25 2906425 2 données entre deux machines, ou terminaux. Ces protocoles assurent un transfert ordonné et sans perte de données, en marquant les octets avec un numéro de séquence et en fournissant un numéro d'accusé de 5 réception explicite dans un en-tête standard. Généralement, la détection de perte de segments s'effectue de deux manières : soit par expiration d'un délai prédéterminé sans qu'aucun accusé de réception n'ait été reçu par l'émetteur, soit par 10 réception d'un nombre d'accusés de réception dupliqués consécutifs supérieur à un seuil critique prédéterminé. En cas de détection de perte, le ou les segments supposés perdus sont retransmis. Le délai de retransmission est calculé sur la base de l'estimation 15 du temps de transfert noté RTT (pour round-trip time) d'un segment jusqu'au récepteur ajouté au temps de transfert de l'accusé de réception correspondant depuis le récepteur jusqu'à l'émetteur. En outre, ces protocoles de transport 20 fournissent des mécanismes de contrôle de flux et de congestion, fondés sur des fenêtres glissantes dynamiques. L'objectif du contrôle de flux est d'empêcher une machine émettrice rapide de déborder la mémoire tampon d'une machine récepteur plus lente. Dans ce but, un récepteur fournit explicitement une taille de fenêtre de réception en octets dans l'en-tête protocolaire, qui sera notée rcv wnd, (pour receiver window) dans la suite de cette description. Cette taille reflète la capacité de la mémoire tampon du récepteur allouée à la connexion pour absorber le 2906425 3 transfert. Le protocole de transport utilisé requiert que l'émetteur ne transmette pas plus de rcv wnd octets non acquittés afin d'éviter la perte de données par le récepteur. 5 En plus, un émetteur peut non seulement déborder la mémoire du récepteur, mais aussi saturer la capacité des mémoires tampons des noeuds intermédiaires dans le réseau, par exemple les routeurs IP (pour Internet Protocol). Dans ce cas, des données sont 10 supprimées par ces noeuds intermédiaires. L'objectif du contrôle de congestion est de trouver un équilibre entre une utilisation trop abusive des ressources du réseau, qui conduit à des pertes importantes de données (et à de nombreuses retransmissions), et une sous- 15 utilisation de ces ressources, qui garantit l'absence de pertes au détriment des performances de transfert du protocole. Dans le cas particulier des réseaux TCP/IP, l'architecture de ces réseaux ne supporte pas une 20 signalisation explicite de l'état des ressources du réseau aux terminaux, aussi, le protocole TCP, qui réside dans ces terminaux, utilise un algorithme d'estimation de ces ressources. Dans les standards actuels, TCP a recours à 25 la détection de pertes comme un signal implicite de congestion dans le réseau. L'émetteur TCP maintient une fenêtre de congestion, en octets, notée traditionnellement cwnd, qui estime le nombre d'octets non acquittés que l'émetteur peut injecter dans le 30 réseau. La quantité optimale est le produit de la bande 2906425 4 passante par le délai, BDP pour bandwidth delay product . L'algorithme de contrôle de congestion de TCP s'effectue en deux phases : initialement, 5 l'émetteur sonde le réseau en augmentant sa fenêtre de congestion de la taille d'un segment pour chaque accusé de réception reçu, jusqu'à ce qu'un segment soit perdu. Cette première phase est qualifiée de démarrage lent , (slow start), bien que l'augmentation de la 10 fenêtre soit exponentielle. Ensuite, la seconde phase, dite d'évitement de congestion (congestion avoidance), voit la fenêtre oscillée autour d'une valeur d'équilibre, par une croissance modérée (linéaire) et des décroissances multiplicatives (la fenêtre est 15 divisée par deux en cas de perte de segment). Il faut noter que l'évolution dynamique de la fenêtre de congestion est complètement déterminée par le débit d'arrivée des accusés de réception, et donc est très sensible au RTT de la connexion. La 20 fenêtre de transmission de l'émetteur est calculée comme le minimum des valeurs de cwnd et rcv wnd. Sur la base de cette fenêtre, l'émetteur transmet des segments à sa couche IP : si les données sont disponibles, et si la fenêtre est suffisante, 25 plusieurs segments sont envoyés simultanément, c'est-à-dire l'un à la suite de l'autre. On parle d'émission en rafales ( burst ) caractéristique des transferts TCP. Bien que le contrôle de congestion de TCP soit considéré comme la pierre angulaire de la 30 stabilité du réseau Internet, son efficacité est reconnue comme sous optimale dans un certain nombre 2906425 5 d'environnements, en particulier les réseaux exhibant un BDP élevé, dû par exemple à un RTT important. En outre, l'utilisation de pertes comme signal implicite de congestion pose problème pour des réseaux avec un 5 taux d'erreur élevé comme les réseaux sans fil. Enfin certaines applications ont des caractéristiques qui interagissent mal avec TCP : c'est le cas des transactions très courtes, qui ne parviennent pas à atteindre l'état d'équilibre de la 10 fenêtre de congestion par manque de paquets à transmettre, et qui souffre d'un temps de latence plus élevé que nécessaire en raison de la phase de slow start . De telles applications transportées sur des réseaux avec un BDP important souffrent de performances 15 très faibles, mais l'ubiquité des réseaux TCP/IP les rend incontournables. Dans les architectures de l'art antérieur munies d'un régulateur de trafic, ce dernier est en général, constitué d'une ou plusieurs unités physiques 20 déployées à la frontière entre deux réseaux de caractéristiques très différentes, par exemple à la bordure entre des réseaux locaux haut débit et un accès à un réseau longue distance (WAN) comme un réseau à relais de trame (Frame Relay), un réseau ATM ou MPLS 25 (Multiprotocol Label Switching), ou bien encore au niveau d'un point d'accès ou d'une station de base qui interconnecte un réseau sans fil (Wifi ou Wimax,) et un réseau filaire. La régulation de trafic a pour but de lisser le trafic en fonction de caractéristiques 30 spécifiques d'accès au réseau ou en fonction d'une configuration du réseau respectant un contrat de 2906425 6 Qualité de Service (QoS) avec les utilisateurs du réseau. La régulation de trafic peut par exemple permettre de garantir une allocation d'une partie de la bande passante disponible entre différentes classes de 5 trafic, et d'arbitrer les transmissions de paquets simultanées entre des flux de ces classes de trafic. Un lissage permet de limiter un flux à un débit configuré, mesuré en nombre de paquets par seconde ou en nombre d'octets ou de bits transmis par seconde : les paquets 10 sont transmis plus ou moins strictement en fonction du débit configuré, ce qui peut réduire notablement l'émission de rafales continues de paquets. Les procédés de lissage de trafic sont typiquement fondés sur l'algorithme de seau à jeton, et l'ordonnancement 15 des paquets est réalisé par des disciplines de service spécifique de file d'attente de paquets. Dans les réseaux utilisant le protocole TCP, la régulation du trafic réduit considérablement les rafales continues de paquets, qui sont inhérentes 20 au mécanisme de transmission standard de TCP. Les paquets sont transmis en continu l'un après l'autre par TCP, suivant son mécanisme de contrôle de trafic par fenêtre glissante. Le lissage de trafic introduit un délai déterminé entre chaque paquet émis, et espace 25 ainsi les paquets trop proches les uns des autres, en fonction du débit d'émission alloué par le régulateur. Ceci permet de réduire la probabilité de pertes de paquets dans les noeuds intermédiaires, notamment les routeurs IP, puisque les mémoires tampons 30 des routeurs ont moins de rafales continues de paquets 2906425 7 à absorber, ce qui réduit la probabilité de débordement de ces tampons mémoire. En outre, si l'émission des segments de données d'une connexion TCP dépasse le débit alloué par 5 le régulateur de trafic, ces paquets sont retardés par ce régulateur. Ce retard augmente le RTT, qui est calculé par connexion, ce qui va ralentir la transmission de segments par l'émetteur TCP, puisque ce dernier recevra les accusés de réception avec plus de 10 retard. Cependant, la régulation de trafic seule ne permet pas de contrôler l'augmentation de la taille de la fenêtre de congestion de l'émetteur TCP. Puisque le lissage de trafic réduit la probabilité de pertes dans 15 le réseau en aval du régulateur, la taille de la fenêtre de congestion de l'émetteur sera même plus importante qu'en l'absence de régulateur. Par conséquent, l'émetteur transmet des rafales de taille plus importante, ce qui va entraîner l'augmentation de 20 la taille des files d'attente dans le régulateur, voire des débordements de mémoire dans les noeuds intermédiaires en amont du régulateur. Par conséquent, bien que le lissage de trafic améliore la performance du réseau en aval du régulateur, il peut conduire à une 25 dégradation de la performance de TCP, due à des pertes en amont du régulateur ou dans le régulateur lui-même Du fait qu'un régulateur de trafic peut contrôler l'intervalle de temps entre les émissions d'une source TCP, en ralentissant les paquets de données, mais ne 30 permet pas pour autant de contrôler la taille (en nombre d'octets) des rafales émises par la source. 2906425 8 Enfin, un régulateur de trafic ne permet pas de résoudre l'inefficacité de TCP dans sa phase de démarrage lent . Par conséquent, même si le regulateur maîtrise le débit d'émission d'une 5 connexion, il ne peut pas implicitement gérer le mécanisme de contrôle de congestion sans introduire de pertes de paquets. Le but de l'invention est pallier les inconvénients de l'art antérieur décrits ci-dessus. 10 Plus spécifiquement, l'invention a pour but d'optimiser l'interaction des algorithmes de protocoles de transport orientés connexion avec une infrastructure réseau qui fournit une régulation du trafic, soit au niveau de la couche liaison de données (niveau 2) soit 15 au niveau de la couche réseau (niveau 3) c'est-à-dire IP afin de lisser de façon optimale le trafic entre deux terminaux dans un réseau de télécommunication. EXPOSÉ DE L'INVENTION A cet effet, l'invention préconise un 20 procédé d'optimisation du contrôle du trafic dans un réseau de télécommunication par paquets comportant au moins un terminal émetteur, au moins un terminal récepteur, et un régulateur de trafic agencé entre le terminal émetteur et le terminal récepteur, lesdits 25 terminaux émetteur et récepteur échangeant des segments de paquets de données via une liaison orientée connexion mettant en oeuvre un protocole de transport à accusé de réception Selon l'invention, ce procédé comporte les 30 étapes suivantes : 2906425 9 lorsqu'une connexion est établie entre le terminal émetteur et le terminal récepteur, - intercepter, au niveau du régulateur de trafic, les segments de paquets émis du terminal 5 émetteur vers le terminal récepteur, - générer un accusé de réception anticipé ACKa simulant la réception desdits segments de paquets par le terminal récepteur lorsque le régulateur de trafic transmet les paquets interceptés audit terminal 10 récepteur, - transmettre ledit accusé de réception anticipé ACKa au terminal émetteur de manière à asservir le débit d'émission des segments de paquets par ce terminal émetteur à un débit fixé par ledit 15 régulateur de trafic. Le caractère anticipé de l'accusé de réception ACKa provient du fait qu'il est généré avant que les segments de paquets ne soient reçus par le terminal récepteur. 20 Selon l'invention, ledit accusé de réception anticipé ACKa est généré par une unité de traitement associée audit régulateur de trafic et présente un format de donnée conforme au protocole de transport mis en oeuvre pour la transmission de données 25 entre le terminal émetteur et le terminal récepteur. Préférentiellement, le procédé selon l'invention comporte les étapes suivantes : - estimer la valeur BDP représentant le produit de la bande passante disponible par le délai 30 RTT de transfert des segments de paquets entre le terminal émetteur et le terminal récepteur, 2906425 10 calculer la valeur adv wnd représentant la fenêtre temporelle optimale de réception par le terminal récepteur des segments de paquets émis par le terminal émetteur au moyen de la formule suivante : 5 adv wnd = min(rcv wnd - pipe size, bdp estim) où, • rcv wnd représente une fenêtre temporelle de réception imposée par le terminal récepteur, 10 . pipe size représente le nombre d'octets non encore acquittés par le terminal récepteur, ou une estimation de ce nombre, • bdp estim représente la valeur estimée du produit BDP, -transmettre au terminal émetteur la valeur adv wnd calculée de manière à contrôler la longueur des rafales émises par ledit terminal émetteur. Le procédé permet ainsi de contrôler la taille des rafales émises par le terminal émetteur. Le procédé selon l'invention comporte en outre une étape consistant à transmettre un acquittement dupliqué ACKd au terminal émetteur 25 identique à l'acquittement précédemment émis si au moins un segment de paquets n'est pas reçu à sa position dans le flux de données, conformément à l'ordonnancement des paquets utilisé dans le protocole de transmission mis en oeuvre entre le terminal émetteur 30 et le terminal récepteur. 15 20 2906425 11 Dans un mode préféré de réalisation, le procédé selon l'invention comporte en outre les étapes suivantes . -intercepter les acquittements ACKr 5 renvoyés du terminal récepteur vers le terminal émetteur, - filtrer les acquittements ACKr interceptés de manière à supprimer les acquittements qui apparaîtraient au terminal émetteur comme des 10 acquittements dupliqués d'un ACKa précédemment envoyés par l'unité de traitement, déduire à partir desdits acquittements ACKr les segments non délivrés. Selon une autre caractéristique de 15 l'invention, les en-têtes des acquittements ACKr non supprimés sont modifiés par l'unité de traitement, pour transmettre au terminal emetteur la valeur adv wnd représentant la fenêtre temporelle optimale de réception par le terminal récepteur des segments de 20 paquets émis par le terminal émetteur. Ceci permet de contrôler le débit transmission et la taille des rafales émises par le terminal émetteur. La retransmission des segments de paquets 25 non délivrés est effectuée soit après réception d'un nombre d'acquittements dupliqués supérieur à un seuil critique prédéfini, soit à la suite de l'expiration d'un délai de retransmission prédéfini. Selon l'invention, cette retransmission 30 s'effectue sous le contrôle du régulateur de trafic, et l'émission des paquets retransmis vers le terminal 2906425 12 récepteur s'effectue selon le débit d'émission fixé par ce régulateur de trafic. Le procédé selon l'invention est mis en oeuvre par un dispositif comportant au moins un terminal 5 émetteur, au moins un terminal récepteur, et un régulateur de trafic agencé entre le terminal émetteur et le terminal récepteur, lesdits terminaux émetteur et récepteur échangeant des segments de paquets de données via une liaison orientée connexion mettant en oeuvre un 10 protocole de transport à accusé de réception. Selon l'invention, le régulateur est couplé à une unité de traitement comportant des moyens pour générer un accusé de réception anticipé ACKa configurér pour simuler la réception des segments de paquets par 15 le terminal à l'émission d'un paquet par ledit régulateur de trafic. L'unité de traitement est une unité à états comportant une mémoire pour stocker une structure de contrôle par connexion, l'état de la connexion, les 20 paramètres de ladite connexion et la file de retransmission des segments de paquets non encore acquittés par le terminal récepteur. Dans une application particulière, les terminaux émetteur et récepteur communiquent selon le 25 protocole de transmission TCP et l'unité de traitement comporte un module supportant les mécanismes de détection d'erreur et de retransmission du protocole TCP. En outre, ladite unité de traitement 30 comporte : 2906425 13 - des moyens pour intercepter les acquittements ACKr renvoyés du terminal récepteur vers le terminal émetteur, - des moyens pour déduire à partir desdits 5 acquittements ACKr les segments non délivrés, - des moyens pour filtrer les acquittements ACKr de manière à supprimer les acquittements qui apparaîtraient au terminal émetteur comme des acquittements dupliqués d'un ACKa précédemment envoyés 10 par l'unité de traitement. L'unité de traitement comporte également des moyens pour modifier les en-têtes des acquittements ACKr non supprimés de manière à contrôler le débit de transmission et la taille des rafales émises par le 15 terminal émetteur. Le procédé selon l'invention est mis en oeuvre par un logiciel stocké sur une unité de traitement associée à un régulateur de trafic dans un réseau de télécommunication par paquets comportant au 20 moins un terminal émetteur, au moins un terminal récepteur, ledit régulateur de trafic étant agencé entre le terminal émetteur et le terminal récepteur, lesdits terminaux émetteur et récepteur échangeant des segments de paquets de données via une liaison orientée 25 connexion mettant en oeuvre un protocole de transport à accusé de réception. Ledit logiciel comporte des instructions pour générer un accusé de réception anticipé ACKa simulant la réception desdits segments de paquets par 30 le terminal récepteur, à l'émission desdits segments de paquets par le régulateur de trafic. 2906425 14 Le logiciel selon l'invention comporte en outre : - des instructions pour intercepter les acquittements ACKr renvoyés du terminal récepteur vers 5 le terminal émetteur, - des instructions pour déduire à partir des acquittements ACKr intercéptés les segments non délivrés, - des instructions pour filtrer les 10 acquittements ACKr de manière supprimer les acquittements qui apparaîtraient au terminal émetteur comme des acquittements dupliqués d'un ACKa précédemment envoyés par l'unité de traitement. Préférentiellement, ce logiciel comporte en 15 outre des instructions pour modifier les en-têtes des acquittements ACKr non supprimés pour transmettre au terminal émetteur une valeur adv wnd représentant la fenêtre temporelle optimale de réception par le terminal récepteur des segments de paquets émis par le 20 terminal émetteur de manière à contrôler le débit transmission et la taille des rafales émises par ledit terminal émetteur. BRÈVE DESCRIPTION DES DESSINS D'autres caractéristiques et avantages de 25 l'invention ressortiront de la description qui va suivre, prise à titre d'exemple non limitatif, par référence aux figures annexées dans lesquelles : - la figure 1, illustre schématiquement un dispositif dans lequel est mis en oeuvre le procédé 30 selon l'invention ; 2906425 15 - la figure 2 représente une vue détaillée d'une unité de gestion d'accusé réception selon l'invention ; - les figures 3 à 5 illustrent 5 schématiquement les chemins de flux échangés entre un terminal émetteur et un terminal récepteur via le dispositif de la figure 1, - la figure 6 représente un organigramme illustrant la régulation du trafic selon le procédé de 10 l'invention ; - la figure 7 représente un organigramme illustrant le traitement d'un flux amont (entre l'unité de traitement et l'émetteur) selon le procédé de l'invention ; 15 - la figure 8 représente un organigramme illustrant le traitement d'un flux aval (entre le récepteur et l'unité de traitement) selon le procédé de l'invention ; - la figure 9 représente un organigramme 20 illustrant la gestion de la retransmission d'un flux selon le procédé de l'invention. EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS L'invention sera décrite, à titre d'exemple d', dans une application du procédé à une liaison TCP 25 (pour Control Transmission Protocol) entre un émetteur 2 et un récepteur 4 dans un réseau de télécommunication. Notons cependant que le procédé s'applique, sans sortir du cadre de l'invention, quel que soit le type de protocole de transmission utilisé 30 entre l'émetteur 2 et le récepteur 4. Pour plus de clarté on désignera par émetteur la machine distante 2906425 16 qui transmet des segments de données et récepteur une autre machine connectée à l'émetteur et qui transmet en retour uniquement des segments d'accusé de réception, ou ACK audit émetteur. 5 Notons qu'une même machine peut être simultanément un émetteur et un récepteur pour une même connexion. La figure 1 illustre une liaison entre l'émetteur 2 et le récepteur 4 via un dispositif 5 10 d'optimisation du contrôle du trafic. On désignera par réseau amont la partie du réseau entre l'émetteur 2 et le dispositif 5, et par réseau aval la partie entre dispositif 5 et le récepteur 4. De même, un segment (resp. paquet) amont 15 est un segment (resp. paquet) transporté de la partie amont du réseau, donc de l'émetteur 2, vers la partie aval , donc vers le récepteur 4, un segment (resp. paquet) aval est un segment (resp. paquet) transporté de la partie aval du réseau, donc du 20 récepteur 4, vers la partie amont , donc vers l'émetteur 2. Le dispositif 5 peut interagir avec les terminaux 2 et 4 quel que soit le format de réception et de transmission des paquets sur les interfaces 25 d'entrée/sortie amont et aval . Il peut ainsi agir au niveau de la couche 2 (MAC, pour Medium Access Control) ou/et de la couche 3 (IP, pour Internet Protocol) et au-delà, sans sortir du cadre de l'invention. Un tel dispositif peut être centralisé, 30 c'est-à-dire, constitué par un seul élément physique, comme un adaptateur réseau, un pont filtrant, un 2906425 17 commutateur, un routeur, un point d'accès ou une station de base sans fil, ou d'un élément logiciel comme un pilote de périphérique opérant sur un hôte TCP. 5 Alternativement, le dispositif peut être distribué sur plusieurs éléments de réseaux physiques. Par référence à la figure 1, le dispositif 5 comporte un régulateur de trafic 6 comportant ordonnanceur de paquets 8 et à un module contrôle 10. 10 Le régulateur de trafic 6 est relié, via une interface de communication 12, à une unité de traitement 14 comportant des moyens pour générer un accusé de réception anticipé ACKa simulant la réception par le terminal récepteur 4 des segments de paquets émis par 15 le terminal émetteur 2, lorsque le régulateur de trafic 6 émet des segments de paquets vers le terminal récepteur 4. Le module contrôle 10 a pour fonction d'adapter dynamiquement les paramètres du régulateur de 20 trafic 6 en fonction d'une politique de gestion de trafic établi dans une unité de réseau externe ou des conditions perçues du réseau. La figure 2 représente en détail l'unité de traitement 14. 25 Préférentiellement, cette dernière comporte : - un démultiplexeur de segment 20 destiné à extraire les informations nécessaires des en-têtes TCP et IP du paquet reçu, que ce soit une trame de niveau 2 30 (couche liaison de données) ou d'un datagramme IP de niveau 3, et optionnellement, à réassembler les paquets 2906425 18 IP fragmentés pour disposer de la totalité des segments TCP ; - un gestionnaire des étapes de contrôle 22. Pour chaque connexion, l'état courant est 5 stocké dans une mémoire 24 sous la forme d'une structure, appelée étape de contrôle, avec la file d'attente des segments non acquittés, et tout autre information nécessaire pour réaliser la détection de pertes et la retransmission conformément aux standards 10 TCP. Le gestionnaire des étapes de contrôle 22 est destiné à créer, retrouver et détruire les étapes de contrôle dans cette mémoire 24. L'association entre une connexion et l'adresse mémoire du contrôle 15 correspondant peut s'effectuer au moyen de structure de données appropriées comme un arbre balancé ou une table de hachage. L'identifiant d'une étape de contrôle peut être soit un tag de niveau 2 soit le quadruplet extrait des en-têtes TCP et IP ; L'unité 14 comporte en outre un premier filtre 26 pour filtrer les segments amont. Ce composant n'est utilisé que dans le traitement des segments émis 25 par le terminal émetteur vers le terminal récepteur. Il fournit diverses vérifications sur l'en-tête et le segment TCP extrait par le démultiplexeur 20. En particulier, ce filtre vérifie si le segment TCP transporte des données ou non. Si non, le segment est 30 un acquittement pur, qui ne doit pas être acquitté à son tour, et ce segment peut être ignoré par l'unité de 2906425 19 traitement 14, puis transmis vers le terminal récepteur 4. Ce filtre 26 vérifie également si la somme de contrôle (checksum) du segment TCP est valide ou non. Si non, le segment est supprimé. Il vérifie en outre si 5 le segment est dupliqué ou non, c'est-à-dire si le segment est une retransmission du terminal émetteur 2. Si oui, le segment est supprimé. Dans tous les autres cas, le segment est passé à un gestionnaire de file de retransmission 28 10 pour la suite du traitement amont. L'unité 14 comporte en outre une mémoire tampon 29 associée au gestionnaire de file de retransmission 28. Ce composant fournit le coeur du mécanisme TCP de détection d'erreur et de 15 retransmission, en ne considérant aucun mécanisme de contrôle de congestion de TCP. En effet, comme l'unité de traitement 14 émet des acquittements anticipés vers l'émetteur 2, la responsabilité de la livraison correcte et ordonnée des segments acquittés incombe au 20 gestionnaire de file de retransmission 28. Pour les segments amont ce composant conserve une copie de chaque segment transmis dans une file de segments, ordonnée suivant les numéros de séquence des octets des segments. 25 Pour les segments aval le numéro d'accusé de réception cumulatif indique les segments correctement reçus par le terminal récepteur : les copies de ces segments maintenus dans la file de retransmission peuvent être supprimées sans risque. 30 L'algorithme de détection d'erreur doit être conforme au standard TCP pour que l'unité de traitement 14 soit 2906425 20 compatible avec l'implantation de TCP sur le terminal récepteur. Un ou plusieurs segments sont retransmis soit par la procédure dite de recouvrement rapide ( Fast Recovery ) spécifiée pour les variantes 5 Reno de TCP, c'est-à-dire lorsque le nombre d'acquittements dupliqués consécutifs atteint un seuil critique prédéfini,généralement trois, soit par la procédure de recouvrement d'acquittement sélectif spécifiée pour les variantes SACK de TCP, soit par 10 la procédure d'expiration d'une minuterie de retransmission. Pour cette dernière procédure, le gestionnaire 28 doit estimer le RTT de chaque connexion pour évaluer une durée de la minuterie qui ne soit ni trop courte ni trop longue, par exemple conformément à 15 l'algorithme standard d'échantillonnage de TCP. Lorsque des segments doivent être retransmis, ils sont placés sous le contrôle du régulateur de trafic 6.Pour éviter tout effet de bord de retransmissions cachées (par exemple une sous- 20 estimation importante du trafic circulant vers le terminal récepteur), le gestionnaire de file de retransmission 28 dispose d'une interface avec le régulateur de trafic 6. Par exemple, si régulateur de trafic 6 comporte des files d'attente par classe de 25 trafic, le gestionnaire de retransmission 28 place les segments retransmis en tête de la file d'attente correspondante, contrairement aux nouveaux paquets à transmettre qui sont placés en fin de file. L'unité 14 comporte en outre un deuxième 30 filtre 30 dédié aux segments aval. Ce composant n'est utilisé que dans le traitement des segments émis par le 2906425 21 terminal récepteur 4 vers le terminal émetteur 2. Il fournit diverses vérifications sur l'en-tête et le segment TCP extrait par le démultiplexeur 20. En particulier, ce filtre vérifie si le bit d'acquittement 5 (ACK) est positionné ou non. Si non, le segment est ignoré. Il vérifie également si la somme de contrôle du segment TCP est valide ou non. Si non, le segment est supprimé. Dans tous les autres cas, le segment est 10 passé au gestionnaire de file de retransmission 28 pour la suite du traitement aval. L'unité 14 comporte également un générateur d'acquittement anticipé 32 qui génère des segments contenant uniquement un accusé de réception vers le 15 terminal émetteur 2, suite au traitement des paquets amont. Si le paquet intercepté contient un segment TCP qui n'est pas celui attendu dans l'ordre des numéros de séquence, le générateur d'acquittement anticipé 32 émet un acquittement dupliqué, c'est-à-dire le même 20 acquittement que précédemment. Ce générateur 32 doit donc stocker un acquittement dans le contrôle de l'étape de la connexion, ainsi que le numéro de séquence du prochain segment attendu. Si le paquet intercepté est celui attendu, le générateur 25 d'acquittement anticipé 32 construit un acquittement de telle sorte qu'il apparaisse comme émis par le terminal recepteur 4 vers le terminal émetteur 2. En particulier, les adresses IP et les ports TCP doivent être inversés par rapport au paquet intercepté. Le 30 numéro de séquence de l'acquittement est positionné à la valeur du numéro d'accusé de réception du paquet 2906425 22 intercepté. Le numéro d'accusé de réception est positionné au numéro de séquence du paquet intercepté augmenté de la longueur des données TCP du paquet (i.e. la taille de sa charge utile). Enfin, la fenêtre de 5 réception est positionnée conformément à la formule : adv wnd = min(rcv wnd - pipe size, bdp estim) où, . rcv wnd représente une fenêtre temporelle de réception imposée par le terminal récepteur, • pipe size représente le nombre d'octets non encore acquittés par le terminal récepteur, ou une estimation de ce nombre. • bdp estim représente la valeur estimée du produit BDP. Pour les paquets aval, un générateur d'acquittement anticipé 32 filtre les acquittements purs : si un acquittement pur du terminal émetteur 2 20 vers le terminal récepteur ne conduit à aucun changement de taille de fenêtre, et n'a aucun des bits SYN, RST ou FIN positionné dans son en-tête, le paquet peut être silencieusement supprimé. Dans les cas contraires, et si un segment du terminal émetteur 2 25 vers le terminal récepteur 4 contient des données, le composant altère l'en-tête TCP du segment en : 10 15 2906425 23 • Modifiant le numéro d'accusé de réception pour placer le dernier numéro émis dans un acquittement anticipé vers le terminal émetteur 2. Sans cette modification, le segment pourrait être ignoré 5 comme trop vieux par le terminal émetteur 2, c'est-à-dire que le numéro d'accusé de réception se trouve avant le bord gauche de sa fenêtre, ou encore le segment pourrait être considéré comme un acquittement dupliqué entraînant des 10 retransmissions superflues. • Modifiant la fenêtre de réception, conformément à la formule ci-dessus. • Fixant la somme de contrôle du segment pour tenir compte des deux modifications précédentes. 15 Notons que, compte tenu de l'algorithme de calcul, la somme peut être fixée de façon incrémentale, sans la recalculer sur la totalité du segment TCP. L'unité 14 comporte en plus un échantillonneur de BDP 34. Ce composant estime le BDP 20 de chaque connexion à partir de l'échantillonnage du RTT nécessaire au mécanisme de retransmission. Si le régulateur 6 fournit une gestion de file par connexion TCP et offre une interface pour connaître le débit configuré pour chaque file, le BDP peut être 25 échantillonné en multipliant directement le débit de la file de la connexion par le RTT de la connexion. On suppose alors que le débit dans la partie aval du réseau est entièrement contraint par le débit du régulateur. Si un tel calcul n'est pas possible, le BDP 30 peut être échantillonné en mesurant la longueur de la 2906425 24 file de retransmission, en octets. Un numéro de séquence dédié est maintenu dans l'étape de contrôle, et la taille maximale de la file de retransmission est mesurée jusqu'à ce que ce numéro de séquence soit 5 acquitté par un accusé de réception du terminal émetteur 2. Le BDP peut alors être estimé comme une moyenne de ces échantillons. Une telle procédure est similaire à l'échantillonnage standard du RTT en l'absence d'option de Timestamp . 10 L'unité 14 comporte aussi un module de fragmentation des segments TCP 36 dont la fonction sera décrite ci-après. Un problème particulier dans le cas d'une application du procédé selon l'invention dans un réseau 15 IP est le support de la découverte du MTU (pour Maximum Transmit Unit, représentant la taille maximale (en octets) du paquet pouvant être transmis en une seule fois). Selon le standard actuel les routeurs 20 intermédiaires entre deux machines implantant le protocole TCP suppriment un paquet IP dont la taille excède la taille maximale autorisée sur une interface (MTU) et dont le drapeau Dont fragment de l'en-tête IP est présent. En outre, le routeur émet vers la 25 source un message ICMP (pour Internet Control Message Protocol) contenant la valeur du MTU sur l'interface considérée. Si un tel routeur se situe en aval de l'unité de traitement 14, l'émetteur 2 recevra un ou 30 plusieurs acquittements anticipés pour des segments qui seront par la suite supprimés par le routeur. 2906425 25 En effet, si l'unité fonctionne au niveau IP, et si le MTU est fixé dynamiquement dans le réseau, l'unité de traitement 14 peut anticiper un acquittement pour des segments qui seront supprimés par un routeur 5 en aval, avec émission d'un paquet ICMP (pour Internet Control Message Protocol) spécifiant la valeur du MTU sur le chemin considéré. Ce paquet ICMP doit parvenir au terminal émetteur 2, qui transmettra par la suite des paquets à la taille adaptée. 10 Cependant si l'unité de traitement 14 n'intercepte pas aussi ce paquet ICMP, la procédure de retransmission conduit à la réémission des paquets supprimés par le routeur sans tenir compte du MTU : ainsi les retransmissions seront à nouveau supprimées 15 par le routeur, et ne parviendront jamais au terminal récepteur 4. Le module de fragmentation des segments TCP 36 est donc responsable de l'interception des paquets ICMP indiquant un MTU dynamique, et de la fragmentation des segments acquittés conformément au 20 MTU renvoyé par le routeur en aval. Ces segments sont alors immédiatement retransmis vers le terminal récepteur 4 par le gestionnaire de retransmission 28. Selon une caractéristique de l'invention, l'unité de traitement 14 intercepte les messages ICMP 25 de type patte mtu discovery pour retransmettre les segments perdus des connexions impactées, en fragmentant ces segments à la taille du MTU fourni (et ce, même si les paquets IP ont le drapeau Dont Fragment positionné). Ensuite tant que l'émetteur 2 30 n'a pas été informé par le message ICMP, l'unité de 2906425 26 traitement 14 fragmente les segments acquittés localement. Afin de supporter le protocole TCP, l'unité de traitement 14 comporte les interfaces logiques 5 suivantes . • TS requeue (TS queue q, TS packet p): destinée à insérer les paramètres des paquets au début de la file d'attente des paquets à transmettre au terminal récepteur 4. 10 • TS rate (TS queue q): Cette interface est optionnelle et est destinée à retourner le débit courant de transmission des paramètres de file d'attente, • TS availspace (TS queue q): Cette interface est 15 optionnelle et est destinée à retourner la quantité disponible de la mémoire tampon de la file d'attente. Notons que cette interface n'est pas nécessaire si le système est distribué entre différents dispositifs physiques, en particulier 20 si le régulateur de trafic 6 et l'unité de traitement 14 sont intégrés dans des dispositifs de réseaux différents. Les différentes phases du procédé selon l'invention seront maintenant décrites par référence 25 aux figures 3, 4 et 5. La figure 3 illustre schématiquement le traitement des segments de paquets d'un flux amont émis par le terminal émetteur 2. 2906425 27 Ces segments sont d'abord interceptés par le régulateur de trafic 6, qui les classe et les range dans une mémoire tampon appropriée (flèche 30). Le régulateur de trafic 6 sélectionne 5 ensuite le segment à transmettre au récepteur 4 et le délivre à l'unité de traitement 14 (flèche 32). Le segment est ensuite transmis sans délai et sans modification au terminal récepteur 4 via le réseau aval (flèche 34). 10 Si le segment TCP transporte des données utiles, l'unité de traitement 14 génère un accusé de réception ACK qu'elle transmet (flèche 36) au terminal émetteur 2. La figure 4 illustre schématiquement le 15 traitement des segments de paquets d'un flux aval émis par le terminal récepteur 4. Ces derniers sont d'abord intercéptés par l'unité de traitement 14 (flèche 40) qui les filtre, modifie les en-têtes des paquets non supprimés puis 20 transmet ces paquets (flèche 42) au terminal émetteur 2 avec la valeur adv wnd. La figure 5 illustre schématiquement la retransmission de paquets au terminal récepteur 4. Notons qu'une retransmission est effectuée 25 soit après réception par l'unité de traitement 14 d'un nombre d'acquittements dupliqués supérieur à un seuil critique prédéfini, soit à la suite de l'expiration d'un délai de retransmission prédéfini. Lorsque l'unité de traitement 14 reçoit un 30 accusé de réception dupliqué supérieur à un seuil critique (flèche 50), ou à la suite de l'expiration du 2906425 28 délai de retransmission prédéfini, le module de gestion des retransmissions 28 de l'unité 14 sélectionne un ou plusieurs segments qui doivent être retransmis. Cette procédure sera décrite en détail dans la suite de la 5 description. Un segment qui doit être retransmis est renvoyé à l'entrée du régulateur de trafic 6 (flèche 52) qui le positionne en tête de la mémoire tampon de retransmission. Lorsque le segment est sélectionné par 10 l'ordonnanceur de paquets 8 du régulateur de trafic 6, il est directement fourni à l'interface du réseau aval sans traitement supplémentaire dans l'unité de traitement 14 (flèche 54). Les différents traitements des segments 15 amont et aval réalisés en application du procédé de l'invention vont maintenant être décrits par référence aux figures 6 à 9. TRAITEMENT DES PAQUETS AMONT Les étapes du traitement des segments amont 20 sont décrites ci-après par référence à la figure 6. A l'étape 100, le régulateur de trafic effectue une classification des flux reçus du terminal émetteur 2. Cette classification consiste à trier les paquets en flux de trafic prédéfinis et à appliquer à 25 chaque flux un traitement particulier. Ainsi par exemple, une partie de la bande passante disponible peut avoir été réservée pour un flux, ou bien un flux peut être soumis à une contrainte de délai ou de gigue. Les paramètres utilisés pour la classification 30 dépendent du niveau de traitement du régulateur de trafic 6. En effet, si le régulateur 6 est lié à la 2906425 29 couche liaison de données (niveau 2), un simple identifiant de circuit virtuel ou de canal peut suffire, par contre, si ce régulateur 6 agit au niveau IP, la classification peut utiliser une combinaison de 5 champs de l'en-tête IP, voire de l'en-tête TCP ou UDP, ou même le contenu applicatif du paquet (niveau 7). En général, la classification a pour effet de placer le paquet dans une file d'attente dédiée au flux sélectionné (étape 110), et une discipline de 10 service adaptée est affectée à la file. A l'étape 111, on vérifie si la file d'attente ne dispose plus d'espace mémoire suffisant. Si oui, un traitement approprié est exécuté à l'étape 120 pour supprimer un ou plusieurs paquets. 15 Sinon le paquet est placé à la fin de la file d'attente et le classificateur signale un ordonnanceur de paquets (étape 130). L'ordonnanceur de paquets 8 choisit ensuite parmi les flux éligibles le prochain paquet à 20 transmettre. Le paquet élu est transmis alors à l'unité de traitement TCP 14. Génération d'accusé de réception par l'unité 14 Rappelons que l'unité de traitement TCP 14 a pour fonction de générer un accusé de réception (ACK) 25 et de transmettre cet accusé de réception au terminal émetteur 2 indépendamment du délai de transmission du paquet dans la partie aval du réseau, de façon à asservir le débit d'émission de ce terminal 2 au débit du flux correspondant dans le régulateur de trafic 6. 30 La figure 7 est un organigramme illustrant la suite des traitements appliqués au flux amont. 2906425 30 L'étape 200 est un démultiplexage du flux amont pour en extraire le segment, et notamment l'en-tête TCP du paquet reçu. Cette étape permet de filtrer les paquets invalides ou non TCP et dépend du niveau de 5 traitement du régulateur 6 de trafic. En effet, si le régulateur 6 agit au niveau 2, l'étape doit d'abord extraire et vérifier un en-tête IP valide. L'étape 210 consiste à rechercher la structure de contrôle de la connexion TCP associée au 10 segment TCP en cours de traitement dans la mémoire 24. Cette étape peut utiliser toute structure de donnée adéquate pour effectuer une recherche exacte en fonction du quadruplet (IP adresse source, IP adresse destination, TCP port source, TCP port destination). 15 Si cette structure n'existe pas ou n'est pas dans l'état établi , la phase d'établissement de la connexion n'est pas encore complète et le segment est traité à l'étape 220 selon la procédure TCP 3WHS (pour, three-way handshake). Cette procédure consiste à 20 vérifier la validité de la procédure d'établissement, notamment les numéros de séquence SYN et ACK, et permet de stocker les options TCP négociées durant cette phase, qui impactent le mécanisme de retransmission, notamment le facteur d'échelle de fenêtre (window scale 25 factor) pour calculer correctement la fenêtre offerte par le récepteur 4 et le support de SACK (selective acknowledgement). Si la procédure ou l'état de la connexion n'est pas jugé(e) valide, cette connexion sera ignorée et sa structure de contrôle libérée. En 30 particulier, si l'unité de traitement 14 n'intercepte pas les deux directions d'une connexion qui utilisent 2906425 31 des routes asymétriques, par exemple, les segments de cette connexion seront ignorés. Aucun accusé de réception anticipé ne sera généré pour un segment SYN, afin de ne pas désynchroniser l'état de la connexion 5 dans les machines distantes. Lorsque la connexion est dans l'état établi , l'étape 230 consiste à vérifier la présence des drapeaux FIN et RST dans l'en-tête TCP : ceux-ci marquent la clôture de la connexion, et la structure de 10 contrôle pourra être libérée (étape 240) dès que la file de retransmission sera vide. Les paquets amont pour la connexion seront désormais ignorés. En particulier, la méthode ne génère aucun ACK local pour un segment FIN (ni RST), afin de ne pas désynchroniser 15 l'état de la connexion dans les machines distantes. Les étapes décrites ci-dessous permettent de filtrer les segments TCP à ignorer : • L'étape 250 consiste à vérifier si la charge utile du segment TCP est nulle. 20 Si oui, le segment est un ACK pur qui ne doit pas être acquitté à son tour, et le segment est ignoré. • L'étape 260 consiste à vérifier la somme de contrôle (checksum) du segment. Si la somme est invalide, la 25 machine distante ignorera le segment dans la pile TCP. Le segment peut être ignoré ou supprimé en fonction de cette vérification. • L'étape 270 consiste à vérifier si le segment est 30 retransmis par le terminal émetteur 2 en comparant le 2906425 32 numéro de séquence du dernier octet avec le prochain numéro de séquence attendu, par exemple. Un segment retransmis par le terminal émetteur 2 doit être supprimé. 5 A ce niveau, le segment TCP transporte des octets que l'unité de traitement 14 n'a encore pas interceptés : le segment peut donc être transmis vers le récepteur 4. L'étape 280 consiste à insérer une copie du 10 segment dans la file de retransmission. Cette file est ordonnée par le numéro de séquence des octets des segments. Si le numéro de séquence du segment n'est pas celui attendu, i.e. le segment reçu n'est pas en 15 séquence (étape 290), un ou plusieurs segments peuvent avoir été perdus dans la partie amont du réseau. L'unité de traitement 14 transmet alors (étape 295) un acquittement dupliqué au terminal émetteur 2, c'est-à-dire exactement le même acquittement que précédemment 20 émis. Si l'option SACK a été négociée entre les terminaux émetteur et récepteur, cet acquittement peut contenir des étapes SACK indiquant les derniers segments reçus, conformément au standard TCP. 25 La pile TCP implantée dans l'émetteur 2 retransmettra les segments manquants, si cela est nécessaire, en fonction du mécanisme de retransmission négocié (SACK ou Reno). Si le numéro de séquence du segment est 30 celui attendu, l'unité de traitement 14 transmet un accusé de réception anticipé vers l'émetteur 2. Cet 2906425 33 acquittement est contrefait pour être reçu et traité par l'émetteur 2 comme s'il avait été émis par le récepteur 4. En particulier, le numéro de séquence de l'acquittement est le numéro de séquence d'accusé de 5 réception du segment amont, et le numéro de séquence d'accusé de réception couvre le dernier octet copié dans la file de retransmission. Le problème reste donc la fenêtre de réception utilisée pour le contrôle de flux TCP. C'est 10 la raison pour laquelle le procédé selon l'invention comporte une étape consistant à estimer le produit BDP de la valeur de la bande passante par le délai de la connexion (Bandwidth-Delay Product, BDP). En annonçant une estimation du BDP, notée 15 bdp estim, dans la fenêtre de réception des segments envoyés vers l'émetteur 2 (y compris les acquittements anticipés), il est possible de contrôler la longueur des rafales (burst) émises par l'émetteur 2. Cependant il est également important de respecter la contrainte 20 de fenêtre du récepteur 4, notée rcv wnd, pour éviter de déborder sa mémoire tampon allouée à la connexion. La fenêtre annoncée doit enfin tenir compte du nombre d'octets non encore acquittés, que l'on note in flight, et qui, soit circulent dans le réseau aval, soit sont 25 stockés dans la mémoire tampon du récepteur 4. Dans une première variante, on considère la valeur in flight comme égale à la longueur de la file de retransmission, bien qu'il soit possible d'affiner cette estimation grâce aux procédures de détection 30 d'erreurs et d'estimation du RTT de TCP. La fenêtre 2906425 34 annoncée à la source TCP est alors calculée à l'étape 300 par la formule suivante : adv wnd = min(rcv wnd - in flight, bdp estim). En dernier lieu, la fenêtre annoncée ne 5 devrait pas occasionner de débordement de la file du flux dans le régulateur de trafic 6, pour éviter toute perte dans le système. Préférentiellement, la taille mémoire des files d'attente du régulateur 6 n'est pas sous 10 dimensionnée compte tenu des BDP des connexions TCP. L'étape 310 consiste à gérer le déclenchement du comptage du temps d'attente des acquittements RTO et à estimer le RTT et le BDP en phase de transmission de segment et de réception 15 d'acquittement (ACK). Cette étape 310 sera décrite plus en détail ci-après. A l'étape 320 l'unité de traitement 14 compare la taille des segments acquittés à celle du MTU. 20 A l'étape 330, l'unité de traitement 14 fragmente les segments acquittés de façon anticipée et dont la taille est supérieure au MTU (étape 320). Cette fragmentation s'effectue au niveau de la couche IP. Notons qu'à l'exception des paquets 25 fragmentés, les paquets amont transmis ne subissent aucune modification des en-têtes IP. Les en-têtes TCP ne sont modifiés en aucun cas. TRAITEMENT DES PAQUETS AVAL Rappelons que le traitement par l'unité 14 30 des paquets aval consiste, d'une part, à scruter les acquittements TCP renvoyés par le récepteur 4 vers 2906425 l'émetteur 2 pour détecter les segments non délivrés et retransmettre ces segments suivant les procédures standards de TCP, et d'autre part, à modifier les en-têtes TCP des segments pour contrôler le débit de 5 l'émetteur 2. Ces traitements seront décrits en détail par référence aux figures 8 et 9. Le traitement aval comporte les mêmes étapes 200, 210, 220 et 260 décrites dans le traitement 10 amont visant à extraire un segment TCP et sa structure de contrôle associée en mode établi. Dans le traitement aval, l'étape 26 consiste à vérifier la somme de contrôle (checksum) et à supprimer un segment dont la somme est invalide. Si 15 la somme est valide, une vérification du drapeau ACK est effectuée à l'étape 400. Si le drapeau ACK n'est pas positionné, le segment est ignoré (en général, il s'agit d'un segment SYN de réouverture de connexion). A partir de l'étape 410, la méthode est une 20 version allégée du protocole TCP en mode réception, sans gestion de congestion mais uniquement avec reprise sur erreur. L'étape 410 consiste à vérifier si l'accusé réception ACK est dupliqué, c'est-à-dire, si le 25 récepteur 4 décale sa fenêtre de réception ou non. L'étape 420 consiste à gérer des accusés réception ACK dupliqués selon les standards TCP New Reno et SACK, qui peut entraîner la retransmission d'un ou plusieurs segments TCP. 30 Cette procédure sera décrite en détail par la suite. 2906425 36 Une compatibilité stricte aux standards de retransmission New Reno ou SACK garantit l'interopérabilité du système avec les piles TCP du récepteur 4 et de l'émetteur 2. 5 Si l'accusé réception ACK n'est pas dupliqué, la mémoire des octets acquittés par l'accusé réception ACK cumulatif est libérée de tous les octets dont le numéro de séquence est strictement inférieur au numéro d'accusé de réception reçu. 10 L'étape 425 consiste à estimer et gérer les délais du RTO (et RTT) ainsi que le BDP. L'estimation du RTT peut, soit suivre le standard TCP, soit s'adapter à tout nouvel algorithme. Une implantation de la méthode peut supporter l'option 15 timestamp pour affiner l'estimation du RTT. La gestion du temps d'attente d'acquittement RTO est conforme au standard TCP. L'estimation du produit BDP peut s'effectuer par deux méthodes : 20 • Si le régulateur de trafic 6 dispose d'une interface permettant d'accéder au débit du flux correspondant à la connexion, l'unité de traitement 14 utilise cette interface pour estimer le BDP en multipliant le débit du flux, pondéré 25 par le nombre de connexions TCP agrégées dans ce flux, par le RTT moyen. • Sinon, le BDP peut être échantillonné en supervisant la taille de la file de retransmission. Un numéro de séquence est maintenu 30 dans la structure de contrôle de la connexion, ainsi que le nombre d'octets transmis en aval, à 2906425 37 l'exception des segments retransmis, jusqu'à ce que le numéro d'accusé de réception cumulatif des segments aval couvre le numéro de séquence spécifié. Le BDP est estimé comme une moyenne 5 pondérée ou le maximum de ces nombres d'octets transmis. C'est une procédure très similaire à l'échantillonnage du RTT en l'absence de l'option timestamp . La valeur initiale du BDP ne doit pas 10 empêcher l'émetteur 2 de transmettre les tous premiers segments du transfert. Par exemple si le premier accusé de réception ACK anticipé positionne la fenêtre à un segment, en raison de la valeur bdp estim, l'émetteur 2 ne peut pas transmettre une rafale complète si sa 15 fenêtre de congestion initiale (initial congestion window) est supérieure à un segment, comme recommandée par les standards TCP. Selon une caractéristique de l'invention, l'estimation du BDP ajoute donc un nombre fixe de 20 segments à la valeur échantillonnée, par exemple 4 à 8 segments. L'étape 430 consiste à mettre à jour la valeur rcv wnd de la fenêtre du récepteur 4. Comme les étapes 230 et 240 dans le 25 traitement amont l'étape 432 consiste à vérifier la présence des drapeaux FIN et RST dans l'en-tête TCP marquant la clôture de la connexion. La structure de contrôle sera libérée à l'étape 435 dès que la file de retransmission sera vide. 30 L'étape 438 consiste à calculer la taille de la charge utile du segment aval. 2906425 38 Si cette taille est nulle, correspondant à un segment d'acquittement pur, le procédé se poursuit par l'étape 440 consistant à vérifier si le numéro d'accusé de réception ou la fenêtre ont évolués par 5 rapport au dernier ACK envoyé. Si tel n'est pas le cas, le segment est supprimé. Si c'est le cas, l'émetteur 2 considèrerait le segment comme un acquittement dupliqué, ce qui 10 fausserait sa procédure de retransmission. Dans tous les autres cas, le segment doit être transmis vers l'émetteur 2. Cependant, pour être validé par la pile TCP de l'émetteur 2, certains champs de l'en-tête TCP sont 15 modifiés à l'étape 450. A cet effet : • Le numéro d'accusé de réception doit correspondre au dernier numéro d'accusé de réception des ACK anticipés générés, c'est-à-dire être plus grand ou égal à ce numéro. Sans cette modification, la pile 20 TCP de l'émetteur 2 soit ignorerait le segment comme trop ancien (un numéro d'accusé de réception plus petit que le bord gauche de sa fenêtre) soit considèrerait le segment comme un acquittement dupliqué. 25 • La fenêtre de réception peut être recalculée pour tenir compte des nouvelles valeurs de bdp estim, rcv wnd et in flight. • La somme de contrôle doit être fixée pour tenir compte des deux modifications précédentes de l'en-30 tête. 2906425 39 TRAITEMENT DES RETRANSMISSIONS TCP Les segments retransmis doivent être soumis au régulateur de trafic 6 afin d'éviter des effets de bord de retransmission cachées sur les mécanismes de 5 contrôle du régulateur de trafic 6 (par exemple une sous-estimation significative du trafic injecté dans le réseau en aval ). Le traitement des retransmissions est décrit en détail par référence à la figure 9. 10 Rappelons qu'une retransmission de segment peut avoir lieu selon les procédures de TCP soit après réception d'un nombre d'acquittements dupliqués supérieur à un seuil critique (généralement trois) suivant TCP New Reno ou SACK (étape 500), ce qui 15 déclenche une procédure de FastRetransmit (étape 510), soit à la suite de l'expiration de la minuterie de retransmission (étape 520), qui indique qu'aucun accusé de réception cumulatif n'a été reçu couvrant le segment transmis durant le délai imparti. 20 L'étape 530 consiste à renvoyer le prochain segment de la file de retransmission qui doit être retransmis. En général, le numéro d'accusé de réception doit être modifié par rapport au segment original pour refléter le dernier accusé de réception renvoyé par 25 l'émetteur (notamment dans le cas de transfert réellement bidirectionnel entre les deux machines). Cette valeur est donc stockée dans la structure de contrôle au cours du traitement amont. Dans une variante de mise en oeuvre du 30 procédé selon l'invention, dans le cas d'une connexion supportant l'option timestamp , la valeur des 2906425 timestamp est modifiée pour mesurer le RTT même en cas de retransmission ou pour détecter une retransmission erronée. Enfin la somme de contrôle (checksum) est 5 fixée pour tenir compte de ces changements dans l'en- tête TCP (étape 540). La figure 9 montre une boucle de retransmission de segment dans le cas du support de TCP SACK, qui peut déterminer que plusieurs segments ont 10 été perdus. Il faut noter que la retransmission des segments ne fait appel à aucun mécanisme de contrôle de congestion, mais dépend uniquement de l'étage de régulation de trafic pour protéger le réseau aval. En particulier, une fois que le régulateur 15 6 a émis les segments retransmis, tout nouveau segment en attente après ces segments retransmis sera émis à son tour. Rappelons que le régulateur de trafic 6 est couplé à l'unité de traitement 14 via une interface de 20 communication permettant d'insérer un paquet en tête de file d'attente, devant tout autre paquet en attente, sans supprimer ce paquet en cas de débordement (étape 550). REVENDICATIONS 1. Procédé d'optimisation du contrôle du trafic dans un réseau de télécommunication par paquets comportant au moins un terminal émetteur (2), au moins un terminal récepteur (4), et un régulateur de trafic (6) agencé entre le terminal émetteur (2) et le terminal récepteur (4), lesdits terminaux émetteur (2) et récepteur (4) échangeant des segments de paquets de données via une liaison orientée connexion mettant en oeuvre un protocole de transport à accusé de réception, procédé caractérisé en ce qu'il comporte les étapes suivantes . lorsqu'une connexion est établie entre les terminaux émetteur (2) et récepteur (4), - intercepter, au niveau du régulateur de trafic (6), les segments de paquets émis du terminal émetteur (2) vers le terminal récepteur (4), - générer un accusé de réception anticipé ACKa simulant la réception desdits segments de paquets par le terminal récepteur (4) lorsque le régulateur de trafic (6) transmet les paquets interceptés audit terminal récepteur (4), -transmettre ledit accusé de réception anticipé ACKa au terminal émetteur (2) de manière à asservir le débit d'émission des segments de paquets par le terminal émetteur (2) à un débit fixé par ledit régulateur de trafic (6). 2. Procédé selon la revendication 1, dans lequel ledit accusé de réception anticipé ACKa présente un format de donnée conforme au protocole de transport 2906425 42 mis en oeuvre entre lesdits terminaux émetteur (2) et récepteur (4) et est généré par une unité de traitement (14) associée audit régulateur de trafic (6) et. 5 3. Procédé selon la revendication 2, caractérisé en ce qu'il comporte en outre une étape consistant à : - estimer la valeur BDP représentant le produit de la bande passante disponible par le délai 10 (RTT, Round-Trip Time) de transfert des segments de paquets entre le terminal émetteur et le terminal récepteur, - calculer la valeur adv wnd représentant la fenêtre temporelle optimale de réception par le 15 terminal récepteur (4) des segments de paquets émis par le terminal émetteur (2) au moyen de la formule suivante : adv wnd = min(rcv wnd - pipe size, bdp estim) où, . rcv wnd représente une fenêtre temporelle de réception imposée par le terminal récepteur (4), • pipe size représente le nombre d'octets non encore acquittés par le terminal récepteur (4), ou une estimation de ce nombre. • bdp estim représente la valeur estimée du produit BDP. transmettre au terminal émetteur (2) la 30 valeur adv wnd calculée de manière à contrôler la 20 25 2906425 43 longueur des rafales émises par ledit terminal émetteur (2). 4. Procédé selon la revendication 2, 5 comportant en outre une étape consistant à transmettre un acquittement dupliqué ACKd au terminal émetteur (2) identique à l'acquittement précédemment émis si au moins un segment de paquets n'est pas reçu à sa position dans le flux de données, conformément à 10 l'ordonnancement des paquets utilisés dans ledit protocole de transport. 5. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre les étapes 15 suivantes . - intercepter les acquittements ACKr renvoyés du terminal récepteur (4) vers le terminal émetteur (2), -filtrer les acquittements ACKr de manière 20 à supprimer les acquittements qui apparaîtraient au terminal émetteur (2) comme des acquittements dupliqués d'un ACKa précédemment envoyés par l'unité de traitement (14), -déduire à partir desdits acquittements 25 ACKr les segments non délivrés. 6. Procédé selon les revendications 3 à 5, comportant en outre l'étape consistant à modifier par l'unité de traitement (14), les en- têtes des 30 acquittements ACKr non supprimés pour transmettre au terminal émetteur (2) la valeur adv wnd. 2906425 44 7. Procédé selon la revendication 6, dans lequel une retransmission est effectuée soit après réception d'un nombre d'acquittements dupliqués 5 supérieur à un seuil critique prédéfini, soit à la suite de l'expiration d'un délai de retransmission prédéfini. 8. Procédé selon la revendication 7, dans 10 lequel la retransmission d'un paquet s'effectue sous le contrôle du régulateur de trafic (6), et en ce que l'émission des paquets retransmis vers le terminal récepteur (4) s'effectue selon le débit d'émission fixé par ledit régulateur de trafic (6). 15 9. Procédé selon l'une des revendications 1 à 8, dans lequel les terminaux émetteur (2) et récepteur (4) communiquent selon le protocole de transport TCP. 10. Procédé selon l'une des revendications 1 à 8, dans lequel les terminaux émetteur (2) et récepteur (4) communiquent selon le protocole SCTP (Stream Control Transport Protocol). 25 11. Dispositif d'optimisation du contrôle du trafic dans un réseau de télécommunication par paquets comportant au moins un terminal émetteur (2), au moins un terminal récepteur (4), et un régulateur de 30 trafic (6) agencé entre le terminal émetteur (2) et le terminal récepteur (4), lesdits terminaux émetteur (2) 20 2906425 45 et récepteur (4) échangeant des segments de paquets de données via une liaison orientée connexion mettant en oeuvre un protocole de transport à accusé de réception, dispositif caractérisé en ce que ledit régulateur de 5 trafic (6) est couplé à une unité de traitement (14) comportant des moyens (32) pour générer un accusé de réception anticipé ACKa simulant la réception par le terminal récepteur (4) des segments de paquets émis par le terminal émetteur (2), lorsque le régulateur de 10 trafic (6) émet lesdits segments de paquets vers le terminal récepteur (4). 12. Dispositif selon la revendication 11, dans lequel ladite unité de traitement (14) est une 15 unité à états comportant une mémoire (24) pour stocker une structure de contrôle par connexion, l'état de la connexion, les paramètres de ladite connexion et la file de retransmission des segments de paquets non encore acquittés par le terminal récepteur (4). 20 13. Dispositif selon la revendication 12, dans lequel les terminaux émetteur (2) et récepteur (4) communiquent selon le protocole de transport TCP et en ce que ladite unité de traitement (14) comporte un 25 module (28) supportant les mécanismes de détection d'erreur et de retransmission du protocole TCP. 14. Dispositif selon la revendication 13, dans lequel ladite unité de traitement (14) comporte en 30 outre : 2906425 46 - des moyens (20) pour intercepter les acquittements ACKr renvoyés du terminal récepteur vers le terminal émetteur (2), - des moyens pour déduire à partir desdits 5 acquittements ACKr les segments non délivrés, - des moyens (30) pour filtrer les acquittements ACKr de manière supprimer les acquittements qui apparaîtraient au terminal, émetteur (2) comme des acquittements dupliqués d'un ACKa 10 précédemment envoyés par l'unité de traitement (14). 15. Dispositif selon la revendication 14, dans lequel ladite unité de traitement (14) comporte en outre des moyens pour modifier les en- têtes des 15 acquittements ACKr non supprimés de manière à contrôler le débit transmission et la taille des rafales émises par le terminal émetteur (2). 16. Unité de traitement (14) associée à un 20 régulateur de trafic (6) dans un réseau de télécommunication par paquets comportant au moins un terminal émetteur (2), au moins un terminal récepteur (4), ledit régulateur de trafic (6) étant agencé entre le terminal émetteur (2) et le terminal récepteur (4), 25 lesdits terminaux émetteur (2) et récepteur (4) échangeant des segments de paquets de données via une liaison orientée connexion mettant en oeuvre un protocole de transport à accusé de réception, ladite unité (14) étant caractérisée en ce qu'elle est couplée 30 au régulateur de trafic (6) via une interface de communication (12) et en ce qu'elle comporte des moyens 2906425 47 (32) pour générer un accusé de réception anticipé ACKa simulant la réception desdits segments de paquets par le terminal récepteur (4), à l'émission desdits segments de paquets par le régulateur de trafic (6). 17. Unité de traitement selon la revendication 15, caractérisée en ce qu'elle comporte en outre : - des moyens (20) pour intercepter les 10 acquittements ACKr renvoyés du terminal récepteur (4) vers le terminal émetteur (2), - des moyens pour déduire à partir desdits acquittements ACKr les segments non délivrés, - des moyens (30) pour filtrer les 15 acquittements ACKr de manière a supprimer les acquittements qui apparaîtraient au terminal émetteur (2) comme des acquittements dupliqués d'un ACKa précédemment envoyés par l'unité de traitement (14). 20 18. Unité de traitement selon la revendication 16, caractérisée en ce qu'elle comporte en outre des moyens pour modifier les en-têtes des acquittements ACKr non supprimés pour transmettre au terminal émetteur (2) une valeur adv wnd représentant 25 la fenêtre temporelle optimale de réception par le terminal récepteur (4) des segments de paquets émis par le terminal émetteur (2) de manière à contrôler le débit transmission et la taille des rafales émises par le terminal émetteur (2). 5 30 2906425 48 19. Logiciel stocké sur une unité de traitement (14) associée à un régulateur de trafic (6) dans un réseau de télécommunication par paquet comportant au moins un terminal émetteur (2), au moins 5 un terminal récepteur (4), ledit régulateur de trafic (6) étant agencé entre le terminal émetteur (2) et le terminal récepteur (4), lesdits terminaux émetteur (2)et récepteur (4) échangeant des segments de paquets de données via une liaison orientée connexion mettant 10 en oeuvre un protocole de transport à accusé de réception, ledit logiciel caractérisé en ce qu'il comporte des instructions pour générer un accusé de réception anticipé ACKa simulant la réception desdits segments de paquets par le terminal récepteur (4), à 15 l'émission desdits segments de paquets par le régulateur de trafic (6). 20. Logiciel selon la revendication 19, caractérisé en ce qu'il comporte en outre : - des instructions pour intercepter les acquittements ACKr renvoyés du terminal récepteur (4) vers le terminal émetteur (2), - des instructions pour déduire à partir desdits acquittements ACKr les segments non délivrés, - des instructions pour filtrer les acquittements ACKr de manière supprimer les acquittements qui apparaîtraient au terminal émetteur (2) comme des acquittements dupliqués d'un ACKa précédemment envoyés par l'unité de traitement (14). 20 25 30 2906425 49 21. Logiciel selon la revendication 20, caractérisé en ce qu'il comporte en outre des instructions pour modifier les en-têtes des acquittements ACKr non supprimés pour transmettre au 5 terminal émetteur (2) une valeur adv wnd représentant la fenêtre temporelle optimale de réception par le terminal récepteur (4) des segments de paquets émis par le terminal émetteur (2) de manière à contrôler le débit transmission et la taille des rafales émises par 10 ce terminal émetteur (2).