Métrologie et performances réseau

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 1

Plan de l exposé Les protocoles de transport (principales caractéristiques) UDP TCP : exposé détaillé DCCP SCTP RTP/RTCP, RTSP 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 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 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 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 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 Longueur Port destination Somme de contrôle Données (longueur variable) 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) 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 -»FIN «- SYN -»SYN, ACK Listen Closed SYN received -»ACK du SYN Established Serveur Client -»SYN «- SYN -»ACK «- SYN, ACK -»ACK SYN sent -»SYN -»FIN «- FIN -»ACK Fin wait-1 -»ACK du FIN Fin wait-2 «- FIN -»ACK «- FIN -»ACK Closing Time wait -»ACK du FIN timeout Close wait -»FIN Last-ACK Closed -»ACK du FIN 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 S F offset R C S S Y I fenêtre G K H T N N Somme de contrôle Options Pointeur urgent Bourrage Données applicatives à transmettre 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) 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 20 octets Données TCP Paquet IP En-tête IP Données IP En-tête 20/40 octets (v4/v6) Données Ethernet 14 octets 4 octets MTU 1500 octets 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 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 Segment Réception ACK émetteur 1 2 4 temps taille de la FE (en MSS) RTT 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

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 TCP : contrôle de flux (émetteur) émetteur En cas de congestion 4 5 6 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) temps taille de la FE (en MSS) 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) 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) 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 en MSS FR Détection d une congestion SEC FE Temps en RTT 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 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 récepteur temps 0 0 0 0 0 0 0 8 9 1011 émetteur 1 2 3 4 5 6 7 8 1 9 1011 12 FE = SEC = 8 7 4 8 9.. 11.. 11 4 4 4 4 Fast Recovery 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 en MSS FR 3è ACK dupliqué 3 SEC FE Temps en RTT 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 récepteur temps 0 0 0 0 2 2 émetteur FE = SEC = 1 2 3 4 5 6 7 8 8 1 7 4 9 8 4 4 4 Fast Recovery 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 23/45 23

TCP Reno + SACK récepteur temps 0;2 0;4 0;6 0;8 2 4 6 8 émetteur FE = 1 2 3 4 5 6 7 8 1 3 5 7 8 7 9 4 FE = 8 7 6 5 6 6 7 6 SEC = 4 4 4 Fast Recovery 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 SE>SEC Evitement de congestion RTO secondes Retransmission Fast retransmit Fast recovery 3 ACK dupliqués 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) 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 Throughput (Mbps) 1,0E+06 1,0E+05 1,0E+04 1,0E+03 TCP AIMD HSTCP STCP 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/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) Wmax 256 224 Smin Available Bandwidth 192 160 Linear Search Binary Search with Smax and Smin cwnd 128 96 64 Smax 32 Wmin 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Time (RTT) 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) 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 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) 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) 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) 33/45 Décode des couleurs à rajouter. 33

Analyse d une mauvaise session TCP (2) 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) 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 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 Si X = 0 (en-tête additionnelle réduite à 4 octets) séquence d acquitement 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 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) 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) 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 Block données 1 Champ de vérification Somme de contrôle.......... Type Flags Longueur bloc Block données n Paramètres et données du bloc 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 Le serveur crée un cookie mais ne réserve pas de ressources système Serveur Closed Closed «- INIT -»INIT-ACK «- COOKIE-ECHO -»COOKIE-ACK Client Closed -»INIT Cookie-wait Cookie-echoed «- INIT-ACK -»COOKIE-ECHO Established «- COOKIE-ACK -le client doit rester visible du serveur -la consommation de ressources équilibrée ==> Meilleure protection contre le déni de service 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 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 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? 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 Fin-wait Fin-wait -» REPONSES -» REPONSES Vous??????? -» QUESTIONS??. -» QUESTIONS Pause 45/45 45