EP1649666A2 - Procede pour evaluer la bande passante disponible d'un canal de transmission lors d'une transmission de donnees et dispositif d'emission pour la mise en oeuvre du procede - Google Patents

Procede pour evaluer la bande passante disponible d'un canal de transmission lors d'une transmission de donnees et dispositif d'emission pour la mise en oeuvre du procede

Info

Publication number
EP1649666A2
EP1649666A2 EP04767689A EP04767689A EP1649666A2 EP 1649666 A2 EP1649666 A2 EP 1649666A2 EP 04767689 A EP04767689 A EP 04767689A EP 04767689 A EP04767689 A EP 04767689A EP 1649666 A2 EP1649666 A2 EP 1649666A2
Authority
EP
European Patent Office
Prior art keywords
loop delay
transmitter
window
time
delay
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.)
Withdrawn
Application number
EP04767689A
Other languages
German (de)
English (en)
Inventor
Amine Lamani
Joél PENHOAT
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.)
Orange SA
Original Assignee
France Telecom SA
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 France Telecom SA filed Critical France Telecom SA
Publication of EP1649666A2 publication Critical patent/EP1649666A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/27—Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • 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
    • 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]

Definitions

  • the invention relates to a method for evaluating the available bandwidth of a transmission channel during a data transmission between a transmitter and a receiver through said channel, said transmission using a so-called “sliding window” method and a device. of emission for the implementation of the process.
  • available bandwidth is meant the amount of data that can be transmitted per unit of time, that is to say the bit rate, through the transmission channel.
  • TCP Transfer Control Protocol
  • the transmitter assigns a sequence number to each byte of a transmitted data packet. On receipt of this packet, the receiver returns to the transmitter an acknowledgment of receipt "ACK" accompanied by the sequence number of the next expected byte.
  • ACK acknowledgment of receipt
  • the transmitter triggers a retransmission timer clock memorizing a retransmission delay "RTO" (Retransmission Time Out).
  • the transmitter If, at the end of the RTO retransmission period, the transmitter has not received an acknowledgment of receipt for a previously transmitted packet, it transmits it again.
  • This RTO retransmission delay is calculated, using an algorithm, according to a "RTT" loop delay (Round Trip Time), also called round trip delay, corresponding to the average duration between the emission of a forward packet and receipt of a return receipt. If the receiver receives non-successive packets, this is signaled to the transmitter by the arrival of duplicate acknowledgments.
  • a sliding window mechanism is used to allow the transmitter to transmit multiple data packets before receiving an acknowledgment. Ultimately, the size of the window fixes a number of packets that can be transmitted without the need for an acknowledgment.
  • This window moves as acknowledgments are received.
  • the transmitter upon receipt of each acknowledgment, deletes the transmitted and acknowledged packets in its transmission buffer memory and advances its window in order to transmit the following packets.
  • the window size is dynamic. Initially, it is fixed at a single packets, or even at a few packets (generally four at most), then it increases in the forum and as the acknowledgments of receipt are received, first exponentially, up to a threshold preset called “ssthresh" (Slow Start Threshold), then linearly.
  • the transmission window On reception of each acknowledgment, the transmission window not only advances, so that the next packets are transmitted, but also increases. The size of the window thus increases up to an upper congestion limit, the value of which depends on the available bandwidth of the transmission channel.
  • the available bandwidth in other words the maximum data rate permissible for transmission, essentially depends on the theoretical maximum capacity of the channel and the actual data traffic through this channel.
  • the window is too large (too high speed given the available bandwidth), there is congestion, which results in the loss of data packets.
  • the transmitter receives a notification of loss from the receiver or b) the RTO retransmission period expires before receipt of an acknowledgment of receipt.
  • the size of the window is halved, then remains stable for a short period before resuming linear growth until reaching an upper limit of congestion again.
  • the size of the window is reduced to a single packet and the "ssthresh" threshold is fixed at half the size of the window at the time when the congestion was detected. Window size starts to grow again exponential up to the "ssthresh” threshold then linearly until reaching an upper congestion limit again.
  • the detection of congestion is therefore carried out a posteriori, by detection of the loss of data packets.
  • the size of the window is then suddenly reduced to a conservative value and it takes a certain period of time for it to become optimal again in view of the available bandwidth. Such a reduction in the size of the window induces a significant recovery time and, consequently, considerably reduces the average data rate in transmission.
  • the invention aims to overcome this last drawback.
  • the invention relates to a method for evaluating the available bandwidth of a transmission channel during a data transmission between a transmitter and a receiver, through said channel, the transmission using a method called “window” sliding “according to which the sender is authorized to send to the receiver several data packets, contained in the window, before receiving an acknowledgment of receipt for at least one of these packets, and advances the window, in order to send the following packets, as it receives the acknowledgments, process in which the transmitter measures a loop delay corresponding to the time between sending a data packet and receiving a acknowledgment of receipt corresponding to successive sampling instants, characterized in that the transmitter observes the state of the loop delay and, each time it detects a state of stability thereof, it stores the pair of values (RTT n , W n , m ax) containing the stable value of the loop delay and the maximum size of the transmission window observed for this stable value of the loop delay.
  • the transmitter keeps in memory pairs of values associated with loop delay / window size corresponding to the states of stability observed for the transmission channel considered.
  • This history of loop delay / window size pairs makes it possible, after congestion or a period of instability through the transmission channel, to return to a window size having a reference value. It also makes it possible, in the event of a reduction in the available bandwidth, to quantify the oversizing of the transmission window in relation to the new bandwidth. In the event of a decrease in available bandwidth, the rate of decrease in bandwidth can be deducted from the rate of increase in loop delay.
  • the "available bandwidth” represents the maximum amount of data that the transmitter can transmit to the receiver per unit of time, that is, the maximum allowable data rate, through the transmission channel.
  • the invention therefore also consists in observing the evolution of the loop delay in order to deduce therefrom the availability of the bandwidth of the transmission channel.
  • the transmitter measures a loop delay error corresponding to the difference between the last two loop delay samples and calculates an accumulation of errors by adding the loop delay errors over the last N loop delay samples, - if the transmitter detects that the last N loop delay errors and the cumulative - SSS of errors are between and -, - representing a tolerance threshold, it
  • the transmitter detects a stable state of the loop delay.
  • the accumulation of errors makes it possible to quantify the evolution of the loop delay, in other words to measure the amount of increase or decrease in the loop delay.
  • the threshold duration is equal to the recorded loop delay.
  • the transmitter detects that C t ) - L for the first time at time t x , i) from time t x , for each sampling instant ti, the transmitter calculates the accumulation of errors Ci by adding all the errors measured from this instant t x to the sampling instant ti, and ii) if the transmitter detects that C i ) S c , S c representing a critical threshold, it signals that the data rate is greater than the available bandwidth.
  • the transmitter detects that C t (for the first time at time t y , i) from time t y , for each sampling instant ti, the transmitter calculates the cumulative error Ci by adding all the errors measured from this instant t x until the sampling instant ti, and ii) if it detects that C t ( ⁇ S C , it signals that the data rate is lower than the bandwidth
  • the transmitter records the stable value of the loop delay and the maximum size of available. the window observed for this stable value of the loop delay.
  • the transmitter can thus memorize one or more pair (s) each comprising a stable value RTT n of delay loop and the maximum value of window size W n) ma ⁇ observed when the loop delay is stable and is equal to RTT n and there is therefore no risk of congestion.
  • the invention also relates to a transmission device for implementing the previously defined method, comprising - transmission means through a transmission channel, using a method called “sliding window", arranged to send several packets of data, contained in the window, before receiving an acknowledgment for at least one of these packets and for advancing the window in order to transmit the following packets, and - means for measuring a loop delay corresponding to the duration between the sending of a data packet and the reception of a corresponding acknowledgment of receipt, at successive sampling instants, device characterized in that it comprises means for detecting a state of stability of the delay of loop and means for memorizing, each time the transmitter detects a state of stability of the loop delay (RTT n ), the pair of values
  • FIG. 4A there is shown a communication network 1, in this case the Internet, and a client communication terminal 2 connected to the Internet 1 via an ISP (Internet Service provider). Provider) 3.
  • the access provider 3 integrates a speed accelerator server 4, also called a "proxy" server.
  • the reference 5 designates the transmission channel between the communication terminal 2 and the rate accelerator server 4.
  • the transmission channel 5 is a TCP (Transfer Control Protocol) link by satellite.
  • the TCP flow control protocol used on the transmission channel 5, makes it possible to control the correct routing of data packets between the server 4 and the client terminal 2, using a cumulative acknowledgment mechanism. operating as follows:
  • the TCP sender assigns a sequence number to each byte of a transmitted data packet. After having received several packets transmitted by the TCP transmitter, the TCP receiver returns to the TCP transmitter an acknowledgment of receipt "ACK" accompanied by the sequence number of the next byte expected and thus confirming the good reception of all the packets preceding this byte .
  • the TCP transmitter In addition, if, at the expiration of a predetermined retransmission time (RTO) (Retransmission Time Out), the TCP transmitter has not received an acknowledgment of receipt for a previously transmitted packet, it transmits a new one times to the TCP receiver.
  • This RTO retransmission delay is calculated by the TCP transmitter, using an algorithm, according to a "RTT" (Round Trip Time) loop delay corresponding to the duration average between sending a forward packet and receiving a return acknowledgment.
  • the TCP transmitter also uses a "sliding transmission window" mechanism authorizing it to transmit several data packets, contained in the window, before receiving an acknowledgment. Due to its size, the transmission window fixes a number of packets that can be transmitted without the need for an acknowledgment of receipt (see Figure 3).
  • the TCP transmitter advances its transmission window in order to transmit the following packets and increases the size of the window.
  • the send window contains a packet, or even a few packets (generally not more than four), and increases first exponentially to a predefined threshold called "ssthresh" (Slow Start Threshold), then linear to an optimal limit beyond which there is congestion, which results in the loss of data packets.
  • ssthresh Slow Start Threshold
  • the data packets can be classified as follows: - packets sent and acknowledged 61: n ° ll to 13 - packets sent and unacknowledged 62: n ° 14 to 16 - packets to be sent 63: n ° 17 to 21 - packets not authorized to be sent 64: n ° 22 to 24
  • the last acknowledgment received "ACK" 60, of value 14 confirmed the reception of all the data packets preceding packet n ° 14.
  • the left edge of window 7 is therefore positioned just before package # 14.
  • the TCP sender is only allowed to send the packets contained in the send window (numbered from 14 to 21) without receiving an acknowledgment.
  • the next packet that the TCP sender will send is No. 17.
  • the TCP sender To be authorized to send the following packets, not contained in window 7 as shown in Figure 3 (i.e. packets # 22 and following), the TCP sender must receive a new acknowledgment ACK of value strictly greater than 14 and drag its window 7 to the right (in the direction of arrow 8), so as to position the left edge of window 7 just before the packet whose number corresponds to the value of the acknowledgment received. For example, if the next acknowledgment of receipt has the value 16, the left edge of window 7 is moved in the direction of arrow 8 so as to be positioned just before packet n ° 16. Furthermore, at the same time as it moves window 7, the transmitter
  • TCP increases the size of window 7. For example, if the phase in which it is located allows the TCP sender to increase the size of window 7 of a packet upon receipt of each acknowledgment, the new window 7 then contains nine packages.
  • the TCP transmitter shown in Figure 2 is the speed accelerator server
  • the transmission module 40 comprises, in known manner, a module 40 for transmitting data packets, a module 41 for receiving acknowledgments of receipt, a module 42 for calculating the retransmission delay RTO and a timer 43 for retransmission delay.
  • the transmission module 40 is arranged to transmit data packets using the method of the "sliding transmission window" previously explained (see FIG. 3). It is therefore authorized to send several data packets, contained in the transmission window, before receiving an acknowledgment of receipt.
  • the transmission module 40 As for and as the reception of the acknowledgments of reception, signaled by the reception module 41, the transmission module 40, on the one hand, advances the sliding transmission window and, on the other hand, calculates and updates the size of this window.
  • TCP the size of the window, initially set to a packet, or even a few packets
  • the module 41 for receiving acknowledgments is arranged to receive and process the "ACK" acknowledgments and to transmit to the other modules useful information, provided by acknowledgments, to update emission state variables such as in particular the RTO retransmission delay, the RTT loop delay, the size W of the sliding transmission window and the "ssthresh” threshold.
  • the RTO retransmission delay calculation module 42 is arranged to calculate the RTO retransmission delay using an algorithm provided by the TCP protocol, from the loop delay. It is recalled here that the loop delay corresponds to the average time between the sending of a forward data packet and the reception of a return acknowledgment. In operation, the calculation module 42 measures the loop delay
  • SRRTj represents the smoothed value of the RTTj sample of the Smoothed Round Trip Time measured at time tj. It then calculates the RTO retransmission delay from the measured and smoothed loop delay, using the algorithm of the TCP protocol. For more information on this subject, the reader is invited to refer in particular to document RFC2988 of ITETF (Internet Engineering Task Force). The RTO retransmission delay thus calculated is supplied to the clock 43.
  • the retransmission delay clock 43 connected to the module for calculating the RTO retransmission delay and to the transmission module 40, is arranged to control the retransmission of a data packet if, at the end of the RTO retransmission delay, the TCP sender has not yet received an acknowledgment for this packet.
  • the TCP transmitter 4 further comprises a module 44 for evaluating the available bandwidth of the transmission channel 5 and a memory 45.
  • the memory 45 connected to the evaluation module 44 and to the transmission module 40, is intended to memorize one or more pairs of values (RTT n , W n max ), each comprising a stable loop delay value and the maximum size of the sliding transmission window observed when the loop delay is stable and equals RTT n .
  • the evaluation module 44 is interposed between the module 42 for calculating the retransmission delay and the transmission module 40. During transmission, the evaluation module 44 observes the state of the loop delay measured and smoothed by the calculation module
  • the evaluation module 44 stores in memory 45 the pair of values ⁇ RTT n , W n max ⁇ containing the stable value of the loop delay RTT n and the maximum size of the sliding transmission window observed when the loop delay is stable and equals RTT n .
  • the evaluation module 44 signals to the transmission module 40 that the transmission data rate is greater than the available bandwidth.
  • the evaluation module 44 signals to the transmission module 40 that the transmission data rate is less than the available bandwidth.
  • the evaluation module 44 detects a state of stability of the loop delay. Case B If, after a period of stability of the loop delay, the evaluation module 44
  • the evaluation module 44 calculates the accumulation of errors by adding all the errors ⁇ j measured from this instant t x and up to instant t ;, and ii) if the evaluation module 44 detects that C,.) S C (S c representing a critical threshold), the loop delay is in a state of progressive increase. The evaluation module 44 then signals to the transmission module 40 that the transmission data rate is greater than the available bandwidth. Case C If, after a stable period of the loop delay, the evaluation module 44
  • the evaluation module 44 calculates the accumulation of errors by adding all the errors e, - measured from this instant t y and until instant tj, and ii) if the evaluation module 44 detects that C i ⁇ -S c , the loop delay is in a state of gradual decrease.
  • the evaluation module 44 then signals to the transmission module 40 that the transmission data rate is less than the available bandwidth. In other cases than cases A, B and C explained above, the loop delay is in an unidentifiable state which may correspond to a period of instability.
  • the server 4 can take various appropriate measures consisting of - reducing or stabilizing the size of the window, in order to avoid congestion, or - to increase the size of the window, in order to increase the data rate through the channel 5 from the server 4 to the client terminal 2.
  • maximum W n , max allows a faster increase in window size to an optimal value taking into account the available bandwidth.
  • the size W n of the transmission window increases and the evaluation module 44 stores it in memory 45. This allows the server 4 to memorize, for each stable value RTT n of the loop delay, the pair of reference values (RTT n , W n , max ) containing the stable value of the loop delay RTT n and the maximum size of the transmission window observed for this RTT n value of the loop delay.
  • the evaluation module 44 thus has the available bandwidth, worth
  • SRTT1 560 ms
  • FIG. 5A we can observe a momentary increase in the loop delay errors ⁇ j, slightly perceptible, shortly after the time t4 of reduction of the bandwidth.
  • FIG. 5B shows perfectly clearly a peak of increase in the cumulation of errors Ci, shortly after the instant t4.
  • the evaluation of the available bandwidth is performed in the server 4 in order to optimize the data rate in the downward direction (from the server 4 to the client terminal 2).
  • the invention applies not only to satellite networks but also to any other type of network, and more particularly to networks with long loop delay
  • GPRS Global System for Mobile communications
  • LFN Long Fat Network

Landscapes

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

Abstract

La transmission utilise une méthode dite de 'fenêtre glissante' selon laquelle l'émetteur (4) est autorisé à envoyer vers le récepteur (2) plusieurs paquets de données, contenus dans la fenêtre, avant de recevoir un accusé de réception pour l'un au moins de ces paquets, et fait avancer la fenêtre, afin d'émettre les paquets suivants, au fur et à mesure qu'il reçoit les accusés de réception. L'émetteur (4) mesure un délai de boucle correspondant à la durée entre l'envoi d'un paquet de données et la réception d'un accusé de réception correspondant, à des instants d'échantillonnage successifs (ti) et observe l'état du délai de boucle (RTT). A chaque fois qu'il détecte un état de stabilité de celui-ci (RTTn), il mémorise le couple de valeurs (RTTn,Wn,max) contenant la valeur stable du délai de boucle (RTTn) et la taille maximale de la fenêtre d'émission observée pour cette valeur stable du délai de boucle (RTTn).

Description

- u - -- -l -- d'une transmission de données et dispositif d'émission pour la mise en œuvre du procédé
L'invention concerne un procédé pour évaluer la bande passante disponible d'un canal de transmission lors d'une transmission de données entre un émetteur et un récepteur à travers ledit canal, ladite transmission utilisant une méthode dite de "fenêtre glissante" et un dispositif d'émission pour la mise en œuvre du procédé. D'emblée, on notera que par les termes "bande passante disponible" on entend désigner la quantité de données pouvant être transmise par unité de temps, c'est-à-dire le débit, à travers le canal de transmission. Lors d'une transmission de paquets de données à travers un réseau, un protocole de contrôle de flux vérifie généralement le bon acheminement des paquets de données entre l'émetteur et le récepteur. Sur l'Internet, le protocole de contrôle de flux le plus largement utilisé est le protocole TCP (Transfer Control Protocol), lequel s'assure de la bonne réception des paquets de données émis par un mécanisme d'accusé de réception. Ce mécanisme fonctionne de la manière suivante: L'émetteur attribue un numéro de séquence à chaque octet d'un paquet de données émis. A la réception de ce paquet, le récepteur retourne à l'émetteur un accusé de réception "ACK" accompagné du numéro de séquence du prochain octet attendu. Afin de limiter le nombre d'accusés de réception, il est connu d'utiliser un mécanisme d'acquittement cumulatif consistant à émettre des accusés de réception "ACK" confirmant chacun la bonne réception de plusieurs paquets de données. Dans ce cas, chaque accusé de réception est accompagné du numéro de séquence du prochain octet attendu et signale à l'émetteur que tous les précédents paquets de données ont bien été reçus. De plus, pour chaque paquet de données émis, l'émetteur déclenche une horloge de temporisation de retransmission mémorisant un délai de retransmission "RTO" (Retransmission Time Out). Si, à l'expiration du délai de retransmission RTO, l'émetteur n'a pas reçu d'accusé de réception pour un paquet préalablement émis, il le transmet une nouvelle fois. Ce délai de retransmission RTO est calculé, à l'aide d'un algorithme, en fonction d'un délai de boucle "RTT" (Round Trip Time), encore appelé délai aller-retour, correspondant à la durée moyenne entre l'émission d'un paquet aller et la réception d'un accusé de réception retour. Si le récepteur reçoit des paquets non successifs, cela est signalé à l'émetteur par l'arrivée d'accusés de réception dupliqués. Parallèlement, un mécanisme de fenêtre glissante est utilisé afin d'autoriser l'émetteur à émettre plusieurs paquets de données avant de recevoir un accusé de réception. En définitive, la taille de la fenêtre fixe un nombre de paquets pouvant être transmis sans avoir besoin d'accusé de réception. Cette fenêtre se déplace au fur et à mesure que les accusés de réception sont reçus. Ainsi, à la réception de chaque accusé de réception, l'émetteur supprime les paquets transmis et acquittés dans sa mémoire tampon d'émission et fait avancer sa fenêtre afin d'émettre les paquets suivants. De plus, la taille de la fenêtre est dynamique. Au départ, elle est fixée à un seul paquets, voire à quelques paquets (généralement quatre au plus), puis elle augmente au for et à mesure que les accusés de réception sont reçus, d'abord de façon exponentielle, jusqu'à un seuil prédéfini appelé "ssthresh" (Slow Start Threshold), puis de façon linéaire. A la réception de chaque accusé de réception, la fenêtre d'émission non seulement avance, de façon à ce que les paquets suivants soient émis, mais augmente également. La taille de la fenêtre croît ainsi jusqu'à une limite supérieure de congestion dont la valeur dépend de la bande passante disponible du canal de transmission. La bande passante disponible, autrement dit le débit de données maximal admissible en émission, dépend essentiellement de la capacité maximale théorique du canal et du trafic de données réel à travers ce canal. Lorsque la fenêtre est trop large (débit trop important compte tenu de la bande passante disponible), il y a congestion, ce qui se traduit par la perte de paquets de données. Deux cas sont alors envisageables: a) l'émetteur reçoit une notification de perte provenant du récepteur ou b) le délai de retransmission RTO expire avant réception d'un accusé de réception. Dans le cas a), selon le protocole TCP, la taille de la fenêtre est divisée par deux, puis demeure stable pendant un courte période avant de recommencer à croître de manière linéaire jusqu'à atteindre à nouveau une limite supérieure de congestion. Dans le cas b), selon le protocole TCP, la taille de la fenêtre est réduite à un seul paquet et le seuil "ssthresh" est fixé à la moitié de la taille de la fenêtre au moment où la congestion a été détectée. La taille de la fenêtre recommence à croître de façon exponentielle jusqu'au seuil "ssthresh" puis de façon linéaire jusqu'à atteindre à nouveau une limite supérieure de congestion. Dans les deux cas a) et b), la détection d'une congestion s'effectue donc a posteriori, par détection de la perte de paquets de données. La taille de la fenêtre est alors brutalement réduite à une valeur conservatrice et il faut un certain laps de temps pour qu'elle redevienne optimale eu égard à la bande passante disponible. Une telle réduction de la taille de la fenêtre induit un temps de reprise important et, par conséquent, réduit considérablement le débit de données moyen en émission. La présente invention vise à pallier ce dernier inconvénient. A cet effet, l'invention concerne un procédé pour évaluer la bande passante disponible d'un canal de transmission lors d'une transmission de données entre un émetteur et un récepteur, à travers ledit canal, la transmission utilisant une méthode dite de "fenêtre glissante" selon laquelle l'émetteur est autorisé à envoyer vers le récepteur plusieurs paquets de données, contenus dans la fenêtre, avant de recevoir un accusé de réception pour l'un au moins de ces paquets, et fait avancer la fenêtre, afin d'émettre les paquets suivants, au fur et à mesure qu'il reçoit les accusés de réception, procédé dans lequel l'émetteur mesure un délai de boucle correspondant à la durée entre l'envoi d'un paquet de données et la réception d'un accusé de réception correspondant, à des instants d'échantillonnage successifs, caractérisé par le fait que l'émetteur observe l'état du délai de boucle et, à chaque fois qu'il détecte un état de stabilité de celui-ci, il mémorise le couple de valeurs (RTTn,Wn,max) contenant la valeur stable du délai de boucle et la taille maximale de la fenêtre d'émission observée pour cette valeur stable du délai de boucle. Grâce à cela, l'émetteur conserve en mémoire des couples de valeurs associées délai de boucle / taille de fenêtre correspondant à des états de stabilité observés pour le canal de transmission considéré. Cet historique de couples délai de boucle / taille de fenêtre permet, après une congestion ou une période d'instabilité à travers le canal de transmission, de revenir à une taille de fenêtre ayant une valeur de référence. Il permet également en cas de réduction de la bande passante disponible de quantifier le surdimensionnement de la fenêtre d'émission par rapport à la nouvelle bande passante. En cas de diminution de la bande passante disponible, on peut déduire le taux de diminution de la bande passante du taux d'augmentation du délai de boucle. A titre d'exemple illustratif, si la bande passante est divisée par deux, on observera un délai de boucle après réduction valant globalement le double du délai de boucle avant réduction, dans l'hypothèse où la taille de la fenêtre avant réduction est égale à la taille de la fenêtre après réduction. Avantageusement, - si, après une période de stabilité du délai de boucle, l'émetteur détecte une augmentation progressive dudit délai, il signale que le débit de données est supérieur à la bande passante disponible, - si, après une période de stabilité du délai de boucle, l'émetteur détecte une diminution progressive dudit délai, il signale que le débit de données est inférieur à la bande passante disponible. Par augmentation, ou diminution, "progressive", on entend désigner une augmentation, ou une diminution, régulière et continue, par opposition à une augmentation, ou une diminution, brusque généralement suivie d'un retour à une valeur normale du délai de boucle. La "bande passante disponible" représente la quantité de données maximale que l'émetteur peut émettre vers le récepteur par unité de temps, c'est-à-dire le débit de données maximal admissible, à travers le canal de transmission. L'invention consiste donc aussi à observer l'évolution du délai de boucle afin d'en déduire la disponibilité de la bande passante du canal de transmission. Avantageusement, - pour chaque instant d'échantillonnage, l'émetteur mesure une erreur de délai de boucle correspondant à l'écart entre les deux derniers échantillons de délai de boucle et calcule un cumul d'erreurs en additionnant les erreurs de délai de boucle sur les N derniers échantillons de délai de boucle, - si l'émetteur détecte que les N dernières erreurs de délai de boucle et le cumul — S S S d'erreurs sont compris entre et — , — représentant un seuil de tolérance, il
enregistre provisoirement le délai de boucle, - si le délai de boucle demeure sensiblement constant pendant une durée supérieure à un seuil prédéterminé, l'émetteur détecte un état de stabilité du délai de boucle. Le cumul des erreurs permet de quantifier l'évolution du délai de boucle, autrement dit de mesurer la quantité d'augmentation ou de diminution du délai de boucle. De préférence, la durée seuil est égale au délai de boucle enregistré. Ainsi, on observe un état de stabilité du délai de boucle sur une période au moins égale au délai de boucle lui-même. Avantageusement, si, après une période de stabilité du délai de boucle,
l'émetteur détecte que Ct)— L pour la première fois à l'instant tx, i) à partir de l'instant tx, pour chaque instant d'échantillonnage ti, l'émetteur calcule le cumul d'erreurs Ci en additionnant toutes les erreurs mesurées à partir de cet instant tx jusqu'à l'instant d'échantillonnage ti, et ii) si l'émetteur détecte que Ci)Sc , Sc représentant un seuil critique, il signale que le débit de données est supérieur à la bande passante disponible. Avantageusement encore, si, après une période de stabilité du délai de boucle,
l'émetteur détecte que Ct ( pour la première fois à l'instant ty, i) à partir de l'instant ty, pour chaque instant d'échantillonnage ti, l'émetteur calcule le cumul d'erreurs Ci en additionnant toutes les erreurs mesurées à partir de cet instant tx jusqu'à l'instant d'échantillonnage ti, et ii) s'il détecte que Ct (~SC , il signale que le débit de données est inférieur à la bande passante disponible. De préférence, lorsque le délai de boucle est stable, la taille de la fenêtre augmentant au fur et à mesure que l'émetteur reçoit des accusés de réception, l'émetteur enregistre la valeur stable du délai de boucle et la taille maximale de la fenêtre observée pour cette valeur stable du délai de boucle. L'émetteur peut ainsi mémoriser un ou plusieurs couple(s) comprenant chacun une valeur stable RTTn de délai de boucle et la valeur maximale de taille de fenêtre Wn)maχ observée lorsque le délai de boucle est stable et vaut RTTn et qu'il n'y a, par conséquent, pas de risque de congestion. L'invention concerne également un dispositif d'émission pour la mise en œuvre du procédé précédemment défini, comprenant - des moyens d'émission à travers un canal de transmission, utilisant une méthode dite de "fenêtre glissante", agencés pour envoyer plusieurs paquets de données, contenus dans la fenêtre, avant de recevoir un accusé de réception pour l'un au moins de ces paquets et pour faire avancer la fenêtre afin d'émettre les paquets suivants, et - des moyens pour mesurer un délai de boucle correspondant à la durée entre l'envoi d'un paquet de données et la réception d'un accusé de réception correspondant, à des instants d'échantillonnage successifs, dispositif caractérisé par le fait qu'il comprend des moyens pour détecter un état de stabilité du délai de boucle et des moyens pour mémoriser, à chaque fois que l'émetteur détecte un état de stabilité du délai de boucle (RTTn), le couple de valeurs
(RTTn,Wn,max) contenant la valeur stable du délai de boucle (RTTn) et la taille maximale de la fenêtre d'émission observée pour cette valeur stable du délai de boucle. L'invention sera mieux comprise à l'aide de la description suivante d'un mode de réalisation particulier du procédé pour évaluer la bande passante disponible d'un canal de transmission et du dispositif pour la mise en œuvre de ce procédé, selon l'invention, en référence aux dessins annexés sur lesquels: - la figure 1 représente une vue schématique d'un réseau de communication, d'un fournisseur d'accès au réseau, avec un serveur accélérateur de débit, un terminal de communication et un canal de transmission entre le serveur et le terminal; - la figure 2 représente un schéma bloc fonctionnel du serveur accélérateur de débit de la figure 1 ; - la figure 3 représente une succession de paquets de données transmis ou à transmettre par le serveur accélérateur de débit de la figure 1 et une fenêtre d'émission de ces paquets; - les figures 4A et 4B représentent respectivement le délai de boucle et le débit de données mesurés lors d'une transmission à travers le canal de transmission de la figure 1; - les figures 5A et 5B représentent respectivement les erreurs de délai de boucle et le cumul de ces erreurs, calculés à partir des échantillons de délai de boucle mesurés (figure 4A); - la figure 6A et 6B représentent l'évolution du délai de boucle mesuré (figure 4A) respectivement en début de transmission et à un instant auquel la bande passante est réduite. Sur la figure 1, on a représenté un réseau de communication 1, en l'espèce l'Internet, et un terminal de communication client 2 connecté à l'Internet 1 par l'intermédiaire d'un fournisseur d'accès ISP (Internet Service Provider) 3. Le fournisseur d'accès 3 intègre un serveur accélérateur de débit 4, encore appelé serveur "proxy". La référence 5 désigne le canal de transmission entre le terminal de communication 2 et le serveur accélérateur de débit 4. Dans l'exemple particulier de la description, le canal de transmission 5 est une liaison TCP (Transfer Control Protocol) par voie satellite. Le protocole TCP de contrôle de flux, utilisé sur le canal de transmission 5, permet de contrôler le bon acheminement de paquets de données entre le serveur 4 et le terminal client 2, à l'aide d'un mécanisme d'accusé de réception cumulatif fonctionnant de la manière suivante: L'émetteur TCP attribue un numéro de séquence à chaque octet d'un paquet de données émis. Après avoir reçu plusieurs paquets transmis par l'émetteur TCP, le récepteur TCP renvoie à l'émetteur TCP un accusé de réception "ACK" accompagné du numéro de séquence du prochain octet attendu et confirmant ainsi la bonne réception de tous les paquets précédant cet octet. De plus, si, à l'expiration d'un délai de retransmission "RTO" (Retransmission Time Out) prédéterminé, l'émetteur TCP n'a pas reçu d'accusé de réception pour un paquet préalablement émis, il le transmet une nouvelle fois vers le récepteur TCP. Ce délai de retransmission RTO est calculé par l'émetteur TCP, à l'aide d'un algorithme, en fonction d'un délai de boucle "RTT" (Round Trip Time) correspondant à la durée moyenne entre l'émission d'un paquet aller et la réception d'un accusé de réception retour. L'émetteur TCP utilise également un mécanisme de "fenêtre d'émission glissante" l'autorisant à émettre plusieurs paquets de données, contenus dans la fenêtre, avant de recevoir un accusé de réception. Par sa taille, la fenêtre d'émission fixe un nombre de paquets pouvant être transmis sans avoir besoin d'accusé de réception (voir figure 3). Cette fenêtre se déplace et augmente au for et à mesure que l'émetteur TCP reçoit les accusés de réception. Ainsi, à la réception de chaque accusé de réception, l'émetteur TCP fait avancer sa fenêtre d'émission afin d'émettre les paquets suivants et augmente la taille de la fenêtre. Au départ, la fenêtre d'émission contient un paquet, voire quelques paquets (généralement pas plus de quatre), et augmente d'abord de façon exponentielle jusqu'à un seuil prédéfini appelé "ssthresh" (Slow Start Threshold), puis de façon linéaire jusqu'à une limite optimale au-delà de laquelle il y a congestion, ce qui se traduit par la perte de paquets de données. Sur la figure 3, on a représenté une succession 6 de paquets de données numérotés de 11 à 24 et une fenêtre glissante d'émission 7 à un instant donné. Sur cette figure 3, on peut classer les paquets de données de la manière suivante: - paquets envoyés et acquittés 61: n°ll à 13 - paquets envoyés et non acquittés 62: n°14 à 16 - paquets devant être envoyés 63 : n°17 à 21 - paquets non autorisés à être envoyés 64: n°22 à 24 Le dernier acquittement reçu "ACK" 60, de valeur 14, a confirmé la réception de tous les paquets de données précédant le paquet n°14. Le bord gauche de la fenêtre 7 est donc positionné juste avant le paquet n°14. L'émetteur TCP n'est autorisé à envoyer que les paquets contenus dans la fenêtre d'émission (numérotés de 14 à 21) sans recevoir d'accusé de réception. Sur la figure 3, on voit que le prochain paquet que l'émetteur TCP va émettre est le n°17. Pour être autorisé à émettre les paquets suivants, non contenus dans la fenêtre 7 telle que représentée sur la figure 3 (c'est-à-dire les paquets n°22 et suivants), l'émetteur TCP doit recevoir un nouvel accusé de réception ACK de valeur strictement supérieure à 14 et faire glisser sa fenêtre 7 vers la droite (dans le sens de la flèche 8), de manière à positionner le bord gauche de la fenêtre 7 juste avant le paquet dont le numéro correspond à la valeur de l'accusé de réception reçu. Par exemple, si le prochain accusé de réception a la valeur 16, le bord gauche de la fenêtre 7 est déplacé dans le sens de la flèche 8 de manière à être positionné juste avant le paquet n°16. En outre, en même temps qu'il déplace la fenêtre 7, l'émetteur
TCP augmente la taille de la fenêtre 7. Par exemple, si la phase dans laquelle il se trouve permet à l'émetteur TCP d'augmenter la taille de la fenêtre 7 d'un paquet à la réception de chaque accusé de réception, la nouvelle fenêtre 7 contient alors neuf paquets. L'émetteur TCP représenté sur la figure 2 est le serveur accélérateur de débit
4. Il comprend, de façon connue, un module 40 d'émission de paquets de données, un module 41 de réception d'accusés de réception, un module 42 de calcul du délai de retransmission RTO et une horloge 43 de temporisation de retransmission. Le module d'émission 40 est agencé pour émettre des paquets de données en utilisant la méthode de la "fenêtre glissante d'émission" précédemment explicitée (voir figure 3). Il est donc autorisé à envoyer plusieurs paquets de données, contenus dans la fenêtre d'émission, avant de recevoir un accusé de réception. Au for et à mesure de la réception des accusés de réception, signalés par le module de réception 41, le module d'émission 40, d'une part, fait avancer la fenêtre glissante d'émission et, d'autre part, calcule et met à jour la taille de cette fenêtre. On rappelle ici que, selon le protocole
TCP, la taille de la fenêtre, fixée au départ à un paquet, voire à quelques paquets
(quatre au plus), augmente, dans un premier temps, de façon exponentielle jusqu'à un seuil "ssthresh" (Slow Start Threshold), puis, dans un second temps, de façon linéaire. Le module 41 de réception d'accusés de réception, interposé entre le module de calcul 42 et le module d'émission 40, est agencé pour recevoir et traiter les accusés de réception "ACK" et pour transmettre aux autres modules des informations utiles, fournies par les accusés de réception, pour mettre à jour des variables d'état d'émission telles que notamment le délai de retransmission RTO, le délai de boucle RTT, la taille W de la fenêtre glissante d'émission et le seuil "ssthresh". Le module 42 de calcul du délai de retransmission RTO est agencé pour calculer le délai de retransmission RTO à l'aide d'un algorithme prévu par le protocole TCP, à partir du délai de boucle. On rappelle ici que le délai de boucle correspond à la durée moyenne entre l'envoi d'un paquet de données aller et la réception d'un accusé de réception retour. En fonctionnement, le module de calcul 42 mesure le délai de boucle
RTT à des instants d'échantillonnage tj successifs, lisse les échantillons de délai de boucle mesurés RTTj de telle sorte que:
SRTT; = (1 - ).SRTTt + a.RTTt avec a = - , 8 où SRRTj représente la valeur lissée de l'échantillon RTTj du délai de boucle (Smoothed Round Trip Time) mesuré à l'instant tj. Il calcule ensuite le délai de retransmission RTO à partir du délai de boucle mesuré et lissé, à l'aide de l'algorithme du protocole TCP. Pour plus de renseignements à ce sujet, le lecteur est invité à se reporter notamment au document RFC2988 de ITETF (Internet Engineering Task Force). Le délai de retransmission RTO ainsi calculé est fourni à l'horloge 43. L'horloge 43 de temporisation de retransmission, reliée au module de calcul du délai de retransmission RTO et au module d'émission 40, est agencée pour commander la retransmission d'un paquet de données si, à l'expiration du délai de retransmission RTO, l'émetteur TCP n'a pas encore reçu d'accusé de réception pour ce paquet. L'émetteur TCP 4 comprend en outre un module 44 d'évaluation de la bande passante disponible du canal de transmission 5 et une mémoire 45. La mémoire 45, reliée au module d'évaluation 44 et au module d'émission 40, est destinée à mémoriser un ou plusieurs couples de valeurs (RTTn, Wn max), comprenant chacun une valeur stable de délai de boucle et la taille maximale de la fenêtre glissante d'émission observée lorsque le délai de boucle est stable et vaut RTTn. Le module d'évaluation 44 est interposé entre le module 42 de calcul du délai de retransmission et le module d'émission 40. En cours d'émission, le module d'évaluation 44 observe l'état du délai de boucle mesuré et lissé par le module de calcul
42 afin de détecter i) soit un état de stabilité du délai de boucle, ii) soit une augmentation progressive du délai de boucle, apparaissant à la suite d'une période de stabilité dudit délai, iii) soit une diminution progressive du délai de boucle, apparaissant à la suite d'une période de stabilité dudit délai. On rappelle ici que par les termes augmentation/diminution "progressive", on entend désigner une augmentation diminution régulière et continue, par opposition à une augmentation/diminution brusque. Dans le cas i), pour chaque valeur stable RTTn du délai de boucle, le module d'évaluation 44 enregistre dans la mémoire 45 le couple de valeurs {RTTn, Wn max} contenant la valeur stable du délai de boucle RTTn et la taille maximale de la fenêtre glissante d'émission observée lorsque le délai de boucle est stable et vaut RTTn. Dans le cas ii), le module d'évaluation 44 signale au module d'émission 40 que le débit de données en émission est supérieur à la bande passante disponible. Dans le cas iii), le module d'évaluation 44 signale au module d'émission 40 que le débit de données en émission est inférieur à la bande passante disponible. La méthode de détection de l'état du délai de boucle (stabilité, augmentation progressive ou diminution progressive) par le module d'évaluation 44 est décrite ci- après dans la description du procédé. Le procédé qui va maintenant être décrit permet d'évaluer la bande passante disponible du canal de transmission 5 entre le serveur accélérateur de débit 4 et le terminal 2, lors d'une transmission de données du serveur 4 vers le terminal 2. Lors d'une transmission de données du serveur 4, émetteur TCP, vers le terminal 2, récepteur TCP, le module de calcul 42 du serveur 4 mesure et lisse le délai de boucle à des instants d'échantillonnage successifs tj. On rappelle ici que "SRTTj"
(Smoothed Round Trip Time) représente la valeur de l'échantillon d'indice i du délai de boucle mesuré à l'instant t; et lissé. A partir des échantillons de délai de boucle mesurés et lissés SRTTj, fournis par le module de calcul 42, pour chaque instant d'échantillonnage t;, le module d'évaluation 44 calcule - une erreur de délai de boucle e égale à l'écart entre les deux derniers échantillons de délai de boucle mesurés et lissés SRTTj et SRTTi-l5 autrement dit: et = SRTT; - SRTT^ et - un cumul d'erreurs C; en additionnant les erreurs de délai de boucle sur les N derniers échantillons de délai de boucle mesurés et lissés, autrement dit:
C, = ±.j . j=i-N+l Cas A Si le module d'évaluation 44 détecte que les N dernières erreurs de délai de — S S boucle βj V/' e [ι - N + l,z] et le cumul d'erreurs ( ) sont compris entre et — '- , g — - représentant un seuil de tolérance, autrement dit que
^) ~ fi,{^ j i - N+ ,i], alors il enregistre provisoirement le délai de boucle. La valeur enregistrée du délai de boucle est ici égale à la moyenne des N derniers échantillons de délai de boucle. On pourrait envisager de déterminer le délai de boucle par une autre méthode consistant par exemple à retenir la valeur du dernier échantillon mesuré et lissé SRTTj et à ne la remplacer par une autre valeur d'échantillon SRTTj que si la différence entre les deux échantillons SRTTj et SRTTj est supérieure à un seuil de tolérance prédéfini. Si le délai de boucle demeure sensiblement constant pendant une durée au moins égale à une durée seuil, ici égale au délai de boucle lui-même, le module d'évaluation 44 détecte un état de stabilité du délai de boucle. Cas B Si, après une période de stabilité du délai de boucle, le module d'évaluation 44
détecte que Ci)—L pour la première fois à l'instant tx, i) à partir de l'instant tx, pour chaque instant d'échantillonnage tj, le module d'évaluation 44 calcule le cumul d'erreurs en additionnant toutes les erreurs βj mesurées à partir de cet instant tx et jusqu'à l'instant t;, et ii) si le module d'évaluation 44 détecte que C,.)SC (Sc représentant un seuil critique), le délai de boucle est dans un état d'augmentation progressive. Le module d'évaluation 44 signale alors au module d'émission 40 que le débit de données en émission est supérieur à la bande passante disponible. Cas C Si, après une période de stabilité du délai de boucle, le module d'évaluation 44
détecte que Ci { pour la première fois à l'instant ty, i) à partir de l'instant ty, pour chaque instant d'échantillonnage tj, le module d'évaluation 44 calcule le cumul d'erreurs en additionnant toutes les erreurs e,- mesurées à partir de cet instant ty et jusqu'à l'instant tj, et ii) si le module d'évaluation 44 détecte que Ci {-Sc , le délai de boucle est dans un état de diminution progressive. Le module d'évaluation 44 signale alors au module d'émission 40 que le débit de données en émission est inférieur à la bande passante disponible. Dans les autres cas que les cas A, B et C explicités ci-dessus, le délai de boucle est dans un état non identifiable pouvant correspondre à une période d'instabilité. Dans les cas B et C, selon que le débit de données en émission est supérieur ou inférieur à la bande passante disponible, le serveur 4 peut prendre diverses mesures appropriées consistant - à diminuer ou à stabiliser la taille de la fenêtre, afin d'éviter une congestion, ou - à augmenter la taille de la fenêtre, afin d'augmenter le débit de données à travers le canal 5 du serveur 4 vers le terminal client 2. Dans le cas où l'émetteur TCP 4 a préalablement observé et mémorisé un délai de boucle stable, de valeur RTTn, et une valeur maximale Wn max pour la taille de la fenêtre d'émission, il peut décider de modifier la valeur du seuil "ssthresh" afin que ssthresh = aWn mΑ avec α proche de la valeur 1 mais strictement inférieur à 1. A titre 7 3 d'exemple, on peut prendre a = — ou a = — . Une seuil "ssthresh" proche de la valeur
maximale Wn,max permet une augmentation plus rapide de la taille de la fenêtre jusqu'à une valeur optimale compte tenu de la bande passante disponible. Lorsque le délai de boucle est stable et vaut RTTn, au fur et à mesure de la réception des accusés de réception, la taille Wn de la fenêtre d'émission augmente et le module d'évaluation 44 la mémorise dans la mémoire 45. Cela permet au serveur 4 de mémoriser, pour chaque valeur stable RTTn du délai de boucle, le couple de valeurs de référence (RTTn,Wn,max) contenant la valeur stable du délai de boucle RTTn et la taille maximale de la fenêtre d'émission observée pour cette valeur RTTn du délai de boucle.
Le module d'évaluation 44 dispose ainsi de la bande passante disponible, valant
W "'""* , pour cette valeur RTTn du délai de boucle. Si, après une période de stabilité RTTn durant laquelle le délai de boucle vaut RTTn, le délai de boucle passe dans un état d'augmentation progressive, alors que la taille de la fenêtre continue parallèlement à augmenter comme cela est prévu par le protocole TCP, l'émetteur pourra limiter la taille de la fenêtre à la valeur Wn,maχ, et par conséquent le débit de données, afin d'éviter une congestion. En outre, si le délai de boucle varie de manière aléatoire en raison de perturbations (et non en raison du fait que le débit de données s'approche de la bande passante disponible du canal de transmission 5), ce couple (RTTn,Wn.max) constitue un point de référence pour la reprise de la transmission. Tous les couples de valeurs délai de boucle / taille de fenêtre pour lesquels un état de stabilité de la transmission est observée sont mémorisés. On conserve ainsi un historique de couples délai de boucle / taille de fenêtre de référence. A titre d'exemple illustratif, on va maintenant décrire le processus d'évaluation de la charge du canal de transmission 5 lors d'une transmission de données par liaison satellite du serveur 4 vers le terminal 2, au cours de laquelle la bande passante disponible sur le canal de transmission 5 est brutalement réduite. Pour cette évaluation, on prend: - N = 5, - St = 100 ms et - Sc = 200 ms. Les figures 4A et 4B représentent respectivement le délai de boucle lissé (en ms) et le débit de données (en kbits/s) à travers le canal de transmission 5, mesurés entre les instants t2 = 70 s et t3 = 85 s. Les figures 5A et 5B représentent respectivement les erreurs de délai de boucle βj (en ms) et le cumul d'erreurs Ci (en ms), entre les instants t2 = 70s et t3 = 85s, calculés à partir des échantillons du délai de boucle représentés sur la figure 4A. Les figures 6A et 6B représentent respectivement l'évolution du délai de boucle en début de transmission, entre l'instant tO = 38s (début de la transmission) et tl = 55s, et au moment d'une réduction de la bande passante disponible, entre les instants t2 et t3. Sur la figure 6A, on peut observer que le délai de boucle est instable en début de transmission puis se stabilise à la valeur SRTT1=560 ms. Cet état de stabilité est détecté par le processus d'évaluation à l'instant t5 = 46 s. Comme on peut le voir sur la figure 4B, le débit de données à travers le canal de transmission 5 vaut initialement 1000 kbits/s puis est brutalement réduit à 500 kbits/s, à l'instant t4 = 76,6s, en raison d'une réduction de la bande passante disponible.
Sur la figure 6B, on peut observer que le délai de boucle, qui vaut initialement SRTT1=560 ms, augmente progressivement à compter de l'instant t4 de réduction brutale du débit, jusqu'à une valeur SRTT2=1130 ms. Sur la figure 5A, on peut observer une augmentation momentanée des erreurs de délai de boucle βj, faiblement perceptible, peu après l'instant t4 de réduction de la bande passante. En revanche, la figure 5B fait apparaître de façon parfaitement distincte une pic d'augmentation du cumul d'erreurs Ci, peu après l'instant t4. Un tel pic d'augmentation signale une augmentation progressive du délai de boucle. Grâce au processus d'évaluation préalablement décrit, l'augmentation progressive du délai de boucle corrélative à la réduction de la bande passante disponible, est détectée à l'instant t6=77s. Dans la description qui précède, l'évaluation de la bande passante disponible est réalisée dans le serveur 4 afin d'optimiser le débit de données dans le sens descendant (du serveur 4 vers le tenninal client 2). On pourrait envisager d'évaluer la bande passante disponible dans le terminal client 2, afin d'optimiser le débit de données dans le sens montant (du terminal client 2 vers le serveur 4), ou encore, dans le cas d'une transmission de données entre deux terminaux, dans chaque terminal émetteur. L'invention s'applique non seulement aux réseaux satellites mais également à tout autre type de réseau, et plus particulièrement aux réseaux à long délai de boucle
(de plusieurs centaines de millisecondes), par exemple les réseaux GPRS ou plus particulièrement les réseaux LFN (Long Fat Network).

Claims

Revendications
1. Procédé pour évaluer la bande passante disponible d'un canal de transmission (5) lors d'une transmission de données entre un émetteur (4) et un récepteur (2), à travers ledit canal (5), la transmission utilisant une méthode dite de
"fenêtre glissante" selon laquelle l'émetteur (4) est autorisé à envoyer vers le récepteur (2) plusieurs paquets de données, contenus dans la fenêtre (7), avant de recevoir un accusé de réception pour l'un au moins de ces paquets, et fait avancer la fenêtre (7), afin d'émettre les paquets suivants, au for et à mesure qu'il reçoit les accusés de réception, procédé dans lequel l'émetteur (4) mesure un délai de boucle correspondant à la durée entre l'envoi d'un paquet de données et la réception d'un accusé de réception correspondant, à des instants d'échantillonnage successifs (tj), caractérisé par le fait que l'émetteur observe l'état du délai de boucle (RTT) et, à chaque fois qu'il détecte un état de stabilité de celui-ci (RTTn), il mémorise le couple de valeurs (RTTn,Wn,max) contenant la valeur stable du délai de boucle (RTTn) et la taille maximale de la fenêtre d'émission observée pour cette valeur stable du délai de boucle (RTTn).
2. Procédé selon la revendication 1, dans lequel - si, après une période de stabilité du délai de boucle, l'émetteur (4) détecte une augmentation progressive dudit délai, il signale que le débit de données est supérieur à la bande passante disponible, - si, après une période de stabilité du délai de boucle, l'émetteur (4) détecte une diminution progressive dudit délai, il signale que le débit de données est inférieur à la bande passante disponible.
3. Procédé selon la revendication 2, dans lequel - pour chaque instant d'échantillonnage (tj), l'émetteur (4) mesure une erreur de délai de boucle (e;) correspondant à l'écart entre les deux derniers échantillons de délai de boucle (SRTTj et SRTTj- et calcule un cumul d'erreurs (C;) en additionnant les erreurs de délai de boucle sur les N derniers échantillons de délai de boucle, - si l'émetteur (4) détecte que les N dernières erreurs de délai de boucle (ej
V; e [z' - N + lJ]) et le cumul d'erreurs (Ci) sont compris entre et — '- , — - À, À, représentant un seuil de tolérance, il enregistre provisoirement le délai de boucle, - si le délai de boucle demeure sensiblement constant pendant une durée supérieure à un seuil prédéterminé, l'émetteur (4) détecte un état de stabilité du délai de boucle.
4. Procédé selon la revendication 3, dans lequel la durée seuil est égale au délai de boucle enregistré.
5. Procédé selon l'une des revendications 3 et 4, dans lequel si, après une
période de stabilité du délai de boucle, l'émetteur (4) détecte que C,>— pour la
première fois à l'instant tx, i) à partir de l'instant tx, pour chaque instant d'échantillonnage ti, l'émetteur (4) calcule le cumul d'erreurs C; en additionnant toutes les erreurs ej mesurées à partir de cet instant tx jusqu'à l'instant d'échantillonnage tj, et ii) si l'émetteur (4) détecte que C,)SC , Sc représentant un seuil critique, il signale que le débit de données est supérieur à la bande passante disponible.
6. Procédé selon l'une des revendications 3 à 5, dans lequel si, après une — S période de stabilité du délai de boucle, l'émetteur (4) détecte que C,( '- pour la
première fois à l'instant ty, i) à partir de l'instant ty, pour chaque instant d'échantillonnage tj, l'émetteur (4) calcule le cumul d'erreurs Ci en additionnant toutes les erreurs ej mesurées à partir de cet instant tx jusqu'à l'instant d'échantillonnage t;, et ii) s'il détecte que C,(-Sc, il signale que le débit de données est inférieur à la bande passante disponible.
7. Dispositif d'émission pour la mise en œuvre du procédé de la revendication 1, comprenant - des moyens (40) d'émission à travers un canal de transmission, utilisant une méthode dite de "fenêtre glissante", agencés pour envoyer plusieurs paquets de données, contenus dans la fenêtre, avant de recevoir un accusé de réception pour l'un au moins de ces paquets et pour faire avancer la fenêtre afin d'émettre les paquets suivants, et - des moyens (42) pour mesurer un délai de boucle correspondant à la durée entre l'envoi d'un paquet de données et la réception d'un accusé de réception correspondant, à des instants d'échantillonnage successifs, dispositif caractérisé par le fait qu'il comprend des moyens (44) pour détecter un état de stabilité du délai de boucle et des moyens (45) pour mémoriser, à chaque fois que l'émetteur détecte un état de stabilité du délai de boucle (RTTn), le couple de valeurs (RTTn,Wn,max) contenant la valeur stable du délai de boucle (RTTn) et la taille maximale de la fenêtre d'émission observée pour cette valeur stable du délai de boucle.
EP04767689A 2003-07-21 2004-07-15 Procede pour evaluer la bande passante disponible d'un canal de transmission lors d'une transmission de donnees et dispositif d'emission pour la mise en oeuvre du procede Withdrawn EP1649666A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0350358A FR2858144A1 (fr) 2003-07-21 2003-07-21 Procede pour evaluer la bande passante disponible d'un canal de transmission lors d'une transmission de donnees entre un emetteur et un recepteur a travers ledit canal et dispositif d'emission pour la mise en oeuvre du procede
PCT/FR2004/001865 WO2005011229A2 (fr) 2003-07-21 2004-07-15 Procédé pour évaluer la bande passante disponible d'un canal de transmission lors d'une transmission de données et dispositif d'émission pour la mise en couvre du procédé

Publications (1)

Publication Number Publication Date
EP1649666A2 true EP1649666A2 (fr) 2006-04-26

Family

ID=33561187

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04767689A Withdrawn EP1649666A2 (fr) 2003-07-21 2004-07-15 Procede pour evaluer la bande passante disponible d'un canal de transmission lors d'une transmission de donnees et dispositif d'emission pour la mise en oeuvre du procede

Country Status (3)

Country Link
EP (1) EP1649666A2 (fr)
FR (1) FR2858144A1 (fr)
WO (1) WO2005011229A2 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101163238B (zh) * 2007-07-20 2010-12-01 中兴通讯股份有限公司 一种平滑实现实时转播/直播的流媒体服务方法
CN112068997B (zh) * 2020-09-09 2023-12-19 恒生电子股份有限公司 数据备份方法、装置、设备及存储介质
CN115250288B (zh) * 2022-07-18 2024-07-09 国仪量子技术(合肥)股份有限公司 数据通信方法、下位机、上位机、数据传输系统和介质

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5193151A (en) * 1989-08-30 1993-03-09 Digital Equipment Corporation Delay-based congestion avoidance in computer networks
CA2249152C (fr) * 1998-09-30 2003-07-08 Northern Telecom Limited Appareil et methode de gestion de largeur de bande pour connexion par paquets

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005011229A2 *

Also Published As

Publication number Publication date
WO2005011229A3 (fr) 2005-05-19
FR2858144A1 (fr) 2005-01-28
WO2005011229A2 (fr) 2005-02-03

Similar Documents

Publication Publication Date Title
Wang et al. Adaptive bandwidth share estimation in TCP Westwood
EP1376945B1 (fr) Mesure du temps aller-retour en TCP par un récepteur
US6445681B1 (en) Method for measuring delay parameters in a network
KR100789034B1 (ko) 검출 방법 및 장치
US7782758B2 (en) Efficient loss recovery architecture for loss-decoupled TCP
US7564792B2 (en) Transparent optimization for transmission control protocol flow control
WO2003030469A2 (fr) Procede pour ameliorer les performances d'un protocole de transmission utilisant un temporisateur de retransmission
US7444578B2 (en) Data unit sender and method of controlling the same
EP1217778A1 (fr) Procédé et dispositif de communication de données avec demande de répétition automatique
KR20040015009A (ko) Ｎａｃｋ-기반 프로토콜에서 적체의 제어를 신뢰할만하고효과적으로 지원하기 위한 방법
EP3319281A1 (fr) Procédé et appareil de régulation de l'encombrement de réseau sur la base des gradients de vitesse de transmission
WO1998025355A1 (fr) Procede de detection rapide de debit d'informations dans un environnement de communication par paquets sans surveillance de debit d'information
JP2008182410A (ja) 通信端末、輻輳制御方法および輻輳制御プログラム
US20030198250A1 (en) Method, apparatus and system for transmitting compressed header data
WO2005011229A2 (fr) Procédé pour évaluer la bande passante disponible d'un canal de transmission lors d'une transmission de données et dispositif d'émission pour la mise en couvre du procédé
EP1330071A2 (fr) Système de gestion de réseau ou de services pour la détermination de la synchronisation entre deux flots de paquets
Gupta et al. WebTP: A receiver-driven web transport protocol
EP1161023A1 (fr) Procédé et système de transmission de données bi-mode, émetteur et récepteur correspondants
EP1668869B1 (fr) Procede pour adapter un seuil d'evitement de congestion en fonction de la charge du reseau et dispositif d'emission associe
CN115665058B (zh) 一种数据发送速度控制方法、装置、设备及介质
EP1745603B8 (fr) Procede et dispositif d'emission de paquets de donnees
EP1411689A1 (fr) Procédé de contrôle de retransmission de données et unité de contrôle pour mettre en oeuvre le procédé
Hossain Behind The TCP-newCWV Implementation To Improve Bursty Application Performance
GB2588930A (en) Multimedia system & method
CN116708247B (zh) 路由器测速方法和路由器

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060207

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: LAMANI, AMINE

Inventor name: PENHOAT, JOEL

RIN1 Information on inventor provided before grant (corrected)

Inventor name: LAMANI, AMINE

Inventor name: PENHOAT, JOEL

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20160202

R18D Application deemed to be withdrawn (corrected)

Effective date: 20160202