(Nom du fichier) - D1 - 22/09/2000 Le présent document contient des informations qui sont la propriété de France Télécom. L'acceptation de ce document.

Présentation au sujet: "(Nom du fichier) - D1 - 22/09/2000 Le présent document contient des informations qui sont la propriété de France Télécom. L'acceptation de ce document."— Transcription de la présentation:

1 (Nom du fichier) - D1 - 22/09/2000 Le présent document contient des informations qui sont la propriété de France Télécom. L'acceptation de ce document par son destinataire implique, de la part de ce dernier, la reconnaissance du caractère confidentiel de son contenu et l'engagement de n'en faire aucune reproduction, aucune transmission à des tiers, aucune divulgation et aucune utilisation commerciale sans l'accord préalable écrit de France Télécom R&D TCP et UDP : La couche transport d’INTERNET Emmanuel BESSON (FTR&D/DMI/ISE) Novembre 2000

2 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D2 - 22/09/2000 France Télécom R&D Plan du cours è Présentation générale è Le modèle TCP è L ’en-tête TCP è Gestion d ’une connexion TCP è Politique de transmission TCP è Contrôle de congestion TCP è Gestion des temporisations TCP è UDP

3 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D3 - 22/09/2000 France Télécom R&D Présentation générale è La couche transport du réseau doit fournir à l ’utilisateur un service de transport d ’information : ‡ efficace ; ‡ fiable ; ‡ économique. è A la différence de la couche réseau, la couche transport appartient à l ’utilisateur. Elle est sa garante d ’un transfert de qualité, y compris lorsque des routeurs du réseau (donc de l ’opérateur) fonctionnent mal.  Notion de Qualité de Service

4 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D4 - 22/09/2000 France Télécom R&D Présentation générale è Qu ’est ce que la Qualité de Service ? ‡ Ensemble de paramètres (critères) négocié pour un échange d ’informations ‡ chaque paramètre a une valeur désirée et une valeur minimale ‡ exemples : Temps d ’établissement de la connexion Probabilité d ’échec d ’établissement Débit de la liaison Temps de transit Taux d ’erreur Protection Priorité Résiliation

5 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D5 - 22/09/2000 France Télécom R&D Présentation générale è Ces critères sont négociés entre l ’utilisateur (qui spécifie les valeurs) et le réseau par l ’intermédiaire de la couche transport qui reçoit les informations du réseau. è Ces négociations ont lieu avant l ’établissement d ’une connexion : TCP fonctionne en mode connecté è Il existe un protocole de couche transport qui ne tient pas compte de ces considérations. Il assure donc un service minimal et est utilisé pour des échanges très courts pour lesquels l ’établissement d ’une connexion est trop coûteux : UDP fonctionne en mode non connecté

6 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D6 - 22/09/2000 France Télécom R&D Présentation générale è TCP (Transmission Control Protocol) est conçu pour traiter de bout-en- bout des données : ‡ en apportant la fiabilité que ne donne pas IP : détecter les pertes éventuelles et les combler en retransmettant les données perdues ; ordonner des datagrammes déséquencés. ‡ en s ’adaptant dynamiquement aux changements dans le réseau. è UDP (User Data Protocol) ne se distingue d ’IP que par l ’ajout d ’un petit en-tête pour assurer de façon minimaliste le transfert.

7 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D7 - 22/09/2000 France Télécom R&D Le modèle TCP è Le service en mode connecté de TCP nécessite la création de 2 points de connexion appelés sockets : ‡ un à l ’émetteur, un au récepteur ‡ identifiés par l ’adresse IP + le numéro de port (16 bits) : numéro local à l ’ordinateur 256 ports réservés (ex: 20-21 pour ftp, 23 pour telnet) è Une connexion TCP est : ‡ identifiée par le couple : (socket1, socket2) ; ‡ bidirectionnelle : les données peuvent circuler dans les 2 sens simultanément ; ‡ point-à-point : 2 points d ’extrémité et 2 seulement (pas de multicast ou de broadcast).

8 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D8 - 22/09/2000 France Télécom R&D Le modèle TCP è Les appels aux sockets sont : ‡ SOCKET : création d ’un nouveau point terminal ; ‡ BIND : attache une adresse locale au socket ; ‡ LISTEN : annonce la volonté d ’accepter des connexions ; ‡ ACCEPT : bloque l ’appelant jusqu ’à l ’arrivée d ’une connexion entrante ; ‡ CONNECT : tente l ’établissement d ’une connexion ; ‡ SEND : envoie des données sur la connexion ; ‡ RECEIVE : reçoit des données sur la connexion ; ‡ CLOSE : libère la connexion.

9 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D9 - 22/09/2000 France Télécom R&D Le modèle TCP è TCP transmet sur le réseau des segments : ‡ 20 octets d ’en-tête fixes (plus une partie optionnelle) ; ‡ 0 ou plusieurs octets de données… ‡ … à concurrence : de la taille maximale du datagramme IP ; de l ’unité de transfert maximale (MTU) propre au réseau. è Chaque segment porte un numéro de séquence.

10 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D10 - 22/09/2000 France Télécom R&D Le modèle TCP è TCP est fondé sur le mécanisme de fenêtre d ’anticipation : ‡ l ’émetteur transmet un segment et arme un temporisateur ; ‡ le récepteur renvoie un segment (acquittement) avec le numéro de séquence suivant attendu ; ‡ si la temporisation de l ’émetteur expire avant réception de l ’acquittement, l ’émetteur retransmet le segment. è Problèmes que doit résoudre TCP de manière efficace : ‡ réseau congestionné ou hors-service ; ‡ perte d ’un fragment du segment original ; ‡ déséquencement ; ‡ la réémission entraîne des possibles doublons incohérents car fragmentés différemment.

11 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D11 - 22/09/2000 France Télécom R&D L ’en-tête TCP è Longueur fixe 20 octets è Partie optionnelle de longueur variable è Suivi par des octets de données : ‡ nombre maximal = 65535 -20(IP) -20(TCP) = 65495 octets ‡ nombre minimal = 0 (acquittements et supervision)

12 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D12 - 22/09/2000 France Télécom R&D L ’en-tête TCP Port source Port destination Numéro de séquence Numéro d ’acquittement Long. En-tête Taille de fenêtre URGURG ACKACK PSHPSH RSTRST SYNSYN FINFIN Total de contrôlePointeur d ’urgence Options (0, 1 ou plusieurs mots de 32 bits) 32 bits

13 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D13 - 22/09/2000 France Télécom R&D L ’en-tête TCP è Premier champ : Port source16 bits ‡ identifie la source de la connexion è Deuxième champ : Port destination16 bits ‡ identifie la destination de la connexion è Les ports vont jusqu ’à 65535 ‡ 0-1023 : « Well-known ports » ‡ 1024-49151 : « Registered ports » ‡ 49152-65535 : « Dynamic and/or Private ports »

14 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D14 - 22/09/2000 France Télécom R&D L ’en-tête TCP è Troisième champ : Numéro de séquence32 bits ‡ indique le numéro affecté au premier octet du segment TCP envoyé par la connexion è Quatrième champ : Numéro d ’acquittement32 bits ‡ indique le numéro du prochain octet attendu ; ‡ n ’indique pas le numéro du dernier octet correctement reçu ! è Cinquième champ : Longueur d ’en-tête TCP 4 bits ‡ longueur de l ’en-tête exprimé en nombre de mots de 32 bits ‡ longueur variable (options) limitée à :

15 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D15 - 22/09/2000 France Télécom R&D L ’en-tête TCP è Sixième champ : inutilisé6 bits ‡ réservé à l ’origine pour des utilisations futures è Septième champ : 6 drapeaux6  1 bits ‡ URG : pointeur d ’urgence en cours d ’utilisation indique que le segment contient des données urgentes ‡ ACK : validité du numéro d ’acquittement indique si le segment contient un acquittement ou pas ‡ PSH : poussée le récepteur doit immédiatement remonter les données à l ’application ‡ RST : réinitialisation signale que la connexion est devenue incohérente

16 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D16 - 22/09/2000 France Télécom R&D L ’en-tête TCP ‡ SYN : demande d ’établissement de connexion ‡ FIN : libération de la connexion è Huitième champ : Taille de fenêtre16 bits ‡ indique le nombre d ’octets pouvant être transmis sans acquittement è Neuvième champ : Total de contrôle16 bits ‡ assure la fiabilité de la transmission è Dixième champ : Pointeur d ’urgence16 bits ‡ exprime le décalage (en octets) à partir du numéro de séquence, à partir duquel se trouve les données urgentes

17 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D17 - 22/09/2000 France Télécom R&D L ’en-tête TCP è Champs optionnelsvariable ‡ pour spécifier la taille de segment maximale admissible : de grands segments permettent d ’absorber la charge de l ’en-tête certains ordinateurs ne sont pas toujours capables de traiter de grands segments tout ordinateur sur Internet, par défaut, doit accepter des segments de 536 octets utiles (+20 octets TCP + 20 octets IP = 576 octets) ‡ pour permettre des réémissions intelligentes la destination peut réclamer la réémission d ’un segment spécifique sinon, la source réémet tous les segments depuis le dernier correctement reçu ‡ etc.

18 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D18 - 22/09/2000 France Télécom R&D Gestion d ’une connexion TCP è Une extrémité attend de manière passive l ’arrivée d ’une connexion : ‡ LISTEN : désigne une source précise ; ‡ ACCEPT : accepte l ’appel d ’où qu ’il vienne. è L ’autre extrémité indique son désir de connexion dans un premier segment TCP : ‡ CONNECT : signifie sa volonté de connexion (SYN=1, ACK=0) ‡ indique : l ’adresse IP et le port auxquels il désire se connecter ; la taille maximale des segments (MSS) qu ’il admet ; éventuellement des données (ex. : mot de passe).

19 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D19 - 22/09/2000 France Télécom R&D Gestion d ’une connexion TCP è Arrivé à destination, celle-ci cherche si une application est à l ’écoute (LISTEN) sur le Port destination indiqué : ‡ si oui, elle envoie un acquittement (SYN=1, ACK=1) ; ‡ si non, elle renvoie un rejet (RST=1). è Deux connexions simultanées sur les mêmes sockets ne conduisent pas à deux connexions parallèles mais une seule car une connexion est identifiée par (socket1, socket2).

20 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D20 - 22/09/2000 France Télécom R&D Gestion d ’une connexion TCP SYN (SEQ=x) SYN (SEQ=y, ACK=x+1 ) SYN (SEQ=x+1, ACK=y+1 ) Ordinateur 1Ordinateur 2 SYN (SEQ=x) Ordinateur 1Ordinateur 2 SYN (SEQ=y) SYN (SEQ=y, ACK=x+1 ) SYN (SEQ=x, ACK=y+1 ) Temps

21 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D21 - 22/09/2000 France Télécom R&D Gestion d ’une connexion TCP è Libération de la connexion (bidirectionnelle) : ‡ (1) une extrémité envoie un segment avec FIN=1 ‡ (2) l ’autre extrémité acquitte  fin de ce sens ‡ (3) pour fermer l ’autre sens, elle doit à son tour envoyer FIN=1 ‡ (4) à l ’acquittement, la connexion est terminée è Cas particuliers : ‡ les étapes 2 et 3 peuvent être dans le même segment ; ‡ envoi simultané des segments FIN=1 : aucun problème : deux acquittements et la connexion est terminée ‡ utilisation de temporisateurs pour éviter d ’attendre la confirmation si un acquittement est perdu.

22 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D22 - 22/09/2000 France Télécom R&D Politique de transmission TCP 2K | SEQ=0 04K Vide ACK=2048 | fenêtre=2048 2K | SEQ=2048 ACK=4096 | fenêtre=0 ACK=4096 | fenêtre=2048 1K | SEQ=4096 L ’application écrit 2K L ’application écrit 3K L ’application peut envoyer jusqu ’à 3K L ’application lit 2K L ’émetteur est bloqué

23 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D23 - 22/09/2000 France Télécom R&D Politique de transmission TCP è L ’émetteur n ’est pas tenu de transmettre immédiatement les données venues des applications : ‡ Exemple : une application qui transmet octet par octet consomme beaucoup de bande passante (en-têtes à chaque fois !) è Le récepteur n ’est pas tenu d ’acquitter immédiatement. ‡ Exemple : TCP, sachant qu ’il a une fenêtre de réception de 4Ko, peut attendre qu ’elle soit remplie avant d ’acquitter.  TCP utilise des temporisateurs pour retarder l ’émission de données/acquittement et attendre d ’éventuels données à transmettre (dans un seul segment) ou recevoir (un seul acquittement).

24 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D24 - 22/09/2000 France Télécom R&D Politique de transmission è Problème des applications « octet par octet » : ‡ on consomme beaucoup d ’en-têtes ; ‡ solution : algorithme de Nagle TCP transmet le 1er octet ; TCP attend l ’acquittement et stocke pendant ce temps les octets venus de l ’application ; TCP envoie à réception de l ’acquittement et ainsi de suite ‡ très utilisé ‡ limitation : « hache » le trafic en rafales ne convient pas à X Window exemple : déplacement du curseur d ’une souris

25 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D25 - 22/09/2000 France Télécom R&D Politique de transmission è Syndrome de la « fenêtre stupide » : Le tampon récepteur est plein L ’application lit 1 octet Place libre pour un octet supplémentaire Indication de fenêtre envoyée Un octet arrive En- tête 1 octet

26 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D26 - 22/09/2000 France Télécom R&D Politique de transmission è Syndrome de la fenêtre stupide : ‡ arrive lorsque : l ’application émettrice donne de grands blocs à TCP ; l ’application réceptrice lit octet par octet dans le buffer TCP. ‡ solution de Clark : le récepteur envoie une indication de fenêtre lorsque la place libre atteint MSS ou la moitié de la place maximale ; l ’émetteur n ’envoie pas de petits segments mais des segments au moins égaux à la moitié de la place du récepteur.

27 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D27 - 22/09/2000 France Télécom R&D Politique de transmission è Réaction en cas de perte : ‡ le récepteur peut stocker le 4 et le 5 ‡ l ’émetteur réemet le 3 ‡ le récepteur acquitte le 3 et les paquets 4 et 5 stockés ‡ sinon, l ’émetteur recommence depuis le 4  Contrôle et détection de perte 0101 23452345 3 2 3 4 ou 6

28 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D28 - 22/09/2000 France Télécom R&D Contrôle de congestion TCP è Les congestions dans Internet sont majoritairement traitées au niveau TCP. è La solution la plus simple est la meilleure : limiter le nombre de segments entrants le temps que les segments entrés soit écoulés. è TCP utilise pour cela ‡ une limite au débit entrant : la fenêtre de congestion (fenêtre TCP) ; ‡ des temporisateurs (timers) pour détecter les congestions ex. : RTO = Retransmission Time Out

29 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D29 - 22/09/2000 France Télécom R&D Contrôle de congestion TCP è Temporisateur RTO : ‡ si un segment n ’est pas acquitté avant que le RTO n ’expire, l ’émetteur considère que le segment est perdu ‡ l ’émetteur réémet ce segment. è Fenêtre TCP : W(indow) ‡ reflète le nombre d ’octets que l ’émetteur peut transmettre sans entraîner de pertes a priori ‡ initialisée à MSS ‡ augmente jusqu ’à un seuil (threshold W th ) de manière exponentielle (phase de Slow- Start) ‡ puis augmente de manière linéaire jusqu ’au maximum (W max ) négocié entre émetteur et récepteur (phase de Congestion Avoidance)

30 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D30 - 22/09/2000 France Télécom R&D Contrôle de congestion TCP è TCP fonctionne par cycle entre deux pertes è Seuil de Slow-Start : W th ‡ au début (instant t=0) : W th = 64Ko W(t=0) = MSS (ex.: 1Ko) ‡ à la perte (instant t=t*) : W a atteint une valeur W(t=t*) W th est réinitialisée à : W th = W(t=t*) / 2 è Tant que W < W th : Slow-Start (croissance exponentielle) è Dès que W > W th : Congestion Avoidance (croissance linéaire)

31 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D31 - 22/09/2000 France Télécom R&D Contrôle de congestion TCP

32 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D32 - 22/09/2000 France Télécom R&D Contrôle de congestion TCP è Slow Start : ‡ la fenêtre commence à W = MSS ‡ elle croît à chaque acquittement : W = W+MSS ‡ elle croît ainsi jusqu ’à ce que W = W th è Congestion Avoidance : ‡ la fenêtre a atteint W = W th ‡ elle croît quand elle a été entièrement acquittée : W = W+MSS/W ‡ elle continue à croître jusqu ’à : détection de perte (expiration de temporisateur) W = W max message ICMP de limitation de production

33 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D33 - 22/09/2000 France Télécom R&D Contrôle de congestion TCP è Mécanisme des acquittements retardés (ou groupés) : ‡ Le récepteur attend un certain temps (défini par le temporisateur DAT) avant d’acquitter les segments arrivés. ‡ Permet d’acquitter plusieurs segments avec un seul acquittement Jusqu’à k segments (en général 2 ou 3) Limite le trafic d’acquittements ‡ Modifie fondamentalement la croissance de la fenêtre !!! La fenêtre croît en fonction des acquittements reçus et non des segments envoyés… … donc moins d’acquittements entraîne croissance ralentie.

34 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D34 - 22/09/2000 France Télécom R&D Gestion des temporisations TCP è TCP utilise des temporisateurs dont le plus important est le temporisateur de retransmission (Retransmission Time Out). è Le réglage de ce RTO est très délicat : ‡ si trop grand, long délai à chaque perte ‡ si trop court, retransmissions inutiles  performances de la transmission dégradées (délai, charge)  Il faut ajuster en permanence RTO en fonction des paramètres du réseau.  Il faut calculer le « temps de boucle » ou RTT (Round Trip Time) et l ’utiliser pour calculer RTO.

35 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D35 - 22/09/2000 France Télécom R&D Gestion des temporisations TCP è A l ’envoi d ’un segment à la date t e, TCP arme un temporisateur T. è Si T atteint RTO avant la date de retour de l ’acquittement : ‡ le segment est renvoyé à une date t e + RTO ‡ on ne peut calculer RTT de manière fiable ‡ RTO* = 2  RTO (algorithme de Karn) è Si l ’acquittement revient à la date t a : ‡ T = t a - t e ‡ RTT* = .RTT + (1-  ).T (avec  <1) ‡ RTO* = .RTT* (avec  >1) (proposition de Jacobson)

36 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D36 - 22/09/2000 France Télécom R&D Gestion des temporisations TCP è Autres temporisateurs : ‡ temporisateur de persistance : déclenche l ’envoi d ’un message sonde lorsque l ’émetteur est bloqué par une fenêtre de réception nulle évite le blocage dû à la perte d ’un message de nouvelle fenêtre de réception non nulle ‡ temporisateur de limitation d ’attente : connexion inactive depuis longtemps à l ’expiration une extrémité vérifie si son interlocuteur est toujours là si non, ferme la connexion ‡ temporisateur de de fermeture assure un délai de fermeture pour s ’assurer que tous les segments de la connexion ont disparu

37 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D37 - 22/09/2000 France Télécom R&D Gestion des temporisations TCP è Autres temporisateurs : ‡ Temporisateur de groupement des acquittements : DAT (Delayed Ack Timer) Activé cycliquement toutes les 200ms A l’expiration, acquitte l’ensemble des segments reçus et non encore acquittés 0 200 400 600 800 k = 3  10 segments reçus 5 acquittements

38 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D38 - 22/09/2000 France Télécom R&D Versions successives de TCP è TCP Tahoe (1988) : ‡ Etat initial : W = 1 MSS W th = 65535 octets ‡ Phase Slow Start : Croissance exponentielle de W tant que W < W th ‡ Phase Congestion Avoidance : Croissance en racine carrée de W jusqu’à la perte ‡ Phase Recouvrement de perte : Fondée sur la valeur du RTO (et donc du RTT estimé) Retour de W à 1

39 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D39 - 22/09/2000 France Télécom R&D Versions successives de TCP è Amélioration de TCP Tahoe (1989) : Fast Retransmit ‡ L’attente de l’expiration du RTO pénalise les performances : Silence de la source ‡ Idée : utiliser les acquittements dupliqués Au niveau du récepteur TCP, un acquittement dupliqué est envoyé sans attente dès qu’un segment hors séquence arrive Au niveau de l’émetteur, si 3 acquittements dupliqués sont reçus, on considère qu’il y a eu perte ‡ Avantage : Redémarrage plus rapide des émissions ‡ Inconvénient : Fonctionne mal en cas de pertes multiples La première perte est détectée avec les acquittements dupliqués, la suivante avec le RTO

40 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D40 - 22/09/2000 France Télécom R&D Versions successives de TCP è TCP Reno (1990) : mécanisme de Fast Recovery ‡ Réduction trop draconienne du débit avec un retour en phase Slow Start ‡ Idée : supprimer le retour en phase Slow Start ! ‡ Algorithme : Au troisième acquittement dupliqué reçu : – W th = W/2 – retransmission du segment perdu – W = W th + 3 MSS A chaque nouvel acquittement dupliqué reçu : – W = W + 1 MSS Au premier acquittement non dupliqué reçu : – W = W th – Mode Congestion Avoidance ‡ Avantage : Pas de chute brutale du flot de données = moins de perte de bande passante ‡ Inconvénient : Inadapté dans les WAN (pertes souvent multiples)

41 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D41 - 22/09/2000 France Télécom R&D Versions successives de TCP è TCP Vegas (1994) : ‡ Trois principaux points d’amélioration Prise de décision plus rapide pour la retransmission : – Calcul du RTT plus fin Anticipation des états de congestion : – Calcul du débit théorique sans congestion : W/ (min RTT) – Mesure du débit réel : nombre de bits envoyés / (RTT courant) – Ajustement de W en fonction de ces valeurs Modification du Slow Start : – W croît de 1 MSS une fois sur deux ! ‡ Avantage : Meilleures performances ‡ Inconvénients : Complexité Cohabitation difficile avec Reno et Tahoe Non approuvé par l’IETF !

42 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D42 - 22/09/2000 France Télécom R&D Extensions futures è Adaptation au contexte haut-débit : ‡ Extension de la taille de fenêtre maximale Option « Window Scale » De 64Ko à 1074Mo ‡ Mesure du RTT Option RTTM Améliore la mesure et le calcul du RTT ‡ Extension du champ numéro de séquence Algorithme PAWS (Protect Against Wrapped Sequence numbers) Meilleure gestion des numéros de séquence ‡ Gestion des pertes multiples Mécanisme SACK (Selective ACKnowledgment) Option de l’en-tête TCP qui indique exactement la liste des segments déjà reçus

43 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D43 - 22/09/2000 France Télécom R&D UDP è Protocole de transport en mode non connecté (User Data Protocol) : il n ’y a pas d ’établissement préalable de connexion è Relations de type client-serveur avec questions/réponses épisodiques et courtes : ‡ la gestion d ’une connexion TCP serait lourde ‡ gain de temps, mais pas de sécurité (pas d ’acquittement) è UDP ajoute un simple en-tête de 8 octets aux données. Port sourcePort destination Longueur UDPTotal de contrôle UDP 32 bits

44 La communication de ce document est soumise à autorisation de France Télécom R&D (Nom du fichier) - D44 - 22/09/2000 France Télécom R&D UDP è En-tête : ‡ Port source et Port destination : même fonction que pour TCP ‡ Longueur UDP : longueur totale du segment UDP ‡ Total de contrôle UDP : même fonction que pour TCP optionnel ! è UDP : ‡ fonctionne en mode non connecté ; ‡ est non sécurisé ; ‡ n ’assure pas de contrôle de congestion.