Transcript TCP - LIP6

les protocoles de transport
TCP et UDP
Transport Layer
1
PLAN
 Origines de TCP-IP
 Les protocoles de transport
 Fonctions
 Ports
 UDP
 TCP
 Éléments de base de TCP
 Fiabilité
 Fenêtres
 Reprise sur erreurs
 Algorithmes de contrôle de congestion
Transport Layer
2
Origine de TCP/IP
Transport Layer
3
TCP-IP: origine
 Commutation de paquets
 Approche « informatique » vs « télécom »
 Expérimentations de chercheurs
 Approche intégrée : des applications aux
outils techniques
 Approche de complémentarité par rapport
à l’existant
 Déploiement rapide
 Devient standard de fait
 Internet
 Le Web
Transport Layer
4
Interconnexion de réseaux
 Les réseaux




d'entreprise
Les passerelles
Les protocoles
Les adresses
Le monde TCP-IP
A
B
C
Réseau 1
Réseau 3
P1
Réseau 2
D
P2
Réseau 4
E
F
Transport Layer
G
5
Architecture TCP-IP
Machine A
Passerelle
Machine D
Applications
standards
Applications
standards
Transport
Transport
Protocole
IP
Protocole
d'accès à R1
Réseau R1
Protocole
IP
R1
R2
Protocole
IP
Protocole
d'accès à R2
RéseauTransport
R2 Layer
6
Rôle du transport
Transport Layer
7
Le principe du bout en bout
 Pas d’intelligence dans le réseau
Traitement simple dans le réseau -> haut débit
 Réseau généraliste -> évolution de l’utilisation
du réseau
 Pas de redondance de contrôle

 Séparation des fonctions
Contrôle -> hôte
 Acheminement -> routeur

Bout en bout
Hôte
Protocole
IP
Hôte
Routeur
Protocole
IP
Transport Layer
8
Services et protocoles de transport
 Fournissent une




communication logique entre
des processus applicatifs
s’exécutant sur des hôtes
différents
transport protocols run in
end systems
transport vs network layer
services:
network layer: data transfer
between end systems
transport layer: data
transfer between processes

application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
relies on, enhances, network
layer services
Transport Layer
9
Principe du bout en bout
 Service réseau

Modes d’acheminement
• Circuit virtuel
• Datagramme

Mode non connecté et sans garantie
 Robustesse
 Indépendance du fonctionnement
• Le fonctionnement du système d’extrémité n’est pas
lié à celui du réseau
Transport Layer
10
Fonction des protocoles de
transport
 Protocoles de bout en bout (pas comme à la
couche réseau par exemple)
 Service connecté ou non
 fiabilité
 performance
 Transport d’un message d’un émetteur au
récepteur

Indépendamment des réseaux qui véhiculent l’information
• Pas de connaissance sur les réseaux traversés
 « Interface » entre les applications et le réseau
 S’appuie sur des protocoles (des couches basses)
pour l’acheminement des données.
 Deux protocoles principaux :
 TCP : fiabilité, contrôle d’erreur, de flux,
d’ordre
Transport Layer
 UDP : Vérification des erreurs
11
Rôle du Transport
 Général



Communication inter-process
Identification des points d‘extrémités
Bout en bout
 A la demande de l'application



Contrôle des échanges
Corriger les défauts du service réseau
Compte rendu sur la performance de la
communication
 Construction du service attendu par les
applications distinct de celui fourni par la couche
réseau

Mode connecté fiable, sur un réseau datagramme
non fiable
 Séparation du service fourni par l’opérateur
et
Transport Layer
offert à l’utilisateur
12
Ports
 Pour identifier une cible plus spécifique que l’adresse IP car les
datagrammes sont destinés à des process et pas au système.


PID -> trop dynamique
par un point d’extrémité:
• le port
• n° de port sur 2 octets
 Ceci est réalisé avec les ports
 16-bits qui identifient quel process est associé à quel datagramme.
 Attachement du processus au port
 Identification: (@ IP, n° port)
 Deux types de ports :
 well-known : appartiennent aux serveurs standards
•
•
•
•

Numéro impair entre 1 et 1023
Utilisation d’un seul port sauf BOOTP (ports 67 et 68)
telnet utilise le port 23
Permettent aux clients de trouver des serveurs sans information de
configuration
ephemeral
• Les clients utilisent des ports spécifiés dans les paquets UDP
• Entre 1024 et 5000 habituellement
• <transport protocol, IP address, port number> doit être unique.
Transport Layer
13
Multiplexing/demultiplexing
Recall: segment - unit of data
exchanged between
transport layer entities
 aka TPDU: transport
protocol data unit
application-layer
data
segment
header
segment
Ht M
Hn segment
P1
M
application
transport
network
P3
Demultiplexing: delivering
received segments to
correct app layer processes
receiver
M
M
application
transport
network
P4
M
P2
application
transport
network
Transport Layer
14
Multiplexing/demultiplexing
Multiplexing:
gathering data from multiple
app processes, enveloping
data with header (later used
for demultiplexing)
multiplexing/demultiplexing:
 based on sender, receiver
port numbers, IP addresses
 source, dest port #s in
each segment
 recall: well-known port
numbers for specific
applications
32 bits
source port #
dest port #
other header fields
application
data
(message)
TCP/UDP segment format
Transport Layer
15
Multiplexing/demultiplexing: examples
host A
source port: x
dest. port: 23
server B
source port:23
dest. port: x
Source IP: C
Dest IP: B
source port: y
dest. port: 80
port use: simple telnet app
Web client
host A
Web client
host C
Source IP: A
Dest IP: B
source port: x
dest. port: 80
Source IP: C
Dest IP: B
source port: x
dest. port: 80
Web
server B
port use: Web server
Transport Layer
16
TSAP/NSAP
Host 1
Host 2
Application
TSAP n
La connexion transport
commence ici
La connexion réseau
commence ici
Couche transport
Couche réseau
Serveur
TSAP m
NSAP
Couche liaison
Couche physique
Transport Layer
17
Adressage TSAP
 Transport Service Access Point
 Identification des applications en
communication
 Ex : adresse IP + Port
 Scénario de connexion
 Serveur sur host2 associé au TSAP n
 Client sur host1 s’associe localement au TSAP m
(source) et demande le TSAP n sur host 2
(destination)
 Établissement de la connexion réseau entre la
source (host 1) et la destination (host 2)
 Demande d’établissement d’une connexion au
niveau transport entre TSAP n et TSAP m
Transport Layer
 Validation
18
Problèmes de transport
 Etablissement de connexion

Déséquencement
Etablissement en 3 étapes
entité de
transport B
entité de
transport
A
TPDU
demande de
connexion
Entité de
transport B
Entité de
transport A
TPDU
de données
TPDU
confirmation de
connexion
Transport Layer
19
Three Way handshake
 Etablissement d’une connexion
bidirectionnelle avec des numéros de
séquence indépendants
 Utilisation d’un échange de 3 TPDU
 CONNECTION_REQUEST
• Init. Envoie son numéro de séquence vers la
destination
• CONNECTION_ACCEPTED
– Acquittement et envoi de numéro de séquence
• DATA
– Init. Acquitte avec les premières données vers le
destinataire
Transport Layer
20
Problèmes de transport
 Perte

Temporisateur de retransmission
• Difficulté: dimensionnement
Transport Layer
21
Problèmes de transport
 Etablissement de connexion
Survivance
TPDU DT 0
TPDU AK 1
T1
TPDU DT 1
TPDU AK 2
établissement d'une
nouvelle connexion
TPDU DT 1
TPDU DT 0
TPDU AK 2
TPDU DT 1
TPDU AK 2
.
.
.
La TPDU DT 1 est reçue sans
erreur mais hors séquence
Elle est gardée en attente de
reséquencement
La TPDU DT 0 ayant été reçue,
l'acquittement peut se faire
La seconde TPDU DT 1 est
détectée comme dupliquée
Elle est écartée mais acquittée
Transport Layer
Duplication
Non Détéctée
fermeture de la connexion
Perte
Non Détéctée

A
B
ouverture d'une connexion
entre A et B
22
Etablissement d’une connexion :
bilan
 Envoi d’un CONNECTION_REQUEST
TPDU, avec possibilité de
Perte
 Mémorisation
 Duplication

 Eviter la duplication avec
 Génération d’un nouveau TSAP à chaque
connexion
 Utilisation d’identificateurs uniques de
connexion (état)
 Élimination des anciens (=TTL mais circulaire)
Transport Layer
23
Pipelined protocols
Pipelining: sender allows multiple, “in-flight”, yet-tobe-acknowledged pkts


range of sequence numbers must be increased
buffering at sender and/or receiver
 Two generic forms of pipelined protocols:
selective repeat
go-Back-N,
Transport Layer
24
Go-Back-N
Sender:
 k-bit seq # in pkt header
 “window” of up to N, consecutive unack’ed pkts allowed
 ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”
may deceive duplicate ACKs (see receiver)
 timer for each in-flight pkt
 timeout(n): retransmit pkt n and all higher seq # pkts in window

Transport Layer
25
GBN in
action
Transport Layer
26
Selective Repeat
 receiver
individually acknowledges all correctly
received pkts

buffers pkts, as needed, for eventual in-order delivery
to upper layer
 sender only resends pkts for which ACK not
received

sender timer for each unACKed pkt
 sender window
 N consecutive seq #’s
 again limits seq #s of sent, unACKed pkts
Transport Layer
27
Selective repeat: sender, receiver windows
Transport Layer
28
Selective repeat
sender
data from above :
receiver
pkt n in [rcvbase, rcvbase+N-1]
 if next available seq # in
 send ACK(n)
timeout(n):
 in-order: deliver (also
window, send pkt
 resend pkt n, restart timer
ACK(n) in [sendbase,sendbase+N]:
 mark pkt n as received
 if n smallest unACKed pkt,
advance window base to
next unACKed seq #
 out-of-order: buffer
deliver buffered, in-order
pkts), advance window to
next not-yet-received pkt
pkt n in
[rcvbase-N,rcvbase-1]
 ACK(n)
otherwise:
 ignore
Transport Layer
29
Selective repeat in action
Transport Layer
30
Selective repeat:
dilemma
Example:
 seq #’s: 0, 1, 2, 3
 window size=3
 receiver sees no
difference in two
scenarios!
 incorrectly passes
duplicate data as new
in (a)
Q: what relationship
between seq # size
and window size?
Transport Layer
31
Protocoles de bout en bout :
bilan
 Réseau “best effort” sous jacent
Perte de paquets
 Dé-séquencement
 Limite la taille des paquets
 Temps de transfert aléatoire

 Services courants de bout en bout
 Remise garantie des messages
 Séquencement
 Taille des messages quelconque
 Synchronisation récepteur - émetteur
 Plusieurs processus applicatif sur une même
Transport Layer
machine
32
Problèmes de transport
 Contrôle de flux

Adaptatif: fenêtre à taille variable
A
Numérotation séquentielle
(modulo 2 7 ou 231)
DT0
B
DT1
ACK2, CDT=3
Dernier octet
acquité
CDT
Fenêtre
DT2
DT3
DT4
Limite supérieure
de fenêtre
ACK5, CDT=0
ACK5, CDT=1
DT5
 Dissociation du rôle des ACK:
 Contrôle d’erreur
 Contrôle de flux
•
•
•
Transport Layer
33
Problèmes de transport
 Libération
 Brutale
utilisateur
Action synchronisée sur réseau non fiable
fournisseur
utilisateur
temporisateur de
retransmission
T_DATA.req
T_DATA.ind
T_DATA.req

DC
effacement de
connexion
T_DISC.req
absence de T_DATA.ind
après le T_DISC.req
T_DISC.req
A
Ordonnée
DR
AK
Temporisateur
d’effacement
effacement de
connexion
B
DT3
T_CLOSE.request
DT4
CR5
Fermeture
effective de la
demi-conexion
T_DATA.indication
T_CLOSE.indication
AK6
DT8
CR9
T_DATA.request
T_CLOSE.request
T_CLOSE.indication
AK10
Transport Layer
34
Terminaison de connexion
 Symétrique
Terminaison indépendante des deux directions
 Fin de connexion lorsque chaque extrémité à
terminé

 Asymétrique
 Fin de connexion dès qu’une des extrémités le
demande
• Petres possibles car plus de données acceptées après le DR
Transport Layer
35
Automate d’état
Connection request
TPDU received
Connection primitive executed
IDLE
Passive establishment
pending
Active establishment
Pending
Transitions déclenchées par des
primitives locales ou des arrivées
de TPDU
Connection accepted TPDU received
Connection primitive executed
Establishment
Disconnect request
TPDU received
Disconnect primitive executed
Passive disconnect
pending
Active disconnect
pending
Disconnect primitive executed
Disconnection request
TPDU received
IDLE
Transport Layer
36
UDP
Transport Layer
37
UDP
 RFC 768
 Numéro de protocole 17 quand transporté par IP.
 Interface d’application pour IP
 Pas de fiabilité, contrôle de flux ou récupération







sur erreur.
Aucun contrôle sur le flot -> simplicité
Peu d’overhead, mécanisme minimaliste
Mode datagramme, non connecté (orienté message)
“multiplexer/demultiplexer'' pour
envoyer/recevoir des datagrammes, en utilisant
des ports pour diriger ces datagrammes.
Qualité “best effort”
création d’un paquet et transmission immédiate au
niveau IP
Transport Layer
Attention : pas de contrôle de congestion
38
UDP: User Datagram Protocol [RFC 768]
 “no frills,” “bare bones”
Internet transport
protocol
 “best effort” service, UDP
segments may be:
 lost
 delivered out of order
to app

connectionless:


no handshaking between
UDP sender, receiver
each UDP segment
handled independently
of others
Why is there a UDP?
 no connection
establishment (which can
add delay)
 simple: no connection state
at sender, receiver
 small segment header
 no congestion control: UDP
can blast away as fast as
desired
Transport Layer
39
Communication entre les
couches
process 1
port x
process 2
process n
port y
port z
UDP : démultiplexage de ports
IP
Transport Layer
40
Datagrammes UDP (1)
 Port Source
 indique le numéro de
port du processus
émetteur,
 toute réponse y est
dirigée.
 Port Destinataire
 Longueur :
 nombre d'octets
dans le datagramme
entier (avec en-tête).
 >8
Transport Layer
41
Datagrammes UDP (2)
 Contrôle d’erreur
 Optionnel en IPv4, obligatoire en IPv6
 Pseudo-header + en-tête + données
 Pseudo-header:
• @ IP source
• @ IP destination
• protocole
Transport Layer
42
UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted
segment
Sender:
 treat segment contents
as sequence of 16-bit
integers
 checksum: addition (1’s
complement sum) of
segment contents
 sender puts checksum
value into UDP checksum
field
Receiver:
 compute checksum of
received segment
 check if computed checksum
equals checksum field value:
 NO - error detected
 YES - no error detected.
But maybe errors
nonethless? More later ….
Transport Layer
43
Applications d’UDP
 la signalisation de certains protocoles
 Trivial File Transfer Protocol (TFTP)
 Domain Name System (DNS) name server
 Remote Procedure Call (RPC), utilisé par Network
File System (NFS)
 Network Computing System (NCS)
 Simple Network Management Protocol (SNMP)
 applications temps réel, visio et audio conférences
 applications nécessitant transmission multipoint
(multicast) exemple : applications du MBONE, sdr,
tableau blanc, etc
Transport Layer
44
UDP: more
 often used for streaming
multimedia apps
 loss tolerant
 rate sensitive
 other UDP uses
(why?):
Length, in
bytes of UDP
segment,
including
DNS
 SNMP
 reliable transfer over UDP:
add reliability at
application layer
 application-specific
error recover!

32 bits
source port #
dest port #
length
checksum
header
Application
data
(message)
UDP segment format
Transport Layer
45
TCP
Transport Layer
46
TCP
 RFC 793 - Transmission
 90% du trafic
 Principes


Control Protocol
Bonne utilisation des ressources du réseau
Couche de transport des systèmes d’extrémités (i.e. utilisateurs des
données)
• Communication bidirectionnelle et point à point sur des réseaux hétérogènes

Transfert fiable de données
( UDP)
• Contrôle de perte
• Contrôle de flux
• Contrôle de congestion: interaction hôte-réseau réactive et agréssive
• TCP suppose que les couches de communication qui lui sont
inférieures lui procurent un service de transmission de paquet simple,
dont la qualité n'est pas garantie.

Mode connecté et commutation de paquets
Orienté flux d’octets:

Récepteur le plus simple possible -> complexité chez l’émetteur

• application écrit des octets
• TCP émet des segments
• application lit des octets
• interopérabilité maximum recherchée
 Utilisé parTELNET, FTP, HTTP …
Transport Layer
47
Caractéristiques de TCP
 Flot d’octets
 Circuit virtuel en mode
connecté


La connexion est établie
et considérée comme un
circuit physique
fiabilité
 Transfert bufferisé

Attendre d’avoir assez de
données pour émettre
(performance)
Application process
Application process
…

Séquencés
Segmentation des
données au niveau TCP
…

Octets écrits
TCP
Octets
lus
TCP
Buffer émission
Buffer réception
Segment
Segment… Segment
TSegments transmis
 Full duplex

Pour les ACKs
Transport Layer
48
Caractéristiques de TCP
 Numéros de séquence indépendants dans les 2
directions

Associés à chaque octets
• Indique le numéro du premier octet transmis

Mots de 32 bits
• Bouclage théorique en moins de 6 minutes à 100 Mbps mais
en pratique, c’est beaucoup plus long !

Utilisé pour les acquittements
• Si N octets sont délivrés du paquet avec le numéro de
séquence X, l’acquittement aura la valeur X+N (soit le
numéro du prochain octet à recevoir)

Piggybacking
• Les deux numéros sont présents dans les mêmes paquets
Transport Layer
49
Caractéristiques de TCP
 Fiabilité






Numéro de séquence
Détection des pertes :
• Aquittements positifs (ACK) du récepteur -> OK
• Pas d’ACK -> timeout (temporisation) -> retransmission
• ACK dupliqué
Réordonnancement des paquets au récepteur
Elimination des paquets dupliqués
Checksum
Retransmissions :
• Selective repeat
• Go back N
 Contrôle de flux par annonce de fenêtres


Fenêtre modulée par le récepteur
Inclus dans l’ACK
• Fenêtre qui indique le plus grand numéro de séquence pouvant être
reçu
• Erreur = congestion
 Contrôle de congestion : adaptation à l’état d’occupation du
réseau

Sans signalisation réseau
 Orienté connexion
Transport Layer
50
Caractéristiques de TCP
 Multiplexage
 Pour permettre à plusieurs tâches d'une même machine de
communiquer simultanément via TCP, le protocole définit un
ensemble d'adresses et de ports pour la machine.

Une "socket" est défini par l'association des adresses
Internet source, destinataire, ainsi que les deux numéros de
port à chaque extrémité. Une connexion nécessite la mise
en place de deux sockets. Une socket peut être utilisée par
plusieurs connexions distinctes.

L'affectation des ports aux processus est établie par chaque
ordinateur.
Transport Layer
51
Segments
 Les octets de
données sont
accumulés jusqu’au
moment où TCP
décide d’envoyer un
segment
 Découpage en
segment indépendant
du découpage au
niveau application
 MSS = longueur
maximale d’un
segment
Application
Buffer d’émission
TCP
header
IP
header
TCP
IP
Transport Layer
52
Sockets
 Deux process communiquent par des sockets TCP qui
fournissent aux process un flux de données full duplex.
 Ports éphémères
 Port = TCP TSAP = numéro sur 16 bits




Valeur locale
0 à 255 : well-known
0 à 1023 : ports système
1024 à 65536 : ports utilisateurs
 Une socket TCP :

Triplet <TCP, IP address, port number>.
 Une connexion TCP :

2 sockets <TCP, local IP address, local port, remote IP address,
remote port>.
Transport Layer
53
BSD Sockets
 Primitives pour TCP utilisées par les UNIX BSD








SOCKET (création d’un nouveau point terminal)
BIND (attache une adresse à la socket)
LISTEN (acceptation des connexions avec file
d’attente)
ACCEPT (acceptation bloquante)
CONNECT (établissement actif de connexion)
SEND (envoi de données sur une connexion)
RECEIVE (réception de données d’une connexion)
CLOSE (terminaison d’une connexion)
 Serveur : SOCKET -> BIND -> LISTEN -> ACCEPT
… [SEND, RECEIVE]… -> CLOSE
 Client : SOCKET –> BIND -> CONNECT … [SEND,
RECEIVE]…-> CLOSE
Transport Layer
54
Communication entre
applications
process 1
port x
Données
TCP header
port:x
Données
process 2
connexion
port y
socket
TCP
connexion TCP fiable
IP
TCP
Adresse IP
IP
paquets IP non fiable
Transport Layer
Hôte 1
Hôte 2
55
Problèmes pour TCP
 Connexion avec des hôtes différents

Établissement et libération de connexion
 RTT variable
 adaptation de la temporisation
 Survivance de paquets (très long délai de
transfert)

Attention aux arrivées de très vieux paquets
 Capacité de stockage dynamique des
extrémités

“Apprendre” les ressources disponibles
 Capacité de la route varie dans le réseau
Transport Layer
 Ajuster le débit d’émission à la bande passante
56
Vie d’une Connexion
 Si deux processus désirent communiquer,
établissement d’une connexion TCP
 Internet => best effort

on utilise donc une méthode d'initialisation par
négociation bilatérale basée sur une horloge pour
les numéros de séquence.
 A la fin de la connexion
 Fermeture qui libère les ressources
 3 phases
 Ouverture d’une connexion
 Transfert de données
 Fermeture de la connexion
Transport Layer
57
Établissement d’une connexion
 Appel OPEN passif (serveur)/actif (client)
 Fermeture d’une connexion avec le bit FIN
(à faire dans les deux sens)
Process 1
Active OPEN
Send SYN, seq=n
Process 2
Passive open
attend une requête active
Receive SYN
Send SYN, seq=m, ACK=n+1
Receive SYN+ACK
Send ACK=m+1
Transport Layer
58
Connexion TCP
 Trois phases
Etablissement de la connexion
 Transfert des informations avec

• Contrôle de flux
• Contrôle de congestion

Libération de la connexion
Transport Layer
59
Etablissement de la connexion
TCP
 Procédure à trois échanges

Three way handshake
 ISN (Initial Sequence Number)
 Numéro de séquence du premier octet
d’information transporté
 Le premier octet transporté est alors ISN+1
 ISN est généralement dérivé de l’horloge de
l’hôte
Transport Layer
60
Exemple
Transport Layer
61
Libération de la connexion
 Normale

Fin demandée par l’une des extrémités (flag
FIN=1)
 Terminaison brutale
• Envoi de la primitive ABORT (flag RST=1)
• Toutes les transmissions ou réceptions sont
interrompues et les tampons sont vidés
Transport Layer
62
Automate TCP
CLOSED
Listen/-
Close/-
Close/-
LISTEN
SYN/SYN+ACK
Send/SYN
RST/-
Connect/SYN
SYN RCVD
SYN SENT
SYN/SYN+ACK
Simultaneous open
ESTABLISHED
ACK/-
SYN+ACK/ACK
CLOSE/FIN
CLOSE/FIN
FIN/ACK
FIN/ACK
FIN WAIT 1
CLOSING
ACK/-
CLOSE WAIT
ACK/-
CLOSE/FIN
FIN+ACK/ACK
FIN WAIT 2
FIN/ACK
TIME WAIT
LAST ACK
ACTIVE CLOSE
PASSIVE CLOSE
Timeout/CLOSED
ACK/-
Transport Layer
63
Transfert de données
 Segmentation
 Découpage du flux en segments selon la MTU locale
 Numérotation des octets
 Gel du numéro de séquence pendant MSL (Maximum Segment Lifetime)
 Contrôle de perte (fiabilité)
 Acquittement positif
 Protection par temporisateur de retransmission chez l'émetteur
uniquement
 Contrôle de flux (optimisation des ressources disponibles)
 fenêtres à taille variable
 Progression par acquittement et crédit : fenêtres glissantes
Data (Sequence Number)
Sender
Receiver
Acknowledgement +
Advertised Window
Transport Layer
64
Fiabilité : stop and wait
 Envoi d’un paquet et attendre un acquittement avant
d’envoyer un nouveau paquet.
 Si timeout, alors retransmission
 Fiabilité vs. utilisation de la bande passante
Lancer nam ici
émetteur
Envoi du
paquet 1
récepteur
Data
ACK
Réception
ACK
Envoi paquet 2
Réception paquet 1
Envoi ACK 1
Data
Transport Layer
65
Contrôle de flux TCP
Fenêtre annoncée
Transmis et acquitté
Transmis
non acquitté
Non transmis
Non transmissible
 Basé sur la fenêtre glissante
 Pointeur de début de fenêtre
 Pointeur indiquant la partie transmise et non
acquittée
 Pointeur indiquant la fin de la fenêtre
 Envoi de données urgentes toujours possible
Transport Layer
66
Fenêtre d’émission
 F=min (cwnd, W)

Cwnd est une variable maintenue par la source
• Tient compte de la congestion du réseau

W : fixé par la destination, champ fenêtre
annoncé
• Tient compte de la capacité du récepteur
Transport Layer
67
Fenêtres
 But : optimiser les ressources

Contrôle de flux et contrôle de congestion
 L’émetteur peut envoyer n paquets dans une fenêtre de taille n sans
recevoir d’ACK.
 L’émetteur fait glisser la fenêtre sur réception d’un ACK.
 Fenêtre effective = Fenêtre annoncée - (octets transmis - octets
non acquittés)
 Arrêt de la transmission quand fenêtre effective=0
émetteur
récepteur
DATA 1
DATA 2
DATA 3
DATA 4
DATA 5
ACK2
DATA 6
1
2
3
4
5
6
7
8
9
fenêtre
glissante
Transport Layer
68
Silly window syndrome
 L’émetteur a beaucoup de données à
transmettre
 Petite fenêtre annoncée => émission de
petits segments
 Solution pour le récepteur

Annoncer des fenêtres par tranches plus larges
(MSS par exemple)
 Solution pour l’émetteur
 Retarder l’envoi de petits segments
 Soit PUSH positionné soit on a au moins ½ de la
fenêtre à envoyer
Transport Layer
69
Fiabilité avec Go-back-N
 Fenêtre d’anticipation
 Détection d’erreurs par l’émetteur
 Retransmission continue (go-back-n) ou
sélective (stockage en désordre)
A
DT0
B
DT1
ACK2
DT2
DT3
DT4
ACK3
DT3
•
•
•
Transport Layer
70
La reprise sur erreurs
émetteur
 Exemples

Paquet 2 perdu:
T
• ACK 3 non reçu par S,
• W reste en 1
• R aquitte 3, 4, 5 avec un
ACK 2
• Timout sur S,
retransmission
• ACK 6 envoyé par R

Paquet 2 arrivé et ACK
perdu
• ACK 3 non reçu mais ACK 4
reçu
• ACK 4 acquitte tous les
paquets avant 4
• S fait glisser sa fenêtre au
paquet 4
récepteur
DATA 1
DATA 2
DATA 3
DATA 4
DATA 5
ACK2
ACK2
ACK2
ACK2
DATA 2
ACK6
récepteur
émetteur
DATA 1
DATA 2
DATA 3
DATA 4
DATA 5
ACK2
ACK3
ACK4
Transport Layer
71
Exemple de reprise sur erreurs
Sender
Receiver
Segment 1 (seq. 1000)
Receives 1000, send ACK 1500
Segment 2 (seq. 1500)
Segment 3 (seq. 2000)
Receives ACK 1500
Slide the window
Segment 4 (seq. 2500)
Waiting for ACK
Receives one of the frames and
replies with ACK 1500
Receive ACK 1500
which does not slide the window
Timeout -> retransmission
Of segment 2
Transport Layer
72
TCP: retransmission scenarios
time
Host A
Host B
X
loss
lost ACK scenario
Host B
Seq=100 timeout
Seq=92 timeout
timeout
Host A
time
premature timeout,
cumulative ACKs
Transport Layer
73
TCP ACK generation
[RFC 1122, RFC 2581]
Event
TCP Receiver action
in-order segment arrival,
no gaps,
everything else already ACKed
delayed ACK. Wait up to 500ms
for next segment. If no next segment,
send ACK
in-order segment arrival,
no gaps,
one delayed ACK pending
immediately send single
cumulative ACK
out-of-order segment arrival
higher-than-expect seq. #
gap detected
send duplicate ACK, indicating seq. #
of next expected byte
arrival of segment that
partially or completely fills gap
immediate ACK if segment starts
at lower end of gap
Transport Layer
74
Conséquences de ces
mécanismes
 Fiabilité des transmissions
 Bonne utilisation de la bande passante
 Contrôle de flux orienté récepteur : la
taille de la fenêtre varie au cours de la
connexion
Transport Layer
75
Temporisateurs de TCP
 Temporisateur de retransmission
 Temporisateur de peristence
 Pour débloquer la situation après une fenêtre
d’émission réduite à zéro et une ouverture
perdue
 Temporisateur d’inactivité
 Vérifie la présence de l’autre extrémité
 Temporisateur de déconnexion
 Deux fois la durée de vie des paquets
Transport Layer
76
TCP et Long Fat Networks
 Performance maximum si l’émetteur toujours en
activité

Eviter l’épuisement de la numérotation en séquence

Eviter la fermeture de la fenêtre

•
•
durée de rebouclage > MSL
Seq number: 32 bits
•
fenêtre annoncée ≥ bande passante * RTT
•
Window: 16 bits -> soit 64 Ko
• RTT (Round Trip Time) = temps entre émission d’un segment et réception de l’ACK correspondant
• bande passante * RTT = capacité de mémorisation du réseau
Cas des Long Fat Networks:
 Extension TCP pour les LFNs


facteur d’échelle sur la fenêtre d’émission
ajout d’une estampille temporelle sur 32 bits
(RFC1323)
Transport Layer
77
Ajustement des timeouts :
Contrôle d’erreur
 Délais variables sur Internet
Distance
 Temps de traversée du réseau (charge,
saturation des liens …)

 Le timeout est calculé en fonction de
l’estimation du RTT (Round Trip Time)
 Log du moment où un paquet est envoyé et
quand il est acquitté
 Moyenne pondérée des RTT mesurés
 Permet de trouver une valeur de timeout
pour le segment suivant
Transport Layer
78
Ajustement des timeouts:
Contrôle d’erreur
 Temporisateur de retransmission adaptatif

Mesure de RTT et en déduire une estimation
Algorithme
Err
= SampleRTT - EstRTT
EstRTT = EstRTT + (d x Err)
Var
= Var + d(|Err| - Var)
Prise en compte de la variance
Temporisateur = m x EstRTT + f x Var
Où m = 1 et f = 4
 Mesure du RTT

Cas d’erreurs

Actions:
• pas de mesure de RTT quand il y a eu une retransmission
• Doublement de la valeur du temporisateur après chaque
Transport Layer
retransmission
79
TCP Round Trip Time and Timeout
Q: how to set TCP
timeout value?
 longer than RTT
note: RTT will vary
 too short: premature
timeout
 unnecessary
retransmissions
 too long: slow reaction
to segment loss

Q: how to estimate RTT?
 SampleRTT: measured time from
segment transmission until ACK
receipt
 ignore retransmissions,
cumulatively ACKed segments
 SampleRTT will vary, want
estimated RTT “smoother”
 use several recent
measurements, not just
current SampleRTT
Transport Layer
80
TCP Round Trip Time and Timeout
EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT
 Exponential weighted moving average
 influence of given sample decreases exponentially fast
 typical value of x: 0.1
Setting the timeout
 EstimtedRTT plus “safety margin”
 large variation in EstimatedRTT -> larger safety margin
Timeout = EstimatedRTT + 4*Deviation
Deviation = (1-x)*Deviation +
x*|SampleRTT-EstimatedRTT|
Transport Layer
81
TCP congestion control:
 “probing” for usable
bandwidth:



ideally: transmit as fast
as possible (Congwin as
large as possible)
without loss
increase Congwin until
loss (congestion)
loss: decrease Congwin,
then begin probing
(increasing) again
 two “phases”
 slow start
 congestion avoidance
 important variables:
 Congwin
 threshold: defines
threshold between two
slow start phase,
congestion control
phase
Transport Layer
82
Contrôle de congestion
 Congestion

Goulot d'étranglement
Réseau 1
Routeur
Réseau 2
Datagrammes en
attente de relayage
routeur
Réseau 3
temps de
transfert
• Effondrement des performances
Réponses:
- niveau réseau: gestion des ressources
- niveau transport: adaptation du débit
trafic offert
Transport Layer
83
Causes/costs of congestion: scenario 1
 two senders, two
receivers
 one router,
infinite buffers
 no retransmission
 large delays
when congested
 maximum
achievable
throughput
Transport Layer
84
Causes/costs of congestion: scenario 2
 one router,
finite buffers
 sender retransmission of lost packet
Transport Layer
85
Causes/costs of congestion: scenario 2
= l
(goodput)
out
in
 “perfect” retransmission only when loss:
 always:

l
l > lout
in
retransmission of delayed (not lost) packet makes l
in
l
(than perfect case) for same
out
larger
“costs” of congestion:
 more work (retrans) for given “goodput”
 unneeded retransmissions: link carries multiple copies of pkt
Transport Layer
86
Causes/costs of congestion: scenario 3
 four senders
 multihop paths
 timeout/retransmit
Q: what happens as l
in
and l increase ?
in
Transport Layer
87
Causes/costs of congestion: scenario 3
Another “cost” of congestion:
 when packet dropped, any “upstream transmission
capacity used for that packet was wasted!
Transport Layer
88
Approaches towards congestion control
Two broad approaches towards congestion control:
End-end congestion
control:
 no explicit feedback from
network
 congestion inferred from
end-system observed loss,
delay
 approach taken by TCP
Network-assisted
congestion control:
 routers provide feedback
to end systems
 single bit indicating
congestion (SNA,
DECbit, TCP/IP ECN,
ATM)
 explicit rate sender
should send at
Transport Layer
89
Contrôle de congestion TCP
 Conservation des paquets

Ne pas injecter un nouveau paquet tant qu’un vieux n’est
pas sorti du réseau
• nombre de paquets en transit constant

Synchronisation sur les acquittements: autosynchronisation
 Trouver le point de synchronisation

Utilisation d’une fenêtre dynamique: fenêtre de
contrôle de congestion (cwnd)
 Détection de la congestion

Pertes généralement dues à la congestion
 Guérison de la congestion

Diminution du débit à la source pour diminuer
la
Transport Layer
congestion
90
Contrôle de congestion
 Principe

Trouver le point d’équilibre: “additive
increase”
• Augmenter la fenêtre de contrôle de congestion
Détection de la congestion par l’indication
de la perte d’un paquet
 Suppression de congestion en réduisant la
fenêtre
 Algorithme





phase 1: slow start
• Après une perte détectée par expiration de
temporisation
phase 2: congestion avoidance
En cas de perte: réduction de la taille de la fenêtre et
récupération
Récupération : fast recovery
• Après une perte détectée par retransmission rapide
(fast retransmit)
Transport Layer
91
Algorithmes de contrôle de
congestion et gestion des fenêtres
 Slow Start
 Multiplicative decrease
 Fast recovery
 RED
 Delayed ACK
 etc.
Transport Layer
92
Slow Start
 Fenêtre glissante et taille variable de la
fenêtre
 Croissance exponentielle de la taille de la
fenêtre (x2 à chaque fois que les paquets
sont transmis correctement)

Augmentation de 1 segment à chaque
acquittement
 Lancer nam ici
Transport Layer
93
Congestion avoidance
 Pour stopper l’augmentation trop rapide (le
slow start est exponentiel)
 À partir d’un seuil : augmentation de 1
segment à chaque RTT
 Le seuil vaut la moitié de la fenêtre lors de
la dernière congestion
Transport Layer
94
Congestion avoidance
 Initialisation avec cwnd=1 et ssthresh=65536
 TCP envoie moins de min(cwnd, fenêtre de
réception)
 Congestion => ssthresh = max(fenêtre/2, 2).
 Si timeout (cad perte), alors cwnd=1
 Nouvel ACK => grandir cwnd


Si cwnd<=ssthresh alors slow start jusque cwnd =
cwnd avant congestion /2
Sinon Congestion avoidance (croissance linéaire de la
taille de la fenêtre)
 Avant ces mécanismes : simple-pre-vj.nam
 Lancer nam (multiplicative decrease) ici
 Lancer simple.avi ici ou nam (simple.nam)
Transport Layer
95
TCP et grands RTTs
 Avec Congestion avoidance, la taille de la
fenêtre augmente de 1 à chaque RTT
 Croissance moins rapide si le RTT est grand
 Lancer biais.avi
Transport Layer
96
Fast recovery
 Empêche le slow start après la congestion
 Slow start utilisé en cas de perte de
paquets (expiration de timer)
Transport Layer
97
Fast retransmit
 Modification de congestion
avoidance


3 DUPACKs -> paquet supposé
perdu et donc retransmission
Après la transmission, tout
continue normalement (on
attend pas d’ACK)
 Si 3 DUPACKs
 Sshthresh = ½
min(cwnd,fenêtre récepteur)
 Retransmettre le segment
perdu
 Cwnd+=3 taille de segment
 Autre DUPACK -> cwnd
+=taille de segment et
transmet un paquet
 Acquittement de nouvelles
données -> cwnd = ssthresh
 Lancer nam ici
Transport Layer
98
RED (Random Early Detection)
 Dans les routeurs
 Congestion imminente -> notification à la
source en perdant un paquet
 La congestion est calculée en mesurant la
taille moyenne des queues dans les routeurs
 Lancer nam ici
 Comparaison avec drop tail
Transport Layer
99
Delayed ACKs
 Possibilité d’acquitter plusieurs paquets
d’un coup
 Lancer nam ici
Transport Layer
100
Contrôle de congestion
 Evolution de cwnd
segment
20
18
16
perte de segment
croissance
linéaire
réduction
f enêtre à
1 segment
14
12
10
8
croissance
exponentielle
réduction de moitié du seuil
6
4
2
0
temps
Transport Layer
101
TCP Congestion Avoidance
Congestion avoidance
/* slowstart is over
*/
/* Congwin > threshold */
Until (loss event) {
every w segments ACKed:
Congwin++
}
threshold = Congwin/2
Congwin = 1
1
perform slowstart
1: TCP Reno skips slowstart (fast
recovery) after three duplicate ACKs
Transport Layer
102
Segment TCP
 Port source (16 bits) : le numéro de port de la source.
 Port Destination (16 bits) : Le numéro de port du destinataire.
 Numéro de séquence (32 bits) : Le numéro du premier octet de
données par rapport au début de la transmission (sauf si SYN est
marqué). Si SYN est marqué, le numéro de séquence est le
numéro de séquence initial (ISN) et le premier octet à pour numéro
ISN+1.
 Accusé de réception (32 bits) : si ACK est marqué ce champ
contient le numéro de séquence du prochain octet que le récepteur
s'attend à recevoir. Une fois la connexion établie, ce champ est
toujours renseigné.
Transport Layer
103
Segment TCP
 Header length (4 bits): La taille de l'en-tête TCP en nombre de
mots de 32 bits. Il indique là ou commence les données. L'en-tête
TCP, dans tous les cas à une taille correspondant à un nombre
entier de mots de 32 bits.
 Réservé (6 bits) : réservés pour usage futur. Doivent
nécessairement être à 0.
 Bits de contrôle (6 bits - de gauche à droite):
- URG: Pointeur de données urgentes significatif
- ACK: Accusé de réception significatif
- PSH: Fonction Push
- RST: Réinitialisation de la connexion
- SYN: Synchronisation des numéros de séquence
- FIN: Fin de transmission
 Fenêtre (16 bit): le nombre d'octets à partir de la position marquée
Transport
104
dans l'accusé de réception que le récepteur est capable
de Layer
recevoir.
Segment TCP
 En-tête de 20 octets (+ options) = IP
 Zéro ou plus octets de données
 Taille des segments décidés par TCP
 Taille max = max (65535o avec entête TCP,
MTU)
 Un segment doit tenir dans le MTU
 Pour IPv4, la MTU minimale est 556 octets
(payload TCP de 536 octets)
Transport Layer
105
Versions de TCP
 Unix
BSD 4.2 (1983) 1ére souche TCP/IP largement
disponible
 BSD 4.3 Tahoe (1988), slow start, congestion
avoidance
 BSD 4.3 Reno (1990), fast recovery
 BSD 4.3 Vegas (1990), Estimateur de BP

Transport Layer
106
AIMD
TCP congestion
avoidance:
 AIMD: additive
increase,
multiplicative
decrease


increase window by 1
per RTT
decrease window by
factor of 2 on loss
event
TCP Fairness
Fairness goal: if N TCP
sessions share same
bottleneck link, each
should get 1/N of link
capacity
TCP connection 1
TCP
connection 2
bottleneck
router
capacity R
Transport Layer
107
Why is TCP fair?
Two competing sessions:
 Additive increase gives slope of 1, as throughout increases
 multiplicative decrease decreases throughput proportionally
R
equal bandwidth share
loss: decrease window by factor of 2
congestion avoidance: additive increase
loss: decrease window by factor of 2
congestion avoidance: additive increase
Connection 1 throughput R
Transport Layer
108
TCP latency modeling
Q: How long does it take to Notation, assumptions:
receive an object from a  Assume one link between
client and server of rate R
Web server after sending
 Assume: fixed congestion
a request?
 TCP connection establishment
 data transfer delay
window, W segments
 S: MSS (bits)
 O: object size (bits)
 no retransmissions (no loss,
no corruption)
Two cases to consider:
 WS/R > RTT + S/R: ACK for first segment in
window returns before window’s worth of data
sent
 WS/R < RTT + S/R: wait for ACK after sending
Transport Layer
window’s worth of data sent
109
TCP latency Modeling
Case 1: latency = 2RTT + O/R
K:= O/WS
Case 2: latency = 2RTT + O/R
+ (K-1)[S/R + RTT - WS/R]
Transport Layer
110
TCP Latency Modeling: Slow Start
 Now suppose window grows according to slow start.
 Will show that the latency of one object of size O is:
Latency  2 RTT 
O
S
S

 P  RTT    (2 P  1)
R
R
R

where P is the number of times TCP stalls at server:
P  min{Q, K  1}
- where Q is the number of times the server would stall
if the object were of infinite size.
- and K is the number of windows that cover the object.
Transport Layer
111
TCP Latency Modeling: Slow Start (cont.)
Example:
O/S = 15 segments
K = 4 windows
initiate TCP
connection
request
object
first window
= S/R
RTT
second window
= 2S/R
Q=2
third window
= 4S/R
P = min{K-1,Q} = 2
Server stalls P=2 times.
fourth window
= 8S/R
complete
transmission
object
delivered
time at
client
time at
server
Transport Layer
112
TCP Latency Modeling: Slow Start (cont.)
S
 RTT  timefrom when server startstosend segment
R
untilserver receivesacknowledgement
initiate TCP
connection
2k 1
S
 time to transmit the kth window
R

request
object
S
k 1 S 

RTT

2
 stall timeafter thekth window
 R
R 
first window
= S/R
RTT
second window
= 2S/R
third window
= 4S/R
P
O
latency  2 RTT   stallTim ep
R
p 1
P
O
S
S
  2 RTT   [  RTT  2k 1 ]
R
R
k 1 R
O
S
S
  2 RTT  P[ RTT  ]  (2 P  1)
R
R
R
fourth window
= 8S/R
complete
transmission
object
delivered
time at
client
time at
server
Transport Layer
113
Conclusion et synthèse
 Protocoles de transport => de bout-en-bout




multiplexing/demultiplexing
reliable data transfer
flow control
congestion control
 Principalement deux protocoles de transport


UDP : non fiable, seulement vérification des erreurs
TCP : fiable, contrôle de congestion, reprise sur erreurs (ACK +
timeout)…
 Implémentés partout
Cours suivant :
 On quitte la bordure du réseau (couches application et
transport)...
 ... pour entrer au coeur du réseau.
Transport Layer
114
Chapter 3: Summary
 principles behind
transport layer services:
 instantiation and
implementation in the Internet
 UDP
 TCP
Transport Layer
115