Groupe de travail

Métrologie
http://www.inria.fr http://gt-metro.grenet.fr

Métrologie et performances réseau

Les protocoles de transport

UDP, TCP, DCCP, SCTP, RTP/RTCP, RTSP

Luc.Saccavini@inria.fr

V1.1 octobre 2007

1
 Plan de l’exposé

→ Les protocoles de transport (principales caractéristiques)

→ UDP
→ TCP : exposé détaillé
→ DCCP
→ SCTP
→ RTP/RTCP, RTSP

V1.1 octobre 2007

2/45

2
 Présentation des protocoles sur IP (1)

→ IP est un protocole d’acheminement de paquets entre deux

extrémités (interfaces de machines) du réseau
→ il est robuste
→ efficace
→ non fiable : la perte de paquets est même nécessaire pour
éliminer les boucles (TTL<64)
→ ne prend pas en compte la notion de service (N° de port), de
session...
→ c’est le rôle de protocoles au dessus d’IP comme UDP, TCP,
SCTP…

V1.1 octobre 2007

3/45

La robustesse du protocole IP vient de la technique de routage qui est :

- distribuée : chaque routeur prend localement une décision de routage qui est par nature, bien
adaptée au contexte local
- dynamique : les tables de routage évoluent automatiquement pour tenir compte des évolutions
de la topologie du réseau (perte/ajout de liens ou de routeurs)
- fonction de l’adresse destination : un seul paramètre pour prendre la décision de routage

L’efficacité du protocole IP (pour les aspects débit) peut se mesurer par le ratio entre le volume de
données nécessaire au protocole (en-tête, options…) et le volume de données utiles.
Exemple : en se plaçant dans le contexte de transport Ethernet, qui autorise une taille de paquet
IP de 1500 octets au maximum, le volume d’information utilisé par le protocole IP est de 1,33%
(en tête de 20 octets) en IPv4 et 2,67% (en tête de 40 octets) en IPv6.
Ces chiffres sont comparables aux 2,47% correspondant au protocole Ethernet.

3
 Présentation des protocoles sur IP (2)

→ UDP (User Datagram Protocol)

– procure l’identification d’un flux de données (lié à un
service) à partir du quadruplet (@IP/src, port/src, @IP/dest,
port/dest). @IP/dest peut être de type multicast.
– très efficace, (mais) peut utiliser toute la bande passante
– n’assure pas la fiabilité de la transmission
→ TCP (Transmission Control Protocol)
– identifie le flux de données comme UDP
– assure une transmission fiable
– assure un contrôle de congestion
– connexion point à point (unicast) en mode duplex
V1.1 octobre 2007
4/45

La transmission de données par UDP a potentiellement de meilleures qualités isochrones que

TCP car les paquets reçus sont immédiatement transmis à la couche applicative. C’est ce qui fait
souvent préférer ce protocole pour les transmissions de données de type audio/vidéo. Cela
suppose que la perte de paquets soit gérée au niveau applicatif.

Pour ne pas subir la pénalisation temporelle induite par une retransmission de données les
applicatifs peuvent, soit ignorer les pertes de données quand c’est acceptable (vidéo), soit y parer
en envoyant une information redondante (audio).
Une évolution du protocole UDP a été proposée dans ce sens par le RFC3828, en autorisant la
transmission de données partiellement corrompues à la couche applicative (alors que
normalement le paquet est détruit dans ce cas).

À contrario, la fiabilité de la transmission des données assurée par TCP peut se traduire, en cas
de perte de paquets par un allongement du délai de transmission. En effet, il faut attendre la
retransmission du paquet perdu pour que les données soient transmises à la couche applicative.
Ce délai concerne aussi tous les paquets arrivés entre temps.

4
 Présentation des protocoles sur IP (3)

→ DCCP (Datagram Congestion Control Protocol)

– similaire à UDP avec un contrôle de congestion en plus
– plusieurs algorithmes de contrôle de congestion possibles

→ STCP (Stream Transport Control Protocol)

– améliore TCP sur les aspects redondance
– crée une association entre deux machines (qui ont N @IP)
– utilise plusieurs flux de données entre les deux machines
– assure le backup automatique entre interfaces réseau

V1.1 octobre 2007

5/45

DCCP (RFC 4340) algorithmes de contrôle congestion

- TCP-like (RFC 4341)
- TCP Friendly Rate Control (TFRC, RFC 4342)

Un des objectifs de DDCP est d’être moins «agressif» qu’UDP vis à vis de la bande passante.

SCTP (RFC 2960, RFC 3309)

plus complexe que TCP
en-tête plus gros que TCP

5
 Présentation des protocoles sur IP (4)

→ RTP (Real-time Transmission Protocol)

– caractéristiques de transmission temps réel (latence, gigue)
– peut utiliser un transport UDP, DCCP, TCP
– support du multicast
→ RTCP (Real-time Transmission Control Protocol)
– associé à RTP
– suivi QoS, contrôle flux, contrôle des participants
→ RTSP (Real Time Streaming Protocol)
– spécifique à la transmission de flux audio et vidéo
– utilise un transport UDP, TCP

V1.1 octobre 2007

6/45

Spécification RTP
RFC 3550: RTP: A Transport Protocol for Real-Time Applications (STD, 2003)
RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control (STD, 2003)
(+ 65 autres RFC en PS, et 15 autres en INFO, BCP, EXP)

Spécification RTCP
RFC 3556: Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol
(RTCP) Bandwidth (PS, 2003)
RFC 3605: Real Time Control Protocol (RTCP) attribute in Session Description
Protocol (SDP) (PS, 2003)
RFC 3611: RTP Control Protocol Extended Reports (RTCP XR) (PS, 2003)
RFC 4571: Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP)
Packets over Connection-Oriented Transport (PS, 2006)
RFC4585: Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based
Feedback (RTP/AVPF) (PS, 2006)

Spécification RTSP
RFC 2326: Real Time Streaming Protocol (RTSP) (PS, 1998)
RFC 4567: Key Management Extensions for Session Description Protocol (SDP) and Real Time
Streaming Protocol (RTSP) (PS, 2006)

6
 Le protocole UDP

→ Pas de notion de session, ni d’acquitement des paquets reçus

→ Exemples d’utilisation
– Echanges courts : DHCP, DNS, RIP, SNMP
– Flux isochrones : voix, vidéo
→ L’entête du paquet UDP

Port source Port destination

Longueur Somme de contrôle

Données (longueur variable)

V1.1 octobre 2007

7/45

Port source (16bits) : numéro identifiant le flux UDP sur la machine qui initie la session. Ce
numéro n’a pas de signification particulière.

Port destination (16bits) : numéro identifiant le flux UDP sur la machine qui reçoit la demande
d’ouverture de session. Ce numéro identifie en général un service donné.

Longueur (16bits) : taille du paquet = en tête + données. Elle est au minimum de 8 octets.

Somme de contrôle (16bits) : couvre l’ensemble du segment TCP en-tête + données

Spécification UDP
RFC 768: User Datagram Protocol (STD, 1980)
RFC 3828: The Lightweight User Datagram Protocol (UDP-Lite) (PS, 2004)

L’efficacité du protocole UDP (pour les aspects débit) mesurée dans les mêmes conditions que
pour le protocole IP précédemment (volume de données nécessaire au protocole/volume de
données utiles) est très bonne. On obtient un chiffre de 0,55% (8/1460).

7
 Le protocole TCP

→ caractéristiques du protocole
→ le contrôle de flux par le récepteur
→ le contrôle de congestion par la source
→ améliorations successives de TCP
→ travaux en cours et extensions futures
→ l’analyse de sessions TCP (outils, exemples)

V1.1 octobre 2007

8/45

Spécification TCP
RFC 793: Transmission Control Protocol (STD, 1981)
RFC 1180: A TCP/IP Tutorial (INFO, 1991)
RFC 1323: TCP Extensions for High Performance (PS, 1992)
RFC 2018: TCP Selective Acknowledgment Options (PS, 1996)
RFC 2525: Known TCP Implementation Problems (INFO, 1999)
RFC 2581: TCP Congestion Control (PS, 1999)
RFC 2582: The NewReno Modification to TCP's Fast Recovery Algorithm (EXP, 1999)
RFC 2583: An Extension to the Selective Acknowledgement (SACK) Option for TCP (PS, 2000)
RFC 2988: Computing TCP's Retransmission Timer (PS, 2000)
RFC 3042: Enhancing TCP's Loss Recovery Using Limited Transmit (PS, 2001)
RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP (PS, 2001)
RFC 3390: Increasing TCP ’s Initial Window (PS, 2002)
RFC 3448: TCP Friendly Rate Control (TFRC): Protocol Specification (PS, 2003)
RFC 3517: A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm
for TCP (PS, 2003)
RFC 3782: The NewReno Modification to TCP Fast Recovery Algorithm (PS, 2004)
RFC 4015: The Eifel Response Algorithm for TCP (PS, 2005)
RFC 4653: Improving the Robustness of TCP to Non-Congestion Events (EXP, 2006)
RFC 4727: Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP and TCP Headers
(PS, 2006)

8
 Caractéristiques TCP : l’automate
Serveur Client
Listen Closed
-»SYN
«- SYN -»SYN, ACK -»SYN
«- SYN -»ACK
SYN received SYN sent
-»ACK du SYN
-»FIN
«- SYN, ACK -»ACK
Established

-»FIN «- FIN -»ACK

«- FIN -»ACK
Fin wait-1 Close wait
-»ACK du FIN -»FIN
Closing
Last-ACK
Fin wait-2 -»ACK du FIN -»ACK du FIN
«- FIN -»ACK Time wait timeout
Closed
V1.1 octobre 2007
9/45

Noter que la séquence d’établissement de la session permet de traiter le cas de l’initialisation

(envoi d’un SYN) simultanée d’une session par les 2 automates TCP.

La terminaison d’une session peut se faire en mode actif par émission d’un FIN (passage à l’état
Fin wait1) ou en mode passif par réception d’un FIN (passage à l’état Close wait).
Dans les états Fin wait{1,2} la réception de données est toujours possible, mais seule la ré-
émission de segments non acquités est autorisée (clôture de la moitié émission de la session
TCP).
Un segment TCP non acquité est ré-émis au plus tard après RTO secondes.
Le minuteur réglant la transition Time wait -> Closed est égal à 2 fois la durée de vie d’un
segment dans le réseau. Ce délai permet de s’assurer qu’il n’y a plus de segments TCP dans le
réseau et évite de perturber une nouvelle session qui serait établie entre les 2 machines
concernées. Ce délai fixé initialement à 2 minutes (RFC 793).

9
 Caractéristiques TCP : l’en tête
Port source Port destination
Numéro de séquence
Numéro de séquence d’acquitement
data U A P R SF
offset R C S S YI fenêtre
G K H T NN
Somme de contrôle Pointeur “urgent”
Options Bourrage

Données applicatives à transmettre

V1.1 octobre 2007

10/45

Port source (16bits) : numéro identifiant la session TCP sur la machine qui initie la session. Ce
numéro n’a pas de signification particulière.
Port destination (16bits) : numéro identifiant la session TCP sur la machine qui reçoit la
demande d’ouverture de session. Ce numéro identifie en général un service donné.
Numéro de séquence (32bits) : Numéro du premier octets de données de ce segment dans le
flot d’octets. Si be bit SYN est positionné, c’est la valeur initiale du numéro de séquence.
Numéro de séquence d’acquitement (32bits) : si le bit ACK est positionné, c’est le numéro du
prochain octet qui devra être reçu. Il est égal au Numéro de séquence du prochain segment de
données reçu.
Data offset (4bits) : longueur de l’entête TCP en multiple de 4 octets. (en-tête <= 64 octets)
Réservé (6bits) : ces bits doivent être à 0.
Bits de contrôle (6bits) : indiquent une fonction particulière du segment TCP
- URG : le champ Urgent est signifiant
- ACK : le champ Numéro de séquence d’acquitement est signifiant
- PSH : les données doivent être transmises sans délai
- RST : RAZ de la connection
- SYN : synchronisation des Numéro de séquence lors de l’ouverture d’une session TCP
- FIN : plus de données à émettre (fin de la session)
Fenêtre (16bits) : nombre d’octets acceptés en réception (fenêtre de réception)
Somme de contrôle (16bits) : couvre l’ensemble du segment TCP en-tête + données
Pointeur Urgent (16bits) : si le bit URG est positionné, pointe sur le premier octet suivant les
données urgentes.
Options (multiple de 8bits) : l’option Wscale, permet par exemple de multiplier la taille de la
fenêtre par une puissance de 2 et de s’affranchir ainsi de la taille réduite du champ Fenêtre.

10
 Caractéristiques TCP : les options

→ Window Scale
– Elle permet de s’affranchir de la limitation de la taille de la fenêtre due
à la longueur de 16bits du champ Fenêtre dans l’en-tête TCP
– valeur maxi autorisée : 14 (=> fenêtre de réception jusqu’à 1Go)
→ TimeStamps
– permet un horodatage des segments, et un calcul plus précis du RTT
→ Selective Acknoledgments (SACK)
– permet d’informer l’émetteur qu’un segment est arrivé alors que des
segments précédents ne le sont pas encore (désequencement, retard ou
perte d’un segment)

V1.1 octobre 2007

11/45

FR <= 2**14 ~ 1Go par le RFC 1323. Ce RFC définit aussi une option (TimeStamps Option)
permettant d’horodater les segments TCP. Cette option permet de faire une mesure plus précise
du RTT. (ex. cas où l’émetteur attend des données de la couche applicative, en cas de ACK
retardés).

L’option ACK partiel (SACK) est standardisée par le RFC 2018 après avoir été proposée sans
être standardisée dans le RFC1072. L’usage de l’option SACK est possible (mais non obligatoire)
pour un receveur de données si l’émetteur a positionné l’option SACK-permitted dans les
segments SYN échangés lors de l’ouverture de la session.

Cette option donne 2 pointeurs de 32 bits pour indiquer chaque bloc de données reçu dans le flot
TCP. Le premier bloc doit obligatoirement contenir le dernier segment arrivé.
Compte tenu de la taille maxi de 40 octets possible pour l’ensemble des options TCP et des 10
octets utilisés par l’option TimeStamps , il ne peut y avoir que 3 blocs de données dont la
réception est accusée par une option SACK.

L’option SACK a été complétée par l’option D-SACK (RFC2883) qui permet à l’émetteur d’inférer
s’il y a eu des déséquencements de paquets coté récepteur et de ne pas faire de ré-émission de
segments inutilement.

11
 TCP : encapsulation

données applicatives à transmettre

MSS

Segment TCP en-têteTCP Données TCP

20 octets

Paquet IP En-tête IP Données IP

20/40 octets (v4/v6)

En-tête Données Ethernet

14 octets MTU 1500 octets 4 octets

V1.1 octobre 2007

12/45

MSS : taille maximale du segment TCP.

Avec un MTU de 1500 octets sur Ethernet, le MSS vaut 1460 octets en IPv4 et 1440 octets en IPv6.

Sur un lien Ethernet à 100Mb/s, le débit maximal de trames de 1500 octets de données est de
10**7/(1538*8) = 8127 trames par seconde.
[1538 = 12 (inter-trame) + 8 (préambule) +14 (en-tête trame) + 1500 + 4 (CRC)]

Le débit maximal en TCP sera donc de

- 8127*1460 = 11,86 Mo/s (ou 94,92 Mb/s) en IPv4
- 8127*1440 = 11,70 Mo/s (ou 93,62 Mb/s) en IPv6

Exercice 1 : refaire le calcul avec des jumbo frames (9180 octets, Ethenet giga)
(MTU limité à 9000o à cause du CRC sur 4 octets qui perd son efficacité/précision au delà)

12
 TCP : contrôle de flux (récepteur)

→ le récepteur ouvre une Fenêtre de Réception (FR) autorisant

l’émetteur à émettre le nombre correspondant d’octets.
→ à chaque segment TCP reçu, le récepteur envoie à l’émetteur
un accusé de réception (ACK) pour ce segment
→ les données sont stockées (et éventuellement ré-ordonnées)
pour être transmises à la couche applicative du récepteur
→ quand la couche applicative récupère (sur un read) les données,
le récepteur fait «glisser» la FR
→ Si on veut pouvoir utiliser toute la bande passante d’un lien, on
doit donc avoir : FR > (bande passante) x RTT

V1.1 octobre 2007

13/45

FR : taille de la fenêtre de réception. Sur Linux (noyau 2.6.xx) ce paramètre est accessible par la
commande :
#>cat /proc/sys/net/ipv4/tcp_rmem
#>4096 87380 2076672
Les trois nombres donnent respectivement la valeur minimale (4096 octets), par défaut (87380
octets) et maximale (2076672 octets) de la FR d’une session TCP.

Sur un lien Ethernet à 100Mb/s, le débit utile maxi de 95 Mb/s en TCP, ne pourra donc être atteint
que si le RTT est inférieur à :
87380/(95 000 000/8)*1000*2 = 14,72 ms pour une FR de 87 ko
2076672 /(95 000 000/8)*1000*2 = 349,8 ms pour une FR de 2076 ko

Les valeurs de RTT sont typiquement de

- 10 ms entre sites intra Renater,
- 35 ms entre des sites intra Europe,
- 90 ms entre des sites situés en France et aux USA
- 210 ms entre des sites situés en Europe et en Asie

13
 TCP : contrôle de flux (émetteur)

→ Au démarrage : phase dite «slow start»

– l’émetteur envoie un segment et attend le ACK correspondant
– quand il reçoit le ACK, l’émetteur incrémente sa Fenêtre d’Emission
(FE) de 1 MSS. Il envoie donc 2 segments et attend les ACK.
– à chaque RTT, si tout va bien, la FE est doublée
– la FE (et aussi le débit) croît donc exponentiellement jusqu’à un seuil
prédéfini (SEC)
récepteur
Envoi d’un Réception
Segment ACK

émetteur temps
1 2 4 taille de la FE (en MSS)

RTT
V1.1 octobre 2007
14/45

Le but principal du contrôle de flux est de détecter une éventuelle congestion sur le chemin entre
émetteur et récepteur TCP. S’il y a congestion, la FE est réduite, s’il n ’y a pas de congestion, on
essaie d’agrandir au maximum la FE.

FE : taille de la fenêtre d ’émission (en MSS)

Sur Linux (noyau 2.6.xx) ce paramètre est accessible par la commande :

#>cat /proc/sys/net/ipv4/tcp_wmem
#>4096 16384 2076672

Les trois nombres donnent respectivement la valeur minimale (4096 octets), par défaut (16384
octets) et maximale (2076672 octets) de la FE d’une session TCP.

14
 TCP : contrôle de flux (émetteur)
→ Quand le seuil SEC est atteint, l’émetteur passe en mode
évitement de congestion
– quand il reçoit le ACK, l’émetteur incrémente sa FE de 1/FE
– à chaque RTT, si tout va bien, la FE est augmentée de 1 MSS
– en respectant toujours la condition : FE < FR
récepteur

émetteur temps
4 5 6 taille de la FE (en MSS)
→ En cas de congestion
– l’émetteur ré-émet le paquet qui n’a pas été acquitté
– divise par 2 le seuil SEC
– repart en mode slow-start (FE = 1)
V1.1 octobre 2007
15/45

Les algorithmes de contrôle de congestion (slow start, congestion avoidance, fast retransmit, fast
recovery) sont standardisés par le RFC2581.
Les publications et implémentations de référence correspondantes sous Unix les plus connues
sont :
Tahoe (Jacobson 1988)
Slow Start
évitement de la congestion
Fast Retransmit
Reno (Jacobson 1990)
Fast Recovery
Vegas (Brakmo & Peterson 1994)
Nouvel algorithme d’évitement de la congestion
RED (Floyd & Jacobson 1993)
marquage probabiliste
REM (Athuraliya & Low 2000)
Clear buffer, match rate

15
 TCP : contrôle de flux (Tahoe)
→ Le contrôle de flux d’une session TCP se caractérise donc
– par un algorithme de gestion des FR et FE

pour chaque ACK {

si (FE < SEC) alors { FE++ } (Slow Start)
sinon { FE += 1/FE } (évitement de congestion)
}
pour chaque perte de segment TCP {
SEC = max(FE/2, 2) (on mémorise le fait qu’il a eu congestion)
FE = 1 (on repart en Slow Start)
}
En respectant les conditions FR > bande passante*RTT et FE < FR

– par un algorithme de détection de la congestion

• pas d’accusé de réception d’un segment émis au bout de RTO secondes
• réception de 3 ACK dupliqués (qui acquittent le même segment TCP)

V1.1 octobre 2007

16/45

Quand le récepteur reçoit un paquet déséquencé, il envoie à l’émetteur un ACK avec un numéro
de séquence inchangé. Cet envoi de ACK dupliqué permet à l’émetteur de s’apercevoir qu’un
segment n’est pas arrivé au récepteur. Au bout du 3ème ACK dupliqué reçu, l’émetteur ré-émet le
segment considéré comme perdu, sans attente le délai de RTO secondes : c’est le Fast
Retransmit.

16
 TCP : estimation RTT
→ Estimation du RTT (Round Trip Time)
– importante -> calcul d’un «bon» RTO (Retransmit Time Out)
– méthode :
• ERR = RTT mesurée -SRTT
• SRTT = SRTT + g*ERR (g = 0.125)
• D = D + h*(|ERR| - D) (h=0.25, D est une approximation de l’écart type)
→ Estimation du RTO
– pas de perte de segments : RTO = SRTT + 4*D
– en cas de perte de segment RTO = 2*RTO (avec RTO < 64s)

V1.1 octobre 2007

17/45

Initialement le RTO était calculé de la façon suivante :

SRTT = ( Alpha * SRTT ) + ((1-Alpha) * RTT), avec 0,8 < Alpha < 0,9 (facteur de lissage du RTT)
RTT est la valeur mesurée
SRTT est une moyenne glissante
RTO = min[UBOUND,max[LBOUND,(Beta*SRTT)]], avec 1,3 < Beta < 2 (facteur de variance du SRTT)
avec UBOUND : valeur supérieure du RTO, par exemple 1 minute
avec LBOUND : valeur inférieure du RTO, par exemple 1 seconde

Si le ACK d’un segment n’est pas reçu au bout de RTO secondes

- le segment est re-émis
- le RTO est doublé (avec RTO < 64 secondes)
- le nombre de retransmissions est limité à 12

17
 TCP : contrôle de flux (Tahoe)
→ Le contrôle de congestion Tahoe donne des graphes
d’évolution de la taille de la FE de ce type
Taille fenêtre Détection d’une congestion
en MSS
FR

SEC

Temps
en RTT
FE
V1.1 octobre 2007
18/45

Le diagramme ci-dessus est basé sur l’hypothèse que l’émetteur cherche à transmettre le plus
d’information possible.

La fermeture de la fenêtre d’émission après une détection de congestion est une mesure assez
brutale qui a l’avantage de protéger le réseau en limitant la bande passante consommée. Elle a
l’inconvénient de faire chuter le débit de la session TCP même pour des taux de perte de paquets
faibles.

Exercice 2 : trouver la formule donnant le temps nécessaire pour faire passer la FE de 87380
octets à 2076672 octets quand on est en mode évitement de congestion.
Application avec un MSS de 1460 octets et un RTT 300ms
Application avec un MSS de 9000 octets et un RTT 300ms

18
 Amélioration TCP : Fast Recovery
→ Buts
– ne pas retransmettre des segments bien arrivés (signalés par les ACK
dupliqués)
– relancer la transmission de segments au plus vite
→ Après 3 ACK dupliqués l’émetteur passe en Fast recovery
– SEC = max[flightsize/2, 2]
– le segment perdu est immédiatement retransmis (Fast Retransmit)
– FE = SEC + 3 (pas de slow start, inflation temporaire de la FE)
– FE est incrémenté à chaque nouveau ACK dupliqué reçu
– transmission de nouveaux segments si possible (cf. FE et FR)
– au premier ACK correspondant aux nouveaux segments transmis,
positionner FE à SEC et continuer en mode évitement de congestion

V1.1 octobre 2007

19/45

Le but de l’algorithme de Fast Recovery est d’optimiser le comportement de TCP pour des taux
de perte de paquets faibles (pas plus de 1 dans le flot de paquets en transit dans le réseau entre
émetteur et récepteur TCP). Dans cette hypothèse, l’arrivée d’un ACK dupliqué est à la fois une
mauvaise nouvelle (perte potentielle d’un segment) et aussi une bonne nouvelle (arrivée du
segment suivant).

Au bout de 3 ACK dupliqués on considère que le premier segment non acquitté est perdu et on le
retransmet. Dans l’hypothèse qu’il n’y pas eu d’autre perte de segment, il est donc légitime de
poursuivre le transmission de nouveaux segments si les FE et FR le permettent.

Il est tout aussi légitime de ne pas revenir en mode slow start.

La mémoire de l’indicent de tranmission est consigné dans la valeur de la FE qui est divisée par 2
à la fin de la phase de Fast Recovery.

19
 Amélioration TCP : Fast Recovery
→ Exemple

temps
récepteur

0 0 0 0 0 0 0 8 9 1011

émetteur 1 2 3 4 5 6 7 8 1 9 1011 12
FE = 8 7 8 9 .. 11 .. 11 4
SEC = 4 4 4 4

Fast Recovery

V1.1 octobre 2007

20/45

Une amélioration a été proposée dans le RFC2582 pour mieux prendre en compte une perte de
paquets multiple dans le flots de paquets en transit.

20
 Amélioration TCP : Reno

→ Reno = Tahoe + fast recovery

Taille fenêtre 3è ACK dupliqué
en MSS
FR

SEC

Temps
en RTT
FE
V1.1 octobre 2007
21/45

On note qu’à la suite d’une phase de Fast recovery, la FE est divisée par 2.

21
 Limites de TCP Reno
→ Problème si perte multiple de segments

temps
récepteur

0 0 0 0 2 2

émetteur 1 2 3 4 5 6 7 8 1 9
FE = 8 7 8 4
SEC = 4 4 4

Fast Recovery

V1.1 octobre 2007

22/45

Quand on sort de la phase de Fast Recovery, il faut attendre de détecter à nouveau 3 ACK
dupliqués pour recommencer une nouvelle phase de Fast Recovery, ce qui induit un délai
supplémentaire pour ré-émettre les segments perdus.

Dans l’exemple ci-dessus, après la deuxième phase de Fast Recovery, il n’y aura plus d’arrivée
de ACK dupliqués, il faudra donc attendre que minuteur RTO expire pour repartir en mode slow
start, en émettant le segment N°3.

Une amélioration a été proposée dans le RFC2582 pour mieux prendre en compte une perte de
paquets multiple dans le flots de paquets en transit.

22
 Amélioration TCP : Reno+SACK
→ Buts
– tenir compte des SACK pour
– rester en mode Fast Recovery
→ Après 3 ACK dupliqués l’émetteur passe en Fast recovery
– même mécanismes que vu précédemment avec en +
• retransmission du dernier segment perdu indiqué par un SACK
• émission d’un nouveau segment si S données reçues < FE
• sortie du mode Fast Recovery quand tous les segments perdus sont
acquités
→ Améliorations
– émission d’un segment perdu par RTT
– prolonge la phase de Fast Recovery, retarde/évite le passage en slow
start

V1.1 octobre 2007

23/45

23
 TCP Reno + SACK

temps
récepteur

0;2 0;4 0;6 0;8 2 4 6 8

émetteur 1 2 3 4 5 6 7 8 1 35 7
FE = 8 7 9 4
FE’ = 8 7 6 5 6 6 7 6

SEC = 4 4 4

Fast Recovery

V1.1 octobre 2007

24/45

Quand on sort de la phase de Fast Recovery, il faut attendre de détecter à nouveau 3 ACK
dupliqués pour recommencer une nouvelle phase de Fast Recovery, ce qui induit un délai
supplémentaire pour ré-émettre les segments perdus.

Dans l’exemple ci-dessus, après la deuxième phase de Fast Recovery, il n’y aura plus d’arrivée
de ACK dupliqués, il faudra donc attendre que minuteur RTO expire pour repartir en mode slow
start.

24
 TCP Reno : Synthèse
→ Diagramme global de gestion de la congestion

Slow start Retransmission

SE>SEC e co ndes
R TO s
Fast retransmit
Evitement de congestion
Fast recovery

3 ACK dupliqués

V1.1 octobre 2007

25/45

25
 Améliorations TCP : autres directions

→ Propositions modifiant la gestion de la fenêtre d’émission (FE)

→ évitement de congestion congestion
→ RENO FE = FE + 1 FE = FE*(1-1/2)
→ AIMD FE = FE + 32 FE = FE*(1-1/8)
→ STCP FE = FE + 0,01*FE FE = FE*(1-1/8)
→ HSTCP FE = FE + finc(FE) FE = FE*(1-fdec(FE))
– finc(FE) croît avec FE fdec(FE) décroît avec FE

→ Double objectif recherché par ces propositions

– permettre à TCP d’atteindre des très hauts débits (10Gb/s) rapidement
– bien prendre en compte les congestions (être TCP Friendly)

V1.1 octobre 2007

26/45

AIMD (Additive Increase Multiplicative Decrease) (Jumbo Frame, GridFTP, PFTP, Psockets)

HSTCP (High-Speed TCP) par Sally Floyd (ICIR, Berkeley)

STCP (Scalable TCP) by Tom Kelly par (Cambridge University)

FAST (Fast AQM Scalable TCP) par Steven Low (California Institute of Technology)

RFC 3742 : Limited Slow-Start for TCP with Large Congestion Windows (EXP, 2004)

26
 Améliorations TCP : résultats

1,0E+06
TCP
AIMD
1,0E+05
HSTCP
Throughput (Mbps)

STCP
1,0E+04

1,0E+03

1,0E+02

1,0E+01
1,0E-07 1,0E-06 1,0E-05 1,0E-04 1,0E-03 1,0E-02
Packet Loss Probability

V1.1 octobre 2007

27/45

Source du graphique : http://www.csc.ncsu.edu/faculty/rhee/export/bitcp

Voir aussi http://www-iepm.slac.stanford.edu/bw/tcp-eval/ pour des évaluations de différentes

implémentations de TCP.

27
 Améliorations TCP : BIC
→ BIC (Binary Increase Congestion) mix entre SCTP et HSTCP
→ évitement de congestion congestion
→ BIC FE = FE + f(FE, historique) FE = FE*(1-1/8)
Available Bandwidth
Wmax256
224
Smin

192
Linear Search

160 Binary Search with Smax and Smin

cwnd

128

96 Smax
64

32

0
Wmin 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Time (RTT)

V1.1 octobre 2007

28/45

Algorithme de gestion de la FE

tant que (Wmin <= Wmax) {

inc = (Wmin+Wmax)/2 - FE;
si (inc > Smax)
inc = Smax;
sinon si (inc < Smin)
inc = Smin;
FE = FE + inc;
si (aucune perte de paquets)
Wmin = FE;
sinon
break;
}
Wmax: valeur maximale pour la FE
Wmin: valeur minimale pour la FE
Smax: incrément maximum, valeur typique de 16 à 64 (MSS)
Smin: incrément minimum, valeur typique de 0,001 à 0,1(MSS)

28
 Performances TCP : points clés

→ sur l’émetteur TCP

– buffers, algorithme de gestion de la congestion, évolution FE, RTT

→ sur le récepteur TCP

– buffer de réception (min, max, évolution)

→ sur les deux

– vérifier les implémentation de TCP (Tahoe < Reno < NewReno <BIC)

V1.1 octobre 2007

29/45

Sous Linux, il est possible de changer l’algorithme de TCP.

Compilation des modules noyau, sous « make menuconfig », aller dans :
Networking->Networking options->TCP: advanced congestion control
et compiler les modules correspondants aux algorithmes choisis

Il existe des outils de simulation permettant de modéliser le fonctionnement d’un réseau et de

TCP les plus connus sont :

Network Simulator : http://www.isi.edu/nsnam/ns

Network Animator : http://www.isi.edu/nsnam/nam

29
 TCP : anlayse d’une session

→ La boîte à outils disponible

– capture des paquets : tcpdump, wireshark
– analyse la session TCP : wireshark, tcptrace+xplot, TcpPlot
– simulation et tests : iperf, iproute2+netem (Linux), NS2
→ 1ère méthodologie
– sur l’émetteur : capture et analyse d’une session
• wireshark : analyse fine, perte de segments, fermeture de la FR….
• tcptrace+xplot : analyse graphique des paramètres (RTT, FE, FR, pertes de
segments…) de la session
→ Exemples

V1.1 octobre 2007

30/45

Sites de référence des outils :

tcpdump : outil d’analyse et de capture de paquets IP et des protocoles supérieurs
http://www.tcpdump.org/

wireshark : idem tcpdump, mais en mode fenêtré

http://www.wireshark.org/

tcptrace et xplot : permettent de générer un ensemble de diagrammes temporels de sessions

TCP (RTT, bande passante, évolution des FE, FR, …). Nécessite xplot pour la visualisation.
http://jarok.cs.ohiou.edu/software/tcptrace/index.html
http://www.xplot.org/

tcpillust : trace des diagrammes temporels de sessions TCP (évolue peu depuis 2000)
http://www.csl.sony.co.jp/person/nishida/tcpillust.html

anontool, tcpurify : permettent d’anonymiser des captures de paquets IP

http://www.ics.forth.gr/dcs/Activities/Projects/anontool.html
http://masaka.cs.ohiou.edu/~eblanton/tcpurify/

30
 Analyse d’une bonne session TCP (1)

V1.1 octobre 2007

31/45

1 - mise en place iperf sur le serveur

serveur>iperf -s -V
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
2 - sondage iperf depuis le client
client>iperf -V -c serveur -t 5
------------------------------------------------------------
Client connecting to ipv6-serv, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 194.199.19.70 port 49360 connected with 194.199.17.34 port 5001
[ 3] 0.0- 5.0 sec 56.4 MBytes 94.5 Mbits/sec
3 - analyse de lma session capturée (en // avec wireshark ou tcpdump)
client>tcptrace -s -zxy -E10000 -G ex01
1 arg remaining, starting with 'ex01'
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004

706 packets seen, 706 TCP packets traced

elapsed wallclock time: 0:00:00.124994, 5648 pkts/sec analyzed
trace file elapsed time: 0:00:05.346061
TCP connection info:
1: client:56492 - serveur:5001 (a2b) 405> 301< (complete)
client>xplot -x a2b*

31
 Analyse d’une bonne session TCP (2)

V1.1 octobre 2007

32/45

Maniper avec xplot

pour zoomer : sélection la zone à agarndir avce le bouton gauche

pour dé-zoomer : « clic bouton gauche »

pour déplacer le graphique : donner le vecteur de translation avec le bouton du milieu

pour fermer la fenêtre : « clic bouton droit »

32
 Analyse d’une mauvaise session TCP (1)

V1.1 octobre 2007

33/45

Décode des couleurs à rajouter.

33
 Analyse d’une mauvaise session TCP (2)

V1.1 octobre 2007

34/45

34
 Le protocole DCCP

→ Assure ou permet
– contrôle de congestion (avec choix de l’algorithme possible)
• CCID=2 TCP like (similaire à AIMD, à privillégier)
• CCID=3 TCP-Friendly Rate Control (TFRC), meilleur lissage du débit
– connexion bi directionnelle ou unidirectionnelle (pas de ACK)
– ouverture/fermeture de la connection
– négociation d’options
→ Mais
– perte de paquets non récupérée, pas de multicast
→ Applications cibles
– flux de données importants (isochrones ou non)

V1.1 octobre 2007

35/45

Spécification DDCP
RFC4336 Problem Statement for the Datagram Congestion Control Protocol (DCCP)
S. Floyd, M. Handley, E. Kohler (INFO, 2006)
RFC4340 Datagram Congestion Control Protocol (DCCP) E. Kohler, M. Handley, S. Floyd,
(PS, 2006)
RFC4341 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2:
TCP-like Congestion Control S. Floyd, E. Kohler (PS, 2006)
RFC4342 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3:
TCP-Friendly Rate Control (TFRC) (PS, 2006)

Les contrôles de congestion autorisés sont ceux standardisés par l’IETF

Site du groupe de travail DCCP à l’IETF

http://www.ietf.org/html.charters/dccp-charter.html

Autres bons sites sur DCCP :

http://www.read.cs.ucla.edu/dccp/
http://linux-net.osdl.org/index.php/DCCP

35
 DCCP : format du paquet (1)
→ Paquet = en-tête générique+en-tête additionnelle+options+data
→ En-tête générique de 16 octets, toujours présent (X = 1)

Port source Port destination

Data offset CCval CsCov Somme de contrôle
Res Type X Réservé Numéro
de séquence

→ Si X = 0 (en-tête réduit à 12 octets)

Port source Port destination
Data offset CCval CsCov Somme de contrôle
Res Type X Numéro de séquence

V1.1 octobre 2007

36/45

Port source (16bits) : numéro identifiant la session DCCP sur la machine qui initie la session. Ce
numéro n’a pas de signification particulière.
Port destination (16bits) : numéro identifiant la session DCCP sur la machine qui reçoit la
demande d’ouverture de session. Ce numéro identifie en général un service donné.
Data offset (8bits) : longueur de l’entête DCCP en multiple de 4 octets. (en-tête <= 1024)
CCval (4bits) : Informations sur le contrôle de congestion (dépend du CCID)
CsCvov (4bits) : (Checksun Coverage). Couverture de la somme de contrôle (en plus de l’en-tête
qui est toujours incluse)
Somme de contrôle (16bits) : couvre l’ensemble du paquet DCCP en-tête + données
Res (4bits) : réservé
Type (4bits) : type du paquet. Il existe 10 type possibles pour un paquet DDCP : DDCP-Request,
DDCP-Response, DDCP-Data, DDCP-Ack, DDCP-DataAck, DDCP-CloseReq, DDCP-Close,
DDCP-Reset, DDCP-Sync, DDCP-SyncAck.
X (1bit) : donne la longueur des numéros de séquence (X=1 -> 48 bits, X=0 -> 24bits)
Réservé : 0 bits si X=1, 8 bits si = X=0
Numéro de séquence (24 ou 48bits) : Numéro du paquet. dans le flot de paquets en incluant les
paquets de contrôle. Si le Type est DDCP-Request est positionné, c’est la valeur initiale du
numéro de séquence (choisie aléatoirement à priori).

Par rapport à TCP

-pas de champ Window (Fenêtre de réception)
-pas de pointeur Urgent

36
 DCCP : format du paquet (2)

→ L’en-tête aditionnelle (dépent du type de paquet)

– Exemple : tous types sauf DCCP-Request DCCP-Data (X=1)

Réservé Numéro de
séquence d’acquitement

– Si X = 0 (en-tête additionnelle réduite à 4 octets)

Réservé Numéro de séquence d’acquitement

→ Options
– données complémentaires (dépend du type de paquets)
– ex : négociations de fonctionnalités, contrôle de congestion, ACK

V1.1 octobre 2007

37/45

Numéro de séquence d’acquitement (24 ou 48bits) : c’est (en général) le plus grand de tous les
numéros de séquence de paquets reçus.

37
 DCCP : conclusion

→ Pour
– Design intéressant (intermédiaire entre UDP et TCP)
– peut simplifier l’écriture d’applications (prise en charge congestion)
– introduit moins de variation de délai que TCP
→ Mais
– implémentation complexe (en-tête variable, options, négociations)
– peu déployé à ce jour bien que disponible (Linux, BSD)

V1.1 octobre 2007

38/45

38
 Le protocole SCTP

→ Association entre deux hôtes

– support de la multi-domicilation aux deux extrémités
– plusieurs flux par plusieurs chemins (liés aux interfaces)
– contrôle de congestion par flux
– meilleure sécurité contre : inondation de SYN, homme du milieu
– haute disponibilité du canal de communication entre les hôtes
→ Plusieurs mode de transmission
– flots d’octets (comme TCP)
– ordre partiel (par flux)
– sans ordre garanti (comme UDP)

V1.1 octobre 2007

39/45

39
 SCTP : format du paquet (1)
→ Paquet = en-tête générique+blocs de données

Port destination Port source

En-tête commun Champ de vérification

Block données 1 Somme de contrôle

.....
..... Type Flags Longueur bloc

Block données n Paramètres et données

du bloc

V1.1 octobre 2007

40/45

Port source (16bits) : numéro identifiant la session SCTP sur la machine qui initie la session. Ce
numéro n’a pas de signification particulière.
Port destination (16bits) : numéro identifiant la session SCTP sur la machine qui reçoit la
demande d’ouverture de session. Ce numéro identifie en général un service donné.
Somme de contrôle (32bits) : couvre l’ensemble du paquet SCTP en-tête + données

Type (8bits) : type du bloc de données

Flags (8bits) : drapeaux associés au bloc de données. Peut prndre les valeurs
- U : données sans ordre particulier
- B : début d’un fragment
- E : fin d’un fragment
Longueur du bloc (16bits) : longueur de l’entête DCCP en multiple de 4 octets.

40
 SCTP : ouverture de session
→ Association en 4 étapes
Serveur Client
Closed Closed
Le serveur crée
un cookie mais «- INIT -»INIT
ne réserve pas de -»INIT-ACK
ressources système
Closed Cookie-wait
«- INIT-ACK
«- COOKIE-ECHO -»COOKIE-ECHO
-»COOKIE-ACK
Cookie-echoed
«- COOKIE-ACK
Established

-le client doit rester visible du serveur Meilleure protection contre

==>
-la consommation de ressources équilibrée le déni de service
V1.1 octobre 2007
41/45

L’initialisation de la session SCTP se fait par un échange de 4 paquets (3 pour TCP) ce qui rend
plus symétrique le rôle des deux participants et limite les possibilités d’attaque en déni de service.

41
 SCTP : la multi domicilation
→ Plusieurs interfaces par hôtes peuvent participer à l’association
– le Init-Ack contient toutes les @IP participant à l’association
– un des chemins est choisi comme chemin primaire (données+contrôle)
– le/les chemins de secours peuvent être utilisés pour les retransmissions
– surveillance des chemins par « chien de garde »

Internet

V1.1 octobre 2007

42/45

42
 SCTP : le multi-flux

→ Une application (vidéo) = de plusieurs flux de données

– vidéo, son_droit, son_gauche, sous_titres, infos de contrôle….
– ces flux sont pris en charge directement par SCTP
• TSN : N° du paquet SCTP
• SSN : N° du bloc dans le flux
Type Flags Longueur bloc
• SI : identifiant de flux
TSN
• PPI : Protocole associé aux données
SI SSN
PPI
Données
du bloc

V1.1 octobre 2007

43/45

43
 SCTP : conclusion

→ Pour
– haute disponibilité native du canal de communication
– le multi-flux de données applicatives
– prise en compte de la mobilité (modif des @IP d’une associaton)

→ Mais
– implémentation complexe (en-tête variable, options, négociations)
– peu déployé à ce jour bien que disponible (Linux, BSD)
– coexistence avec IPsec ?

V1.1 octobre 2007

44/45

Le protocole de transport SCTP (version pratially reliable) est par exemple utilisé par IPFIX. Il est
aussi utilisé par Cisco pour le transport de la signalisation de la téléphonie sur IP.

44
 Dernier diagramme

Votre serviteur Vous

Fin-wait ???????
-» REPONSES -» QUESTIONS

Fin-wait ??
-» QUESTIONS
-» REPONSES
.

Pause

V1.1 octobre 2007

45/45

45