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