FR2805112A1 - Procede et unite de controle de flux d'une connexion tcp sur un reseau a debit controle - Google Patents

Procede et unite de controle de flux d'une connexion tcp sur un reseau a debit controle Download PDF

Info

Publication number
FR2805112A1
FR2805112A1 FR0001735A FR0001735A FR2805112A1 FR 2805112 A1 FR2805112 A1 FR 2805112A1 FR 0001735 A FR0001735 A FR 0001735A FR 0001735 A FR0001735 A FR 0001735A FR 2805112 A1 FR2805112 A1 FR 2805112A1
Authority
FR
France
Prior art keywords
segment
connection
tcp
receiver
transmitter
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0001735A
Other languages
English (en)
Other versions
FR2805112B1 (fr
Inventor
Christophe Mangin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Information Technology Corp
Original Assignee
Mitsubishi Electric Information Technology Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mitsubishi Electric Information Technology Corp filed Critical Mitsubishi Electric Information Technology Corp
Priority to FR0001735A priority Critical patent/FR2805112B1/fr
Priority to US09/770,215 priority patent/US6925060B2/en
Priority to EP01400241A priority patent/EP1168729A1/fr
Priority to EP01102508A priority patent/EP1168722A1/fr
Priority to JP2001029528A priority patent/JP2001268130A/ja
Publication of FR2805112A1 publication Critical patent/FR2805112A1/fr
Application granted granted Critical
Publication of FR2805112B1 publication Critical patent/FR2805112B1/fr
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1809—Selective-repeat protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1835—Buffer management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/187—Details of sliding window management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1806—Go-back-N protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/188—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5638—Services, e.g. multimedia, GOS, QOS
    • H04L2012/5665—Interaction of ATM with other protocols
    • H04L2012/5667—IP over ATM
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]

Landscapes

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

Abstract

L'invention propose un procédé et une unité de contrôle du flux d'au moins une connexion TCP entre un émetteur (10) et un récepteur (20), le procédé étant du type consistant à contrôler, au niveau d'un noeud de multiplexage déterminé par lequel transitent des segments TCP relevant de la connexion, un paramètre de taille de fenêtre (Wa) présent dans des segments d'acquittement retournés par le récepteur, et comprenant les étapes consistant à :a) recevoir (100) au niveau dudit noeud de multiplexage déterminé un segment d'acquittement provenant du récepteur sur le sens montant (récepteur vers émetteur) de la connexion;b) contrôler (200-600) un paramètre de taille de fenêtre (Wa) présent dans ledit segment d'acquittement, en fonction de la différence (Diff) entre, d'une part, une première valeur de contexte (NoSeqDatai ) associée à la connexion TCP, définie comme le numéro de séquence du dernier segment ayant été transmis depuis ledit noeud de multiplexage déterminé sur le sens descendant (émetteur vers récepteur) de la connexion auquel on ajoute la longueur dudit segment, et, d'autre part, le numéro de séquence indiqué dans ledit segment d'acquittement; c) transmettre (700) sur le sens montant de la connexion, depuis ledit noeud de multiplexage vers l'émetteur (10), le segment d'acquittement avec un paramètre de taille de fenêtre (Wa) ainsi contrôlé.

Description

<Desc/Clms Page number 1>
PROCEDE ET UNITE DE CONTROLE DE FLUX D'UNE CONNEXION TCP
SUR UN RESEAU A DEBIT CONTROLE
La présente invention concerne un procédé et une unité de contrôle de flux d'une connexion TCP, en particulier une connexion TCP établie à travers un réseau à débit contrôlé
Le protocole TCP (de l'anglais "Transmission Control Protocol"), ci-après TCP, est un protocole de la couche transport du modèle de référence TCP/IP Il est très utilisé dans les réseaux et, notamment, le plus utilisé dans le réseau Internet. Il fournit un service de transport aux programmes d'application de la couche supérieure sous la forme de connexions bidirectionnelles transportant un flux d'octets entre un émetteur et un récepteur sur lesquels ces programmes sont exécutés (on parle aussi de transport de bout en bout). L'émetteur et le récepteur peuvent par exemple être respectivement un serveur de réseau et un terminal client. Parmi les protocoles reposant sur TCP, on peut citer : FTP (de l'anglais "File Transfer Protocol") pour les transferts de fichiers, HTTP (de l'anglais "HyperText Transfer Protocol") pour les transactions sur le réseau internet ou encore SMTP (de l'anglais "Simple Mail Protocol") pour le courrier électronique.
Pour assurer le transfert de données, TCP prévoit l'établissement préalable d'une connexion entre l'émetteur et le récepteur, dite connexion TCP, et la mise en #uvre de mécanismes de détection et de correction d'erreurs, ainsi qu'un mécanisme de contrôle de flux et un mécanisme de contrôle de congestion. C'est pourquoi on dit que TCP est un protocole orienté connexion (ou en mode connecté) qui, de plus, est fiable.
La connexion consiste à associer de façon bidirectionnelle un couple (adresse IP, port TCP) de l'émetteur à un couple (adresse IP, port TCP) du récepteur. Les adresse IP sont fournies par la couche IP alors que les ports TCP sont locaux. TCP découpe le flot d'octets à transmettre en segments dont la taille maximale est préalablement négociée entre les deux extrémités de la connexion TCP à l'ouverture de celle-ci. Un segment est donc l'unité de protocole de TCP. Des segments sont échangés pour l'établissement de la connexion (segment portant le fanion SYN), pour le transfert de données, pour leur acquittement (segment portant le fanion ACK), pour la fermeture de la
<Desc/Clms Page number 2>
connexion (segment portant le fanion FIN) et pour la réinitialisation de connexion (segment portant le fanion RST)
Les segments transitant sur le sens descendant de la connexion (de l'émetteur vers le récepteur), ou segment de données, contiennent un numéro de séquence. Ce numéro de séquence est inséré par l'émetteur dans l'en-tête du segment de données Il indique le rang, dans le flot de données transmis suivant le sens descendant de la connexion TCP, du premier élément de données (en pratique un octet) porté par le segment. Les segments de données sont acquittés positivement par des segments d'acquittement (ou acquittements) transitant sur le sens montant de la connexion (du récepteur vers l'émetteur). L'en-tête de chaque segment d'acquittement contient un numéro de séquence, inséré par le récepteur. Ce numéro de séquence indique le rang, dans le flot de données transmis suivant le sens descendant de la connexion TCP, de l'élément de données ou octet suivant le dernier élément de données ou octet correctement reçu par le récepteur, c'est à dire le rang du prochain élément de données ou octet attendu par celui-ci.
Le mécanisme de contrôle de flux permet un contrôle du flux de bout en bout, c'est à dire entre les deux extrémités de la connexion, sans hypothèse sur la valeur du flux entre les différents n#uds de multiplexage du réseau. Afin d'améliorer l'efficacité de la transmission du flots de données, ce mécanisme est basé sur un système de fenêtre glissante. Le contrôle de congestion, quant à lui, agit sur la taille de cette fenêtre en fonction d'informations provenant du contrôle de flux qui permettent d'estimer le niveau de congestion du réseau.
Une des caractéristiques principales du mécanisme de contrôle de flux de TCP est qu'il n'utilise aucune information explicite sur l'état du réseau fournie par ce dernier. A fortiori, le mécanisme de contrôle de congestion détermine l'état de congestion du réseau en fonction de signaux implicites fournis par le contrôle de flux, tels que l'arrivée d'acquittements, l'expiration d'une temporisation ou encore la réception d'acquittements dupliqués.
Les implications, sur les performances de TCP, des mécanismes de contrôle de flux et/ou de congestion dans le cadre, notamment, de réseaux de datagrammes purs, tels que IP (de l'anglais "Internet Protocol"), et de réseaux ATM (de l'anglais "Asynchronous Transfer Mode") font l'objet de nombreuses
<Desc/Clms Page number 3>
recherches qui ont déjà abouti à des propositions de modification de ces mécanismes. Ces recherches ont principalement pour but d'améliorer l'utilisation du réseau et de permettre un partage équitable des ressources entre les différentes connexions TCP L'invention se rapporte au domaine de ces travaux de recherche et concerne plus spécifiquement les techniques de contrôle de flux des connexions TCP
Le contrôle de flux de TCP repose sur un mécanisme de fenêtre glissante. La fenêtre W, exprimée en nombre d'octets, est le volume d'information que l'émetteur a transmis sans en avoir reçu l'acquittement par le récepteur. Le principe de la fenêtre permet à TCP d'anticiper la réception d'un segment par le récepteur, c'est à dire d'envoyer des segments entrant dans la fenêtre sans en attendre l'acquittement. C'est pourquoi on parle de fenêtre d'anticipation ou de fenêtre de transmission. La taille de la fenêtre W est modulée par le contrôle de congestion et reste inférieure à une valeur maximale fixée par le récepteur et annoncée dans chaque segment d'acquittement. A cet effet, chaque segment d'acquittement contient un paramètre de taille de fenêtre Wa dont la valeur correspond à ladite valeur maximale. Le fonctionnement de ce mécanisme est illustré par le schéma de la figure 1. Des segments de données sont référencés Seg.1à Seg.11. Le sens de transfert des segments de données depuis l'émetteur vers le récepteur est indiqué par une flèche. On notera que le mécanisme de fenêtre glissante de TCP opère sur des octets et non sur des segments, mais le segment étant en pratique l'unité de protocole de TCP, il est commode de se référer ici à des volumes de données exprimés en nombre de segments. La valeur maximale de la taille de la fenêtre Wa annoncée par le récepteur dans un acquittement détermine une fenêtre offerte, qui, en combinaison avec la valeur du numéro de séquence présent dans le segment d'acquittement, couvre par exemple les segments Seg.4 à Seg.9. Le numéro de séquence présent dans l'acquittement indique dans l'exemple que le récepteur a déjà reçu et acquitté les segments allant jusqu'au segment Seg.3 inclus. La valeur du paramètre Wa donne une indication de l'espace disponible dans une mémoire tampon d'entrée du récepteur, puisqu'elle correspond au volume de données que le récepteur déclare être prêt à accepter. L'émetteur calcule la fenêtre utilisable Wu définie
<Desc/Clms Page number 4>
par Wu=Wa-W, et qui représente le nombre d'octets supplémentaires qu'il peut transmettre sans attendre l'acquittement des segments Seg 4 à Seg.6 déjà émis mais non encore acquittés Dans l'exemple, cette fenêtre utilisable Wu couvre les segments Seg 7 à Seg.9. Ces segments peuvent donc être émis sans délai par l'émetteur
Si l'on considère un réseau sans mémoire tampon et uniquement constitué de canaux de transmission caractérisés par un débit et un temps de transfert, la seule capacité mémoire offerte par le réseau pour absorber la fenêtre d'une connexion TCP est alors la mémoire équivalente du canal de transmission. Pour une connexion TCP déterminée, la taille de la fenêtre W correspond à la quantité de données envoyées dans le réseau et non encore acquittées Physiquement, les données contenues dans le réseau à un instant déterminé comprennent d'une part les segments en cours de transfert sur le sens descendant de la connexion et d'autre part les acquittements en cours de transfert sur le sens montant de la connexion et concernant des segments déjà traités par le récepteur La figure 2 illustre un exemple dans lequel le canal peut absorber une fenêtre correspondant à 12 segments. Dans cet exemple se trouvent dans le réseau à un instant déterminé, d'une part des segments Seg.7 à Seg.12 en cours de transfert sur le sens descendant (symbolisé par la flèche simple), et d'autre part des acquittements Ack. 1 à Ack. 6 en cours de transfert sur le sens montant (symbolisé par la flèche double). La réception d'un segment provoquant l'émission d'un acquittement par le récepteur, ces derniers sont alors espacés sur le sens montant d'une distance équivalente à la durée de transmission d'un segment sur le sens descendant
Si le débit et le temps de transfert sont égaux sur les deux sens, la taille de la fenêtre W qui devrait au maximum être atteinte pour une connexion TCP est donnée par la relation suivante :
Wmax = d x RTT (1) où Wmax est la taille maximale de la fenêtre (exprimé en octets), d est le débit de la connexion (exprimé en octets par seconde), et RTT (de l'anglais "Round-Trip Time") désigne le temps de transfert aller-retour des données sur le canal de transmission ou temps de boucle (exprimé en secondes). Le produit d x RTT est encore appelé produit bande passante-temps de transfert. La
<Desc/Clms Page number 5>
relation (1 ) fait apparaître le lien entre les performances de TCP en termes de débit de la connexion et la taille de la fenêtre maximale utilisable par cette connexion.
Le contrôle de congestion de TCP repose exclusivement sur des mécanismes de détection de perte de segment et de modulation de la taille de la fenêtre W en conséquence
Les mécanismes de détection de perte de segment reposent d'une part sur l'expiration d'une temporisation de retransmission et d'autre part sur une détection anticipée. A chaque émission d'un segment, une temporisation de retransmission (RTO, de l'anglais "Retransmission Time-Out") est démarrée côté émetteur. Si la temporisation expire avant que l'acquittement correspondant n'ait été reçu, TCP considère que le segment est perdu et procède à sa retransmission en démarrant une nouvelle temporisation de retransmission plus élevée que la précédente. De plus TCP peut aussi supposer de manière anticipée qu'un segment est perdu, c'est à dire avant l'expiration de la temporisation de retransmission associée audit segment.
Cette détection anticipée de la perte d'un segment tire parti du fait qu'un acquittement est systématiquement généré pour chaque segment reçu et qu'il porte le numéro de séquence du prochain segment attendu (le suivant dans l'ordre des segments). Suivant ce principe, un récepteur peut être amené à émettre des acquittements portant des numéros de séquence identiques (correspondant au dernier segment reçu dans l'ordre des segments) lorsque qu'une série de segments arrive dans le désordre. De tels acquittements (appelés acquittements dupliqués) permettent d'informer l'émetteur de la bonne réception des segments, à l'exception d'un ou plusieurs d'entre eux, reçus en contradiction avec leur ordre d'émission ou pas reçus du tout, et de l'informer du numéro de séquence du segment effectivement attendu. Du point de vue de l'émetteur, les acquittements dupliqués peuvent être attribués à différents problèmes du réseau : le fait que le réseau a réordonnancé les segments, qu'il a répliqué des acquittements, ou enfin qu'un segment a été perdu. Dans ce dernier cas, tous les segments suivant le segment supposé perdu génèrent un acquittement dupliqué.
<Desc/Clms Page number 6>
Pour la modulation de la taille de sa fenêtre, un émetteur TCP utilise quatre algorithmes différents. Ces algorithmes sont appelés démarrage lent ("slow start" en anglais), évitement de congestion ("congestion avoidance" en anglais), retransmission rapide ("fast retransmit" en anglais) et recouvrement rapide ("fast recovery", en anglais). Les deux premiers sont utilisés, soit immédiatement après l'établissement d'une connexion, lors du démarrage du transfert des données, soit à la suite de la perte d'un segment détectée par l'expiration de sa temporisation de retransmission. L'algorithme "slow start" a pour principal effet de forcer une réduction de la taille de la fenêtre W à un seul segment et de la faire croître ensuite d'un segment par acquittement reçu jusqu'à un seuil (appelé "slow start threshold" en anglais, ou "ssthresh") à partir duquel elle ne croît plus que d'une fraction de segment (égale à la taille d'un segment divisée par la taille courante de la fenêtre) par acquittement reçu.
Cette deuxième phase d'accroissement a lieu selon l'algorithme "congestion avoidance" jusqu'au moment où la fenêtre W atteint la limite annoncée par le récepteur (taille de fenêtre Wa annoncée dans chaque acquittement) Typiquement, le seuil "ssthresh" est fixé à la taille maximale de fenêtre au début d'un transfert et à la moitié du volume de données émises et non encore acquittées suite à une perte de segment détectée par l'expiration de la temporisation de retransmission. Les algorithmes "fast retransmit" et "fast recovery", quant à eux, sont mis en #uvre lors de la détection anticipée d'une perte de segment. Dit autrement, ils sont déclenchés préventivement lors de la réception d'acquittement dupliqués pouvant laisser supposer la perte d'un ou plusieurs segments. Ils ont pour effet de réduire la taille de la fenêtre à la moitié du volume des données émises et non encore acquittées.
Bien que très robustes, les mécanismes de contrôle de flux et de contrôle de congestion de TCP peuvent entraîner une dégradation des performances du protocole On constate ainsi diverses inconvénients.
Premièrement, une connexion qui émet plus de données que les autres dispose d'une fenêtre plus grande que les autres. A l'inverse, une connexion qui utilise des segments de petite taille ou qui est soumise à des temps de transfert plus longs occupe moins vite les ressources disponibles dans le réseau. Il en résulte une répartition inéquitable, entre les différentes
<Desc/Clms Page number 7>
connexions TCP, des ressources en débit et en mémoire du réseau.
Deuxièmement, le temps de transfert de bout en bout est mal maîtrisé En effet, aucune ressource du réseau n'étant préalablement allouée à la connexion et TCP n'exploitant aucune information explicite sur l'état du réseau, des points de congestion peuvent se déclarer, caractérisés par des temps de traversée de file d'attente non maîtrisés En outre, le mécanisme de détection de perte par l'expiration de la temporisation de retransmission ainsi que la retransmission des segments perdus ont aussi un impact non maîtrisé en termes de temps de transfert. Troisièmement, une éventuelle congestion n'est détectée que tardivement, en raison précisément du caractère implicite de cette détection, reposant sur la détection de la perte d'un segment. Il s'ensuit qu'il n'est pas possible d'éviter la perte de segments et donc leur retransmission. Quatrièmement, et cet inconvénient découle du précédent, le débit utile est mal utilisé puisque les ressources de débit et de mémoire sont utilisées non seulement pour transporter les segments perdus jusqu'au point de congestion, mais aussi pour les retransmettre. Ce phénomène est encore accentué par la stratégie de retransmission dite "go-back-N" utilisée en cas de perte détectée par l'expiration de la temporisation de retransmission, qui consiste à retransmettre tous les segments à partir du segment perdu). Enfin, et cinquièmement, le flux de données est très irrégulier. Typiquement, tant qu'il n'a pas atteint sa taille de fenêtre maximale, TCP occupe de plus en plus de ressources de débit et de mémoire jusqu'à leur saturation. La perte de segments qui en découle donne lieu à des cycles de sous-utilisation du réseau (résultant des réductions brutales de taille de fenêtre dues aux algorithmes "slow start" et "fast recovery"), suivi d'une nouvelle phase d'accroissement de la taille des fenêtres à laquelle succède à nouveau un régime de perte, etc...
D'un point de vue qualitatif, ces phénomènes se traduisent par une attente plus ou moins supportable lors du téléchargement de fichiers (utilisation par FTP), par le blocage des navigateurs lors de la consultation de sites sur internet (utilisation par HTTP), etc...
Plusieurs voies ont été explorées pour améliorer le comportement et les performances de TCP aussi bien au niveau de la couche transport (mécanisme d'extrémités) que de la couche réseau. Parmi celles-ci, les algorithmes FFR
<Desc/Clms Page number 8>
(de l'anglais "fast retransmit/recovery") désignant les algorithmes décrits plus haut), l'utilisation d'acquittements sélectifs (SACK, de l'anglais "Selective ACKnowledgement") et la notification explicite de congestion via un bit d'indication de congestion ajouté aux paquets TCP (bit ECN, de l'anglais "Explicit Congestion Notification"), interviennent au niveau transport. FRR et SACK ont pour but d'améliorer le débit, d'éviter l'expiration des temporisations de retransmission et de favoriser une récupération rapide des ressources suite à une perte de segment La technique ECN, quant à elle, requiert un support de la couche réseau pour agir sur la couche transport (indication explicite de congestion fournie par le réseau) et vise à améliorer l'équité de la répartition des ressources entre les connexions et à raccourcir les temps de transfert. Des mécanismes de couche réseau tels que les politiques de destruction anticipée de paquets (RED, de l'anglais "Random Early Discard"), la mise en #uvre d'échéanciers d'émission (WFQ, etc, .) et les techniques de contrôle explicite du débit des connexions TCP permettent une amélioration des performances en termes de débit et d'équité de la répartition des ressources du réseau.
Le mécanisme de contrôle de la taille de la fenêtre qui est à la base du procédé selon l'invention peut se rattacher à cette dernière catégorie, à savoir celle des techniques de contrôle explicite du débit des connexions TCP
Le débit d'une connexion TCP peut être contrôlé de plusieurs manières : soit par régulation du rythme d'émission des segments sur le sens descendant, soit par régulation du rythme de transmission des acquittements sur le sens montant. En effet, une fois la taille de sa fenêtre stabilisée, un émetteur TCP reçoit normalement un acquittement par segment émis, et il est autorisé à émettre sans délai un nouveau segment de données pour chaque segment d'acquittement reçu (régénération des crédits). Dit autrement, la première solution consiste à agir sur le rythme de consommation des crédits d'émission par l'émetteur et la seconde consiste à agir sur leur rythme de régénération. La seconde solution consiste à augmenter ou réduire l'espacement des acquittements et met en oeuvre une fonction d'espacement des acquittements (appelée "Ack bucket"). La première solution peut consister, pour obtenir la conformité à un débit déterminé, à augmenter ou réduire l'espacement des émissions de segments. Mais elle peut aussi reposer sur
<Desc/Clms Page number 9>
l'utilisation d'une couche de niveau inférieur fournissant des liaisons dont le débit est définissable et contrôlable Tel est le cas, par exemple avec un réseau ATM ou TDM. Un point de contrôle du débit se trouve par exemple à l'interface du conduit ATM, au sein de l'équipement d'interconnexion avec le réseau local auquel est relié l'émetteur (équipement d'interconnexion source) Afin de compenser les différences de débit entre le réseau local et le réseau ATM, l'équipement d'interconnexion source comprend une mémoire pour contenir une file d'attente, réalisée sous forme d'une mémoire tampon. Les segments de données transmis par l'émetteur sur le sens descendant de la connexion TCP transitent par cette mémoire tampon.
Le procédé de contrôle de flux selon l'invention consiste en un mécanisme de contrôle de la taille de la fenêtre de transmission d'une connexion TCP, et s'applique plus particulièrement à une connexion TCP établie à travers un réseau à débit contrôlé. Au moins un point de contrôle du débit coopère avec une file d'attente par laquelle transitent les segments de données transmis par l'émetteur sur le sens descendant de la connexion. Un tel réseau est par exemple un réseau ATM à débit contrôlé avec une capacité de transfert de type CBR (de l'anglais "Constant Bit Rate"), ABR (de l'anglais "Available Bit Rate"), ou ABT (de l'anglais "ATM Block Transfer"). Un conduit ATM de ce type permet, une fois la ressource correspondante allouée dans le réseau, de limiter la taille des mémoires tampon mises en #uvre dans chaque étage de multiplexage du réseau et de réduire la perte sur le conduit à un niveau quasiment nul. Des connexions TCP établie à travers un tel conduit ATM, ne rencontrant aucune perte, font alors croître leur fenêtre de transmission W jusqu'à la taille maximale Wa annoncée par le récepteur. Or, la capacité mémoire offerte par le conduit est très réduite (en supposant un débit et un temps de propagation raisonnables), et dépend du produit bande passante-temps de transfert. En effet, le volume V de données absorbable par le réseau, lorsqu'il est émis à un débit déterminé D sur un conduit caractérisé par un temps de transfert aller-retour T, est donné par la relation suivante :
V=DxT (2)
Toujours par souci de clarté, le volume V est dans la suite exprimé en nombre de segments, alors qu'il s'exprime en réalité en nombre d'octets, le
<Desc/Clms Page number 10>
débit D s'exprimant en octets/seconde et le temps T en secondes Le paramètre T étant un paramètre intrinsèque du réseau, il est considéré comme constant pour une connexion donnée. Par conséquent, si D est choisi tel que V est inférieur la taille de la fenêtre W de la connexion TCP, et si l'on considère que le c#ur du réseau ne contient aucune mémoire tampon, on rencontre les situations suivantes # Dans le cas où les segments sont espacés, l'excédent de segments correspondant à la différence W-V s'accumule dans la file d'attente située au niveau du point de contrôle de débit, # Dans le cas où les acquittements sont espacés, une file d'acquittements correspondant aux segments constituant l'excédent W-V s'établit au niveau du point de contrôle.
Les figures 3 et 4, sur lesquelles les mêmes éléments qu'à la figure 2 portent les mêmes références, illustrent respectivement ces deux situations dans le cadre d'un exemple dans lequel W=11segments et V=8 segments. A la figure 3, la mémoire équivalente du réseau contient les segments Seg.5 à Seg.8 en cours de transfert sur le sens descendant et les acquittements Ack.1 à Ack. 4 en cours de transfert sur le sens montant. Les segments de données excédentaires, à savoir les segments Seg.9 à Seg.11, forment une file Fs stockée dans une mémoire tampon, en amont du point Pcd de contrôle de débit suivant le sens descendant. A la figure 4, la mémoire équivalente du réseau contient les segments Seg.8 à Seg.11 en cours de transfert sur le sens descendant et les acquittements Ack. 4 à Ack. 7 en cours de transfert sur le sens montant. Les acquittements excédentaires, à savoir les acquittements Ack. 1 à Ack. 3, forment une file Fa stockée dans une mémoire tampon, en amont du point Pcd de contrôle de débit suivant le sens montant.
Dans le premier cas (figure 3) les segments de données des fenêtres de transmission de chaque connexion TCP se trouvent donc en grande partie stockés dans des files d'attente respectives, à l'interface avec le réseau ATM, au point de multiplexage des flots TCP dans le conduit virtuel, c'est à dire dans une mémoire du routeur assurant la l'interconnexion entre le réseau local et le réseau ATM. Elles peuvent alors occuper un espace mémoire allant jusqu'à
<Desc/Clms Page number 11>
plusieurs dizaines de Kilo-octets par connexion (en fonction de la version de TCP mise en oeuvre) et par conséquent risquent de provoquer une congestion
Dans l'état de la technique, on a déjà proposé un moyen d'éviter la constitution de ces files consistant à limiter la taille de la fenêtre Wu utilisable par l'émetteur en modifiant, dans les segments d'acquittement, la valeur du paramètre de taille de fenêtre Wa inséré par le récepteur Ces techniques ont fait l'objet de différents travaux parmi lesquels on peut citer l'article de L.
Kalampoukas, A. Varma, et K. K. Ramakrishnan, "Explicit Window AdaptationA Method to Enhance TCP Performance, " Proceedings of INFOCOM'98, avril 1998, qui, dans le cadre de la première solution décrite ci-dessus, propose un principe basé sur un algorithme de gestion de mémoire tampon permettant de déterminer directement la taille de fenêtre de la connexion TCP sans avoir à en connaître le débit. L'article de R. Satyavolu, K. Duvedi, et S. Kalyanaraman, "Explicit Rate Control of TCP Applications," ATM Forum/98-0152R1. février 1998, décrit un mécanisme de traduction d'une valeur de débit en une valeur de taille de fenêtre basé sur un des algorithmes d'allocation de débit développé pour la capacité de transfert ATM ABR. L'article de P Narvaez et K. -Y. Siu, "An acknowledgement Bucket Scheme for Regulating TCP Flow over ATM", Computer Networks and ISDN Systems, vol. 30, Spécial Issue on ATM Traffic Management, 1998, propose l'implémentation d'un mécanisme plus complexe d'émulation de TCP au niveau du point de contrôle de débit associé à un "Ack bucket". Enfin, l'article de A. Koike, 'TCP Flow Control with ACR Information," ATM Forum/97-0758, septembre 1997 suggère aussi l'utilisation d'un "Ack bucket". En outre, il est décrit dans la demande internationale de brevet WO 99/35790 un procédé et un dispositif d'optimisation du flux d'une connexion TCP à travers un réseau ATM à débit contrôlé avec une capacité de transfert de type ABR, consistant à contrôler le paramètre de taille de fenêtre présent dans les segments d'acquittement retournés par le récepteur en fonction du débit disponible dans le réseau ATM et de l'espace disponible dans la mémoire tampon stockant la file de la connexion. Néanmoins, ce procédé requiert la prise en compte d'une information relative au débit disponible dans la couche de protocole ABR/ATM.
<Desc/Clms Page number 12>
L'invention vise à proposer une alternative aux méthodes connues de contrôle de flux d'une connexion TCP, notamment d'une connexion établie à travers un réseau à débit contrôlé, qui soit plus simple et donc plus facile à mettre en #uvre.
Ce but est atteint grâce à un procédé de contrôle du flux d'au moins une connexion TCP entre un émetteur et un récepteur, du type consistant à contrôler, au niveau d'un n#ud de multiplexage déterminé par lequel transitent des segments TCP relevant de la connexion, un paramètre de taille de fenêtre présent dans des segments d'acquittement retournés par le récepteur, caractérisé en ce qu'il comprend les étapes consistant à . a) recevoir au niveau dudit n#ud de multiplexage déterminé un segment d'acquittement provenant du récepteur sur le sens montant (récepteur vers émetteur) de la connexion ; b) contrôler un paramètre de taille de fenêtre présent dans ledit segment d'acquittement, en fonction de la différence entre, d'une part, une première valeur de contexte associée à la connexion TCP, définie comme le numéro de séquence du dernier segment ayant été transmis depuis ledit n#ud de multiplexage déterminé sur le sens descendant (émetteur vers récepteur) de la connexion auquel on ajoute la longueur dudit segment, et, d'autre part, le numéro de séquence indiqué dans le segment d'acquittement ; c) transmettre sur le sens montant de la connexion, depuis ledit n#ud de multiplexage vers l'émetteur, le segment d'acquittement avec le paramètre de taille de fenêtre ainsi contrôlé
En particulier, la connexion TCP est établie à travers un réseau 30 à débit contrôlé. Le n#ud de multiplexage déterminé est alors de préférence un point de contrôle du débit du réseau à débit contrôlé. Le point de contrôle du débit coopérant avec une mémoire pouvant contenir une file d'attente associée à la connexion, par laquelle transitent des segments de données émis par l'émetteur sur le sens descendant de la connexion, l'étape c) peut consister à contrôler, en fonction de ladite différence, le paramètre de taille de fenêtre présent dans ledit segment d'acquittement de manière à maintenir le volume des données stockées dans la file d'attente inférieur à une seconde valeur de contexte associée à la connexion TCP. De préférence, le n#ud de
<Desc/Clms Page number 13>
multiplexage déterminé est situé le plus près possible de l'émetteur, par exemple à l'interface entre le réseau local auquel est relié l'émetteur et le réseau à débit contrôlé C'est notamment le cas, dans un exemple, lorsque ce n#ud de multiplexage déterminé est aussi un point de contrôle de débit du réseau à débit contrôlé
Le mécanisme de contrôle de la taille des fenêtres de transmission selon l'invention permet d'empêcher l'apparition d'un phénomène de congestion au niveau du point de contrôle de débit d'un réseau à débit contrôlé en débit, en limitant la taille de fenêtre de chaque connexion TCP de telle manière que la taille de la file d'attente d'une connexion se constituant au niveau du point de contrôle de débit ne dépasse pas une valeur limite déterminée, qui est égale à la seconde valeur de contexte. Toutefois, il autorise des variations du débit offert aux connexions TCP par le réseau à débit contrôlé. Selon un autre avantage, ce mécanisme est compatible avec les algorithmes de contrôle de congestion mentionnés en introduction, qui agissent sur la taille de la fenêtre annoncée telle qu'elle est définie dans les segments d'acquittement lors de leur émission par le récepteur. Le mécanisme de contrôle de la taille de la fenêtre annoncée vient se superposer à ces mécanismes de contrôle de congestion connus.
L'invention propose également une unité de Contrôle de flux pour au moins une connexion TCP entre un émetteur et un récepteur, qui comprend .
- des moyens pour recevoir des segments de données TCP en provenance de l'émetteur et les transmettre vers le récepteur sur le sens descendant (émetteur vers récepteur) de la connexion TCP, et pour déterminer, à partir de chaque segment de données ainsi transmis, une première quantité indicative du rang, au sein d'un flot de données transmis suivant le sens descendant de la connexion TCP, d'un premier élément de données à transmettre vers le récepteur dans un prochain segment de données , - des moyens pour recevoir des segments d'acquittement TCP en provenance du récepteur et les transmettre vers l'émetteur sur le sens montant (récepteur vers émetteur) de la connexion TCP, et pour extraire de chaque segment d'acquittement TCP reçu une seconde quantité indicative du rang, au
<Desc/Clms Page number 14>
sein dudit flot de données, d'un prochain élément de données attendu par le récepteur ; - des moyens de régulation pour contrôler, en fonction de la différence entre ladite première quantité et ladite seconde quantité, un paramètre de taille de fenêtre (Wa) présent dans ledit segment d'acquittement TCP reçu avant de transmettre ledit segment d'acquittement TCP vers le récepteur.
En utilisant le vocabulaire propre à TCP, ladite première quantité correspond au numéro de séquence présent dans le segment de données auquel on ajoute la longueur (en octets) du champ de données de ce segment, et ladite seconde quantité correspond au numéro de séquence présent dans le segment d'acquittement TCP.
Dans un exemple, l'unité de contrôle de flux comprend en outre une mémoire pour contenir une file d'attente de segments de données reçus de l'émetteur et à transmettre vers le récepteur sur le sens descendant de la connexion TCP à travers un réseau à débit contrôlé, et en ce que le contrôle dudit paramètre de taille de fenêtre exercé par les moyens de régulation comporte une limitation dudit paramètre à une valeur au plus égale à la somme de ladite différence et d'une taille maximum fixée pour la file d'attente dans la mémoire. Cette taille maximum correspond à la seconde valeur de contexte associée à la connexion TCP, mentionnée plus haut.
L'invention propose encore un équipement d'interconnexion entre un premier réseau, par exemple un réseau local, et un second réseau, par exemple un réseau à débit contrôlé, qui comprend une telle unité de contrôle de flux.
D'autres caracténstiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre Celle-ci est purement illustrative et doit être lue en regard des dessins annexés, sur lesquels on a représenté : - à la figure 1, déjà analysée :un schéma illustrant le pnncipe de fenêtre glissante du mécanisme de contrôle de flux de TCP ; - à la figure 2, également déjà analysée : un schéma illustrant les transferts des segments et d'acquittements dans le réseau ; - à la figure 3 et à la figure 4, également déjà analysées : un schéma illustrant le principe de remplissage d'une file de segments et d'une file
<Desc/Clms Page number 15>
d'acquittements dans le cas, respectivement, d'un contrôle de débit d'une connexion TCP par espacement des segments ou par espacement des acquittements ; - à la figure 5 le schéma d'une connexion TCP adaptée à la mise en #uvre du procédé de l'invention , - à la figure 6 'le format d'un datagramme IP encapsulant un segment TCP ; - à la figure 7 . le détail de l'en-tête d'un segment TCP , - à la figure 8 et à la figure 9 : organigrammes montrant des étapes du procédé selon l'invention
A la figure 5, on a représenté schématiquement un exemple de liaison TCP sur un réseau à débit contrôlé adapté à la mise en #uvre du procédé selon l'invention. On considère un programme d'application s'exécutant sur un ordinateur 10 (ci-après l'émetteur) et devant transmettre des données à un programme d'application s'exécutant sur un ordinateur 20 distant (ci-après le récepteur). Ces deux programmes d'application utilisent le protocole TCP pour communiquer. L'émetteur 10 est relié à un réseau local 50, par exemple un réseau Ethernet à haut débit. Un tel réseau ne génère pas de congestion, compte tenu de l'importance du débit offert par rapport au volume des données qu'il transmet. Le récepteur 20 est également relié à un réseau local 60. Dans un exemple, on considère que le réseau local 60 est également un réseau ethernet, mais il peut bien entendu s'agir d'un réseau différent, par exemple de type LAN (de l'anglais "Local Area Network").
La connexion TCP se fait sur un réseau à débit commandé 30, par exemple un réseau ATM avec une capacité de transfert de type ABR. Le sens descendant de la connexion est désigné par une simple flèche, alors que son sens montant est désigné par une double flèche. Un équipement 40 d'interconnexion entre le réseau local 50 et le réseau 30 est relié à l'entrée du réseau 30. Il s'agit d'un routeur de périphérie. Cet équipement est le siège du multiplexage des différentes connexions TCP établies sur le réseau 30. Dans un exemple, il est aussi le siège du contrôle de débit du réseau 30 dans le sens descendant et comporte à cet effet un point de contrôle de débit Pcd Il est enfin le siège du contrôle de la taille de la fenêtre annoncée qui est à la base
<Desc/Clms Page number 16>
du procédé de contrôle de flux de la connexion TCP selon l'invention. Un équipement 70 d'interconnexion entre le réseau 30 et le réseau 60 est disposé à la sortie du réseau 30 pour assurer la fonction inverse de démultiplexage des segments TCP. Il s'agit également d'un routeur de périphérie.
Pour l'établissement de la connexion l'émetteur 10 émet un segment avec un fanion SYN dans le sens descendant et le récepteur émet en retour un segment avec un fanion ACK dans le sens montant, précisant éventuellement, dans un champ d'option, la valeur MSS (de l'anglais "Maximum Segment Size") de la taille maximum des segments qu'il peut recevoir compte tenu des caractéristiques de sa mémoire tampon. La connexion TCP est définie par la combinaison du numéro de port source et du numéro de port destination qui identifient respectivement le programme d'application de l'émetteur 10 et celui du récepteur 20.
Le flot de données à émettre est découpé par TCP et encapsulé dans des segments TCP dont la taille a été déterminée lors de l'établissement de la connexion compte tenu éventuellement de la valeur MSS. Chaque segment TCP est lui-même encapsulé dans un datagramme IP, au sein du routeur 40, selon le format montré à la figure 5 Le segment TCP comprend un bloc de données TCP précédé d'un en-tête TCP ('TCP header" en anglais) codé sur au moins 20 octets. Le datagramme IP comprend le segment TCP précédé d'un en-tête IP codé également sur 20 octets. La figure 6 montre le format de l'en-tête TCP. Celui-ci comprend : - un champ contenant le numéro de port source et un autre pour le numéro de port destination, qui sont codés sur 16 bits chacun ; - un champ contenant le numéro de séquence (dans le cas d'un segment de données) et un autre pour le numéro de séquence d'acquittement (dans le cas d'un segment d'acquittement), qui sont codés sur 32 bits chacun ; - un champ pour indiquer la longueur de l'en-tête (qui est toujours un multiple de 32 bits), codée sur quatre bits. ; champ est nécessaire car l'en- tête contient éventuellement un (ou plusieurs) champ (s) d'option, codé chacun sur 32 bits. Un tel champ d'option peut servir à indiquer la valeur du paramètre MSS, mentionné plus haut, s'agissant d'un segment ACK retouné par le récepteur lors de l'établissement de la connexion ,
<Desc/Clms Page number 17>
- 6 bits réservés pour un usage ultérieur, et 6 bits désignant respectivement la valeur de fanions URG, ACK, PSH, RST, SYN et FIN Ces fanions sont actifs à 1 Le fanion URG sert à indiquer que certains au moins des octets de données du segment doivent être remis en urgence. Un pointeur d'urgence, contenu dans un autre champ de l'en-tête, indique alors quel est le premier de ces octets qui doivent être remis en urgence Les fanions ACK, RST, SYN, et FIN ont été décrits plus haut. Enfin, le fanion PSH indique que les données sont émises en utilisant une opération appelée "push" en anglais, exécuté un programme d'application pour obtenir l'émission immédiate des données ; - un champ "taille de fenêtre", pour contenir un paramètre de taille de fenêtre Wa, codé sur 16 bits ; un tel paramètre Wa est présent dans chaque segment d'acquittement retourné par le récepteur sur le sens montant de la connexion ; il permet au récepteur d'indiquer à l'émetteur le nombre d'octets qu'il est prêt à accepter ; - un champ "checksum TCP", indiquant le résultat du calcul d'un total de vérification, codé sur 16 bits, afin de permettre la détection d'erreurs de transmission ; - un champ pour contenir le pointeur d'urgence précité, codé sur 16 bits , - et enfin le ou les champs d'option précités.
Comme on l'aura compris, le format de l'en-tête est identique pour les segment émis par l'émetteur et les segments d'acquittements émis par le récepteur, la valeur de certains champs propres à l'un ou l'autre seulement de ces deux types de segment étant indifférente au programme d'application respectivement du récepteur et de l'émetteur.
Les étapes du procédé selon l'invention vont maintenant être décrites en référence à l'organigramme de la figure 8. La première étape 100 consiste à recevoir, au niveau du point de contrôle de débit Pcd, un segment d'acquittement, noté Acki,j dans la suite, qui est par exemple le j-ième acquittement émis par le récepteur depuis l'établissement de la connexion d'indice i, où i et j sont des indices entiers Ce segment d'acquittement provient donc du récepteur dans le sens montant de la connexion d'indice i.
<Desc/Clms Page number 18>
Dans une étape de 200, le segment d'acquittement Acki,j est décapsulé pour détecter la valeur du numéro de séquence No SeqAcki,j de Acki,j Parallèlement, dans une étape 300, un contexte de connexion {NoSeqDatai ,Lim} est lu dans une mémoire de contexte sur laquelle on reviendra plus loin Ce contexte contient deux paramètres ou valeurs de contexte, qui sont associées à la connexion.
La première valeur de contexte NoSeqDatai est définie comme le numéro de séquence du dernier segment ayant transité par le point de contrôle de débit sur le sens descendant de la connexion auquel on ajoute la longueur de ce segment, exprimée en nombre d'octets. Par longueur d'un segment de données, on entend plus précisément la longueur d'un champ de données du segment, c'est à dire la longueur totale du segment moins celle de son en-tête.
Cette première valeur de contexte correspond donc au rang, dans le flot de données transmis sur le sens descendant de la connexion TCP, d'un premier élément de données ou octet à transmettre vers le récepteur dans un prochain segment de données. On reviendra plus loin sur la manière dont un contexte est généré et sur celle dont la première valeur de contexte est mise à jour.
La seconde valeur de contexte Lim correspond selon l'invention à une taille maximale fixée pour la file d'attente Fs dans la mémoire tampon dans laquelle transitent les segments émis par l'émetteur sur le sens descendant de la connexion. Cette valeur est constante pendant toute la durée de la connexion. Elle est associée à la connexion. Dans un exemple, elle est déterminée à l'établissement de la connexion TCP. Dans un mode de réalisation, elle est la même pour toutes les connexions. Toutefois, dans un mode de réalisation préféré, elle est déterminée en fonction du paramètre de taille maximale de segment MSS associé à la connexion. De préférence, elle est supérieure à la valeur dudit paramètre de taille maximale de segment MSS, de manière à éviter le phénomène de fenêtre stupide ("Silly Window', en anglais). On rappelle que la valeur de ce paramètre est le cas échéant indiquée par le récepteur à l'ouverture de la connexion. La seconde valeur de contexte Lim peut aussi être générée dynamiquement en fonction de l'espace mémoire disponible pour les files d'attente des nouvelles connexions TCP
<Desc/Clms Page number 19>
Dans une étape 400, on calcule un paramètre de contrôle Diff défini comme la différence entre, d'une part, la première valeur de contexte NoSeqDatai associée à la connexion d'indice i, et, d'autre part, le numéro de séquence NoSeqAcki,j indiqué dans le segment d'acquittement Acki,j Dit autrement Diff = NoSeqDatai - NoSeqAcki,j. Les valeurs positives du paramètre Diff constituent une estimation par excès du volume Vdata des données en cours de transfert dans le réseau sur le sens descendant de la connexion d'indice i. Il s'agit d'une estimation par excès en ce sens que la valeur d'estimation produite correspond au volume maximum que le réseau peut être en train d'absorber sur le sens descendant au moment où cette étape est exécutée. En effet, certains segments peuvent avoir été remis au récepteur depuis le moment où celui-ci a émis le segment d'acquittement Acki,j. D'autres segments peuvent avoir été détruits ou perdus. Bien entendu la paramètre Diff n'est représentatif du volume de données en cours de transfert dans le réseau sur le sens descendant de la connexion que si il est positif. On verra sur des exemples que tel n'est pas forcément le cas, en raison du mécanisme de retransmission de segment de TCP.
Une étape 500 consiste ensuite à calculer une valeur modifiée d'un paramètre de taille de fenêtre Wa inséré par le récepteur dans le segment d'acquittement Acki,j. Cette étape permet de modifier dans ledit segment d'acquittement, en fonction du paramètre Diff produit à l'étape précédente, la taille de la fenêtre annoncée de manière à maintenir la taille de la file d'attente Fs inférieure une taille maximale fixée, qui correspond à la seconde valeur de contexte Lim associée à la connexion d'indice i. On rappelle que la valeur de ce paramètre Wa est contenue dans le champ "taille de fenêtre" du segment TCP. Dans un exemple, le paramètre taille de fenêtre Wa est contrôlé selon la règle suivante : soit Wa=Min (Diff+Lim,Wa) si Diff #0 soit Wa=Min (Lim,Wa) si Diff<0 où Min est la fonction minimum.
<Desc/Clms Page number 20>
De cette manière, la valeur du paramètre de taille de fenêtre Wa est en permanence limitée à une valeur au plus égale à la somme du paramètre de contrôle Diff et de la seconde valeur de contexte Lim.
Dans une étape 600, la valeur contenue dans le champ "checksum TCP" du segment d'acquittement Ackj ; est recalculée et le champ "checksum TCP" est modifié en conséquence, de manière à tenir compte de la modification du champ "taille de fenêtre" contenant la valeur du paramètre de taille de fenêtre Wa. Dans une ultime étape 700, le segment d'acquittement Ackjj, avec un champ "taille de fenêtre" et un champ "Checksum TCP" éventuellement modifiés selon l'invention, est transmis, de préférence sans délai, vers l'émetteur 10 pour lui être remis.
Les étapes 100 à 700 décrites ci-dessus sont exécutées pour chaque segment d'acquittement émis par le récepteur 20 et transitant par le point de contrôle de débit Pcd sur le sens montant de la connexion TCP..
L'étape de calcul 400 est mise en oeuvre au niveau du point de contrôle du débit Pcd du réseau à débit contrôlé 30, c'est à dire aussi au niveau de la file d'attente Fs. De plus, le point de contrôle du débit Pcd est préférentiellement le plus près possible de l'émetteur 10. De cette manière, la portion du réseau située entre l'émetteur et le point de contrôle de débit Pcd contient le moins de données possible. De la sorte, le paramètre Diff est une estimation la plus précise possible du volume de donnée Vdata en cours de transfert dans le réseau sur le sens descendant de la connexion. Dans un exemple préféré, le point de contrôle du débit Pcd est situé dans l'équipement 40 d'interconnexion entre le réseau local 50 auquel est relié l'émetteur 10 et le réseau à débit contrôlé 30
L'équipement d'interconnexion entre le réseau local auquel est relié l'émetteur et le réseau à débit contrôlé, tel que le routeur 40 de la figure 5 comprend des moyens pour la mise en oeuvre du procédé. En particulier, il comprend le point de contrôle du débit Pcd et une mémoire de contexte MC. La seconde valeur de contexte Lim et/ou la première valeur de contexte NoSeqDatai sont lues dans cette mémoire MC à l'étape 300 de la figure 8 La première valeur de contexte associée à une connexion déterminée établie sur le réseau 30 est mise à jour dans la mémoire MC à chaque passage d'un
<Desc/Clms Page number 21>
segment au niveau du point de contrôle du débit Pcd sur le sens descendant de cette connexion. A la figure 9, on a représenté un organigramme des étapes de cette mise à jour Dans une étape 1000, un segment de données TCP, noté Segi,k, qui est par exemple le k-ième segment de données émis par l'émetteur 10 sur le sens descendant de la connexion d'indice i, où k est un autre indice entier, est reçu au niveau du point de contrôle de débit Pcd Dans une étape 2000, la première valeur de contexte NoSeqDatai associée à la connexion d'indice i est mise à jour dans la mémoire de contexte MC. A cet effet, une copie du segment Segi,k est décapsulée pour extraire son numéro de séquence. La longueur du segment est alors déterminée et ajoutée à son numéro de séquence et la valeur obtenue est enregistrée en tant que mise à jour de la première valeur de contexte NoSeqDatai. La longueur du segment, exprimée en nombre d'octets, est obtenue en soustrayant la longueur de l'entête TCP (indiquée dans un champ de l'en-tête du segment TCP comme il a été exposé ci-dessus en regard de la figure 7) à la longueur de la charge utile du datagramme IP. Cette dernière longueur est calculée à partir de la longueur totale du datagramme IP à laquelle est soustraite la longueur de son en-tête (indiquée quant à elle dans l'en-tête du datagramme IP). Enfin, dans une étape 3000, le segment de données Segi,k est émis (sans modification) sur le sens descendant de la connexion vers le récepteur 20.
On notera que la mémoire de contexte MC stocke avantageusement les contextes de chacune des connexions TCP établies sur le réseau à débit contrôlé 30. A cet effet, la mémoire MC est indéxée par le couple formé du numéro de port source et du numéro de port destination définnisant la connexion. La capacité mémoire de la mémoire de contexte est gérée dynamiquement. En effet, un contexte de contrôle est créé lors de la détection d'une nouvelle connexion IP. Une nouvelle connexion TCP est détectée soit de manière explicite, à la suite de la détection de segments d'établissements de connexion (segments portant le fanion SYN ainsi qu'il a été dit en introduction), soit de manière implicite à la suite de la détection de segments appartenant à une connexion pour laquelle aucun contexte n'existe encore. Pour permettre ces détections et ces créations de nouveaux contextes, une copie des
<Desc/Clms Page number 22>
segments émis par l'émetteur est systématiquement décapsulée pour en déduire, notamment, le couple formé du numéro de port source et du numéro de port destination, qui identifient la connexion concernée. De la même manière, un contexte est libéré de la mémoire, soit de manière explicite, à la suite de la détection de segments de fermeture de connexion (segments portant le fanion FIN), soit de manière implicite à la suite de la détection de l'expiration d'une temporisation ad-hoc. Bien entendu, l'espace mémoire occupé par la mémoire de contexte selon l'invention est bien plus petit que celui occupé par une file d'attente Fs selon l'art antérieur, en sorte que l'invention permet une économie substantielle d'espace mémoire.
A titre d'exemple du déroulement du procédé de l'invention, on considère un flot de données partagé en segments de taille constante égale à 100 octets, à transmettre sur une connexion TCP pour laquelle le premier contexte Lim a la valeur 300 (Lim=300). Dit autrement, on cherche à limiter la taille de la file d'attente Fs de cette connexion à 300 octets, c'est à dire l'équivalent de 3 segments.
Si l'on se place à un moment où le dernier segment émis par l'émetteur contenait les octets 401 à 500 du flot de données, la première valeur de contexte NoSeqData est affectée de la valeur 401 +100=501 Si la taille courante de la fenêtre de transmission est égale à 400 (W=400), cela signifie que, du point de vue de l'émetteur, le premier segment, qui portait les octets 1 à 100, a été valablement reçu et acquitté, alors que les deuxième, troisième, quatrième et cinquième segments, portant les octets respectivement 101 à, 200,201 à 300,301 à 400, et 401 à 500, et totalisant 400 octets à eux quatre, ont été émis mais n'ont pas encore été acquittés. Selon l'invention, on considère qu'ils sont en cours de transfert sur le sens descendant de la connexion TCP.
Admettons, dans un premier cas, que le récepteur émet un acquittement avec un numéro de séquence NoSeqAck égal à 201 et avec une taille de fenêtre annoncée égale à 500. Dit autrement, dans ce premier cas, le récepteur a reçu et acquitte le deuxième segment, et autorise un élargissement de la fenêtre W de 400 à 500 octets. On calcule alors le paramètre Diff par la différence :
<Desc/Clms Page number 23>
Diff = NoSeqAck - NoSeqData = 501-201 = 300 ;
Comme cette valeur est positive, la valeur modifiée de la taille de fenêtre annoncée par le récepteur est donnée par :
Wa = Min (Lim+Diff,Wa) = Min (600,500) = 500
Dit autrement, la taille de fenêtre Wa annoncée dans l'acquittement est maintenue. En d'autres termes, l'élargissement de la fenêtre de transmission W de la connexion est accepté. En effet, le procédé selon l'invention consiste à considérer que le sens descendant de la connexion peut au mieux absorber 600 octets puisque le réseau absorbe alors les 300 octets des troisième, quatrième et cinquième segments qui sont considérés comme étant toujours en cours de transfert sur le sens descendant, et que le sens descendant dispose d'une capacité supplémentaire de 300 octets permise par la file d'attente Fs.
Admettons, dans un deuxième cas, que le récepteur émet un acquittement avec un numéro de séquence NoSeqAck égal à 401 et avec une taille de fenêtre annoncée égale à 500 (Wa=500). Dit autrement, dans ce deuxième cas, le récepteur a reçu et acquitte le deuxième, le troisième, et le quatrième segment, et autorise un élargissement de la fenêtre W de 400 à 500 octets. On calcule alors le paramètre Diff par la différence :
Diff = NoSeqAck - NoSeqData = 501-401 = 100 ;
Comme cette valeur est positive, la valeur modifiée de la taille de fenêtre annoncée par le récepteur est donnée par -
Wa = Min (Lim+Diff,Wa) = Min (400,500) = 400
Dit autrement, la taille de fenêtre Wa annoncée dans l'acquittement est modifiée pour être ramenée de 500 à 400 octets. En d'autres termes, l'élargissement de la fenêtre de transmission W de la connexion est refusé. En effet, le procédé selon l'invention consiste à considérer que le sens descendant de la connexion ne peut au mieux absorber que 400 octets, puisque le réseau n'absorbe à ce moment que les 100 octets du cinquième segment qui sont dorénavant les seuls (au plus) en cours de transfert, et que le sens descendant ne bénéficie que d'une capacité supplémentaire de 300 octets permise par la file d'attente Fs. Permettre l'émission de quatre nouveaux segments risquerait donc de provoquer une congestion au niveau de la file d'attente Fs entraînant
<Desc/Clms Page number 24>
un dépassement de la valeur maximum de la capacité de celle-ci telle qu'elle est définie par la seconde valeur de contexte LIM
Si l'on se place maintenant à un moment où, ayant transmis les quatre premiers segments, dont seul le premier a valablement été acquitté, mais n'ayant pas reçu l'acquittement correspondant au deuxième segment (octets 101 à 200) avant l'expiration de la temporisation associée à celui-ci, l'émetteur vient de le retransmettre. La première valeur de contexte NoSeqData est donc affectée de la valeur 101 +100=201. Les deuxième, troisième, quatrième et cinquième segments, portant les octets respectivement 101 à 200,201 à 300, 301 à 400, et 101 à 200, et totalisant 400 octets à eux quatre, ont été émis mais n'ont pas encore été acquittés. Admettons que le récepteur émet alors un acquittement avec un numéro de séquence NoSeqAck égal à 401 et avec une taille de fenêtre annoncée égale à 500. Dit autrement, dans ce premier cas, le récepteur a reçu et acquitte le deuxième, le troisième, et le quatrième segment, et autorise un élargissement de la fenêtre W de 400 à 500 octets. On calcule alors le paramètre Diff par la différence .
Diff = NoSeqAck - NoSeqData = 201-401 = -200 ;
Comme cette valeur est négative, elle ne peut correspondre à un volume de données transitant sur le sens descendant de la connexion. La valeur modifiée de la taille de fenêtre annoncée par le récepteur est donnée par.
Wa = Min (Lim,Wa) = Min (300,500) = 300
Dit autrement, la taille de fenêtre Wa annoncée dans l'acquittement est modifiée pour être ramenée de 500 à 300 octets. En d'autres termes, l'élargissement de la fenêtre de transmission W de la connexion est refusé, et au contraire, la taille de la fenêtre W est ramenée de 400 à 300 du fait de la nouvelle valeur de la taille de la fenêtre annoncée Wa obtenue selon l'invention. En effet, le procédé selon l'invention consiste à considérer que le réseau ne peut plus absorber de données, que seuls les 300 octets de la file d'attente Fs sont disponibles pour absorber les données de la fenêtre W, et qu'il convient donc de limiter la taille de la fenêtre W à la taille limite Lim de la file Fs.
On notera que le mécanisme de contrôle de la taille de la fenêtre annoncée conforme au procédé selon l'invention est avantageux car il ne
<Desc/Clms Page number 25>
requiert pas d'indication explicite sur le débit de la connexion De plus il est compatible avec les mécanismes de contrôle de la taille de la fenêtre mis en #uvre au niveau du récepteur, tels que les algorithmes de démarrage lent, d'évitement de congestion, de retransmission rapide et de recouvrement rapide.

Claims (20)

REVENDICATIONS
1. Procédé de contrôle du flux d'au moins une connexion TCP entre un émetteur (10) et un récepteur (20), du type consistant à contrôler, au niveau d'un n#ud de multiplexage déterminé par lequel transitent des segments TCP relevant de la connexion, un paramètre de taille de fenêtre (Wa) présent dans des segments d'acquittement retournés par le récepteur, caractérisé en ce qu'il comprend les étapes consistant à : a) recevoir (100) au niveau dudit n#ud de multiplexage déterminé un segment d'acquittement provenant du récepteur sur le sens montant (récepteur vers émetteur) de la connexion ; b) contrôler (200-600) un paramètre de taille de fenêtre (Wa) présent dans ledit segment d'acquittement, en fonction de la différence (Diff) entre, d'une part, une première valeur de contexte (NoSeqDatai) associée à la connexion TCP, définie comme le numéro de séquence du dernier segment ayant été transmis depuis ledit n#ud de multiplexage déterminé sur le sens descendant (émetteur vers récepteur) de la connexion auquel on ajoute la longueur dudit segment, et, d'autre part, le numéro de séquence indiqué dans ledit segment d'acquittement, c) transmettre (700) sur le sens montant de la connexion, depuis ledit n#ud de multiplexage vers l'émetteur (10), le segment d'acquittement avec un paramètre de taille de fenêtre (Wa) ainsi contrôlé.
2. Procédé selon la revendication 1, caractérisé en ce que la connexion TCP est établie à travers un réseau (30) à débit contrôlé
3. Procédé selon la revendication 2, caractérisé en ce que ledit n#ud de multiplexage déterminé est un point de contrôle du débit (Pcd) du réseau à débit contrôlé (30).
4. Procédé selon la revendication 3, caractérisé en ce que, le point de contrôle du débit (Pcd) coopérant avec une mémoire pour contenir une file d'attente (Fs) associée à la connexion, par laquelle transitent des segments de données émis par l'émetteur sur le sens descendant de la connexion, l'étape c) consiste à contrôler, en fonction de ladite différence (Diff), le paramètre de taille de fenêtre (Wa) présent dans ledit segment d'acquittement de manière à
<Desc/Clms Page number 27>
maintenir le volume des données stockées dans la file d'attente (Fs) inférieur à une seconde valeur de contexte (Lim) associée à la connexion TCP.
5. Procédé selon l'une des revendications précédentes, caractérisé en ce que ledit n#ud de multiplexage déterminé est situé le plus près possible de l'émetteur (10).
6. Procédé selon l'une des revendications 2 à 4, caractérisé en ce que ledit n#ud de multiplexage déterminé est situé à une interface du réseau à débit contrôlé (30).
7. Procédé selon la revendication 4, caractérisé en ce que l'étape b) comprend d'une part la production (200-400) d'un paramètre de contrôle (Diff) égal à ladite différence entre la première valeur de contexte (NoSeqDatai) associée à la connexion TCP et le numéro de séquence indiqué dans le segment d'acquittement , et d'autre part le contrôle (500-600) du paramètre de taille de fenêtre (Wa) présent dans le segment d'acquittement selon la règle : soit Wa=Min (Diff+Lim,Wa) si Diff # 0 soit Wa=Min (Lim,Wa) si Diff < 0 où Wa est ledit paramètre de taille de fenêtre,
Diff est ledit paramètre de contrôle,
Min est la fonction minimum, et Lim est ladite seconde valeur de contexte associée à la connexion.
8. Procédé selon l'une des revendications précédentes, caractérisé en ce que, à l'étape b), la seconde valeur de contexte et/ou la première valeur de contexte sont lues dans une mémoire de contexte (MC).
9. Procédé selon la revendication 8, caractérisé en ce que, la mémoire de contexte (MC) stocke les première et seconde valeurs de contexte de chacune des connexions TCP établies à travers le réseau à débit contrôlé (30).
10. Procédé selon l'une des revendications 8 ou 9, caractérisé en ce que la première valeur de contexte associée à une connexion déterminée est mise à jour dans la mémoire de contexte à chaque réception, au niveau dudit n#ud déterminé, d'un segment de données provenant de l'émetteur sur le sens descendant de cette connexion.
<Desc/Clms Page number 28>
11. Procédé selon l'une quelconque des revendications 4 à 10, caractérisé en ce que la seconde valeur de contexte (Lim) associée à la connexion TCP, est déterminée à l'établissement de la connexion TCP.
12. Procédé selon la revendication 11, caractérisé en ce que la seconde valeur de contexte (Lim) associée à la connexion TCP, est déterminée en fonction d'un paramètre de taille maximale de segment (MSS) associé à cette connexion.
13 Procédé selon la revendication 12, caractérisé en ce que la seconde valeur de contexte (Lim) associée à la connexion TCP est supérieure à la valeur dudit paramètre de taille maximale de segment (MSS) associé à cette connexion.
14. Procédé selon l'une des revendications 3 à 13, caractérisé en ce que le point de contrôle de débit (Pcd) est situé le plus près possible de l'émetteur (10).
15. Procédé selon l'une des revendications précédentes caractérisé en ce que les étapes a) à c) sont mises en #uvre dans un équipement d'interconnexion entre un réseau local (50) et un réseau à débit contrôlé (30) à travers lequel est établie la connexion TCP.
16. Procédé selon l'une des revendications précédentes caractérisé en ce que les étapes a) à c) sont exécutées pour chaque segment d'acquittement reçu par ledit n#ud déterminé.
17. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que, à l'étape c), le segment d'acquittement est transmis sans délai.
18. Unité de Contrôle de flux pour au moins une connexion TCP entre un émetteur (10) et un récepteur (20), caractérisée en ce qu'elle comprend : - des moyens pour recevoir des segments de données TCP en provenance de l'émetteur (10) et les transmettre vers le récepteur (20) sur le sens descendant (émetteur vers récepteur) de la connexion TCP, et pour déterminer, à partir de chaque segment de données ainsi transmis, une première quantité indicative du rang, au sein d'un flot de données transmis suivant le sens descendant de la connexion TCP, d'un premier élément de
<Desc/Clms Page number 29>
données à transmettre vers le récepteur (20) dans un prochain segment de données ; - des moyens pour recevoir des segments d'acquittement TCP en provenance du récepteur (20) et les transmettre vers l'émetteur (10) sur le sens montant (récepteur vers émetteur) de la connexion TCP, et pour extraire de chaque segment d'acquittement TCP reçu une seconde quantité indicative du rang, au sein dudit flot de données, d'un prochain élément de données attendu par le récepteur (20) ; et - des moyens de régulation pour contrôler, en fonction de la différence entre ladite première quantité et ladite seconde quantité, un paramètre de taille de fenêtre (Wa) présent dans ledit segment d'acquittement TCP reçu avant de transmettre ledit segment d'acquittement TCP vers l'émetteur (10).
19. Unité de contrôle de flux selon la revendication 18, caractérisée en ce qu'elle comprend en outre une mémoire pour contenir une file d'attente de segments de données reçus de l'émetteur (10) et à transmettre vers le récepteur (20) sur le sens descendant de la connexion TCP à travers un réseau (30) à débit contrôlé, et en ce que le contrôle dudit paramètre de taille de fenêtre (Wa) exercé par les moyens de régulation comporte une limitation dudit paramètre à une valeur au plus égale à la somme de ladite différence et d'une taille maximum fixée pour la file d'attente dans la mémoire.
20. Equipement d'interconnexion (40) entre un premier réseau (50) et un second réseau (30), caractérisé en ce qu'il comprend une unité de contrôle de flux selon l'une des revendications 18 ou 19.
FR0001735A 2000-02-11 2000-02-11 Procede et unite de controle de flux d'une connexion tcp sur un reseau a debit controle Expired - Fee Related FR2805112B1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR0001735A FR2805112B1 (fr) 2000-02-11 2000-02-11 Procede et unite de controle de flux d'une connexion tcp sur un reseau a debit controle
US09/770,215 US6925060B2 (en) 2000-02-11 2001-01-29 Method and unit for controlling the flow of a TCP connection on a flow controlled network
EP01400241A EP1168729A1 (fr) 2000-02-11 2001-01-31 Procédé et unité de contrôle de flux d'une connexion TCP sur un réseau à débit contrôlé
EP01102508A EP1168722A1 (fr) 2000-02-11 2001-02-05 Procédé et unité de contrôle de flux d'une connexion TCP sur un réseau à débit contrôlé
JP2001029528A JP2001268130A (ja) 2000-02-11 2001-02-06 フロー制御されたネットワーク上におけるｔｃｐ接続のフローを制御するための方法および装置、相互接続機器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0001735A FR2805112B1 (fr) 2000-02-11 2000-02-11 Procede et unite de controle de flux d'une connexion tcp sur un reseau a debit controle

Publications (2)

Publication Number Publication Date
FR2805112A1 true FR2805112A1 (fr) 2001-08-17
FR2805112B1 FR2805112B1 (fr) 2002-04-26

Family

ID=8846921

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0001735A Expired - Fee Related FR2805112B1 (fr) 2000-02-11 2000-02-11 Procede et unite de controle de flux d'une connexion tcp sur un reseau a debit controle

Country Status (4)

Country Link
US (1) US6925060B2 (fr)
EP (2) EP1168729A1 (fr)
JP (1) JP2001268130A (fr)
FR (1) FR2805112B1 (fr)

Families Citing this family (115)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7522631B1 (en) * 1999-10-26 2009-04-21 Qualcomm, Incorporated Method and apparatus for efficient data transmission control in a wireless voice-over-data communication system
JP2001285400A (ja) * 2000-03-29 2001-10-12 Kddi Corp トラヒック統計情報収集方法
CN1209938C (zh) * 2000-07-04 2005-07-06 诺基亚公司 用于附加用户设备至电信网络的方法与系统
JP4691804B2 (ja) * 2001-03-02 2011-06-01 ソニー株式会社 無線伝送装置及び無線伝送方法
FI112140B (fi) * 2001-05-23 2003-10-31 Nokia Corp Informaation kommunikointi
WO2002097580A2 (fr) * 2001-05-31 2002-12-05 Espeed, Inc. Systeme de transaction sur valeurs presentant plusieurs niveaux de taux d'interet
US7856660B2 (en) 2001-08-21 2010-12-21 Telecommunication Systems, Inc. System for efficiently handling cryptographic messages containing nonce values
US7237007B2 (en) * 2001-12-05 2007-06-26 Qualcomm Incorporated Method and system for flow control between a base station controller and a base transceiver station
US20030126196A1 (en) * 2001-12-27 2003-07-03 Todd Lagimonier System for optimizing the invocation of computer-based services deployed in a distributed computing environment
US7411901B1 (en) * 2002-03-12 2008-08-12 Extreme Networks, Inc. Method and apparatus for dynamically selecting timer durations
US7283469B2 (en) * 2002-04-30 2007-10-16 Nokia Corporation Method and system for throughput and efficiency enhancement of a packet based protocol in a wireless network
US7236459B1 (en) * 2002-05-06 2007-06-26 Packeteer, Inc. Method and apparatus for controlling data transmission volume using explicit rate control and queuing without data rate supervision
US7685287B2 (en) * 2002-05-30 2010-03-23 Microsoft Corporation Method and system for layering an infinite request/reply data stream on finite, unidirectional, time-limited transports
US20040017773A1 (en) * 2002-07-23 2004-01-29 Eyeball Networks Inc. Method and system for controlling the rate of transmission for data packets over a computer network
JP2004187099A (ja) * 2002-12-04 2004-07-02 Shinko Electric Ind Co Ltd 通信制御方法、通信システム及び通信装置
AU2002953479A0 (en) * 2002-12-19 2003-01-09 Canon Kabushiki Kaisha Ip rate control
AU2003270971B2 (en) * 2002-12-19 2007-07-12 Canon Kabushiki Kaisha IP Rate Control
US6965564B2 (en) * 2003-02-14 2005-11-15 America Online, Inc. Wireless datagram transaction protocol system
JP4244159B2 (ja) 2003-05-16 2009-03-25 株式会社エヌ・ティ・ティ・ドコモ 受信装置、通信システムおよびプログラム
US8004981B2 (en) * 2003-06-17 2011-08-23 Cisco Technology, Inc. Methods and devices for the coordination of flow control between a TCP/IP network and other networks
JP4235507B2 (ja) * 2003-08-14 2009-03-11 株式会社エヌ・ティ・ティ・ドコモ 中継装置、送信装置、受信装置およびプログラム
US7564792B2 (en) * 2003-11-05 2009-07-21 Juniper Networks, Inc. Transparent optimization for transmission control protocol flow control
JP2005167353A (ja) * 2003-11-28 2005-06-23 Ntt Docomo Inc 送信装置およびプログラム
US7349337B1 (en) * 2003-12-12 2008-03-25 Novell, Inc. Techniques for shaping data transmission rates
US7773620B2 (en) * 2003-12-24 2010-08-10 Intel Corporation Method, system, and program for overrun identification
US7546367B2 (en) 2004-01-15 2009-06-09 Novell, Inc. Methods and systems for managing network traffic by multiple constraints
KR100602651B1 (ko) * 2004-02-13 2006-07-19 삼성전자주식회사 Ｔｃｐ 커넥션 관리 장치 및 방법
CN101076962B (zh) * 2004-07-23 2011-06-15 艾利森电话股份有限公司 数据单元发送机及其控制方法
US20060059256A1 (en) * 2004-09-10 2006-03-16 Nokia Corporation Signaling a state of a transmission link via a transport control protocol
US7292825B2 (en) * 2004-10-19 2007-11-06 Ipwireless, Inc. Retransmission scheme in a cellular communication system
US8743693B2 (en) * 2005-09-30 2014-06-03 Alcatel Lucent Method for dynamically adjusting token bucket sizes
US7701853B2 (en) * 2005-09-30 2010-04-20 Alcatel-Lucent Usa Inc. Method for policing-based adjustments to transmission window size
EP1793553A1 (fr) * 2005-12-02 2007-06-06 Alcatel Lucent Un TCP hôte avec un module de convergence TCP
US8125904B2 (en) * 2006-05-30 2012-02-28 Broadcom Corporation Method and system for adaptive queue and buffer control based on monitoring and active congestion avoidance in a packet network switch
US8000318B2 (en) 2006-06-30 2011-08-16 Embarq Holdings Company, Llc System and method for call routing based on transmission performance of a packet network
US8194643B2 (en) 2006-10-19 2012-06-05 Embarq Holdings Company, Llc System and method for monitoring the connection of an end-user to a remote network
US7948909B2 (en) 2006-06-30 2011-05-24 Embarq Holdings Company, Llc System and method for resetting counters counting network performance information at network communications devices on a packet network
US8289965B2 (en) 2006-10-19 2012-10-16 Embarq Holdings Company, Llc System and method for establishing a communications session with an end-user based on the state of a network connection
US8184549B2 (en) 2006-06-30 2012-05-22 Embarq Holdings Company, LLP System and method for selecting network egress
US9094257B2 (en) 2006-06-30 2015-07-28 Centurylink Intellectual Property Llc System and method for selecting a content delivery network
US8488447B2 (en) 2006-06-30 2013-07-16 Centurylink Intellectual Property Llc System and method for adjusting code speed in a transmission path during call set-up due to reduced transmission performance
US8717911B2 (en) 2006-06-30 2014-05-06 Centurylink Intellectual Property Llc System and method for collecting network performance information
US7684332B2 (en) 2006-08-22 2010-03-23 Embarq Holdings Company, Llc System and method for adjusting the window size of a TCP packet through network elements
US7940735B2 (en) 2006-08-22 2011-05-10 Embarq Holdings Company, Llc System and method for selecting an access point
US8274905B2 (en) 2006-08-22 2012-09-25 Embarq Holdings Company, Llc System and method for displaying a graph representative of network performance over a time period
US7843831B2 (en) 2006-08-22 2010-11-30 Embarq Holdings Company Llc System and method for routing data on a packet network
US8228791B2 (en) 2006-08-22 2012-07-24 Embarq Holdings Company, Llc System and method for routing communications between packet networks based on intercarrier agreements
US8098579B2 (en) * 2006-08-22 2012-01-17 Embarq Holdings Company, LP System and method for adjusting the window size of a TCP packet through remote network elements
US8743703B2 (en) 2006-08-22 2014-06-03 Centurylink Intellectual Property Llc System and method for tracking application resource usage
US8189468B2 (en) 2006-10-25 2012-05-29 Embarq Holdings, Company, LLC System and method for regulating messages between networks
US8238253B2 (en) 2006-08-22 2012-08-07 Embarq Holdings Company, Llc System and method for monitoring interlayer devices and optimizing network performance
US8223655B2 (en) 2006-08-22 2012-07-17 Embarq Holdings Company, Llc System and method for provisioning resources of a packet network based on collected network performance information
US8750158B2 (en) 2006-08-22 2014-06-10 Centurylink Intellectual Property Llc System and method for differentiated billing
US8549405B2 (en) 2006-08-22 2013-10-01 Centurylink Intellectual Property Llc System and method for displaying a graphical representation of a network to identify nodes and node segments on the network that are not operating normally
US8224255B2 (en) 2006-08-22 2012-07-17 Embarq Holdings Company, Llc System and method for managing radio frequency windows
US8194555B2 (en) 2006-08-22 2012-06-05 Embarq Holdings Company, Llc System and method for using distributed network performance information tables to manage network communications
US8015294B2 (en) 2006-08-22 2011-09-06 Embarq Holdings Company, LP Pin-hole firewall for communicating data packets on a packet network
US8307065B2 (en) 2006-08-22 2012-11-06 Centurylink Intellectual Property Llc System and method for remotely controlling network operators
US7889660B2 (en) 2006-08-22 2011-02-15 Embarq Holdings Company, Llc System and method for synchronizing counters on an asynchronous packet communications network
US8537695B2 (en) 2006-08-22 2013-09-17 Centurylink Intellectual Property Llc System and method for establishing a call being received by a trunk on a packet network
US8576722B2 (en) 2006-08-22 2013-11-05 Centurylink Intellectual Property Llc System and method for modifying connectivity fault management packets
US9479341B2 (en) 2006-08-22 2016-10-25 Centurylink Intellectual Property Llc System and method for initiating diagnostics on a packet network node
US8125897B2 (en) 2006-08-22 2012-02-28 Embarq Holdings Company Lp System and method for monitoring and optimizing network performance with user datagram protocol network performance information packets
US8102770B2 (en) 2006-08-22 2012-01-24 Embarq Holdings Company, LP System and method for monitoring and optimizing network performance with vector performance tables and engines
US8107366B2 (en) 2006-08-22 2012-01-31 Embarq Holdings Company, LP System and method for using centralized network performance tables to manage network communications
US8407765B2 (en) 2006-08-22 2013-03-26 Centurylink Intellectual Property Llc System and method for restricting access to network performance information tables
US8064391B2 (en) 2006-08-22 2011-11-22 Embarq Holdings Company, Llc System and method for monitoring and optimizing network performance to a wireless device
US8040811B2 (en) 2006-08-22 2011-10-18 Embarq Holdings Company, Llc System and method for collecting and managing network performance information
US7808918B2 (en) 2006-08-22 2010-10-05 Embarq Holdings Company, Llc System and method for dynamically shaping network traffic
US8619600B2 (en) 2006-08-22 2013-12-31 Centurylink Intellectual Property Llc System and method for establishing calls over a call path having best path metrics
US8144586B2 (en) 2006-08-22 2012-03-27 Embarq Holdings Company, Llc System and method for controlling network bandwidth with a connection admission control engine
US8531954B2 (en) 2006-08-22 2013-09-10 Centurylink Intellectual Property Llc System and method for handling reservation requests with a connection admission control engine
US8144587B2 (en) 2006-08-22 2012-03-27 Embarq Holdings Company, Llc System and method for load balancing network resources using a connection admission control engine
US8130793B2 (en) 2006-08-22 2012-03-06 Embarq Holdings Company, Llc System and method for enabling reciprocal billing for different types of communications over a packet network
US8199653B2 (en) 2006-08-22 2012-06-12 Embarq Holdings Company, Llc System and method for communicating network performance information over a packet network
US9258230B2 (en) * 2006-10-17 2016-02-09 Hewlett Packard Enterprise Development Lp In flight TCP window adjustment to improve network performance
CN101192911B (zh) * 2006-11-23 2010-09-22 大唐移动通信设备有限公司 一种时分复用模式下传输数据的方法和系统
US8111692B2 (en) 2007-05-31 2012-02-07 Embarq Holdings Company Llc System and method for modifying network traffic
KR100889670B1 (ko) * 2007-08-08 2009-03-19 삼성에스디에스 주식회사 모바일 디바이스상에서 ｔｃｐ 기반의 서비스거부 공격의 차단 방법
US8068425B2 (en) 2008-04-09 2011-11-29 Embarq Holdings Company, Llc System and method for using network performance information to determine improved measures of path states
WO2010125429A1 (fr) * 2009-04-30 2010-11-04 Freescale Semiconductor, Inc. Appareil, système de communication et procédé d'optimisation d'un flux de paquets de données
US8325623B1 (en) 2010-02-16 2012-12-04 Google Inc. System and method for reducing latency during data transmissions over a network
US8964543B1 (en) 2010-02-16 2015-02-24 Google Inc. System and method of reducing latency by transmitting duplicate packets over a network
US8468196B1 (en) 2010-05-20 2013-06-18 Google Inc. System and method of reducing latency using adaptive retransmission timeouts
US8239532B1 (en) 2010-06-24 2012-08-07 Google Inc. System and method of reducing latency using adaptive DNS resolution
US8364812B2 (en) * 2010-08-27 2013-01-29 Sandvine Incorporated Ulc Method and system for network data flow management
US8576711B1 (en) 2010-09-28 2013-11-05 Google Inc. System and method for reducing latency via client side dynamic acknowledgements
JP5631754B2 (ja) * 2011-01-14 2014-11-26 株式会社富士通アドバンストエンジニアリング スイッチ装置、輻輳防止方法、及び輻輳防止プログラム
US10425371B2 (en) * 2013-03-15 2019-09-24 Trane International Inc. Method for fragmented messaging between network devices
US10432529B2 (en) 2013-09-19 2019-10-01 Connectivity Systems Incorporated Enhanced large data transmissions and catastrophic congestion avoidance over IPv6 TCP/IP networks
US9350663B2 (en) * 2013-09-19 2016-05-24 Connectivity Systems Incorporated Enhanced large data transmissions and catastrophic congestion avoidance over TCP/IP networks
US11172016B2 (en) * 2017-03-30 2021-11-09 Intel Corporation Device, method and system to enforce concurrency limits of a target node within a network fabric
US11032257B1 (en) 2017-12-08 2021-06-08 Rankin Labs, Llc Method for covertly delivering a packet of data over a network
US11861025B1 (en) 2018-01-08 2024-01-02 Rankin Labs, Llc System and method for receiving and processing a signal within a TCP/IP protocol stack
US10725743B2 (en) 2018-01-22 2020-07-28 John Rankin System and method for generating random numbers
WO2019152573A1 (fr) 2018-01-31 2019-08-08 John Rankin Système et procédé de communication sécurisée utilisant des blocs aléatoires ou des nombres aléatoires
US11294636B2 (en) 2018-02-28 2022-04-05 Rankin Labs, Llc System and method for expanding a set of random values
WO2019183543A1 (fr) 2018-03-23 2019-09-26 John Rankin Système et procédé d'identification d'une communauté d'origine d'un locuteur à partir d'un échantillon sonore
WO2020014354A1 (fr) 2018-07-10 2020-01-16 John Rankin Système et procédé d'indexation de fragments de son contenant des paroles
US11689543B2 (en) 2018-08-10 2023-06-27 Rankin Labs, Llc System and method for detecting transmission of a covert payload of data
US10728220B2 (en) 2018-08-10 2020-07-28 John Rankin System and method for covertly transmitting a payload of data
WO2020041390A1 (fr) 2018-08-21 2020-02-27 John Rankin Système et procédé de diffusion de trafic de réseau sur un certain nombre d'hôtes disparates
US10903977B2 (en) 2018-12-19 2021-01-26 Rankin Labs, Llc Hidden electronic file systems
US11989320B2 (en) 2018-12-19 2024-05-21 Rankin Labs, Llc Hidden electronic file system within non-hidden electronic file system
US11526357B2 (en) 2019-01-21 2022-12-13 Rankin Labs, Llc Systems and methods for controlling machine operations within a multi-dimensional memory space
US11108671B2 (en) 2019-01-21 2021-08-31 Rankin Labs, Llc Systems and methods for processing network traffic using dynamic memory
US10901739B2 (en) 2019-01-21 2021-01-26 Rankin Labs, Llc Systems and methods for controlling machine operations using stack entries comprising instruction configuration parameters
WO2020214752A1 (fr) 2019-04-17 2020-10-22 John Rankin Système et procédé de détection de produits chimiques cachés à l'intérieur d'objets d'une manière non invasive
US11487674B2 (en) 2019-04-17 2022-11-01 Rankin Labs, Llc Virtual memory pool within a network which is accessible from multiple platforms
US11729184B2 (en) 2019-05-28 2023-08-15 Rankin Labs, Llc Detecting covertly stored payloads of data within a network
US11372773B2 (en) 2019-05-28 2022-06-28 Rankin Labs, Llc Supporting a virtual memory area at a remote computing machine
WO2020243249A1 (fr) 2019-05-28 2020-12-03 John Rankin Stockage secret d'une charge utile de données à l'intérieur d'un réseau
US11430010B2 (en) 2019-08-07 2022-08-30 Rankin Labs, Llc System and method for influencing a primary target through word-of-mouth interaction with secondary targets
US11105934B2 (en) 2019-08-07 2021-08-31 Rankin Labs, Llc Determining proximity and attraction of objects within a coordinate system
WO2021183421A2 (fr) 2020-03-09 2021-09-16 John Rankin Systèmes et procédés pour une réponse à implication reflétant des morphèmes

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6701370B1 (en) * 1994-06-08 2004-03-02 Hughes Electronics Corporation Network system with TCP/IP protocol spoofing
JPH09510596A (ja) * 1994-06-08 1997-10-21 エイチイー・ホールディングス・インコーポレーテッド・ディー ビーエー・ヒューズ・エレクトロニクス ハイブリッドネットワークアクセスのための装置および方法
US6370114B1 (en) 1997-12-31 2002-04-09 Nortel Networks Limited Apparatus and method for optimizing congestion control information in a multi-protocol network
US6680922B1 (en) * 1998-07-10 2004-01-20 Malibu Networks, Inc. Method for the recognition and operation of virtual private networks (VPNs) over a wireless point to multi-point (PtMP) transmission system
US6697378B1 (en) * 1998-10-16 2004-02-24 Cisco Technology, Inc. Method and apparatus for class based transmission control of data connections based on real-time external feedback estimates obtained using messaging from a wireless network
US6563787B1 (en) * 1998-11-09 2003-05-13 Alcatel Canada Inc. Method and apparatus for providing data flow control of a transmission port
US6646985B1 (en) * 1999-06-03 2003-11-11 Fujitsu Network Communications, Inc. Congestion control mechanism in a network access device
US6643710B1 (en) * 1999-09-17 2003-11-04 3Com Corporation Architecture to fragment transmitted TCP packets to a requested window size
US6564267B1 (en) * 1999-11-22 2003-05-13 Intel Corporation Network adapter with large frame transfer emulation
US6687227B1 (en) * 2000-03-13 2004-02-03 Nortel Networks Limited Systems and methods for requesting packets for transmission over a wirless channel having a dynamically changing capacity due to a highly varibale delay

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
CHIM V ET AL: "END-TO-END ACKNOWLEDGMENTS FOR INDIRECT TCP OVER WIRELESS INTERNETWORKS", VICTORIA, CANADA, AUG. 20 - 22, 1997,NEW YORK, NY: IEEE,US, 20 August 1997 (1997-08-20), pages 774 - 777, XP000852277, ISBN: 0-7803-3906-1 *
HASEGAWAT T ET AL: "PROTOCOL ARCHITECTURE OF HIGH SPEED TCP/IP SERVICE OVER INTERNATIONAL ATM NETWORK", IEEE ATM WORKSHOP. PROCEEDINGS,XX,XX, 26 May 1998 (1998-05-26), pages 159 - 168, XP000892340 *
KALAMPOUKAS ET AL: "EXPLICIT WINDOW ADAPTATION: A METHOD TO ENHANCE TCP PERFORMANCE", PROCEEDINGS IEEE INFOCOM. THE CONFERENCE ON COMPUTER COMMUNICATIONS,US,NEW YORK, NY: IEEE, 29 March 1998 (1998-03-29), pages 242 - 251, XP000854199, ISBN: 0-7803-4384-0 *
KOIKE A: "Active TCP control by a network", SEAMLESS INTERCONNECTION FOR UNIVERSAL SERVICES. GLOBAL TELECOMMUNICATIONS CONFERENCE. GLOBECOM'99. (CAT. NO.99CH37042), SEAMLESS INTERCONECTION FOR UNIVERSAL SERVICES. GLOBAL TELECOMMUNICATIONS CONFERENCE. GLOBECOM'99, RIO DE JANEIREO, BRAZIL, 5-9 D, 1999, Piscataway, NJ, USA, IEEE, USA, pages 1921 - 1925 vol.3, XP002156592, ISBN: 0-7803-5796-5, Retrieved from the Internet <URL:http://ieeexplore.ieee.org> [retrieved on 20001227] *

Also Published As

Publication number Publication date
EP1168729A1 (fr) 2002-01-02
FR2805112B1 (fr) 2002-04-26
JP2001268130A (ja) 2001-09-28
US6925060B2 (en) 2005-08-02
US20010017844A1 (en) 2001-08-30
EP1168722A1 (fr) 2002-01-02

Similar Documents

Publication Publication Date Title
FR2805112A1 (fr) Procede et unite de controle de flux d&#39;une connexion tcp sur un reseau a debit controle
EP2064853B1 (fr) Procédé d&#39;optimisation du contrôle du trafic dans un réseau de télécommunication par paquets
EP1096827B1 (fr) Procédé de mise en conformité à un contrat de trafic d&#39;un flux de paquets d&#39;un réseau de transport de paquets à longueur variable
FR2933834A1 (fr) Procede de gestion d&#39;une transmission de flux de donnees sur un canal de transport d&#39;un tunnel, tete de tunnel, produit programme d&#39;ordinateur et moyen de stockage correspondants.
FR2926939A1 (fr) Procede de transmission de donnees avec anticipation des acquittements, dispositif d&#39;entree, produit programme d&#39;ordinateur et moyen de stockage correspondants
FR2927749A1 (fr) Procede et dispositif de transmission de donnees, notamment video.
FR2908576A1 (fr) Procede,dispositif et application logicielle d&#39;ordonnancement d&#39;une transmission de paquets d&#39;un flux de donnees
FR2954029A1 (fr) Procede de transmission de paquets d&#39;un flux de donnees bidirectionnel passager, dispositif gestionnaire, produit programme d&#39;ordinateur et moyen de stockage correspondants
EP2706781B1 (fr) Procédé de transmission dans un réseau ad hoc multisauts ip
WO2008087364A2 (fr) Procede de transmission/reception en temps reel de donnees par paquets entre un serveur et un terminal client, serveur et terminal correspondants
EP3637845B1 (fr) Procédé de communication basé sur un protocole de transmission par trames
EP3989494A1 (fr) Procede d&#39;agregation et de regulation de messages via un canal de communication bidirectionnel contraint
EP3414873B1 (fr) Procédé de transmission de données dans une communication multi-chemin
WO2023169938A1 (fr) Procédé de gestion d&#39;une retransmission de données échangées sur un chemin établi entre un premier équipement de communication et un deuxième équipement de communication au moyen d&#39;une valeur d&#39;un paramètre de performance intermédiaire déterminée par un nœud intermédiaire appartenant audit chemin
WO2023078995A2 (fr) Procédé de vérification de la fiabilité d&#39;une première valeur d&#39;un paramètre de contrôle de flux relatif à une connexion destinée à être établie entre un premier équipement de communication et un deuxième équipement de communication reliés par un chemin comprenant au moins un nœud intermédiaire au moyen d&#39;une valeur d&#39;un paramètre de performance intermédiaire déterminée par le nœud intermédiaire
WO2023078993A1 (fr) Procédé de gestion d&#39;une retransmission de données échangées sur un chemin établi entre un premier équipement de communication et un deuxième équipement de communication au moyen d&#39;une valeur d&#39;un paramètre de performance intermédiaire
EP1668869B1 (fr) Procede pour adapter un seuil d&#39;evitement de congestion en fonction de la charge du reseau et dispositif d&#39;emission associe
FR2935576A1 (fr) Procede de gestion d&#39;une transmission de flux de donnees sur un tunnel multi-canal, tete de tunnel, produit programme d&#39;ordinateur et moyen de stockage correspondants.
WO2007101962A1 (fr) Mécanisme de régulation multicouches du débit d&#39;un flux de données tcp dans un réseau haut débit ethernet full duplex
FR2951045A1 (fr) Procede de gestion de la taille de paquets de donnees d&#39;un flux de donnees, produit programme d&#39;ordinateur, moyen de stockage, et tete de tunnel correspondants.
WO2019077247A1 (fr) Procédé d&#39;échange de trames de données et stations wi-fi associées
FR2826824A1 (fr) Procede et dispositif de construction de trame dans un systeme tdma
FR2925806A1 (fr) Procede de transmission de donnees et dispositif correspondant
Afif Interaction des Mécanismes RLC/MAC et de SCTP dans les Réseaux Mobiles B3G
WO2012034982A1 (fr) Dispositif d&#39;adaptation de debit de donnees à une couche physique, circuit integre comportant un tel dispositif et procede, programme d&#39;ordinateur et moyens de stockage correspondants

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20061031