Gestion de congestion

INTRODUCTION RESEAUX HAUT DEBIT PARTIE 1 Master Réseaux et Systèmes

A.Boulouz Département de mathématiques et informatique Faculté des sciences d’Agadir 03/01/2011

1

2

03/01/2011

Pourquoi donc le haut débit ?

Une des finalités de la gestion du haut débit est de proposer un service de transport de données numériques entre deux utilisateurs finaux distants mettant en œuvre des paramètres de qualité de service adaptés aux besoins et aux disponibilités du fournisseur.

03/01/2011

3

03/01/2011

4

Ces nouvelles exigences concernent : •la fourniture d’une bande passante importante, à un instant donné, adapté à la nature sporadiques des flux ; •disposer d’une garantie du délai d’acheminement des PDU ; •un contrôle sur le taux d’erreur.

Tous ces besoins entrent dans le cadre de la définition de paramètres dite qualité de service QoS.

Différence entre applications( informatiques et télécoms)

Ces derniers concernent trois domaines : •Les contraintes temporelles existantes entre la source et la destination.

Cette contrainte concerne, par exemple, les applications téléphoniques où le temps réel exige un transport de données isochrone.

•Les contraintes de débit demandées et offertes : dans quelles conditions contractuelles, quelle plage horaire et dans quelles conditions les PDU vont être transportés ?

•Les contraintes d’acheminement d’un PDU entre l’émetteur et le destinataire qui vont préciser la façon dont le service de « bout en bout » sera fourni par l’opérateur.

03/01/2011

5

03/01/2011

6

La fourniture d’une bande passante n’est pas de nature suffisante pour répondre aux besoins de la transmission des clients. Leurs exigences sont autres :

Les besoins en bande passante, nécessaire aux échanges d’informations (par définition variables), génèrent des flux dits « sporadiques » qui sont de nature à être structurants pour l’opérateur. La mise en place d’application de type JAVA qui consiste à charger, sur un poste-client à code exécutable, la transmission de données multimédias – est de nature à modifier ces flux.

Une bande passante variable adaptés, à un moment donné aux besoins.

Une garantie de temps de réponse.

Un support d’applications temps réels.

Toutes ces contraintes supposent que les opérateurs ( ISP ) soient en mesure de fournir un service adapté à des typologies de trafic. C’est ce que l’on appelle la gestion de la qualité de service ou QoS

La messagerie n’a pas de contrainte de temps.

Le trafic transactionnel suppose une garantie de temps de réponse minimum.

Le transfert de la voix suppose une garantie du temps d’acheminement.

03/01/2011

7

03/01/2011

8

Un protocole atteint ses limites en débit quand le temps de traitement dans les nœuds devient prépondérant sur le lien

L'interconnexion de réseaux locaux distants doit pouvoir offrir aux usagers de la bande passante « à la demande »

2eme approche : un autre protocole qui prenne en compte les spécifications d’un trafic multiservices

1er approche : Simplifier un Protocole déjà existant

Frame Relay ( suite X25) préfigure déjà un certain nombre de choix technologique à mettre dans les réseaux haut débit comme le report d'un maximum de fonctionnalités du réseau vers les équipements usagers (voir partie 2) DQDB est une tentative pour offrir une interconnexion flexible multiservice.( voir partie2) ATM reprend un certain nombre de concept comme la petite taille des paquets ( voir partie 2)

ATM Asynchronous Transfer Mode

Frame Relay Simplification de X25

03/01/2011

9

03/01/2011

10

ATM •

•

•

Asynchronous Transfer Mode. TTA en français (technologie temporelle asynchrone). Technologie de réseau à haut débit (centaines de Mbit/s, jusqu'à 2.5 Gbit/s) très sérieusement normalisée et présentée comme une solution d'avenir. Les données sont transmises sous forme de paquets de taille fixe (53 octets de long), appelés cellule.

Originellement conçu pour la voix et les WANs, l'ATM est en train de passer aux LANs. Cette technologie semble prendre l'ascendant en ce moment sur ses concurrentes. Le principal problème étant la rapidité de commutation, qui doit être élevée vue la taille des cellules.

Distributed Queue Dual Bus DQDB. Standard de réseau sur fibre optique, compatible avec ATM, fonctionnant avec un bus double et permettant des débits allant jusqu'à 140 Mbps.

03/01/2011

11

Tout ces paramètres conduisent à définir des classes de services qui répondront aux besoins suivants :

Bande passante

Qualité de service

Transmission de la voix

64 Kb/s par canal

Flux isochrones

Transaction

Faible

Intégrité des données

Visio conférence

Minimum 384 K

Flux isochrones

Transfert de fichiers

Variable

Intégrité des données

Certains flux – comme la transmission de données – exigent une bande passante importante mais variable. D’autres – comme les flux multimédias – sont plus tolérants sur l’intégrité des données mais exigent une transmission isochrone. C’est la complémentarité de ces exigences qui permet d’envisager un partage des supports.

03/01/2011

12

DÉFINITION D’UNE ARCHITECTURE

DÉFINITION DU MODÈLE

La mise en place d’un service de communication, quel que soit l’environnement, s’inscrit dans le cadre d’un processus logique précis qui, à plusieurs échelons, met en lumière les concepts d’architecture.

On définira une architecture comme l’art d’organiser des services.

Une architecture se présente sous la forme d’un plan qui représente la façon dont les services sont fournis, la façon dont les données s’échangent. Il existe plusieurs visions d’une même organisation du système d’information, examinés de plusieurs points de vue différents.

Il est cependant d’usage de mettre en lumière trois composants de base qui sont :

Un modèle décrit la façon dont sont organisées les différentes fonctions de l’architecture, ainsi que la manière dont les composants des fonctions communiquent entre-eux.

Sur le plan matériel, les composants du modèle sont articulés dans des équipements que l’on désignera, dans le cadre de leur implémentation, sous la forme d’une structure nodale.

En matière de communication, les modèles se présentent en couches fonctionnelles adjacentes, et chaque couche dispose d’un moyen pour identifier l’émetteur ou le récepteur

Le modèle, les services et les protocoles 03/01/2011

13

03/01/2011

TYPOLOGIES DU MODÈLE

14

MODÈLE EN COUCHE

Sur le plan théorique il existe deux familles de modèles qui ne sont pas exclusives l’une de l’autre :

Ce modèle consiste à structurer les services en couches fonctionnelles. Les éléments de services qui les composent sont regroupés en fonction des domaines relatifs au déroulement des processus de communication, lesquels constituent une hiérarchie de services.

Les modèles dits « hiérarchisés », qui consistent à concentrer les fonctions dans des nœuds dépendants les uns des autres.

Ainsi, pour accéder à un nœud, il n’existe qu’une route possible pour aller d’un nœud à l’autre.

La communication d’une couche à l’autre s’effectue par des interfaces qui décrivent les opérations nécessaires à la transmission des PDU (voir cours SMI5-FSA), d’une couche n vers une couche n+ ou -1.

Les modèles dits « distribués » qui communiquent entre eux selon une structure maillée.

C’est l’organisation de ces couches qui constitue le fondement de l’architecture.

Ces modèles sont applicables à l’organisation de l’entreprise, les systèmes d’information et composants techniques.

Voir aussi le TD 2

03/01/2011

15

03/01/2011

16

PARTIE 1

Les interfaces qui décrivent la façon dont les PDU vont échanger les données sont de deux natures : a) Des interfaces logiques qui sont décrits – par exemple – par des API (Application Program Interface). Celles-ci se composent de primitives qui se présentent comme des fonctions associées à des paramètres, générant une opération élémentaire (exemple : programmation de l’envoi ou de la réception d’un message)

Chapitre 1 : TCP/IP

b) Des interfaces physiques qui décrivent la façon dont des équipements vont être raccordés entre eux (exemple : modem, PC réseau Ethernet)

Pour IP, voir le polycopie de cours SMI5

Exemple : modèle en couche OSI de ISO ( voir cours de Licence SMI5)

03/01/2011

17

03/01/2011

18

Réseau TCP/IP

Réseau TCP/IP DNS

Application Ouvrir :ww.dest.fr Ecrire(f,message)

Adresse IP de ww.dest.fr ?

Envoyer : message à ww.dest.fr N°port= 21 Socket N° port=20

IP ww.dest.fr = 111.111.111.111 adresse locale = 111.111.111.222 ROUTAGE

Envoyer '20,21,message' a ww.dest.fr Adresse mac de 111.111.111.111?

Message pour ww.dest.fr n° port =21

ARP

TCP |20|21|message |

L’adresse est : 111.111.111.111

Choix destinataire --> dest |Adr1|adr2|...|20,21,message|

Adresse = dest Envoyer à dest 'Adr1,adr2,...,20,21,message'

Réseau

HDLC Mise en forme trame |F|dest|controle|adr1,adr2,...,20,21,message|bce|F|| erreurs|F|

Pour ARP, @IP, @MAC Voir SMI5 03/01/2011

19

03/01/2011

20

LE MODÈLE TCP/IP Exemples d’application

LE MODÈLE TCP

Service en mode connecté ==> garantie de non perte de messages ainsi que de l'ordonnancement Transport fiable de la technologie TCP/IP : •Adresse les processus (N° Port)

No port Mot-clé

Description

20

FTP-DATA

File Transfer [Default Data]

21

FTP

File Transfer [Control]

23

TELNET

25

SMTP

Simple Mail Transfer

42

NAMESERVER

Host Name Server

Telnet

53

DNS

Domain Name Server

•Fiabilise IP (Connexion et acquittements)

80

HTTP

WWW

•Optimise les ressources (Fenêtres variables)

110

POP3

Post Office Protocol - Version 3

TCP doit assurer un transport fiable des datagrammes IP : 1. service en mode connecté 2. garantie de non perte de messages ainsi que de l'ordonnancement 03/01/2011

21

03/01/2011

LE MODÈLE TCP

LE MODÈLE TCP/IP

On suppose que l'émetteur du premier paquet avec le bit SYN a connaissance du couple (adresse IP du récepteur, numéro de port du service souhaité).

L'émetteur du premier paquet est à l'origine de l'établissement du circuit virtuel, c'est une attitude généralement qualifiée de `` cliente ''. On dit aussi que le client effectue une `` ouverture active '' (active open).

Le récepteur du premier paquet accepte l'établissement de la connexion, ce qui suppose qu'il était prêt à le faire avant que la partie cliente en prenne l'initiative. C'est une attitude de `` serveur ''. On dit aussi que le serveur effectue une `` ouverture passive '' (passive open).

Contrairement aux réseaux orientés connexion, comme X25 ou ATM, la connexion TCP est différente de la notion de circuit virtuel : les routeurs intermédiaires ne maintiennent aucun contexte pour la connexion TCP qui est transparente pour eux. La connexion TCP ne fait invoquer que les deux nœuds terminaux 03/01/2011

22

23

A noter que, la caractérisation de la qualité du service dans l'Internet est généralement exprimée par les critères suivants: •

Délai: temps écoulé entre l'envoi d'un paquet par un émetteur et sa réception par le destinataire. Le délai tient compte du délai de propagation le long du chemin et du délai de transmission induit par la mise en file d'attente des paquets dans les systèmes intermédiaires.

•

Gigue : variation du délai de bout en bout

•

Bande passante ou débit maximum: taux de transfert maximum pouvant être maintenu entre deux points terminaux

•

Disponibilité : taux moyen d'erreurs d'une liaison

03/01/2011

24

TCP : L'établissement d'une connexion TCP

TCP L'établissement d'une connexion TCP s'effectue en trois temps

L'établissement d'une connexion TCP s'effectue en trois temps.

- Au début SYN =ISN (Numéro de séquence initial, c’est un compteur sur 32 bit, incrémenté tout les 4µs) -SYN de serveur contient un acquittement égal à ISN du client + 1. Le SYN = ISN de serveur - Le client acquitte et informant le serveur de l’ouverture de la connexion 03/01/2011

25

03/01/2011

TCP : Déconnexion TCP (en quatre phases)

26

TCP : Déconnexion TCP

Comme une connexion TCP est une connexion bidirectionnelle, le processus client et serveur doivent demander la fermeture de la connexion de façon individuelle.

•

Quand un des deux processus, client ou serveur, demande la fermeture de la connexion, le processus homologue n’ayant pas encore demandé la fermeture de la connexion, peut continuer à envoyer des données.

•

Au niveau de la couche TCP, suite à une demande de fermeture de connexion, TCP envoie un segment de type FIN et une confirmation de déconnexion est transmise au processus ayant demandé la fermeture de la connexion.

•

Le segment FIN est acquitté par l’entité TCP homologue. Cette dernière rentre dans un état dit semi-fermé (“half-close”) et peut continuer à envoyer normalement des données.

•

Après avoir fini cette procédure d’envoi, un segment FIN est envoyé. La connexion est fermée à la réception de l’acquittement du deuxième segment FIN. Une indication de déconnexion est alors transmise au second processus.

Elle se fait en quatre phases 03/01/2011

27

03/01/2011

28

TCP : Déconnexion TCP

TCP : Echange des données

L’une des particularités du protocole TCP est l’utilisation des numéros d’octets et non pas des numéros de paquets pour gérer les acquittements et les retransmissions.

Le champ séquence indique la position du premier octet du paquet dans le flux de données alors que le champ acquittement indique le prochain numéro de l’octet attendu par le récepteur. TCP effectue le transfert d’un flux continu de données dans les deux directions en regroupant à chaque fois un certain nombre d’octets pour former des segments. En général, TCP décide quand il doit bloquer et envoyer des données en utilisant un contrôle de flux connu sous l’appellation fenêtre glissante Ce contrôle de flux permet d’envoyer plusieurs paquets avant de se bloquer en attente d’acquittements (“Stop and Wait”). Ceci permet d’améliorer le débit puisque l’émetteur n’est pas obligé d’attendre la réception d’acquittement après chaque envoi de paquet de données 03/01/2011

29

TCP : Echange des données

03/01/2011

30

TCP : Exemple d’échange Sur le diagramme nous avons présenté les champs : séquence, acquittement, fenêtre, drapeaux, taille du segment et options TCP. Les segments

Note : le protocole TCP utilise la notion de “Piggy Backing” pour acquitter des données.

Le “Piggy Backing” permet d’optimiser l’utilisation de la bande passante lorsque l’émetteur et le récepteur ont des données à émettre et consiste à ne pas envoyer un acquittement systématiquement après la réception d’un paquet de données.

En recevant des données, TCP vérifie s’il a des données à envoyer.

Si c’est le cas, TCP envoie un segment de données tout en mettant à jour le champ acquittement de sorte à acquitter le dernier segment reçu.

•1, 2, 3 correspondent à l’établissement de la connexion TCP en 3 phases. La connexion est établie à l’initiative de la machine A qui annonce, dans le champ options, un MSS de 1460 et une fenêtre de 4096 octets (segment 1).

• La machine B accepte la connexion en envoyant le segment 2 qui annonce un MSS de 1024 octets et une fenêtre de 6144. L’échange de données se fait en utilisant des segments de taille maximale égale à 1024 octets. * Ensuite la machine A envoie 6 segments de taille 1024 octets (segment 4, 5, 6, 7, 8, 9) avant de se bloquer en attente d’un acquittement

Ns= ISN + Nb Octets transmis + 1 Le N° du 1er octet transmis est ISN + 1 03/01/2011

31

03/01/2011

32

TCP : Retransmission de paquet perdu

TCP : Retransmission de paquet perdu

Après l’établissement de la connexion1, la machine A envoie les segments 1, 2 et 3 et arme un temporisateur. Le paquet 1 est perdu dans le réseau. A la réception de chacun des paquets 2 et 3, la machine B envoie un acquittement avec un numéro d’acquittement égal au numéro de séquence du segment 1.

L’utilité de ces acquittements est, d’une part, d’informer l’émetteur (machine A) que le segment 1 (séquence 501) n’est toujours pas reçu, et d’autre part d’annoncer la nouvelle taille de fenêtre. A l’expiration du temporisateur, la machine A retransmet le segment ayant le numéro de séquence 501. La machine B délivre les 3 segments de données et acquitte simultanément les 3 paquets de données par le segment 7.

Notons que la fenêtre annoncée dans le segment 7 est de 6144.

L’établissement de la connexion n’est pas représenté pour simplifier la compréhension

03/01/2011

Retransmission de paquet perdu avec duplication des ACK(voir 50) 33

03/01/2011

34

TCP : Fenêtres glissantes

TCP : Fenêtres glissantes • •

•

•

Au départ du Paquet i une horloge se déclenche. Si cette horloge dépasse une valeur limite avant réception de l'ACK le Paquet i est retransmis.

• •

Le temps qui s'écoule entre l'émission d'un paquet et la réception de son acquittement est le RTT. Il est courant sur l'Internet actuel d'avoir un RTT de l'ordre de la seconde. Il faut noter que le RTT est la somme des temps de transit entre chaque routeur et du temps passé dans les diverses files d'attente sur les routeurs.

•

Avec ce principe, la bande passante du réseau est beaucoup mieux employée.

Si l'un des paquets doit être réémis, la couche TCP du destinataire aura toute l'information pour le replacer dans le bon ordre. À chaque paquet est associée une horloge comme sur la figure diapo 37.

Le nombre de paquets à envoyer avant d'attendre le premier acquittement est fonction de deux paramètres : – La largeur de la fenêtre, précisée dans le champ WINDOW de l'en-tête, change dynamiquement pour deux raisons :

L'émetteur conserve la trace du Paquet i pour éventuellement le renvoyer.

03/01/2011

35

03/01/2011

•

L'application change la taille du `` buffer de la socket qui correspond à la taille de cette fenêtre.

•

Chaque acquittement ACK envoyé est assorti d'une nouvelle valeur de taille de la fenêtre, permettant ainsi à l'émetteur d'ajuster à tout instant le nombre de segment qu'il peut envoyer simultanément. Celle valeur peut être nulle, comme par exemple lorsque l'application cesse de lire les données reçues. C'est ce mécanisme qui assure le contrôle de flux de TCP.

36

TCP : Fenêtres glissantes

03/01/2011

TCP : Fenêtres glissantes

37

03/01/2011

TCP : Fenêtres glissantes

TCP: Introduction à la congestion

•

Le débit obtenu dépend de la taille de la fenêtre et bien sûr de la bande passante disponible. On conçoit aisément qu'entre la situation de la figure (diapo 33) et celle de la figure (diapo 34) l'usage de la bande passante s'améliore. Par contre l'agrandissement de la taille de la fenêtre ne se conçoit que jusqu'à une limite optimale au delà de laquelle des paquets sont perdus parce que envoyés trop rapidement pour être reçus par le destinataire. Or, pour fonctionner de manière optimale, TCP se doit de limiter au maximum la perte de paquets et donc leur réémission.

•

Cette taille limite optimale de la largeur de la fenêtre est, comme on peut le deviner, fonction de la bande passante théorique du réseau et surtout de son taux d'occupation instantané. Cette dernière donnée est fluctuante, aussi TCP doit-il asservir continument les tailles de fenêtre pour en tenir compte.

03/01/2011

38

39

● Lien (bande passante, latence) ● Ex. : taux de transfert idéals entre différents ordinateurs ● CC = adaptation à la bande passante disponible à chaque instant

03/01/2011

40

TCP: Introduction à la congestion

TCP: Introduction à la congestion Exemple de problème réseau :

● Congestion = routeur avec file d'attente pleine ● Si routeur avec file d'attente (quasi) pleine : – rejet/perte de paquet (car débordement mémoire routeur) – délais importants de transfert (car attente dans les files des routeurs) ● Causes de la perte d'un paquet : – problème matériel – problème d'environnement (souvent dans les réseaux sans fil) – mais surtout congestion d'un routeur

Un utilisateur se plaint d'un débit faible ? ● En regardant, une application UDP est très utilisé ● UDP ne s'adapte pas à la bande passante disponible ● TCP s'adapte => TCP est défavorisé

● En filaire, perte d'un paquet ~= congestion d'un routeur 03/01/2011

41

03/01/2011

TCP: comment faire pour minimiser la congestion

42

TCP: comment faire pour minimiser la congestion?

Principe “end to end”

● Une machine réseau « hôte » est impliquée dans 1 transfert, un routeur dans beaucoup de transferts ● Les deux hôtes d'extrémité sont responsables du débit de transfert des données :

● Contrôle de flux : par rapport au récepteur – l'émetteur adapte le nombre de paquets envoyés à la taille du buffer de réception

– à quelle vitesse transmettre ?

– quand transmettre ?

– quand accélérer et décélérer le débit ?

● Contrôle de congestion : par rapport au réseau – l'émetteur adapte le débit des données envoyées à la bande passante instantanée du réseau

● Le réseau ne leur fournit pas des informations explicites 03/01/2011

Ce n'est pas la taille des paquets, mais leur débit d'envoi qui change 43

03/01/2011

44

TCP: Quelques définitions liées à la congestion

TCP: Quelques définitions liées à la congestion

● Buffer de réception : espace de stockage des données (reçues ou non)

● Fenêtre de réception nombre max de paquets que le récepteur est capable de recevoir à un certain moment (l'espace libre au récepteur)

● Accusé de réception – récepteur >émetteur – numéro du 1er octet attendu par le récepteur ● TCP classique : les accusés sont cumulatifs

● Fenêtre d’émission : les données de l'application ● Fenêtre de congestion (cwnd) – sous fenêtre mobile de la fenêtre d'émission – nombre max de paquets que l'émetteur peut envoyer avant de recevoir un accusé lui permettant de poursuivre la transmission

● Delayed ACK : retarder les accusés

● Seuil de démarrage lent (ssthresh) – estimation de la bande passante disponible

03/01/2011

● DupACK : un accusé identique au précédent – si paquet N arrive au récepteur avant N - 1, son accusé est identique à l'accusé de N - 2

45

03/01/2011

46

TCP : Mécanismes de CC TCP: Quelques définitions liées à la congestion ● En général, la perte d'un paquet est la seule information sur l'état du réseau ● Le CC est géré exclusivement par l'émetteur – le récepteur ne fait que renvoyer des accusés de réception

● RTT (Round Trip Time) – temps entre l’envoi d’un paquet et la réception de son accusé

● Les mécanismes basiques de CC supportés par TCP sont [RFC 2581] :

● RTO (Retransmission Timeout) – à chaque envoi d'un paquet, une horloge propre est lancée

– – – –

– si l'horloge expire, le paquet est retransmis ● le RTO est affecté dynamiquement, en fonction du RTT [RFC 2988]

algorithmes AIMD (Additive Increase, Multiplicative Decrease Principe de base: TCP augmente progressivement (au rythme des RTT) la valeur de cette fenêtre jusqu’à la détection d’une perte. A ce point, la source réduit la taille de la fenêtre de congestion et recommence l’augmentation progressivement.

Cet aspect dynamique de la fenêtre est connu dans la littérature par le terme : AIMD (“Additive Increase/Multiplicative Decrease”).

● exemple : RTO = 2*RTT

03/01/2011

slow start ( départ lent ) congestion avoidance ( évitement de congestion) fast retransmission ( retransmission rapide ) fast recovery ( recouvrement rapide)

47

03/01/2011

48

TCP :

Slow start

But : retrouver rapidement la bande passante disponible ● cwnd = 1 ● cwnd++ à chaque accusé reçu (cwnd *= 2 à chaque RTT) – (croissance exponentielle) ● ssthresh = valeur arbitraire ● Si perte : – ssthresh = cwnd / 2 – cwnd = 1 – on relance le slow start ● Si atteinte ssthresh : – on entre en congestion avoidance L'émetteur commence par transmettre un segment. Quand l'accusé de réception est reçu, cwnd est incrémenté de 1 à 2, et 2 segments peuvent être envoyés. Lorsque un ACK arrive pour chacun de ces segments, cwnd est incrémentée de 2 à 4 et ainsi de suite...jusqu'à la fin du transfert ou jusqu'à ce que le buffer de l'émetteur soit plein.

La croissance de cwnd est exponentielle ou presque, le destinataire pouvant retarder les accusés de réception et envoyer un accusé pour deux segments reçus.

03/01/2011

Evolution de la fenêtre de congestion pendant la phase slow-start 03/01/2011

49

TCP :

50

Slow start

TCP : Congestion avoidance

Principe de base :

•

•

But : augmenter le débit en testant la bande passante disponible

Après l’établissement de la connexion ou après l’expiration d’un temporisateur de retransmission, l’émetteur1 fixe la taille de la fenêtre de congestion à 1 segment (MSS). A chaque réception d’acquittement, il augmente la taille de la fenêtre de congestion par 1 MSS Figure diapo 53).

Cet algorithme continue jusqu’à ce que la fenêtre de congestion atteigne un seuil (SS-threshold). Ceci résulte en un accroissement exponentiel de la fenêtre de congestion : si chaque paquet est acquitté, la fenêtre de congestion double de taille après chaque RTT

03/01/2011

51

● Utilisé quand cwnd >= ssthresh

● cwnd++ à chaque RTT – (croissance linéaire) ● Si perte : – ssthresh = cwnd / 2 – cwnd = 1 – retour au mode slow start

03/01/2011

52

TCP :

Slow start

TCP : Congestion avoidance

Contrôle de la congestion TCP Tahoe L'idée de l'algorithme est qu'une indication de pertes de paquets signale une situation de congestion. Une perte de paquets peut être signalée soit par un timeout, soit par la réception de ACKs dupliqués.

Quand la congestion est signalée, TCP doit ralentir son débit d'émission des paquets et demander à l'algorithme slow-start de reprendre la situation en main. Bien que les deux algorithmes sont indépendants (congestion avoidance et slow-start), ils sont généralement implémentés ensemble. Ils nécessitent, outre la fenêtre de congestion définie précédemment (cwnd), un seuil associé au slow-start appelé ssthresh.

Lorsqu'une situation de pertes de paquets est signalée, la fenêtre de congestion est décrémentée de moitié : cette taille est conservée comme seuil pour l'algorithme slow-start (ssthresh).De plus, si la perte de paquets est signalée par un timeout, cwnd est ramenée à sa valeur initiale et TCP se remet en mode slow-start.

cette Figure montre l’évolution de la fenêtre de congestion TCP en fonction du temps d’aller retour : RTT (“Round Trip Time”)1. La croissance de la fenêtre de congestion se fait en deux phases : Slow-start et congestion avoidance 03/01/2011

53

TCP :

54

TCP :

Fast Retransmission

fast recovery

ssthresh = cwnd / 2

But : détecter plus rapidement la perte d'un paquet Un paquet est considéré par l'émetteur comme perdu si : – pas d'accusé au timeout (=> pertes successives), déjà traité – ou bien réception de N dupacks, N = 3 en gén. (=> perte)

Fast retransmission : si N dupacks, on n'attend plus le timeout, mais : – on retransmet le paquet – on entre en slow start (Tahoe) ou fast recovery (les autres) 03/01/2011

03/01/2011

55

cwnd = ssthresh + 3 (“gonflement” de cwnd) – envoi éventuel de nouveaux Paquets Pour chaque dupack, cwnd++ – envoi éventuel d'un nouveau paquet Réception d'un non dupack (“dégonflement” de cwnd) : – cwnd = ssthresh – retour au congestion avoidance

03/01/2011

56

TCP :

TCP: Contrôle de la congestion TCP Reno

algorithmes de CC

Tahoe : slow start + congestion avoidance + fast retrans Reno : Tahoe + fast recovery Newreno : Reno + adaptation aux pertes successives Vegas : basé sur l'historique du RTT (état des routeurs) SACK, DSACK : spécifie exactement les paquets reçus Westwood+ : basé sur l'historique du RTT, meilleure utilisation si pertes aléatoires Beaucoup d'autres...

Voir TD3

03/01/2011

57

TCP :

Tahoe

Perte <=> timeout ou 3 dupacks Utilise : – slow start – congestion avoidance – fast retransmit Initialisation : cwnd 1(MSS); ssthresh Init_Ssthresh; State SlowStart; Voir TD3

03/01/2011

59

03/01/2011

58