PLAN Origines de TCP-IP Les protocoles de transport UDP TCP Fonctions Ports UDP TCP Éléments de base de TCP Fiabilité Fenêtres Reprise sur erreurs Algorithmes de contrôle de congestion Transport Layer

Adresse IP Transport Layer

Origine de TCP/IP Transport Layer

TCP-IP: origine Commutation de paquets Approche « informatique » vs « télécom » Expérimentations de chercheurs Approche intégrée : des applications aux outils techniques Approche de complémentarité par rapport à l’existant Déploiement rapide Devient standard de fait Internet Le Web Transport Layer

Interconnexion de réseaux Les réseaux d'entreprise Les passerelles Les protocoles Les adresses Le monde TCP-IP A B C Réseau 1 Réseau 3 P1 P2 Réseau 2 Réseau 4 D G E F Transport Layer

Transport Layer

L’architecture Internet Transport Layer

L’architecture TCP/IP L’architecture TCP/IP contient trois niveaux protocolaires : Le niveau IP (Internet Protocol) qui est un niveau paquet. Le niveau TCP (Transmission Control Protocol) qui regroupe les niveaux message et session. Le niveau applicatif qui regroupe les niveaux présentation et application. Il est à noter que l’architecture TCP/IP s’appuie sur des niveaux trames quelconque. Transport Layer

Architecture TCP-IP Machine A Passerelle Machine D Applications standards Applications standards Transport Transport Protocole IP Protocole IP Protocole IP Protocole d'accès à R1 R1 R2 Protocole d'accès à R2 Réseau R1 Réseau R2 Transport Layer

Bordure du réseau : services 2 types de services de transport fournis par Internet (et, plus généralement, les réseaux TCP/IP) : Service orienté connexion Service sans connexion Lors de la création d'une application Internet, le développeur doit choisir l'un de ces services. Transport Layer

Bordure du réseau : service en mode connecté Objectif : Transfert de données entre terminaux Handshake : établissement de la connexion avant le transfert de données Échange de messages de contrôle Comme dans les protocoles humains Pourquoi orienté connection ? Seuls les hôtes connaissent cette connexion, les routeurs l'ignorent Allocation des ressources et définition d’états dans les deux hôtes TCP - Transmission Control Protocol Service en mode connecté sur Internet Transport Layer

Flashback Protocoles réseau : Relient des machines Toutes les communications sur Internet sont gouvernées par des protocoles Les machines qui communiquent doivent utiliser le même protocole Connexion TCP req. Connection TCP réponse. <file> Transport Layer

Bordure du réseau : service en mode connecté Service TCP [RFC 793] 3-way handshake Transfert de données fiable transmission de tous les flots d'octets sans erreur et dans l’ordre acquittements et retransmissions Contrôle de flot: L’émetteur ne submerge pas le récepteur : adaptation du débit d'émission Contrôle de congestion : Pour éviter de saturer les buffers des routeurs L’émetteur réduit son débit d’émission quand le réseau est congestionné Alerte pour les hôtes : plus d'acquittement des données Transport Layer

Bordure du réseau : service en mode connecté Transport fiable, contrôle de flux et de congestion non obligatoires dans un service orienté connexion Service orienté connexion : handshake TCP = service de transport en mode connecté d'Internet fournit des fonctionnalités supplémentaires Au niveau de l'application : Connaissance des services fournis Aucune idée de la façon dont ce service est fourni Architecture en couches Transport Layer

Bordure du réseau : service en mode non connecté Objectif : Transfert de données entre terminaux L’objectif ne change pas Service en mode non connecté sur Internet = UDP - User Datagram Protocol [RFC 768] Pas d'établissement de connexion Données émises immédiatement Transfert de données non fiable Pas d'acquittement : on ignore si les paquets sont arrivés ou non Pas de contrôle de flux Pas de limitation du débit d'émission Pas de contrôle de congestion Transport Layer

Bordure de réseau : service en mode non connecté Applications utilisant TCP : HTTP (WWW) FTP (transfert de fichiers) Telnet (login distant) SMTP (email) Applications utilisant UDP : Streaming d'audio et de vidéo Visioconférence Téléphonie sur Internet Transport Layer

Rôle du transport Transport Layer

Le principe du bout en bout Pas d’intelligence dans le réseau Traitement simple dans le réseau -> haut débit Réseau généraliste -> évolution de l’utilisation du réseau Pas de redondance de contrôle Séparation des fonctions Contrôle -> hôte Acheminement -> routeur Bout en bout Hôte Hôte Protocole IP Routeur Protocole IP Transport Layer

Services et protocoles de transport Fournissent une communication logique entre des processus applicatifs s’exécutant sur des hôtes différents transport protocols run in end systems transport vs network layer services: network layer: data transfer between end systems transport layer: data transfer between processes relies on, enhances, network layer services application transport network data link physical network data link physical network data link physical network data link physical logical end-end transport network data link physical network data link physical application transport network data link physical Transport Layer

Principe du bout en bout Service réseau Modes d’acheminement Circuit virtuel Datagramme Mode non connecté et sans garantie Robustesse Indépendance du fonctionnement Le fonctionnement du système d’extrémité n’est pas lié à celui du réseau Transport Layer

Fonction des protocoles de transport Protocoles de bout en bout (pas comme à la couche réseau par exemple) Service connecté ou non fiabilité performance Transport d’un message d’un émetteur au récepteur Indépendamment des réseaux qui véhiculent l’information Pas de connaissance sur les réseaux traversés « Interface » entre les applications et le réseau S’appuie sur des protocoles (des couches basses) pour l’acheminement des données. Deux protocoles principaux : TCP : fiabilité, contrôle d’erreur, de flux, d’ordre UDP : Vérification des erreurs Transport Layer

Rôle du Transport Général A la demande de l'application Communication inter-process Identification des points d‘extrémités Bout en bout A la demande de l'application Contrôle des échanges Corriger les défauts du service réseau Compte rendu sur la performance de la communication Construction du service attendu par les applications distinct de celui fourni par la couche réseau Mode connecté fiable, sur un réseau datagramme non fiable Séparation du service fourni par l’opérateur et offert à l’utilisateur Transport Layer

Ports Pour identifier une cible plus spécifique que l’adresse IP car les datagrammes sont destinés à des process et pas au système. PID -> trop dynamique par un point d’extrémité: le port n° de port sur 2 octets Ceci est réalisé avec les ports 16-bits qui identifient quel process est associé à quel datagramme. Attachement du processus au port Identification: (@ IP, n° port) Deux types de ports : well-known : appartiennent aux serveurs standards Numéro impair entre 1 et 1023 Utilisation d’un seul port sauf BOOTP (ports 67 et 68) telnet utilise le port 23 Permettent aux clients de trouver des serveurs sans information de configuration ephemeral Les clients utilisent des ports spécifiés dans les paquets UDP Entre 1024 et 5000 habituellement <transport protocol, IP address, port number> doit être unique. Transport Layer

Multiplexing/demultiplexing Recall: segment - unit of data exchanged between transport layer entities aka TPDU: transport protocol data unit Demultiplexing: delivering received segments to correct app layer processes receiver P3 P4 application-layer data M M application transport network segment header P1 P2 M M application transport network application transport network segment H t M H n segment Transport Layer

Multiplexing/demultiplexing gathering data from multiple app processes, enveloping data with header (later used for demultiplexing) 32 bits source port # dest port # other header fields multiplexing/demultiplexing: based on sender, receiver port numbers, IP addresses source, dest port #s in each segment recall: well-known port numbers for specific applications application data (message) TCP/UDP segment format Transport Layer

Multiplexing/demultiplexing: examples source port: x dest. port: 23 Web client host C host A server B source port:23 dest. port: x Source IP: C Dest IP: B source port: y dest. port: 80 Source IP: C Dest IP: B source port: x dest. port: 80 port use: simple telnet app Source IP: A Dest IP: B source port: x dest. port: 80 Web server B Web client host A port use: Web server Transport Layer

TSAP/NSAP Host 1 Host 2 Application Couche transport Couche réseau Serveur Couche transport TSAP n TSAP m La connexion transport commence ici La connexion réseau commence ici Couche réseau NSAP Couche liaison Couche physique Transport Layer

Adressage TSAP Transport Service Access Point Scénario de connexion Identification des applications en communication Ex : adresse IP + Port Scénario de connexion Serveur sur host2 associé au TSAP n Client sur host1 s’associe localement au TSAP m (source) et demande le TSAP n sur host 2 (destination) Établissement de la connexion réseau entre la source (host 1) et la destination (host 2) Demande d’établissement d’une connexion au niveau transport entre TSAP n et TSAP m Validation Transport Layer

Problèmes de transport Etablissement de connexion Déséquencement Entité de transport A transport B TPDU CR TPDU CC TPDU DT ou AK TPDU DT Etablissement en 3 étapes entité de entité de transport B transport A TPDU demande de connexion TPDU de données TPDU confirmation de connexion Transport Layer

Three Way handshake Etablissement d’une connexion bidirectionnelle avec des numéros de séquence indépendants Utilisation d’un échange de 3 TPDU CONNECTION_REQUEST Init. Envoie son numéro de séquence vers la destination CONNECTION_ACCEPTED Acquittement et envoi de numéro de séquence DATA Init. Acquitte avec les premières données vers le destinataire Transport Layer

Problèmes de transport Perte Temporisateur de retransmission Difficulté: dimensionnement Transport Layer

Problèmes de transport Etablissement de connexion Survivance A B ouverture d'une connexion entre A et B TPDU DT 0 TPDU AK 1 T1 TPDU DT 1 TPDU AK 2 TPDU DT 1 fermeture de la connexion établissement d'une nouvelle connexion La TPDU DT 1 est reçue sans erreur mais hors séquence Elle est gardée en attente de reséquencement Duplication Non Détéctée . TPDU DT 0 TPDU AK 2 TPDU DT 1 La seconde TPDU DT 1 est détectée comme dupliquée Elle est écartée mais acquittée La TPDU DT 0 ayant été reçue, l'acquittement peut se faire Perte Non Détéctée Transport Layer

Etablissement d’une connexion : bilan Envoi d’un CONNECTION_REQUEST TPDU, avec possibilité de Perte Mémorisation Duplication Eviter la duplication avec Génération d’un nouveau TSAP à chaque connexion Utilisation d’identificateurs uniques de connexion (état) Élimination des anciens (=TTL mais circulaire) Transport Layer

Pipelined protocols Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver Two generic forms of pipelined protocols: go-Back-N, selective repeat Transport Layer

Go-Back-N Sender: k-bit seq # in pkt header “window” of up to N, consecutive unack’ed pkts allowed ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may deceive duplicate ACKs (see receiver) timer for each in-flight pkt timeout(n): retransmit pkt n and all higher seq # pkts in window Transport Layer

GBN in action Transport Layer

Selective Repeat receiver individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order delivery to upper layer sender only resends pkts for which ACK not received sender timer for each unACKed pkt sender window N consecutive seq #’s again limits seq #s of sent, unACKed pkts Transport Layer

Selective repeat: sender, receiver windows Transport Layer

Selective repeat receiver sender data from above : if next available seq # in window, send pkt timeout(n): resend pkt n, restart timer ACK(n) in [sendbase,sendbase+N]: mark pkt n as received if n smallest unACKed pkt, advance window base to next unACKed seq # pkt n in [rcvbase, rcvbase+N-1] send ACK(n) out-of-order: buffer in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt pkt n in [rcvbase-N,rcvbase-1] ACK(n) otherwise: ignore Transport Layer

Selective repeat in action Transport Layer

Selective repeat: dilemma Example: seq #’s: 0, 1, 2, 3 window size=3 receiver sees no difference in two scenarios! incorrectly passes duplicate data as new in (a) Q: what relationship between seq # size and window size? Transport Layer

Protocoles de bout en bout : bilan Réseau “best effort” sous jacent Perte de paquets Dé-séquencement Limite la taille des paquets Temps de transfert aléatoire Services courants de bout en bout Remise garantie des messages Séquencement Taille des messages quelconque Synchronisation récepteur - émetteur Plusieurs processus applicatif sur une même machine Transport Layer

Problèmes de transport Contrôle de flux Adaptatif: fenêtre à taille variable Dissociation du rôle des ACK: Contrôle d’erreur Numérotation séquentielle (modulo 2 7 ou 2 31 ) CDT A B ACK2, CDT=3 DT2 DT3 DT4 ACK5, CDT=0 DT0 DT1 ACK5, CDT=1 DT5 • Dernier octet acquité Fenêtre Limite supérieure de fenêtre Transport Layer

Problèmes de transport Libération Brutale Ordonnée Action synchronisée sur réseau non fiable utilisateur fournisseur T_DATA.ind T_DISC.req T_DATA.req absence de T_DATA.ind après le T_DISC.req Temporisateur d’effacement effacement de connexion DR DC AK t emporisateur de retransmission A B DT3 AK6 DT8 AK10 DT4 CR5 T_CLOSE.request T_CLOSE.indication Fermeture effective de la demi-conexion CR9 T_DATA.indication T_DATA.request Transport Layer

Terminaison de connexion Symétrique Terminaison indépendante des deux directions Fin de connexion lorsque chaque extrémité à terminé Asymétrique Fin de connexion dès qu’une des extrémités le demande Petres possibles car plus de données acceptées après le DR Transport Layer

Automate d’état Transitions déclenchées par des Passive establishment pending Active establishment Pending Establishment Connection request TPDU received Connection primitive executed Connection accepted TPDU received IDLE Transitions déclenchées par des primitives locales ou des arrivées de TPDU Passive disconnect pending Active disconnect pending IDLE Disconnect primitive executed Disconnect request TPDU received Disconnection request Transport Layer

UDP Transport Layer

UDP RFC 768 Numéro de protocole 17 quand transporté par IP. Interface d’application pour IP Pas de fiabilité, contrôle de flux ou récupération sur erreur. Aucun contrôle sur le flot -> simplicité Peu d’overhead, mécanisme minimaliste Mode datagramme, non connecté (orienté message) “multiplexer/demultiplexer'' pour envoyer/recevoir des datagrammes, en utilisant des ports pour diriger ces datagrammes. Qualité “best effort” création d’un paquet et transmission immédiate au niveau IP Attention : pas de contrôle de congestion Transport Layer

UDP: User Datagram Protocol [RFC 768] “no frills,” “bare bones” Internet transport protocol “best effort” service, UDP segments may be: lost delivered out of order to app connectionless: no handshaking between UDP sender, receiver each UDP segment handled independently of others Why is there a UDP? no connection establishment (which can add delay) simple: no connection state at sender, receiver small segment header no congestion control: UDP can blast away as fast as desired Transport Layer

Communication entre les couches process 1 process 2 process n port x port y port z UDP : démultiplexage de ports IP Transport Layer

Datagrammes UDP (1) Port Source Port Destinataire Longueur : indique le numéro de port du processus émetteur, toute réponse y est dirigée. Port Destinataire Longueur : nombre d'octets dans le datagramme entier (avec en-tête). >8 Transport Layer

Datagrammes UDP (2) Contrôle d’erreur Optionnel en IPv4, obligatoire en IPv6 Pseudo-header + en-tête + données Pseudo-header: @ IP source @ IP destination protocole Transport Layer

UDP checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment Receiver: compute checksum of received segment check if computed checksum equals checksum field value: NO - error detected YES - no error detected. But maybe errors nonethless? More later …. Sender: treat segment contents as sequence of 16-bit integers checksum: addition (1’s complement sum) of segment contents sender puts checksum value into UDP checksum field Transport Layer

Applications d’UDP la signalisation de certains protocoles Trivial File Transfer Protocol (TFTP) Domain Name System (DNS) name server Remote Procedure Call (RPC), utilisé par Network File System (NFS) Network Computing System (NCS) Simple Network Management Protocol (SNMP) applications temps réel, visio et audio conférences applications nécessitant transmission multipoint (multicast) exemple : applications du MBONE, sdr, tableau blanc, etc Transport Layer

UDP: more other UDP uses (why?): often used for streaming multimedia apps loss tolerant rate sensitive other UDP uses (why?): DNS SNMP reliable transfer over UDP: add reliability at application layer application-specific error recover! 32 bits source port # dest port # Length, in bytes of UDP segment, including header length checksum Application data (message) UDP segment format Transport Layer

TCP Transport Layer

TCP RFC 793 - Transmission Control Protocol 90% du trafic Principes Bonne utilisation des ressources du réseau Couche de transport des systèmes d’extrémités (i.e. utilisateurs des données) Communication bidirectionnelle et point à point sur des réseaux hétérogènes Transfert fiable de données ( UDP) Contrôle de perte Contrôle de flux Contrôle de congestion: interaction hôte-réseau réactive et agréssive TCP suppose que les couches de communication qui lui sont inférieures lui procurent un service de transmission de paquet simple, dont la qualité n'est pas garantie. Mode connecté et commutation de paquets Orienté flux d’octets: application écrit des octets TCP émet des segments application lit des octets Récepteur le plus simple possible -> complexité chez l’émetteur interopérabilité maximum recherchée Utilisé parTELNET, FTP, HTTP … Transport Layer

Caractéristiques de TCP Flot d’octets Séquencés Segmentation des données au niveau TCP Circuit virtuel en mode connecté La connexion est établie et considérée comme un circuit physique fiabilité Transfert bufferisé Attendre d’avoir assez de données pour émettre (performance) Full duplex Pour les ACKs Application process Application process Octets lus … Octets écrits … TCP TCP Buffer émission Buffer réception … Segment Segment Segment T Segments transmis Transport Layer

Caractéristiques de TCP Numéros de séquence indépendants dans les 2 directions Associés à chaque octets Indique le numéro du premier octet transmis Mots de 32 bits Bouclage théorique en moins de 6 minutes à 100 Mbps mais en pratique, c’est beaucoup plus long ! Utilisé pour les acquittements Si N octets sont délivrés du paquet avec le numéro de séquence X, l’acquittement aura la valeur X+N (soit le numéro du prochain octet à recevoir) Piggybacking Les deux numéros sont présents dans les mêmes paquets Transport Layer

Caractéristiques de TCP Fiabilité Numéro de séquence Détection des pertes : Aquittements positifs (ACK) du récepteur -> OK Pas d’ACK -> timeout (temporisation) -> retransmission ACK dupliqué Réordonnancement des paquets au récepteur Elimination des paquets dupliqués Checksum Retransmissions : Selective repeat Go back N Contrôle de flux par annonce de fenêtres Fenêtre modulée par le récepteur Inclus dans l’ACK Fenêtre qui indique le plus grand numéro de séquence pouvant être reçu Erreur = congestion Contrôle de congestion : adaptation à l’état d’occupation du réseau Sans signalisation réseau Orienté connexion Transport Layer

Caractéristiques de TCP Multiplexage Pour permettre à plusieurs tâches d'une même machine de communiquer simultanément via TCP, le protocole définit un ensemble d'adresses et de ports pour la machine. Une "socket" est défini par l'association des adresses Internet source, destinataire, ainsi que les deux numéros de port à chaque extrémité. Une connexion nécessite la mise en place de deux sockets. Une socket peut être utilisée par plusieurs connexions distinctes. L'affectation des ports aux processus est établie par chaque ordinateur. Transport Layer

Segments Les octets de données sont accumulés jusqu’au moment où TCP décide d’envoyer un segment Découpage en segment indépendant du découpage au niveau application MSS = longueur maximale d’un segment Application Buffer d’émission TCP TCP header IP header IP Transport Layer

Sockets Deux process communiquent par des sockets TCP qui fournissent aux process un flux de données full duplex. Ports éphémères Port = TCP TSAP = numéro sur 16 bits Valeur locale 0 à 255 : well-known 0 à 1023 : ports système 1024 à 65536 : ports utilisateurs Une socket TCP : Triplet <TCP, IP address, port number>. Une connexion TCP : 2 sockets <TCP, local IP address, local port, remote IP address, remote port>. Transport Layer

BSD Sockets Primitives pour TCP utilisées par les UNIX BSD SOCKET (création d’un nouveau point terminal) BIND (attache une adresse à la socket) LISTEN (acceptation des connexions avec file d’attente) ACCEPT (acceptation bloquante) CONNECT (établissement actif de connexion) SEND (envoi de données sur une connexion) RECEIVE (réception de données d’une connexion) CLOSE (terminaison d’une connexion) Serveur : SOCKET -> BIND -> LISTEN -> ACCEPT … [SEND, RECEIVE]… -> CLOSE Client : SOCKET –> BIND -> CONNECT … [SEND, RECEIVE]…-> CLOSE Transport Layer

Communication entre applications Données process 1 process 2 connexion TCP header port:x Données port x port y socket connexion TCP fiable TCP TCP IP IP Adresse IP paquets IP non fiable Transport Layer Hôte 1 Hôte 2

Problèmes pour TCP Connexion avec des hôtes différents RTT variable Établissement et libération de connexion RTT variable adaptation de la temporisation Survivance de paquets (très long délai de transfert) Attention aux arrivées de très vieux paquets Capacité de stockage dynamique des extrémités “Apprendre” les ressources disponibles Capacité de la route varie dans le réseau Ajuster le débit d’émission à la bande passante Transport Layer

Vie d’une Connexion Si deux processus désirent communiquer, établissement d’une connexion TCP Internet => best effort on utilise donc une méthode d'initialisation par négociation bilatérale basée sur une horloge pour les numéros de séquence. A la fin de la connexion Fermeture qui libère les ressources 3 phases Ouverture d’une connexion Transfert de données Fermeture de la connexion Transport Layer

Établissement d’une connexion Appel OPEN passif (serveur)/actif (client) Fermeture d’une connexion avec le bit FIN (à faire dans les deux sens) Process 1 Process 2 Passive open attend une requête active Active OPEN Send SYN, seq=n Receive SYN Send SYN, seq=m, ACK=n+1 Receive SYN+ACK Send ACK=m+1 Transport Layer

Connexion TCP Trois phases Etablissement de la connexion Transfert des informations avec Contrôle de flux Contrôle de congestion Libération de la connexion Transport Layer

Etablissement de la connexion TCP Procédure à trois échanges Three way handshake ISN (Initial Sequence Number) Numéro de séquence du premier octet d’information transporté Le premier octet transporté est alors ISN+1 ISN est généralement dérivé de l’horloge de l’hôte Transport Layer

Exemple Transport Layer

Libération de la connexion Normale Fin demandée par l’une des extrémités (flag FIN=1) Terminaison brutale Envoi de la primitive ABORT (flag RST=1) Toutes les transmissions ou réceptions sont interrompues et les tampons sont vidés Transport Layer

Automate TCP Close/- Close/- Listen/- Connect/SYN Transport Layer SYN RCVD SYN SENT Connect/SYN Close/- Send/SYN SYN/SYN+ACK CLOSED LISTEN Listen/- Close/- RST/- SYN/SYN+ACK Simultaneous open CLOSE/FIN ESTABLISHED ACK/- SYN+ACK/ACK CLOSE WAIT LAST ACK PASSIVE CLOSE CLOSE/FIN FIN/ACK FIN WAIT 1 FIN WAIT 2 CLOSING TIME WAIT ACTIVE CLOSE FIN/ACK FIN+ACK/ACK ACK/- ACK/- CLOSED Timeout/- Transport Layer

Transfert de données Segmentation Contrôle de perte (fiabilité) Découpage du flux en segments selon la MTU locale Numérotation des octets Gel du numéro de séquence pendant MSL (Maximum Segment Lifetime) Contrôle de perte (fiabilité) Acquittement positif Protection par temporisateur de retransmission chez l'émetteur uniquement Contrôle de flux (optimisation des ressources disponibles) fenêtres à taille variable Progression par acquittement et crédit : fenêtres glissantes Data (Sequence Number) Acknowledgement + Advertised Window Sender Receiver Transport Layer

Fiabilité : stop and wait Envoi d’un paquet et attendre un acquittement avant d’envoyer un nouveau paquet. Si timeout, alors retransmission Fiabilité vs. utilisation de la bande passante Lancer nam ici émetteur récepteur Data Envoi du paquet 1 ACK Réception paquet 1 Envoi ACK 1 Réception ACK Envoi paquet 2 Data Transport Layer

Contrôle de flux TCP Basé sur la fenêtre glissante Fenêtre annoncée Transmis et acquitté Transmis non acquitté Non transmis Non transmissible Basé sur la fenêtre glissante Pointeur de début de fenêtre Pointeur indiquant la partie transmise et non acquittée Pointeur indiquant la fin de la fenêtre Envoi de données urgentes toujours possible Transport Layer

Fenêtre d’émission F=min (cwnd, W) Cwnd est une variable maintenue par la source Tient compte de la congestion du réseau W : fixé par la destination, champ fenêtre annoncé Tient compte de la capacité du récepteur Transport Layer

Fenêtres But : optimiser les ressources Contrôle de flux et contrôle de congestion L’émetteur peut envoyer n paquets dans une fenêtre de taille n sans recevoir d’ACK. L’émetteur fait glisser la fenêtre sur réception d’un ACK. Fenêtre effective = Fenêtre annoncée - (octets transmis - octets non acquittés) Arrêt de la transmission quand fenêtre effective=0 émetteur récepteur DATA 1 DATA 2 DATA 3 DATA 4 DATA 5 ACK2 1 2 3 4 5 6 7 8 9 fenêtre glissante DATA 6 Transport Layer

Silly window syndrome L’émetteur a beaucoup de données à transmettre Petite fenêtre annoncée => émission de petits segments Solution pour le récepteur Annoncer des fenêtres par tranches plus larges (MSS par exemple) Solution pour l’émetteur Retarder l’envoi de petits segments Soit PUSH positionné soit on a au moins ½ de la fenêtre à envoyer Transport Layer

Fiabilité avec Go-back-N Fenêtre d’anticipation Détection d’erreurs par l’émetteur Retransmission continue (go-back-n) ou sélective (stockage en désordre) A B DT0 DT1 ACK2 DT2 DT3 DT4 ACK3 DT3 • • • Transport Layer

La reprise sur erreurs Exemples T Paquet 2 perdu: émetteur récepteur DATA 1 DATA 2 DATA 3 DATA 4 DATA 5 ACK2 T ACK6 Exemples Paquet 2 perdu: ACK 3 non reçu par S, W reste en 1 R aquitte 3, 4, 5 avec un ACK 2 Timout sur S, retransmission ACK 6 envoyé par R Paquet 2 arrivé et ACK perdu ACK 3 non reçu mais ACK 4 reçu ACK 4 acquitte tous les paquets avant 4 S fait glisser sa fenêtre au paquet 4 récepteur émetteur DATA 1 DATA 2 DATA 3 DATA 4 ACK2 DATA 5 ACK3 ACK4 Transport Layer

Exemple de reprise sur erreurs Sender Receiver Segment 1 (seq. 1000) Receives 1000, send ACK 1500 Segment 2 (seq. 1500) Segment 3 (seq. 2000) Receives ACK 1500 Slide the window Segment 4 (seq. 2500) Waiting for ACK Receive ACK 1500 which does not slide the window Timeout -> retransmission Of segment 2 Receives one of the frames and replies with ACK 1500 Transport Layer

TCP: retransmission scenarios Host A Seq=92, 8 bytes data ACK=100 loss timeout time lost ACK scenario Host B X Host A Host B Seq=92, 8 bytes data Seq=100, 20 bytes data Seq=92 timeout ACK=100 Seq=100 timeout ACK=120 Seq=92, 8 bytes data ACK=120 time premature timeout, cumulative ACKs Transport Layer

TCP ACK generation [RFC 1122, RFC 2581] Event in-order segment arrival, no gaps, everything else already ACKed one delayed ACK pending out-of-order segment arrival higher-than-expect seq. # gap detected arrival of segment that partially or completely fills gap TCP Receiver action delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK immediately send single cumulative ACK send duplicate ACK, indicating seq. # of next expected byte immediate ACK if segment starts at lower end of gap Transport Layer

Conséquences de ces mécanismes Fiabilité des transmissions Bonne utilisation de la bande passante Contrôle de flux orienté récepteur : la taille de la fenêtre varie au cours de la connexion Transport Layer

Temporisateurs de TCP Temporisateur de retransmission Temporisateur de peristence Pour débloquer la situation après une fenêtre d’émission réduite à zéro et une ouverture perdue Temporisateur d’inactivité Vérifie la présence de l’autre extrémité Temporisateur de déconnexion Deux fois la durée de vie des paquets Transport Layer

TCP et Long Fat Networks Performance maximum si l’émetteur toujours en activité Eviter l’épuisement de la numérotation en séquence durée de rebouclage > MSL Seq number: 32 bits Eviter la fermeture de la fenêtre fenêtre annoncée ≥ bande passante * RTT • RTT (Round Trip Time) = temps entre émission d’un segment et réception de l’ACK correspondant • bande passante * RTT = capacité de mémorisation du réseau Window: 16 bits -> soit 64 Ko Cas des Long Fat Networks: Extension TCP pour les LFNs (RFC1323) facteur d’échelle sur la fenêtre d’émission ajout d’une estampille temporelle sur 32 bits Transport Layer

Ajustement des timeouts : Contrôle d’erreur Délais variables sur Internet Distance Temps de traversée du réseau (charge, saturation des liens …) Le timeout est calculé en fonction de l’estimation du RTT (Round Trip Time) Log du moment où un paquet est envoyé et quand il est acquitté Moyenne pondérée des RTT mesurés Permet de trouver une valeur de timeout pour le segment suivant Transport Layer

Ajustement des timeouts: Contrôle d’erreur Temporisateur de retransmission adaptatif Mesure de RTT et en déduire une estimation Mesure du RTT Cas d’erreurs Actions: pas de mesure de RTT quand il y a eu une retransmission Doublement de la valeur du temporisateur après chaque retransmission Algorithme Err = SampleRTT - EstRTT EstRTT = EstRTT + (d x Err) Var = Var + d(|Err| - Var) Prise en compte de la variance Temporisateur = m x EstRTT + f x Var Où m = 1 et f = 4 Transport Layer

TCP Round Trip Time and Timeout Q: how to set TCP timeout value? longer than RTT note: RTT will vary too short: premature timeout unnecessary retransmissions too long: slow reaction to segment loss Q: how to estimate RTT? SampleRTT: measured time from segment transmission until ACK receipt ignore retransmissions, cumulatively ACKed segments SampleRTT will vary, want estimated RTT “smoother” use several recent measurements, not just current SampleRTT Transport Layer

TCP Round Trip Time and Timeout EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT Exponential weighted moving average influence of given sample decreases exponentially fast typical value of x: 0.1 Setting the timeout EstimtedRTT plus “safety margin” large variation in EstimatedRTT -> larger safety margin Timeout = EstimatedRTT + 4*Deviation Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT| Transport Layer

TCP congestion control: “probing” for usable bandwidth: ideally: transmit as fast as possible (Congwin as large as possible) without loss increase Congwin until loss (congestion) loss: decrease Congwin, then begin probing (increasing) again two “phases” slow start congestion avoidance important variables: Congwin threshold: defines threshold between two slow start phase, congestion control phase Transport Layer

Contrôle de congestion Goulot d'étranglement Réseau 1 Datagrammes en attente de relayage Routeur Réseau 2 routeur Réseau 3 Effondrement des performances temps de transfert trafic offert Réponses: - niveau réseau: gestion des ressources - niveau transport: adaptation du débit Transport Layer

Causes/costs of congestion: scenario 1 two senders, two receivers one router, infinite buffers no retransmission large delays when congested maximum achievable throughput Transport Layer

Causes/costs of congestion: scenario 2 one router, finite buffers sender retransmission of lost packet Transport Layer

Causes/costs of congestion: scenario 2 l in out = always: (goodput) “perfect” retransmission only when loss: retransmission of delayed (not lost) packet makes larger (than perfect case) for same l in out > l in l out “costs” of congestion: more work (retrans) for given “goodput” unneeded retransmissions: link carries multiple copies of pkt Transport Layer

Causes/costs of congestion: scenario 3 four senders multihop paths timeout/retransmit l in Q: what happens as and increase ? l in Transport Layer

Causes/costs of congestion: scenario 3 Another “cost” of congestion: when packet dropped, any “upstream transmission capacity used for that packet was wasted! Transport Layer

Approaches towards congestion control Two broad approaches towards congestion control: End-end congestion control: no explicit feedback from network congestion inferred from end-system observed loss, delay approach taken by TCP Network-assisted congestion control: routers provide feedback to end systems single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) explicit rate sender should send at Transport Layer

Contrôle de congestion TCP Conservation des paquets Ne pas injecter un nouveau paquet tant qu’un vieux n’est pas sorti du réseau nombre de paquets en transit constant Synchronisation sur les acquittements: auto-synchronisation Trouver le point de synchronisation Utilisation d’une fenêtre dynamique: fenêtre de contrôle de congestion (cwnd) Détection de la congestion Pertes généralement dues à la congestion Guérison de la congestion Diminution du débit à la source pour diminuer la congestion Transport Layer

Contrôle de congestion Principe Trouver le point d’équilibre: “additive increase” Augmenter la fenêtre de contrôle de congestion Détection de la congestion par l’indication de la perte d’un paquet Suppression de congestion en réduisant la fenêtre Algorithme phase 1: slow start Après une perte détectée par expiration de temporisation phase 2: congestion avoidance En cas de perte: réduction de la taille de la fenêtre et récupération Récupération : fast recovery Après une perte détectée par retransmission rapide (fast retransmit) Transport Layer

Algorithmes de contrôle de congestion et gestion des fenêtres Slow Start Multiplicative decrease Fast recovery RED Delayed ACK etc. Transport Layer

Slow Start Fenêtre glissante et taille variable de la fenêtre Croissance exponentielle de la taille de la fenêtre (x2 à chaque fois que les paquets sont transmis correctement) Augmentation de 1 segment à chaque acquittement Lancer nam ici Transport Layer

Congestion avoidance Pour stopper l’augmentation trop rapide (le slow start est exponentiel) À partir d’un seuil : augmentation de 1 segment à chaque RTT Le seuil vaut la moitié de la fenêtre lors de la dernière congestion Transport Layer

Congestion avoidance Initialisation avec cwnd=1 et ssthresh=65536 TCP envoie moins de min(cwnd, fenêtre de réception) Congestion => ssthresh = max(fenêtre/2, 2). Si timeout (cad perte), alors cwnd=1 Nouvel ACK => grandir cwnd Si cwnd<=ssthresh alors slow start jusque cwnd = cwnd avant congestion /2 Sinon Congestion avoidance (croissance linéaire de la taille de la fenêtre) Avant ces mécanismes : simple-pre-vj.nam Lancer nam (multiplicative decrease) ici Lancer simple.avi ici ou nam (simple.nam) Transport Layer

TCP et grands RTTs Avec Congestion avoidance, la taille de la fenêtre augmente de 1 à chaque RTT Croissance moins rapide si le RTT est grand Lancer biais.avi Transport Layer

Fast recovery Empêche le slow start après la congestion Slow start utilisé en cas de perte de paquets (expiration de timer) Transport Layer

Fast retransmit Lancer nam ici Modification de congestion avoidance 3 DUPACKs -> paquet supposé perdu et donc retransmission Après la transmission, tout continue normalement (on attend pas d’ACK) Si 3 DUPACKs Sshthresh = ½ min(cwnd,fenêtre récepteur) Retransmettre le segment perdu Cwnd+=3 taille de segment Autre DUPACK -> cwnd +=taille de segment et transmet un paquet Acquittement de nouvelles données -> cwnd = ssthresh Lancer nam ici Transport Layer

RED (Random Early Detection) Dans les routeurs Congestion imminente -> notification à la source en perdant un paquet La congestion est calculée en mesurant la taille moyenne des queues dans les routeurs Lancer nam ici Comparaison avec drop tail Transport Layer

Delayed ACKs Possibilité d’acquitter plusieurs paquets d’un coup Lancer nam ici Transport Layer

Contrôle de congestion Evolution de cwnd Transport Layer

TCP Congestion Avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart 1 1: TCP Reno skips slowstart (fast recovery) after three duplicate ACKs Transport Layer

Segment TCP Port source (16 bits) : le numéro de port de la source. Port Destination (16 bits) : Le numéro de port du destinataire. Numéro de séquence  (32 bits) : Le numéro du premier octet de données par rapport au début de la transmission (sauf si SYN est marqué). Si SYN est marqué, le numéro de séquence est le numéro de séquence initial (ISN) et le premier octet à pour numéro ISN+1. Accusé de réception (32 bits) : si ACK est marqué ce champ contient le numéro de séquence du prochain octet que le récepteur s'attend à recevoir. Une fois la connexion établie, ce champ est toujours renseigné. Transport Layer

Segment TCP Header length (4 bits): La taille de l'en-tête TCP en nombre de mots de 32 bits. Il indique là ou commence les données. L'en-tête TCP, dans tous les cas à une taille correspondant à un nombre entier de mots de 32 bits. Réservé (6 bits) : réservés pour usage futur. Doivent nécessairement être à 0. Bits de contrôle (6 bits - de gauche à droite): - URG: Pointeur de données urgentes significatif - ACK: Accusé de réception significatif - PSH: Fonction Push - RST: Réinitialisation de la connexion - SYN: Synchronisation des numéros de séquence - FIN: Fin de transmission Fenêtre (16 bit): le nombre d'octets à partir de la position marquée dans l'accusé de réception que le récepteur est capable de recevoir. Transport Layer

Segment TCP En-tête de 20 octets (+ options) = IP Zéro ou plus octets de données Taille des segments décidés par TCP Taille max = max (65535o avec entête TCP, MTU) Un segment doit tenir dans le MTU Pour IPv4, la MTU minimale est 556 octets (payload TCP de 536 octets) Transport Layer

Versions de TCP Unix BSD 4.2 (1983) 1ére souche TCP/IP largement disponible BSD 4.3 Tahoe (1988), slow start, congestion avoidance BSD 4.3 Reno (1990), fast recovery BSD 4.3 Vegas (1990), Estimateur de BP Transport Layer

AIMD TCP Fairness TCP congestion avoidance: AIMD: additive increase, multiplicative decrease increase window by 1 per RTT decrease window by factor of 2 on loss event Fairness goal: if N TCP sessions share same bottleneck link, each should get 1/N of link capacity TCP connection 1 bottleneck router capacity R TCP connection 2 Transport Layer

Why is TCP fair? Two competing sessions: Additive increase gives slope of 1, as throughout increases multiplicative decrease decreases throughput proportionally R equal bandwidth share loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 2 throughput loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 1 throughput R Transport Layer

TCP latency modeling Q: How long does it take to receive an object from a Web server after sending a request? TCP connection establishment data transfer delay Notation, assumptions: Assume one link between client and server of rate R Assume: fixed congestion window, W segments S: MSS (bits) O: object size (bits) no retransmissions (no loss, no corruption) Two cases to consider: WS/R > RTT + S/R: ACK for first segment in window returns before window’s worth of data sent WS/R < RTT + S/R: wait for ACK after sending window’s worth of data sent Transport Layer

TCP latency Modeling K:= O/WS Case 2: latency = 2RTT + O/R + (K-1)[S/R + RTT - WS/R] Transport Layer

TCP Latency Modeling: Slow Start Now suppose window grows according to slow start. Will show that the latency of one object of size O is: where P is the number of times TCP stalls at server: - where Q is the number of times the server would stall if the object were of infinite size. - and K is the number of windows that cover the object. Transport Layer

TCP Latency Modeling: Slow Start (cont.) Example: O/S = 15 segments K = 4 windows Q = 2 P = min{K-1,Q} = 2 Server stalls P=2 times. Transport Layer

TCP Latency Modeling: Slow Start (cont.) Transport Layer

Conclusion et synthèse Protocoles de transport => de bout-en-bout multiplexing/demultiplexing reliable data transfer flow control congestion control Principalement deux protocoles de transport UDP : non fiable, seulement vérification des erreurs TCP : fiable, contrôle de congestion, reprise sur erreurs (ACK + timeout)… Implémentés partout Cours suivant : On quitte la bordure du réseau (couches application et transport)... ... pour entrer au coeur du réseau. Transport Layer

Chapter 3: Summary principles behind transport layer services: instantiation and implementation in the Internet UDP TCP Transport Layer