Vous êtes sur la page 1sur 101

Cours Réseaux

Chapitre 3
Couche Transport

Université de Perpignan

Ouvrage de référence: Analyse Structurée des Réseaux, J. Kurose & K. Ross, Pearson Education, 2002
Chapitre 3: Couche Transport

Nos objectifs: 
Apprendre les protocoles de

Comprendre les principes la couche transport d'internet:
derrière les services de la ●
UDP: transport sans connexion
couche transport: ●
TCP: transport orienté

multiplexage/démultiplexage connexion

transfert de donnée fiable ●
contrôle de congestion de TCP

Contrôle de flux

Contrôle de congestion

2
Chapitre 3: Plan


3.1 Services de la couche 
3.5 Transport orienté
transport connexion: TCP

3.2 Multiplexage et

Structure des segments
démultiplexage

Transfert de données fiable

Controle de flux

3.3 Transport sans ●
Gestion de la connexion
connexion: UDP

3.6 contrôle de congestion

3.4 Principe du transfert ●
Principe
de données fiable

Controle de congestion
de TCP

3.7 Performance de TCP

3
Services et protocoles de la
couche Transport

La couche transport fournit une
communication logique entre
applicatio
processus tournant sur différents

Tr
n

an
transport
terminaux

sp
réseau réseau

or
liaison

Les protocoles de transport s'exécutent liaison

t
physique réseau physique

de
liaison
sur les terminaux :

bo
physique

ut
réseau

Coté expéditeur: il découpe les liaison

en
physique réseau
messages des processus en

bo
liaison

ut
physique
segments, et les passe à la couche

de
réseau
réseau liaison

ty
physique

pe

Cote destinataire: il réassemble les

lo
gi
applicatio
messages à partir des segments et

qu
n

les fait passer à la couche transport

e
réseau
application liaison
physique

Plus d'un protocole de transport
disponible :

Internet: TCP et UDP 4
Transport vs. Couche réseau


Couche réseau: Analogie foyer:
communication logique 12 enfants envoient des
entre terminaux lettres a 12 autres enfants

Couche transport: 
processus = enfant
communication logique 
messages des app =
entre processus lettres dans des

Est liée à la couche réseau enveloppes
et étend les services de
cette couche réseau

terminaux = maisons

protocole = Ann et Bill

Protocole de la couche
réseau = service postal

5
La couche transport : Introduction

Deux grands protocoles de


transport :
 UDP (User Datagram Protocol) : applicatio

Tr
n
non fiable

an
 transport

sp
réseau
 sans connexion réseau

or
liaison liaison

t
physique réseau
TCP (Transmission Control physique

de
 liaison

bo
physique
Protocol) :

ut
réseau
liaison
fiable (contrôle de flux, de

en
 physique réseau

bo
liaison
congestion, numéro de

ut
physique

séquence, accusés de

de
réseau
liaison

ty
réception) physique

pe
Convertit le service du protocole

lo

gi
applicatio

qu
IP (service non fiable de la n
transport

e
couche réseau) en un service réseau
liaison

fiable physique
Chapitre 3: Plan


3.1 Services de la couche 
3.5 Transport orienté
transport connexion: TCP

3.2 Multiplexage et ●
Structure des segments
démultiplexage ●
Transfert de données fiable

3.3 transport sans

Controle de flux
connexion: UDP

Gestion de la connexion

3.4 Principe du transfert

3.6 contrôle de congestion
de donnee fiable

Principe

Controle de congestion
de TCP

3.7 Performance de TCP

7
Multiplexage/démultiplexage

Démultiplexage sur le terminal dest.: Multiplexage sur le terminal exp.:


Délivre le segment à la socket Rassemble les données provenant
correspondant au processus de multiple sockets, enveloppant
destinataire les données dans une entête
(utilisées plus tard pour le
= socket = processus
demultiplexage)

P3 P1
P1 P2 P4 application
application application

transport transport transport

reseau reseau reseau

liaison liaison liaison

physique physique physique

term 3
term 1 term 2
8
Comment ca marche le démultiplexage


Le terminal reçoit des datagrammes IP 32 bits

Chaque datagramme a une adresse
Numéro
IP source et une adresse IP de de port source
Numéro de port destination

destination

Chaque datagramme contient 1 Autres champs d'en-tête
segment de la couche transport

Chaque segment a un numéro de
port source et un numéro de port de
destination Données d'application
(message)

Le terminal utilise l'adresse IP et le
numéro de port pour diriger le segment
vers la socket appropriée
Format d'un segment TCP/UDP

9
Démultiplexage UDP (sans connexion)


Crée des sockets avec un 
Quand un terminal reçoit un
numéro de port: segment UDP, Il
DatagramSocket mySocket1 = new ●
vérifie le port de destination
DatagramSocket(12534); port dans les segments
DatagramSocket mySocket2 = new ●
dirige les segments UDP
DatagramSocket(12535);
vers la socket avec ce

Une socket UDP est identifiée numéro de port
par: 
Des datagrammes IP avec
(adresse IP de dest., numéro de port des adresses IP sources et
de dest.) des numéros de port sources
identiques sont redirigés vers
la même socket

10
Démultiplexage UDP (cont.)

DatagramSocket serverSocket = new DatagramSocket(6428);

P2 P1
P1
P3

SP: 6428 SP: 6428


DP: 9157 DP: 5775

SP: 9157 SP: 5775


client DP: 6428 DP: 6428 Client
serveur
IP: A IP:B
IP: C

SP fournit “adresse de retour”


11
Démultiplexage TCP (orienté
connexion)

Socket TCP identifiée par 
Un processus du terminal peut
un quadruplet: supporter de nombreuse

Adresse IP source socket TCP simultanément:

Numéro de port source ●
chaque socket est identifiée par

Adresse IP de dest. son propre 4-tuple

Numéro de port de dest. 
Les serveurs web ont des

Le terminal destinataire sockets différentes pour
utilise les quatre valeurs chaque connexion client
pour diriger le segment à la ●
Une connexion HTTP non
socket appropriée persistante aura différentes
sockets pour chaque requête

12
Démultiplexage orienté
connexion (cont.)

P1 P4 P5 P6 P2 P1P3

SP: 5775
DP: 80
S-IP: B
D-IP:C

SP: 9157 SP: 9157


client DP: 80 DP: 80 client
serveur
IP: A S-IP: A S-IP: B IP:B
IP: C
D-IP:C D-IP:C

13
Démultiplexage orienté
connexion: Web serveur threadé

P1 P4 P2 P1P3

SP: 5775
DP: 80
S-IP: B
D-IP:C

SP: 9157 SP: 9157


client DP: 80 DP: 80 Client
serveur
IP: A S-IP: A S-IP: B IP:B
IP: C
D-IP:C D-IP:C

14
Chapitre 3: Plan


3.1 Services de la couche 
3.5 Transport orienté
transport connexion: TCP

3.2 Multiplexage et ●
Structure des segments
démultiplexage ●
Transfert de données fiable

3.3 Transport sans

Controle de flux
connexion: UDP

Gestion de la connexion

3.4 Principe du transfert

3.6 contrôle de congestion
de données fiable

Principe

Controle de congestion
de TCP

3.7 Performance de TCP

15
UDP: User Datagram Protocol [RFC 768]


Protocole de transport Internet
“sans fioritures” Pourquoi utiliser UDP?

Service “au meilleur effort”, les 
Pas d'établissement de
segments UDP peuvent être: connexion (qui peut ajouter du

perdu délai)

Délivrés en désordre à 
simple: pas de données à
l'application destinataire maintenir concernant la

Sans connexion: connexion (côte expéditeur et
destinataire)

pas de “poignée de mains” ou
“présentation” entre expéditeur

Léger: petite entête
et destinataire UDP 
Pas de contrôle de congestion:

Chaque segment UDP est géré UDP peut envoyer des données
indépendement des autres. aussi rapidement qu'on le
souhaite

16
UDP: cont.


UDP est souvent utilisé par les
applications multimédias utilisant 32 bits
du streaming
Longueur en Port source # Port de dest#

Tolérant aux pertes
octets length checksum

Sensible au taux de d'un segment
transmission UDP

D'autres utilisations d'UDP incluant
l'entête
dans Donnée de

DNS l'application

SNMP (message)

Transfert basé sur UDP: gestion
de la fiabilité au niveau de la
couche application

Recouvrement d'erreur Format de segment UDP
spécifique à l'application !
17
La somme de contrôle
(checksum) d'UDP
Objectif: détecter des “erreurs” (e.g., bits erronés)
dans la transmission d'un segment

Expéditeur: Destinataire:

Traite le contenu des

Calcule la somme de contrôle du
segment reçu
segments comme une suite
d'entiers codés sur 16-bit

Vérifie si la somme de contrôle
calculée est égale à la valeur stockée

checksum: addition avec dans le champs “checksum”:
complément à 1 du contenu ●
NON - erreur détectée
du segment ●
OUI – pas d'erreur détectée. Mais

L'expéditeur met la somme de peut contenir des erreurs tout de
contrôle (checksum) dans le même? On verra ça plus tard ….
champs “checksum” de
l'entête UDP

18
La somme de contrôle d'UDP

Expéditeur Destinataire

0110011001100110
0110011001100110
+ 0101010101010101
+ 0101010101010101
+ 0000111100001111
+ 0000111100001111
= 1100101011001010
= 1100101011001010
+ 0011010100110101
0011010100110101
(complément à 1) = 1111111111111111
(<=Ok)

= 1111111101111111
(<=Erreur)

 Remarque: les additions sont faites modulo 2^16


Chapitre 3: Plan

3.1 Services de la couche 
3.5 Transport orienté
transport connexion: TCP

3.2 Multiplexage et ●
Structure des segments
démultiplexing ●
Transfert de données fiable

Controle de flux

3.3 Transport sans

Gestion de la connexion
connexion: UDP

3.4 Principe du transfert

3.6 contrôle de congestion
de données fiable

Principe

Controle de congestion
de TCP

3.7 Performance de TCP

20
Principes du transfert de données fiable

Aspect important des couches application, transport et liaison.

top-10 des sujets important concernant les réseaux!


Caractéristique d'un canal non fiable déterminera la
complexité du transfert de données fiable. 21

(rdt= reliable data transfert)


Principes du transfert de données fiable

Aspect important des couches application, transport et liaison.

top-10 des sujets important concernant les reseaux!


Caractéristique d'un canal non fiable déterminera la
complexité du transfert de données fiable. 22

(rdt= reliable data transfert)


Principes du transfert de données fiable

Aspect important des couches application, transport et liaison.

top-10 des sujets important concernant les réseaux!


Caractéristique d'un canal non fiable déterminera la
complexité du transfert de données fiable. 23

(rdt= reliable data transfert)


Reliable data transfer: premier pas

rdt_send(): appel par le haut, (e.g., deliver_data(): appelé par


par l'appli.). Récupère les données rdt pour délivrer les données
provenant de la couche supérieure à la couche supérieure
pour les envoyer au destinataire

pôle pôle
expéditeur destinataire

udt_send(): appellé par rdt, rdt_rcv(): appelle lorsqu'un


pour transférer un paquet sur paquet est reçu du
un canal non sûr au côté destinataire
destinataire 24
Transfert de données fiable: premier pas

Nous allons:

Nous allons développer pas a pas les pôles expéditeur et
destinataire d'un transfert de données fiable (rdt)

Considérons seulement un transfert de données unidirectionnel

Mais les informations de contrôle navigueront dans les deux
directions!

On modélisera le rdt via machine à état fini (FSM=Finite State
Machine) pour l'expéditeur et le destinateur

événement provoquant un changement d'état


État: lorsque l'on est Actions réalisées lors du changement d'état
dans cet “état” le
prochain état est état état
déterminé 1 événement
2
uniquement par le actions
prochain événement
25
Rdt1.0: transfert fiable à travers un canal fiable


Le canal de transmission est parfaitement fiable

Pas d'erreurs sur les bits lors de la transmission

Pas de perte de paquet

Séparer FSMs pour l'expéditeur et destinataire:

L'expéditeur envoie des données dans le canal

Le destinataire lit les données sortant du canal

Attend un Attend un
rdt_send(data) appel de la rdt_rcv(packet)
appel de la
couche couche extract (packet,data)
packet = make_pkt(data) inférieure deliver_data(data)
supérieure
udt_send(packet)

Expéditeur Destinataire
26
Rdt2.0: canal avec des erreurs

Le canal de transmission peut modifier certains bits dans les
paquets

checksum pour détecter des erreurs eventuelles

LA question: comment recupérer des paquets erronés:

Accusé de réception/validité (Note ACKs=acknowledgements (): le
destinataire dit explicitement à l'expéditeur que le paquet reçu était correct

Accusé de réception négatif, d'invalidité (NAKs): le destinataire dit
explicitement à l'expéditeur que le paquet contenait des erreurs

L'expéditeur retransmet pkt (=paquet) lors d'une réception d'un NAK

Nouveau mécanisme dans rdt2.0 (au delà de rdt1.0):

détection d'erreur

Le destinataire répond par des messages de contrôle (ACK,NAK)
expéditeur->destinaire

27
Rdt2.0: canal avec des erreurs

Le canal de transmission peut modifier certains bits dans les
paquets

checksum pour détecter des erreurs éventuelles

LA question: comment récupérer des paquets erronés:

Accusé de réception/validité (Note ACKs=acknowledgements (): le
destinataire dit explicitement à l'expéditeur que le paquet reçu était correct

Accusé de réception négatif, d'invalidité (NAKs): le destinataire dit
explicitement à l'expéditeur que le paquet contenait des erreurs

L'expéditeur retransmet pkt (=paquet) lors d'une réception d'un NAK

Nouveau mécanisme dans rdt2.0 (au delà de rdt1.0):

détection d'erreur

Le destinataire répond par des messages de contrôle (ACK,NAK)
expéditeur->destinaire

28
rdt2.0: spécification du FSM

rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
destinataire
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Attend un Attend un rdt_rcv(rcvpkt) &&
appel du ACK ou corrupt(rcvpkt)
udt_send(sndpkt)
haut NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)


Attend un
Λ appel du
dessous
expéditeur
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

29
rdt2.0: exemple de déroulement (1/10)
rdt_send(data)
Exp. Dest.
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Attend un Attend un isNAK(rcvpkt)
Exp. appel du ACK ou
NAK udt_send(sndpkt)
haut

rdt_rcv(rcvpkt) && isACK(rcvpkt)


Λ

Dest.
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt) rdt_rcv(rcvpkt) &&
Attend un corrupt(rcvpkt)
appel du
extract(rcvpkt,data) dessous udt_send(NAK)
deliver_data(data) 30
udt_send(ACK)
rdt2.0: exemple de déroulement (2/10)
rdt_send(data)
Exp. Dest.
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
Données
rdt_rcv(rcvpkt) && provenant
Attend un Attend un isNAK(rcvpkt) de l'app
Exp. appel du ACK ou
NAK udt_send(sndpkt)
haut

rdt_rcv(rcvpkt) && isACK(rcvpkt)


Λ

Dest.
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt) rdt_rcv(rcvpkt) &&
Attend un corrupt(rcvpkt)
appel du
extract(rcvpkt,data) dessous udt_send(NAK)
deliver_data(data) 31
udt_send(ACK)
rdt2.0: exemple de déroulement (3/10)
rdt_send(data)
Exp. Dest.
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
Données
rdt_rcv(rcvpkt) && provenant
Attend un Attend un isNAK(rcvpkt) de l'app
Exp. appel du ACK ou
NAK udt_send(sndpkt)
haut

rdt_rcv(rcvpkt) && isACK(rcvpkt)


Λ

Dest.
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt) rdt_rcv(rcvpkt) &&
Attend un corrupt(rcvpkt)
appel du
extract(rcvpkt,data) dessous udt_send(NAK)
deliver_data(data) 32
udt_send(ACK)
rdt2.0: exemple de déroulement (4/10)
rdt_send(data)
Exp. Dest.
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
Données
rdt_rcv(rcvpkt) && provenant
Attend un Attend un isNAK(rcvpkt) de l'app
Exp. appel du ACK ou
NAK udt_send(sndpkt) données
haut correctes
envoie
ACK
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Λ

Dest.
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt) rdt_rcv(rcvpkt) &&
Attend un corrupt(rcvpkt)
appel du
extract(rcvpkt,data) dessous udt_send(NAK)
deliver_data(data) 33
udt_send(ACK)
rdt2.0: exemple de déroulement (5/10)
rdt_send(data)
Exp. Dest.
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
Données
rdt_rcv(rcvpkt) && provenant
Attend un Attend un isNAK(rcvpkt) de l'app
Exp. appel du ACK ou
NAK udt_send(sndpkt) données
haut correctes
envoie
ACK
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Λ

Dest.
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt) rdt_rcv(rcvpkt) &&
Attend un corrupt(rcvpkt)
appel du
extract(rcvpkt,data) dessous udt_send(NAK)
deliver_data(data) 34
udt_send(ACK)
rdt2.0: exemple de déroulement (6/10)
rdt_send(data)
Exp. Dest.
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
Données
rdt_rcv(rcvpkt) && provenant
Attend un Attend un isNAK(rcvpkt) de l'app
Exp. appel du ACK ou
NAK udt_send(sndpkt) données
haut correctes
envoie
ACK
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Λ Attend un appel du
haut

Dest.
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt) rdt_rcv(rcvpkt) &&
Attend un corrupt(rcvpkt)
appel du
extract(rcvpkt,data) dessous udt_send(NAK)
deliver_data(data) 35
udt_send(ACK)
rdt2.0: exemple de déroulement (7/10)
rdt_send(data)
Exp. Dest.
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
Données
rdt_rcv(rcvpkt) && provenant
Attend un Attend un isNAK(rcvpkt) de l'app
Exp. appel du ACK ou
NAK udt_send(sndpkt) données
haut correctes
envoie
ACK
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Λ Attend un appel du haut

Dest. corrompu
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt) rdt_rcv(rcvpkt) &&
Attend un corrupt(rcvpkt)
appel du
extract(rcvpkt,data) dessous udt_send(NAK)
deliver_data(data) 36
udt_send(ACK)
rdt2.0: exemple de déroulement (8/10)
rdt_send(data)
Exp. Dest.
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
Données
rdt_rcv(rcvpkt) && provenant
Attend un Attend un isNAK(rcvpkt) de l'app
Exp. appel du ACK ou
NAK udt_send(sndpkt) données
haut correctes
envoie
ACK
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Λ Attend un appel du haut

Dest. corrompu
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt) rdt_rcv(rcvpkt) &&
Attend un corrupt(rcvpkt)
appel du
extract(rcvpkt,data) dessous udt_send(NAK)
deliver_data(data) 37
udt_send(ACK)
rdt2.0: exemple de déroulement (9/10)
rdt_send(data)
Exp. Dest.
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
Données
rdt_rcv(rcvpkt) && provenant
Attend un Attend un isNAK(rcvpkt) de l'app
Exp. appel du ACK ou
NAK udt_send(sndpkt) données
haut correctes
envoie
ACK
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Λ Attend un appel du haut

Dest. corrompu
Attend ACK ou NAK données
incorrect
rdt_rcv(rcvpkt) && envoie
notcorrupt(rcvpkt) rdt_rcv(rcvpkt) &&
Attend un NAK
corrupt(rcvpkt)
appel du
extract(rcvpkt,data) dessous udt_send(NAK)
deliver_data(data) 38
udt_send(ACK)
rdt2.0: exemple de déroulement (10/10)
rdt_send(data)
Exp. Dest.
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
Données
rdt_rcv(rcvpkt) && provenant
Attend un Attend un isNAK(rcvpkt) de l'app
Exp. appel du ACK ou
NAK udt_send(sndpk) données
haut correctes
envoie
ACK
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Λ Attend un appel du haut

Dest. corrompu
Attend ACK ou NAK données
incorrecte
rdt_rcv(rcvpkt) && envoie
notcorrupt(rcvpkt) rdt_rcv(rcvpkt) &&
Attend un NAK
corrupt(rcvpkt)
appel du
extract(rcvpkt,data) dessous udt_send(NAK)
deliver_data(data) 39
udt_send(ACK) Attend ACK ou NAK
rdt2.0 a une faille fatale!

Que se passe-t-il si Gérer les duplicatas:


ACK/NAK est corrompu? 
L'expéditeur retransmet le paquet

L'expéditeur ne sait pas ce qu'il courant si ACK/NAK abîmer
s'est passé au pôle 
L'expéditeur ajoute un numéro de
destinataire! séquence pour chaque paquet

Ne peut pas retransmettre: car 
Le destinataire rejette (ne délivre pas
ce la produirait un possible au dessus) des paquets dupliqués
duplicata

« stop and wait »


L'expéditeur envoie un paquet,
puis attend une réponse
du destinataire

40
rdt2.1: expéditeur, gestion des ACK/NAKs
abîmés
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Attend un isNAK(rcvpkt) )
Attend un
ACK ou un
appel 0 du
haut NAK 0 udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)
Λ
Λ
Attend un Attend un
ACK ou un appel 1 du
rdt_rcv(rcvpkt) && NAK 1 haut
( corrupt(rcvpkt) ||
isNAK(rcvpkt) ) rdt_send(data)

udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)


udt_send(sndpkt)

41
rdt2.1: destinataire, gestion des ACK/NAKs
corrompus
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
Attend un Attend un
rdt_rcv(rcvpkt) && pkt 0 de pkt 1 de rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && dessous dessous not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)

sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)


udt_send(sndpkt) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
42
rdt2.1: discussion

Expéditeur: Destinataire:

Seq. # ajouter au pkt 
Doit vérifier si le paquet est

Deux numéros de séquence dupliqué
(0,1) suffisent. Pourquoi? ●
Etat indique si un pkt 0 ou 1
est attendu

Doit vérifier si le ACK/NAK
est corrompu

note: destinataire ne peut pas
savoir si sont dernière

Deux fois plus d'état
ACK/NAK a été reçu

Etat doit “se souvenir” si le
correctement par l'expéditeur
pkt courant a un seq #
valant 0 ou 1

43
rdt2.2: un protocole sans NAK


Même fonctionnalité que rdt2.1, mais n'utilise que des ACKs


A la place d'un NAK, le destinataire envoie un ACK pour le
dernier pkt reçu sans erreur

Le destinataire doit explicitement inclure un numéro de seq # du pkt
qui a été ACKé


Des ACK dupliqués arrivant à l'expéditeur provoque une même
action qu'un NAK: retransmission du paquet courant

44
rdt2.2: Expéditeur, Destinataire (partiel)
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Attend pour Attent un
isACK(rcvpkt,1) )
un appel 0 ACK
du haut 0 udt_send(sndpkt)
Partie du FSM
expéditeur rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) || Λ
has_seq1(rcvpkt)) Attend un Partie du FSM

pkt 0 du
udt_send(sndpkt) dessous destinataire

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)


&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum) 45
udt_send(sndpkt)
rdt3.0: Cannaux avec erreur et pertes

Nouvelle hypothèse : Le canal Approche adoptée: l'expéditeur


de transmission peut aussi attend durant un temps
perdre des paquets (données “raisonnable” l'ACK attendu
ou ACKs)

Il le retransmet si aucun ACK n'est
reçu durant cette période

checksum, seq. #, ACKs,
retransmissions sera

Si le pkt (ou ACK) est juste retardé
nécessaire, mais pas suffisante (mais pas perdu):

La retransmission sera
dupliquée, mais l'utilisation de
numéro de sequence déjà permet
de remédier à ca

Le destinataire doit spécifier le
numéro de séquence d'un paquet
ayant été ACKé

Nécessite un chronomètre
46
rdt3.0 expéditeur
rdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
start_timer
rdt_rcv(rcvpkt) Λ
Λ Attend un Attend
un timeout
appel 0 du
haut ACK0 udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer
stop_timer
Attend Attend un
timeout un appel 1 du
udt_send(sndpkt) ACK1 haut
start_timer rdt_rcv(rcvpkt)

rdt_send(data) Λ
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt)
start_timer
Λ

47
rdt3.0 en action

48
rdt3.0 en action

49
Performance de rdt3.0


rdt3.0 fonctionne, mais sa performance est minable

exemple: une liaison a 1 Gbps , 15 ms de délai de propagation,
paquet de 1KB:

T L (long en bits du pkt) 8kb/pkt


transm
= = = 8 microsec
R (taux de transmission, bps) 10**9 b/sec

 Uexp: utilisation – fraction du temps ou l'expéditeur est occupé à


envoyer
L/ R .008
U = = = 0.00027
sender 30.008
RTT +L / R microsec
onds
 1KB pkt chaque 30 msec -> 33kB/sec
de débit sur un lien a 1 Gbps
 Protocole réseau réduit l'utilisation des
ressources physiques! 50
Fonctionnement de rdt3.0

expéditeur destinataire

les 1er bit du paquet envoyé, t = 0


les derniers bit du paquet envoyé, t = L / R

les 1er bits du paquet arrivent


RTT

ACK arrive, envoie du prochain


paquet, t = RTT + L / R

L/ R .008
U = = = 0.00027
sender 30.008
RTT +L / R microsec
onds
Protocole pipeliné
Pipeline: l'expéditeur permet l'envoie multiple de paquets en
instance d'accusé de réception :

L'espace des numéro de séquence doit être augmenté

La mise en tampon au niveau expéditeur et du receveur


Deux formes génériques des protocoles pipelinés: go-Back-N,
répétition sélective
52
Pipeline: utilisation amélioré
expéditeur destinataire

premier bit du paquet


transmis, t = 0
dernier bit transmis, t = L / R

Premier bit du paquet arrive


RTT Dernier bit du paquet arrive, envoie de l' ACK
Dernier bit du 2nd paquet arrive, ACK envoyé
dernier bit du 3e paquet arrive, ACK envoyé
ACK arrive, envoie du
prochain paquet,
t = RTT + L / R

Améliore l'utilisation
par un facteur 3!

3*L/ R .024
U = = = 0.0008
sender 30.008
RTT +L / R microsecon
ds 53
Go-Back-N

Sender:

numéro de séquence sur K-bit dans l'entête du paquet

“fenêtre” jusqu'a N, paquets non acquités simultanés

 ACK(n): accuse reception de tous les paquets jusqu'au numéro n


(On parle alors d'“ACK cumulatif”)
 Peut recevoir des ACKs dupliqués (cf. destinataire)
 Minuterie (ou timer) pour chaque paquet envoyé
 timeout(n): retransmet le paquet n et ceux de plus grand numéro de
54
séquence # pkts dans la fenêtre
GBN: FSM étendu de l'expéditeur
rdt_send(data)

if (nextseqnum < base+N) {


sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum])
if (base == nextseqnum)
start_timer
nextseqnum++
}
else
Λ refuse_data(data)
base=1
nextseqnum=1
timeout
start_timer
Attente udt_send(sndpkt[base])
udt_send(sndpkt[base+1])
rdt_rcv(rcvpkt)

&& corrupt(rcvpkt)
udt_send(sndpkt[nextseqnum-1])

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
base = getacknum(rcvpkt)+1
If (base == nextseqnum)
stop_timer
else
start_timer 55
GBN: FSM étendu du destinataire
default
udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcurrupt(rcvpkt)
Λ && hasseqnum(rcvpkt,expectedseqnum)

expectedseqnum=1 Attente extract(rcvpkt,data)


sndpkt = deliver_data(data)
make_pkt(expectedseqnum,ACK,chksum) sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
expectedseqnum++

ACK-seulement: envoie toujours ACK pour des paquets


correctement reçu avec le plus haut # seq dans-ordre

peut génère des ACKs dupliqués

Ont besoin seulement de mémorise expectedseqnum

Paquet hors-séquence:

rejeter (ne pas mettre en tampon) -> pas de tampon utilisateur!

Re-ACK paquet avec le plus haut seq # en séquence
56
GBN en action

57
Répétition Sélective


Le destinataire accuse réception individuellement tous les
paquets recus correctement

Paquets dans le tampon, au besoin, au final pourra être délivré
en-séquence à la couche supérieure

L'expéditeur ré-envoie seulement les paquets avec un
ACK non reçu

expéditeur lance un timer pour chaque paquet non acquité

Fenêtre de l'expéditeur

N numéro de seq. consécutifs

Limite encore les numéro de seq. des paquets envoyés mais non
acquités

58
Répétition sélective: fenêtre de l'expéditeur et
du destinataire

59
Répetition sélective
expéditeur destinataire
data from above : pkt n dans [rcvbase, rcvbase+N-1]

Si il y a un numéro de seq.  envoyer ACK(n)
disponible dans la fenêtre send  Hors séquence: mise en
pkt tampon
timeout(n):  en-séquence: délivrer (aussi

renvoyer pkt n, relancer le délivrer les paquet du tampon
minuteur en-séquence), avancer la
fenêtre jusqu'au prochain
ACK(n) dans [sendbase,sendbase+N]: paquet non acquité

marquer pkt n comme reçu

si n est le paquet de plus petit
pkt n dans [rcvbase-N,rcvbase-1]

numéro, avancer la base de la  ACK(n)


fenêtre jusqu'au prochain otherwise:
numéro de paquet non-acquité  ignorer

60
Répétition sélective en action

61
Répétition sélective:
dilemme

Exemple:

seq #’s: 0, 1, 2, 3

Taille de la fenêtre=3


Le destinataire voit
aucune différence dans
deux scénarios!

Des données dupliquées
passent pour nouvelles
dans (a)

Q: Quel relation y a-t-il entre


seq # size et la taille de la
fenêtre?

62
Chapitre 3: Plan


3.1 Services de la couche 
3.5 Transport orienté
transport connexion: TCP

3.2 Multiplexge and

Structure des segments
démultiplexage

Transfert de données fiable

Controle de flux

3.3 Transport sans ●
Gestion de la connexion
connexion: UDP

3.6 contrôle de congestion

3.4 Principe du transfert ●
Principe
de données fiable

Controle de congestion
de TCP

3.7 Performance de TCP

63
TCP: Vue générale RFCs: 793, 1122, 1323, 2018, 2581


point-à-point: 
Donnée en mode duplex:

Un expéditeur, un destinataire ●
Flux de données
bi-directionel dans la même

fiable, en séquence flux connexion
d'octet (byte stream): ●
MSS: maximum segment size

Pas de “message boundaries” 
orienté-connexion:

pipeliné: ●
Poignée de main (échange

Le contrôle de congestion et de msgs de contrôle) initalise
du flux fixe une taille de les données d'état
fenêtre expéditeur, destinataire
avant l'échange de données

Tampon d'envoi & réception
a p p lic a t io n a p p lic a t io n

Contrôle de flux:
w r it e s d a t a re a d s d a ta
socket socket

L'expéditeur ne va pas
door
TCP TCP
door inonder le destinataire
s e n d b u ffe r r e c e iv e b u f f e r
segm ent 64
Structure du segment TCP
32 bits
URG: donnée urgente compteur
(generalement inutilisé) source port # dest port #
par octet
Numéro de séq. de données
ACK: ACK #
(pas de segments!)
valide Numéro acquité
head not
PSH: pousser les len used U A P R S F Fenêtre de récept.
données maintenant # octets
Som. ctrl Urg data pnter accepeté par
(generallement inutilisé)
le
RST, SYN, FIN: Options (de longueur variable)
destinataire
gestion de la connexion
(etablissement, terminaison
commandes)
Donnée
application
somme de (longueur variable)
contrôle
Internet
(comme dans UDP)
65
Chapitre 3: Plan

3.1 Services de la couche 
3.5 Transport orienté
transport connexion: TCP

3.2 Multiplexage and ●
Structure des segments
demultiplexage ●
Transfert de données fiable

3.3 Transport sans

Controle de flux
connexion: UDP

Gestion de la connexion

3.4 Principe du transfert

3.6 contrôle de congestion
de donnée fiable

Principe

Controle de congestion
de TCP

3.7 Performance de TCP

66
Transfert de données fiable de TCP


TCP crée un service transfert 
Les retransmissions sont
de données fiables (rdt) au déclanchés par:
dessus du service non fiable ●
timeout
d'IP ●
ACKs dupliqués

Les segments sont pipelinés 
On considère un expéditeur TCP

ACKs cumulatif simplifié:

TCP utilise une minuterie

ignore ACKs dupliqués
(timer) pour détecter les ●
ignore contrôle de flux et contrôle
pertes de congestion

67
Num. de seq. et ACKs TCP
Numéro de séquence:
Hote A Hote B

Fil de “numéro” d'octets
du premier octet dans les Appli envoit
Seq=4
données du segment ‘C’ 2, AC
K=79 , data
= ‘A’
ACKs: ACKs

Num. de seq. du prochain du
‘ B’ ‘B’ reçu
octet attendu 3, d ata =
K=4 renvoyé

ACK cumulatif (quitte tous q =79, AC
Se
octets de numéros de seq
inférieurs)
ACKs
Qu.: Comment le destinataire du ‘B’ reçu
envoyé
gère les segments
hors-séquence

Rep: TCP ne le spécifie
pas – c'est à la discrétion temps
du développeur Scénario simple
68
Evènement du côté expéditeur TCP:
Données reçues par l'app: timeout:

Créer un segment avec un N° 
Retransmettre le segment qui a
de seq causé le timeout

Le N° de seq est le numéro de 
Redémarrer la minuterie
séquence d'un fil d'octets du ACK reçus:
premier octet de donnée du
segment

S'il acquite des segments

Lancement de la minuterie précédement non acquité
(timer) si elle n'est pas déjà en

Mettre à jour ce que l'on sait
train de tourner (penser à la être acquité
minuterie pour le plus ancien ●
Démarrer le minuteur s'il reste
segment non acquité) des segments en suspens

intervalle d'expiration:
TimeOutInterval
69
TCP expéditeur(simplifié)
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum

loop (forever) {

switch(event)
event: data reçu de l'application de la couche supérieure
cree un segment TCP avec un numéro de séquence NextSeqNum Commentaire:
if (minuterie arretée) SendBase-1: dernier
demarer la minuterie
octet acquité
passer le segment à la couche IP
NextSeqNum = NextSeqNum + length(data) cumulativement
Exemple:
event: timeout de la minuterie SendBase-1 = 71;
retransmettre segment pas-encore-acquité avec y= 73, donc le dest.
le plus petit numéro de séquence veut 73+ ;
demarrer la minuterie y > SendBase, donc
cette nouvelle donnée
event: ACK reçu, avec le valeur du champs ACK de s'y satisfaisant
if (y > SendBase) {
est acquitée.
SendBase = y
if (il y a actuellement des segments pas-encore-acquités)

Demarrer la minuterie}
} /* fin de boucle forever */ 70
TCP: scénarios de retransmission

Hôte A Hôte B Hôte A Hôte B

Seq=9 Seq=9
2, 8 b 2, 8 b y te
y t es da s data
ta

Seq=92 timeout
Seq=
100,
20 by
tes d
timeout

at a

0
X =10
K 120
AC ACK=
perte
Seq=9 Seq=9
2, 8 b 2, 8 b
y te s d a Sendbase y te s d a
ta
ta = 100

Seq=92 timeout
SendBase
= 120 =12
0
K
=100 AC
AC K

SendBase
= 100 SendBase
= 120
Timeout prémature
temps
temps 71
scénario ACK perdu
TCP scénarios de retransmission (suite)

Hote A Hote B
timeout

Seq=1
00, 20
bytes
d ata
X
perte

SendBase
= 120

temps
scénario ACK accumulatif

72
TCP : émission d'un ACK [RFC 1122, RFC 2581]

Evènement chez destin.


Action TCP du dest.
Génération retardée de l'ACK:
Arrive d'un segment dans l'ordre avec attendre jusqu'a 500ms pour envoyer l'ACK.
un seq # attendu. Toutes les données Si aucun segment n'arrive durant ces 500ms
jusqu'à ce seq # ont été ACKée. alors envoyer l' ACK.
Envoyer immédiatemment d'un ACK cumulatif.
Arrivé d'un seqment dans l'ordre Accuse réception des deux segments arrivés
avec le N° de seq attendu. Un autre dans l'ordre (celui dont l'envoie de l'ACK est
segment a un ACK non encore envoyé. retardé + celui qui vient d'arriver).

Arrivé d'un segment dans Envoyer immédiatemment un


le désordre. D'un plus haut N° de seq ACK dupliqué indiquant le numéro de seq.
que celui attendu. Un écart est détecté. du prochain octet attendu

Arrivé d'un segment qui comble Envoyer immédiatemment


partiellement l'écart. un ACK, si le segment
augmente la valeur de base window
de l'expéditeur 73
Retransmission rapide


Hors-délai période souvent 
Si l'expéditeur reçoit 3 ACKs
relativement longue: pour la même donnée, cela

Un délai long avant le suppose que le segment
renvoie d'un paquet perdu après une donnée aquittée a

Segments perdu détectés par été perdue:
réception d'ACKs dupliqués. ●
retransmettre: réenvoyer un

L'expéditeur envoie souvent segment avant que le timeout
ne se produise.
beaucoup de segment
successivement.

Si un segment est perdu, il y
aura probablement
beaucoup d'ACKs dupliqués.

74
Algorithme de retransmission
rapide:

event: ACK recu, avec un champs ACK egal y


if (y > SendBase) {
SendBase = y
if (il y actuellement des segments pas ecore aquites)
start timer
}
else {
incrementer un compteur count d'ACK dupliques recu pour y
if (le compteur d'y = 3) {
reenvoyer le segment de numero de seq y
}

Un AC dupliqué pour des retransmission rapide


segments déjà acquitté

75
Aller-retour TCP: temps et Timeout

Q: Comment fixer la valeur Q: Comment estimer le RTT?


du timeout TCP ? 
SampleRTT: mesure le temps à

Plus grand que le RTT partir de la transmission d'un

mais le RTT varie... segment transmission jusqu'à la
réception d'un ACK

Trop court: timeout
prématuré

Ignorer la retransmission

Retransmissions inutiles

SampleRTT variera, on veut estimer
un RTT plus lisse

Trop long: lente réaction à ●
Moyenne pondérée sur plusieurs
une perte de paquet
mesures récentes, pas juste un
SampleRTT courant

76
Round Trip Time et Timeout de TCP

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

 Moyenne exponentielle pondérée


 L'influence des échantillons du passé
décroit exponentiellement rapidement
 valeur typique: α = 0.125

77
Aller retour TCP: temps et timeout

Calcul du timeout

EstimtedRTT plus une “marge de sécurite”

Grande variation de EstimatedRTT -> plus grande marge de
sécurité

D'abord estimer de combien SampleRTT dévie de EstimatedRTT:

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

(valeur typique: β = 0.25)

Ensuite fixe l'intervalle de timeout:


TimeoutInterval = EstimatedRTT + 4*DevRTT

78
Chapitre 3: Plan

3.1 Services de la couche 
3.5 Transport orienté
transport connexion: TCP

3.2 Multiplexage and

Structure des segments
demultiplexage

Transfert de données fiable

Controle de flux

3.3 Transport sans ●
Gestion de la connexion
connexion: UDP

3.6 contrôle de congestion

3.4 Principe du transfert ●
Principe
de donnée fiable

Controle de congestion
de TCP

3.7 Performance de TCP

79
Contrôle de flux de TCP
Control de flux
L'expéditeur ne va pas

Le coté destinateur de la surcharger le tampon
connexion TCP à un du destinataire
tampon mémoire de: en transmettant trop de
données et trop vite


Service d “adaptation de
la vitesse de trans.”: sert à
adapter la vitesse de
transmission à la rapidité
de lecture du processus.
 Le processus peut lire
lentement les données
dans la lecture des
données sur le tampon 80
Contrôle de flux de TCP: suite

Le destinataire avertit la
taille de l'espace libre en
includant la valeur de
RcvWindow dans les
segments
(Suppose que le destinataire TCP

L'expéditeur limite le
rejette les segments nombre de donnée non
hors-séquence) acquitée à RcvWindow

Guarantie que le tampon de

De l'espace libre dans le tampon réception ne déborde pas
= RcvWindow
= RcvBuffer-[LastByteRcvd -
LastByteRead]

81
Chapitre 3: Plan

3.1 Services de la couche 
3.5 Transport orienté
transport connexion: TCP

3.2 Multiplexage and ●
Structure des segments
demultiplexage ●
Transfert de données fiable

3.3 transport sans

Controle de flux
connexion: UDP

Gestion de la connexion

3.4 Principe du transfert

3.6 contrôle de congestion
de donnée fiable

Principe

Controle de congestion
de TCP

3.7 Performance de TCP

82
Gestion de la connexion TCP

Rappel: L'expéditeur TCP,


Poignée de main en trois
établit une “connexion” avant étapes:
l'échange de données
Etape 1: le client envoie un segment TCP

Initialisation de variables TCP: SYN au serveur

seq. # ●
spécifie le seq # initial du client

tanpons, info. de contrôle de ●
Ne contient pas de données
flux (e.g. RcvWindow)

Client: initiateur de connexion Etape 2: le serveur reçoit SYN, répond avec
un segment SYNACK
Socket clientSocket = new
Socket("hostname","port ●
Serveur alloué des tampons de
number"); mémoire

Serveur: contacté par le client ●
spécifie le seq. # initial du serveur
Socket connexionSocket = Etape 3: le client reçoit SYNACK, répond
welcomeSocket.accept(); avec un segment ACK segment, qui peut
contenir des données.
83
Gestion de la connexion TCP (suite)

Etape 3: le client reçoit FIN, répond


client server
avec un ACK.

Entre dans une phase “timed fermeture
FIN
wait” - répondra avec un ACK
pour des FINs reçus
ACK
fermeture
FIN
Etape 4: le serveur reçoit un ACK.
connexion fermée.

timed wait
ACK
Note: avec de petites modifications,
peut gérer des FINs simultanés. fermé

fermé

84
Gestion de la connexion TCP (suite)

Le cycle de vie
du seveur TCP

Le cycle de vie
du client TCP

85
Chapitre 3: Plan


3.1 Services de la couche 
3.5 Transport orienté
transport connexion: TCP

3.2 Multiplexage and ●
Structure des segments
demultiplexage ●
Transfert de données fiable

3.3 transport sans

Controle de flux
connexion: UDP

Gestion de la connexion

3.4 Principe du transfert

3.6 contrôle de congestion
de donnée fiable

Principe

Controle de congestion
de TCP

3.7 Performance de TCP

86
Principe du contrôle de congestion

Congestion:

informellement: “trop de sources qui envoient trop de
données trop vite pour que le réseau puisse les traiter ”

différent du controle de flux!

manifestations:

Perte de paquets (débordement de tampon au niveau
des routeurs)

Délais longs (les queues s'allongent dans les tampons
des routeurs)

87
Causes/coûts de la congestion: scénario 1

Host A
λout
λin : original

deux expéditeur, data
deux destinataires
tampon ilimité

un routeur, des Host B partage sur le
lien de sortie
tampons infinis

Pas de
retransmission


De très long délai
lors d'une
congestion

Transmission
maximum faisable
88
Causes/coûts de congestion: scénario 2


Un routeur, des tampons finis

L'expéditeur retransmet les paquets perdus

Hote A λin : donnee λout


originelle
λ'in : donnees originelles,
plus les donnees
retransmises
Hote B tampon limité
partage sur le
lien de sortie

89
Causes/coûts de congestion: scénario 2


toujours: λ = λout
(meilleurs cas)
in

Retransmission “parfaite” seulement lorsqu'il y a des pertes: λ > λ
in out

retransmission de paquets retardés (mais pas perdus) rend plus grande λ
in
(que dans le cas parfait) pour la même λ
out
R/2
R/2

R/3
λout

λout
R/2
λin R/2
λin

a.
b.
“Coûts” de la congestion:
 Plus de travail retransmission
 des retransmissions non nécessaires: le lien transporte de 90
nombreuses copies des paquets.
Méthodes de contrôle de la congestion

Deux approches répandues sont:

Control de congestion de Contrôle de congestion


bout en bout: assisté par le réseau:

Pas de retour direct du réseau 
Les routeurs fournissent des

congestion gérée par les hôtes informations aux hôtes
observant des pertes, des ●
simple bit indiquant la
retards congestion (SNA, DECbit,

approche utilisée dans TCP TCP/IP ECN, ATM)

Taux explicite auquel
l'expéditeur doit envoyer
ses données

Approche utilisée dans ATM

91
Contrôle de congestion de TCP:
accroissement additive, décroissance multiplicative
 Approche: augmenter le taux de transmission (taille de
la fenêtre), sondant la bande passante utilisable, jusqu'à
ce qu'une perte de paquet se produise
 Augmentation additive: acroît CongWin d'1 MSS après
chaque RTT jusqu'à détecter une perte
 Reduction multiplicative: réduit la CongWin de moitier
après une perte
c o n g e s tio n
w in d o w
congestion window size

2 4 K b y te s

Comportement en
Dent de scie 1 6 K b y te s

8 K b y te s

temps
tim e

92
Contrôle de congestion TCP : détails


L'expéditeur limite la transmission:
Comment l'expéditeur perçoit
LastByteSent-LastByteAcked la congestion ?
≤ CongWin 
Une perte = timeout ou 3

Plus grossièrememt, ACKs dupliqués

Expéditeur TCP réduit
CongWin
rate = Bytes/sec son taux (CongWin)
RTT
après la détection d'une
perte

CongWin est dynamique, dépent de
Trois mécanismes:
la congestion perçuue du réseau

AIMD

Départ lent

Conservatif après un
timeout
93
Départ lent de TCP

Lorsque une connexion  Lorsque la connexion


commence, CongWin = 1 MSS commence,

Exemple: MSS = 500 octets & accroissement
RTT = 200 msec exponentiel du taux

Taux initial = 20 kbps
jusqu'à la détection

Bande passante disponible
d'une perte
peut être >> MSS/RTT

Il est nécessaire d'accéder
rapidement à un taux de
transmission respectable

94
Départ lent de TCP (suite)


Lorsque la connexion Hote A Hote B
commence, accroissement
exponentielle du taux

RTT
jusqu'à la détection d'une
perte: deux segm
ents

double CongWin à chaque
RTT

Réalise en incrémentant quatre seg
ments
CongWin pour chaque ACK
reçu

Resumé: taux initial est
faible mais augmente de
façon exponentielle temps

95
Raffinement
Q: A partir de quand la
phase exponentielle doit
être remplacée par une
phase linéaire?
A: Lorsque CongWin arrive à
la moitier de sa valeur
avant le timeout.

Implémentation:

Variable Threshold (seuil)

Lorsqu'une perte se produit,
Threshold est fixé à la moitier
de lavaleur de CongWin avant
la détection de la perte
96
Raffinement: détection des pertes


Après 3 ACKs dupliqués:

CongWin est coupé en deux
Philosophie:

La fenêtre augmente alors linéairement

Mais après un timeout:
 3 ACKs dupliqués

CongWin est fixé à 1 MSS;

Le fenêtre augmente alors
indiquent que le reseau
exponentiellement est capable de

Jusqu'au seuil Threshold, ensuite transmettre certains
grossit linéairement segments
 timeout indique une
congestion “plus
alarmante”

97
Résumé:
contrôle de congestion de TCP


Lorsque CongWin est en dessous de Threshold,
l'expéditeur est en phase de départ-lent, la fenêtre
augmente exponentiellement.

Lorsque CongWin est au dessus de Threshold,
l'expéditeur est en phase d'évitement de congestion
augmente linéairement.

Lorsqu'un triple ACK dupliqué se produit, Threshold est
fixé a CongWin/2 et CongWin est fixé à Threshold.

Lorsqu'un timeout se produit, Threshold est fixé à
CongWin/2 et CongWin est fixé à 1 MSS.

98
Chapitre 3: Plan


3.1 Services de la couche 
3.5 Transport orienté
transport connexion: TCP

3.2 Multiplexage and ●
Structure des segments
demultiplexage ●
Transfert de données fiable

3.3 transport sans

Controle de flux
connexion: UDP

Gestion de la connexion

3.4 Principe du transfert

3.6 contrôle de congestion
de donnée fiable

Principe

Controle de congestion
de TCP

3.7 Performance de TCP

99
Taux de transmission TCP


Quel est le taux de transmission moyen de TCP en fonction de
la taille de la fenêtre et d'un RTT?

On ignore le “départ-lent”

Soit W la taille de la fenêtre lorsqu'une perte se produit (si le
réseau est stable cette valeur est toujours de même grandeur).

Lorsque la fenêtre vaut W, le taux de transmission est W/RTT

Juste après une perte, la taille de la fenêtre descend a W/2, et
le taux de transmission à W/2RTT.

Taux de transmission moyen est de: .75 W/RTT

100
Équité

 K connexions TCP partagent le même lien, chacune devraient avoir


1/K de ce lien
connexion TCP 1
 addition d'1 Unité
multiplication par 0.5
Débit de la connexion TCP2

R partage équitable du Routeur encombré


débit de capacité R
connexion TCP 2

Débit > R provoque une perte: divise la fenêtre par 2

 Faussée car par un navigateur


ouvrant plusieurs connexion
TCP pour une même page
R web
Débit de la connexion TCP1

Vous aimerez peut-être aussi