Академический Документы
Профессиональный Документы
Культура Документы
Métrologie
http://www.inria.fr http://gt-metro.grenet.fr
Luc.Saccavini@inria.fr
1
Plan de l’exposé
2
Présentation des protocoles sur IP (1)
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)
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)
Un des objectifs de DDCP est d’être moins «agressif» qu’UDP vis à vis de la bande passante.
5
Présentation des protocoles sur IP (4)
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
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.
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)
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
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
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)
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
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)]
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)
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
13
TCP : contrôle de flux (émetteur)
é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.
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
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)
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
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.
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
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
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
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
23
TCP Reno + SACK
temps
récepteur
é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
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
SE>SEC e co ndes
R TO s
Fast retransmit
Evitement de congestion
Fast recovery
3 ACK dupliqués
25
Améliorations TCP : autres directions
AIMD (Additive Increase Multiplicative Decrease) (Jumbo Frame, GridFTP, PFTP, Psockets)
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
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
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)
Algorithme de gestion de la FE
28
Performances TCP : points clés
29
TCP : anlayse d’une session
tcpillust : trace des diagrammes temporels de sessions TCP (évolue peu depuis 2000)
http://www.csl.sony.co.jp/person/nishida/tcpillust.html
30
Analyse d’une bonne session TCP (1)
31
Analyse d’une bonne session TCP (2)
32
Analyse d’une mauvaise session TCP (1)
33
Analyse d’une mauvaise session TCP (2)
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)
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)
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 (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).
36
DCCP : format du paquet (2)
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
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)
38
Le protocole SCTP
39
SCTP : format du paquet (1)
→ Paquet = en-tête générique+blocs de données
.....
..... Type Flags Longueur bloc
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
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
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
42
SCTP : le multi-flux
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 ?
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
Fin-wait ???????
-» REPONSES -» QUESTIONS
Fin-wait ??
-» QUESTIONS
-» REPONSES
.
Pause
45