Chapter3-Protocoles de Transporthdhili.weebly.com/uploads/9/8/9/6/9896432/chapter3-protocoles_de... · Chapitre 3 Protocoles de transport de llInternet’Internet Dr. M. Jarraya,

Chapitre 3 Chapitre 3

Protocoles de transport de Protocoles de transport de

l’Internetl Internet

Dr. M. Jarraya, Cours Réseaux, 2ème année cycle Ingénieur 1

Chapter 3: Couche Transport

Nos objectifs:j

Comprendre les services implémentés par la couche

Etudier les protocoles de couche transport :p p

transport:multiplexage/demultiplexage

pUDP: transport sans connexion

TCP: transport orienté fiabilité du transfert de données

pconnexion

le contrôle de congestion TCPcontrôle de flux

contrôle de congestion


Couche transport vs. Couche réseau

La couche transport:communication logique entre les

La couche réseau :communication logique entre les communication logique entre les

processus

apporter des améliorations de

communication logique entre les hôtes

apporter des améliorations de fiabilité par rapport à celle de la couche réseau


Multiplexage/demultiplexaep g pDemultiplexage au hôte récep:

C ll t l d é d Multiplexage au hôte émett:

Délivrer les segments à la bonne socket

Colleter les données de plusieurs sockets et enveloppeles données avec l’en-tête

é= process= socket

(utile pour le démultiplexage)

application

transport

P1 application

transport

application

transport

P2P3 P4P1

transport

network

link

network

link

transport

network

linklink

physical

link

physical

link

physical

hôte 3


hôte 1 hôte 2 hôte 3

Comment s’effectue le démultiplexage

Hôte recevant les datagramme IPChaque datagramme a uneadresse IP source et uneadresse IP destination

port source port dest

32 bits

chaque datagrammeencapsule un segment de

h

Les autres champs del’en-têtecouche transport

Chaque segment a un numérode port source et un num de Les données de

l en tête

de port source et un num de port destination spécifiques à l’application

l’application (message)

hôte utilise les adresses IP et les numéros de port pour diriger le segment à la bonne socket

Format d’un segment TCP/UDP


segment à la bonne socket

Démultiplexage sans connexion

S k S k S k (6428)DatagramSocket serverSocket = new DatagramSocket(6428);

P2 P1P1P3P2 P1P3

PS: 6428PD: 9157

PS: 6428PD: 5775

ClientIP B

clientIP A

serveurPS: 9157PD: 6428

PS: 5775PD: 6428

IP:BIP: A IP: C


Démultiplexage orienté connexion

socket TCP identifiée par 4- L’hôte serveur peut supporter tuple:

Adresse IP source

simultanément plusieurssockets :

num de port source

Adresse IP dest

chaque socket est identifiéepar ses 4-tuple

num de port dest

l’hôte récepteur utilise

Les serveurs Web ont des sockets différents pour h i d’ li ttoutes les 4 valeurs pour

diriger le segment à la k t ié

chaque connexion d’un clientHTTP non-persistant aura unesocket différente pour socket appropriée socket différente pour chaque requête


Démultiplexage orienté connexion

P1 P1P2P4 P5 P6 P3P1 P2P4 P5 P6 P3

PS: 5775PD: 80D 8

IP-D:CIP-S: B

ClientIP B

clientIP A

serveurPS: 9157PD: 80

PS: 9157PD: 80

IP S A IP S B IP:BIP: A IP: CIP-D:C

IP-S: AIP-D:C

IP-S: B


Le protocole UDPSouvent utilisé pour des app multimédiasmultimédias

tolère la pertemais c’est un service rapide

port source port dest

32 bits

La longueur totale ( ) rapide

autres utilisations de UDPDNS

longueur checksum(en octet)du segment UDP

y compris l’ têtSNMP

fiabilité de transfert à travers UDP: ajouter des Données de la couche

l’en-tête

travers UDP ajouter des fonctions de contrôle au niveau de la couche application pour améliorer la fiabilité

Application(message)

precouvrement spécifiqued’erreurs au niveauapplicatif

Format d’un segment UDP


appl cat f

checksum UDPBut: detecter des “erreurs” (e.g., bits altérés) dans la transmission du

segment

Emetteur: Récepteur:

segment

traite le contenu du segment comme étant une séquenced’entiers de 16 bits

Calcule le cheksum du segment reçu

d entiers de 16 bitschecksum: le complément à un de la somme de tous les mots de 16

et vérifie si la valeur calculée du checksum est égale à la valeur

bits du segment en éliminant tout dépassement de capacitémet la valeur du checksum dans le

mise dans le champ checksum:

NON - détection d’erreurmet la valeur du checksum dans le champs checksum du segment UDP à envoyer

OUI - pas d’erreur


Exemple de checksum InternetNote

En additionnant les mots de 16 bits, les retenues En additionnant les mots de 16 bits, les retenues sortantes du bit du poids fort doivent être ajoutées au résultat final

E l ddi i d d i 16 biExemple: addition de deux entiers 16-bits

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1Retenue

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0

sortante

sommeh k


1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1checksum

TCP: vue généraleRFCs: 793 1122 1323 2018 2581RFCs: 793, 1122, 1323, 2018, 2581

applicationÉ it d é

application

Interfacesocket

Tampon Tampon de

Écrit données Lit donnéesInterfacesocket

Tampon d ’envoi de

TCP

Tampon de réception

de TCP

segment


structure d’un segment TCP

t t d t

32 bitsURG: données urgentes Compte le nombreport source port dest

sequence numberacknowledgement number

g

ACK: séq de l’ACKp is n nsidé ti n

Compte le nombred’octetsde données(non pas du acknowledgement number

Fenêtre réceptionPointeur donn.URGchecksum

FSRPAUheadlen

notused

pris en considérationPSH: passer les donnée à

la couche application

(non pas du segment !)

Pointeur donn.URG

Options (longueur variable)RST, SYN, FIN:pour établissement

f

Nombre d’octetspouvant êtreacceptés

donnéesapplication

et fermeture de connexion

p

Checksum application(longueur variable)

ChecksumInternet

(comme pour UDP)


sequence number et acknowledgement number acknowledgement number

Numéro de séquence: Hôte A Hôte BLe numéro dans le flux de données du

Hôte A Hôte B

Utilisateurtappe

‘C’premier octets de chaque segment

CAquitte

‘C’, envoie ‘C’

Numéro ACKs:

le num de seq du Aquitteprochain octet qu’il attend de l’autre côté

q‘C’,

envoie ‘C’

côté

ACK cumulatif tempsExemple de scénario Telnet


Exemple de scénario Telnet

Scénarios de retransmission

15

RTT et Timeout TCP

Q: Comment choisir la Q: Comment estimer le RTT?Q: Comment choisir la valeur de timeout?

Supérieur à RTT

QSampleRTT: : mesure le temps entre la transmission du segment et la Supérieur à RTT

mais RTT varie

plus petit

réception de son ACK

ignore les retransmissionsplus petit

des retransmissions inutiles

SampleRTT va varier selon le niveaude congestion

N t êt lbeaucoup plus grand: ralentit la reaction face à

Ne peut pas être une valeurfiable de RTT

On considère une moyenne des la perte des segments

On considère une moyenne des mesures et non le SampleRTTcourant


RTT et Timeout TCP

EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTTEstimatedRTT (1 α) EstimatedRTT + α SampleRTT

Une moyenne pondérée des différentes valeurs de SampleRTT

plus de poids aux échantillons récents qu’aux échantillons plus ianciens

valeur typique: α = 0.125

Timeout= 2 * EstimatedRTT


Exemple d’estimation RTT :

RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

300

350

250

onds

)

200RTT

(mill

iseco

150

1001 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)


SampleRTT Estimated RTT

RTT et Timeout TCP

Configurtion du timeout (Jacobson & Karels )gPremière estimation de combien SampleRTT dévie de EstimatedRTT:

DevRTT = (1-β)*DevRTT +β*|SampleRTT-EstimatedRTT|

(typiquement, β = 0.25)( yp q , β )

TimeoutInterval = EstimatedRTT + 4*DevRTT


Transfert de données fiable avecTCPTCP crée un service de transfert fiable au dessus du service

IP non fiable

Piplinage des segments (plusieurs envoi sans ack)p g g p

acks cumulatifs

TCP li l i d i iTCP utlise un seul timer de retransmission

Initialement considérons la version simplifié de TCP

ignorer la dupplication des acks

ignorer le contrôle de flux et le contrôle de congestionignorer, le contrôle de flux et le contrôle de congestion


Evenements de l’expéditeur TCP:Données reçues de l’app:

créer un segment avec un timeout:

retransmettre le segment qui créer un segment avec un numéro de séquence

le num de séq est le numérod l fl d d é d

retransmettre le segment qui a causé le déclenchement du timeout

dans le flux de données du premier octet de chaquesegment

i l i ’il ’

redémarrer le timerréception d’un Ack:

actionner le timer s’il n’estpas encore déclenché(pensez que le timer est

ps’il accuse réception des segments non acquittés(pensez que le t mer est

pour le plus ancien segment non acquitté)

mettre à jour ce qu’il n’estpas encore acquittédé l ti ’il d interval d’expiration:

TimeOutInterval

démarrer le timer s’il y des segments envoyés non encores acquittés


q

Vérsion simplifiée de l’expéditeur TCP:

NextSeqNum = InitialSeqNumSendBase = InitialSeqNumloop (forever) {

CP

loop (forever) { switch(event)event: données reçues de la couche application

créer un segment TCP avec le num de séq= NextSeqNumgif (timer n’est pas encore déclanché)

start timerpass segment to IP NextSeqNum = NextSeqNum + length(data)

Commentaire:• SendBase-1: num de séq du dernier NextSeqNum = NextSeqNum + length(data)

event: timer timeoutretransmettre le segment non encore acquitté avec le pluspetit numéro de séquence

de séq du dernier octet reçu intact et dans l’ordre•Example:

start timerevent: ACK reçu, avec séq ACK= y

if (y > SendBase) { SendBase = y

Example:• SendBase-1 = 71;y= 73, récepteurdemande 73+ ;SendBase = y

if (S’il reste des segments non encore acquittés)start timer

}

;y > SendBase, doncde nouvelle donnéessont acquittées


} /* end of loop forever */q

TCP: scénarios de retransmissionHôte A Hôte BHôte A Hôte B

imeo

ut

ut

Seq=

92 t

lost

tim

eou

X

meo

ut

SendBase

Sendbase= 100

Seq=

92 t

im

SendBase

= 120

tempsmauvaisTimeout

tempsSSendBase

= 100 SendBase= 120


Perte d’un accusé temps

TCP: scénarios de retransmission

Hôte A Hôte B

lostti

meo

utX

lost

SendBase 120= 120

Accusé de réception cumulatiftemps


p

Génération des ACK TCP [RFC 1122, RFC 2581]

Evénement Réponse du destinataire TCP

Arrivée d’un segment intact et dans l’ordre, porteur du num de séq attendu. Toutes les données jusqu’à ce num de séq

Génération de l’accusé de réceptionretardé d’une durée de 500 ms, en attented’un autre segmentToutes les données jusqu à ce num de séq

sont déjà acquittéd un autre segment

Arrivée d’un segment intact et dans l’ d d té d’ d é tt d U

Envoi immédiat d’un ACK cumulatif simple, t é ti d d t l’ordre, doté d’un num de séq attendu. Un

segment précédent est en attente de l’émission de son ACK

accusant réception des deux segments (dans l’ordre)

Arrivée d’un segment hors séq doté d’un num de Seq supérieur au num attendu. (Lacune détectée)

Envoi immédiat d’un ACK dupliquéindiquant le num de séq du prochain octet attendu (limite inf lacune)

Arrivée d’un segment remplissantcomplétement ou partiellement la lacunedans les données reçues

Envoi immédiat d’un ACK, sous réserve que le segment coïncide avec la limite inf de la lacune


Retransmission rapideSouvent, la periode du Time-out est relativement longue : Si l’émetteur reçoit 3 ACKs m g

Délai long avant la retransmission d’un paquetperdu

Si l émetteur reçoit 3 ACKs du même segment, il suppose que ce segment est perdu:perdu

Détection de perte de segment avec les ACKs dupliqués.

q g pRetransmission rapide:retransmet le segment p q

Emétteur envoie souvent un grand nombre de segment l’underrière l’autre

avant l’expiration du Time-out

derrière l autreLa perte d’un segment estsusceptible de générer un

d d’ é d grand nombre d’accusé de réception en chaîne.


Algorithme de retransmission rapide

event: ACK received, with ACK field value of y if (y > SendBase) {

SendBase = ySendBase = yif (des segments ne sont pas encore acquittés)

start timer }}

else {incrémenter le compteur des ACKs reçus pour y if (compteur des ACKs reçus pour y = 3) {( p ç p y ) {

retransmettre le segment avec le num de séq = y}

Un ACK duppliqué pour un segment

Retransmission rapide


Déjà acquitté

Contrôle de flux TCPLe côte récepteur a un buffer de réception: L’emetteur ne doit pas

Contrôle de fluxp L emetteur ne doit pas

saturer le buffer du récepteur en

transmettant avec un

E it l s t ti n p n

transmettant avec un rythme trop soutenu

Eviter la saturation par un système d’équilibrage qui ajuste le rytme d’envoi à la

d l d vitesse de lecture de l’application destinataireLe processus applicatif

peut prendre du temps ( é d (occupée par d’autres activités) pour lire le contenu du buffer


Contrôle de flux TCP : comment ça marchecomment ça marche

RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead]

(On suppose que le récepteur TCP supprime les segments hors séquence)

RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead]

RcvWindow : Espace mémoire disponible (spare room) en bufferRcvBuffer : la taille du buffer de récéption allouée pour la connexionLastByteRead : numéro du dernier octet dans le flux de donnéesLastByteRead : numéro du dernier octet dans le flux de donnéesretiré du buffer par le processus applicatifLastByteRcvd : numéro du dernier octet dans le flux de données


reçus et placé dans le buffer

Contrôle de flux TCP : comment ça marchecomment ça marche

Récepteur informe l’émetteur de l’espace disponible dans son Récepteur informe l émetteur de l espace disponible dans son buffer en insérant RcvWindow dans tous les segments TCP.L’emetteur limite les segments non acquittés à l’espaceRcvWindowSi RcvWindow passe à 0, l’émetteur continue à émettre des segments TCP contenant un seul octet de gdonnées obligeant le récepteur à envoyer des ACKs porteurs des nouvelles réactualisation de RcvWindow(éviter un deadlock)


(éviter un deadlock)

Gestion de la connexion TCP

Initialisation: Echange de Trois états d’échange:segments TCP de connexionentre un client et un serveurInitialisation de variables TCP:

Trois états d échange:Etape 1: l’hôte client envoie un

segment TCP SYN au serveurInitialisation de variables TCP:Num de séqbuffers, info contrôle de flux

gSpécifie un num de séq initialPas de données

Et 2 l’hôt itff , f f(e.g. RcvWindow)

client: intitiateur de connexion

Etape 2: l’hôte serveur reçoitSYN et répond par un segment SYN+ACK

Socket clientSocket = new

Socket("hostname","port number");

serveur: contacté par le client

Serveur alloue les buffersSpécifie un num de séq initial serveurserveur: contacté par le client

Socket connectionSocket = welcomeSocket.accept();

serveurEtape 3: le client reçoit SYN+ACK

et répond par un segment ACK qui peut contenir des données


qui peut contenir des données

Gestion de la connexion TCPFermeture de connexion:client ferme socket:client ferme socket:

clientSocket.close();

Etape 1: Le système terminal clienti s t d t ôl TCP

client serveur

closeenvoie un segmet de contrôle TCP FIN au serveur

Etape 2: Le serveur reçoit un FIN, é d t ACK lrépond avec un segment ACK.

Ferme la connexion et envoie un segment FIN

Et p 3: li t it FIN é d

close

teEtape 3: client reçoit FIN, répond avec un ACK.

Met un “temps d’attente” –pour recevoir les segments de d

’atte

ntpour recevoir les segments de données en cours de transfert

Etape 4: serveur, reçoit ACK et ferme la connexion F t

Tem

ps


ferme la connexion Fermeture

Gestion de la connexion TCPReprésentation d’une connexion TCP par un automate à états fini : « schéma complet» C0NNECT/SYN« schéma complet» C0NNECT/SYN

FERMÉECLOSE/-

ÉCOUTE

LISTEN/-SYN/SYN+ACK

CLOSE/-

SYNémisSYN

reçu

ÉCOUTE

ÉTABLIESYN+ACK/ACK

Transfert de donnéesACK/-

CLOSE/FIN FIN/ACK

FIN ATTENTE 1

ACK/

FERMETUREEN COURS

FIN/ACK ATTENTEFERMETURE

CLOSE/FINACK/

FINATTENTE 2

ACK/-

ATTENTETEMPORISÉE

FIN+ACK/ACK

FIN/ACK

DernierACK

ACK/-


FERMÉEACK/-

Principe du contrôle de congestion

Congestion:

Informellement :”plusieurs sources envoient un grand volume de

données sur un court intervalle de temps au réseaudonnées sur un court intervalle de temps au réseau.

Différent du contrôle de flux !

Les conséquences:

Perte de paquets (saturation des buffers des routeurs “buffer p q (

overflow”)

Dél i d i fil d’ tt t t è lDélai de mise en file d’attente très long


Causes et effets de congestion: sénario 1

Deux émetteurs, Hôte A

λin : données i i l

λoutD m ,deux récepteursUn routeur, buffer de taille infinie

Tampons de liaison de sortie de nombre illimité

originales

Hôte Btaille infiniePas de retransmission

Un long délai quand g qc’est congestionnéExploitation de la liaison au maximum de sa capacité eq. Longues files d’attentes au


niveau du routeur

Causes et effets de congestion : scenario 2

Un seul routeur buffers limitésUn seul routeur, buffers limitésL’émetteur retransmet les paquets perdus

Hôte A λin : données originales λout

Tampons de liaison de sortie é d b l é

Hôte B

λ'in : données originales, plus données retransmises

partagés de nombre limité



Dans le cas idéal: λin = λout (a)retransmission uniquement dans le cas de perte : λ’i > λ t (b)retransmission uniquement dans le cas de perte : λ in > λout (b)retransmission des paquets retardé (non perdus) met λ’in encore plus grand que λout (c)

R/2R/2 R/2

R/3λ o

ut

λ out

λ out

R/4

R/2λin

b.

R/2λin

a.

R/2λin

c.“coût” de congestion:

Plus de travail (retrasmission) au niveau de l’expéditeur et exploitation inutile du débit de liaison des routeur


inutile du débit de liaison des routeurRetramsmission inutile: la liaison supporte de multiples copies des paquets


Quatre émetteursPl i h i ibl

Q: Que ce passe –t-il si λint λ’ ît t?Plusieurs chemins possibles

timeout/retransmissionet λ’in croîtent?

Hôte Aλin : données originales λout

λ'in : données originale, plus données retransmisses

Serveur D

Tampons de liaison de sortie partagés de nombre limité

Hôte B R1

R2

R4

Serveur C

R3



Hôte A λout

Hôte B

Autre “coût” de congestion:Lorsqu’un paquet est perdu sur son parcours la capacité de Lorsqu un paquet est perdu sur son parcours, la capacité de transmission dépensée par chacun des routeurs en amont pour le faire progresser (jusqu’au routeur saturé) s’en trouve

d


perdue

contrôle de congestionTCP Comment l’émetteur détecte

la congestoin?

Contrôle de bout en bout (pas d’assistance du réseau)

gÉvénement de perte = expiration du timeout ou l’arrivé de 3 acks

L’émetteur limite sa transmission:LastByteSent-LastByteAcked =

Min{CongWin,RcvWindows} ≤ CongWin

l arrivé de 3 acks duppliquésL’émetteur réduit la fenêtre de congestion { g , } g

Rééllement,fenêtre de congestion (CongWin) après l’événement de perte

Trois mécanismes:CongWin

CongWin est dynamique et fonction

Trois mécanismes:Accroissement additif et décroissance multilicative (AIMD)

Vitesse d’envoi = CongWinRTT Bytes/sec

y qdu niveau de congestion du réseau

(AIMD) Départ lentRéactions aux temporisations


temporisations

AIMD TCP décroissance multiplicative:

réduire CongWin à sa moitié si Accroissement additif:

augmenter la valeur de gl’événement de perte apparaît

gCongWin de 1 MSS après chaque RTT en absence de phénomène de perteFenêtre de phénomène de perte

24 Kbytes

Fenêtre decongestion

16 Kbytes

8 Kbytes

temps


Départ lent TCP

Q d l i dé Quand la connexion démarre le Quand la connexion démarre, CongWin = 1 MSS

Exemple: MSS = 500 bytes &

Quand la connexion démarre, le taux d’envoi croît de façon expoentielle jusqu’à l’apparition d’un événement de pertep y

RTT = 200 msectaux d’envoi initiale = 20 kbps

d un événement de pertedoubler CongWin chaque RTT

conclusion: le taux d’envoi initial pLa bande passante disponible peut être >> MSS/RTT

C’ st s uh it bl d

est lent mais augmente rapidement en exponentiel

C est souhaitable de remettre rapidement le taux d’envoi aux taux de la bande passante disponiblepassante disponible


Départ lent TCP

Hôte A Hôte B

RTT

Hôte B

R

time


Réaction aux temporisationsAprès 3 ACKs duppliqués:

C Wi est divisée à sa Philosophie:

CongWin est divisée à sa moitiéeLa fenêtre croît linéairement

• 3 ACKs dup indiquent que le réseau est capable d d dél l Mais après un timeout :

CongWin est mise à 1 MSS;

de de délivrer quelques segments • timeout avant 3 ACKs Puis la fenêtre de congestion

croît de façon exponentielle jusqu’à un seuil puis elle

• timeout avant 3 ACKs dup est “plus critique”

jusqu à un seuil puis elle progresse linéairementLa valeur seuil de la fenêtre :

Initilialiée à valeur élevée (65 Ko)S’il y a un timeout elle passe à la moitié de CongWin


Réaction aux temporisationsQ: Quand est ce que

l’accroissement mexponentiel passe au linéaire?

A: Qaund CongWind l 1/ d prend le 1/2 de sa

valeur avant le timeout.

Implementation:Variable seuil (Threshold) Variable seuil (Threshold)

À l’événement de perte, le seuil est mis à 1/2 du CongWin juste avant g jl’apparition de l’événement de perte


contrôle de congestionTCP : synthèseTant que CongWin est inférieure à la valeur du seuil, l’expéditeur est en phase de départ lent et la fenêtre connaît une croissance est en phase de départ lent et la fenêtre connaît une croissance exponentielle.

Une fois la valeur de seuil dépassée l’expéditeur entre dans la Une fois la valeur de seuil dépassée, l expéditeur entre dans la phase d’évitement de la congestion durant laquelle la fenêtre s’accroît de manière linéaire.

Lorsqu’il y a trois ACKs identiques, la valeur du seuil est réglée à la moitié de la taille de CongWin en cours et cette dernière est portée à la valeur du seuilportée à la valeur du seuil

Lors de l’expiration du timeout, la valeur du seuil est reglée à la moitié de la taille de CongWin en cours et cette dernière est portée moitié de la taille de CongWin en cours et cette dernière est portée à 1 MSS


Contrôle de congestion TCP de l’expéditeur l expéditeur

Do bler la ale r de CongWin àCongWin CongWin + MSSDépart LentRéception d’ n

CommentairesAction TCP de l’expéditeurEtatEvénement

Doubler la valeur de CongWin àchaque RTT

CongWin = CongWin + MSS, If (CongWin > Threshold)

set state to “Evitement de Congestion ”

Départ Lent (DL)

Réception d’un ACK pour un segment non acquitté

Accroissement Additif de CongWin par 1 MSS à chaque RTT

CongWin = CongWin+MSS * (MSS/CongWin)

Evitement de Congestion (EC)

Réception d’un ACK pour un segment non acquitté

Recouvrement rapide, par implementation de la décroissance multiplicative. CongWin ne se met pas à 1

Threshold = CongWin/2, CongWin = Threshold,Set state to “Evitement de Congestion ”

DL ou ECDétection de perte après 3 ACK duplliqués

Passe au Départ Lent Threshold = CongWin/2, CongWin = 1 MSS,Set state to “Départ Lent ”

DL ou ECTimeout

MSS.

CongWin et le seuil ne changent pas

Incrémentation du compteur des ACK dup du segment déja acquitté

DL ou ECACK duppliqué

Set state to Départ Lent


DébitTCPQuel est le débit moyen TCP en fonction de la taille de fenêtre et RTT?

On Ignore le départ lent

Soit W la taille de la fenêtre quand il y a perte.

Quand la fenêtre a la taille W le débit est W/RTTQuand la fenêtre a la taille W, le débit est W/RTT

Juste après la perte, la fenêtre passe à W/2 et le débit passe à / à W/2RTT.

W0.75moyenDébit ×= RTTW0.75moyenDébit =


Equité TCP

Objectif de l’équité: Si K sessions TCP partage la même liaison j f q p g m m( responsable d’un goulet d’étranglement) de débit R, alors chaqu’une doit avoir un débit moyen de R/K

Connexion TCP 1

Routeur encombréde capacité R

Connexion TCP 2Connexion TCP 2


Comment est implémenté l’equité TCP?CP?

Deux sessions compétitives:pAcroissement additif ajoute 1 MSS à la fenêtre et le débit croît avecDécroissance multiplicatif décroit le débit proportionellement

R Partage équitable du débit

E i d i A i ddi ifperte: fenêtre CongWin/2

Evitement de congestion: Accroissement additif

perte: fenêtre CongWin/2Evitement de congestion: Accroissement additif

RDébit C nn ti n 1

additif


RDébit Connection 1

Documents

Chapter3-Protocoles de Transporthdhili.weebly.com/uploads/9/8/9/6/9896432/chapter3-protocoles_de... · Chapitre 3 Protocoles de transport de llInternet’Internet Dr. M. Jarraya,