Exercices TCP et UDP : Evolutions et Approches alternatives TP réseau informatique TCP UDP

Exercice 1 : TCP, Évolutions et Approches alternatives

Question 1
En quoi TCP n'est pas adapté au transfert de données qui ont des contraintes

temps réel (contrainte de gigue constante, contrainte de latence bornée par exemple).

Question 2 

2.1. Rappelez quels événements sont utilisés par TCP pour décider que le réseau est en congestion ?

2.2. Rappelez brièvement les principes des mécanismes baptisés "slow-start", et "congestion avoidance" du protocole TCP. Éventuellement, aidez-vous d'un dessin et indiquez sur ce dessin la partie correspondant au "slow-start" et la partie correspondant à "congestion avoidance".

Question 3

TCP a une approche réactive pour estimer la bande passante disponible pour une connexion. En fait, le débit soumis augmente tant qu'une congestion n'apparaît pas (et tant qu'on ne dépasse pas le crédit alloué par le récepteur). Différentes études proposent des modifications de TCP. 

TCP se voit ajouter des extensions. On examine une extension qui est relative au débit d'émission. Des statistiques sont faites par connexion. 

+  On calcule un débit attendu instantané de la façon suivante : 

        Attendu(t) = TailleFenêtreCongestion(t)/BaseRTT où 

o  BaseRTT : délai Aller/Retour associé à un segment quand le réseau  n'est pas congestionné (avant que les routeurs ne saturent à cause du trafic de cette connexion), on entend par délai Aller/retour (ou encore RTT pour Round Trip Time) le délai qui s'écoule entre l'émission du segment et l'arrivée de son acquittement. BaseRTT est le plus petit RTT mesuré. Il est mesuré à chaque fois qu'on émet un segment, si lors du retour de l'acquittement du segment, le RTT associé à celui-ci est inférieur à BaseRTT, alors BaseRTT prend cette nouvelle valeur.

o  TailleFenêtreCongestion(t) est la valeur courante de la fenêtre de congestion de l'émetteur.

+  On mesure le débit d'émission réel instantané de la façon suivante : 

        Mesuré(t) = TailleSegmentEmis(t)/RTTduSegment

Soit Diff(t) = Attendu(t) – Mesuré(t)

3.1. Expliquer pourquoi Diff(t) ne peut être négatif.

Deux seuils sont définis : A < B
Si Diff(t) < A alors la fenêtre de congestion augmente linéairement.
Si A < Diff(t) < B alors rien n'est fait.
Si B < Diff(t) alors la fenêtre de congestion diminue linéairement.

3.2. A quoi correspondent les seuils A et B ?

3.3. Expliquer en quoi, cette modification vous semble permettre d'augmenter l'efficacité de TCP vis-à-vis de l'occurrence des congestions.

Questions 4 : UDP et gestion de la congestion dans Internet. 

4.1 Quel type de mécanisme faudrait-il ajouter dans le protocole UDP ou en dehors du protocole UDP pour qu'il ne contribue pas à la saturation d'Internet quand un utilisateur tente d'émettre à un fort débit indépendamment de la charge du réseau. 

4.2 Comment devrait alors se comporter une relation ou une "connexion" de cette nouvelle version d'UDP du point de vue du partage de la bande passante de l'Internet vis-à-vis des connexions TCP co-existant sur le réseau ? La réponse doit uniquement considérer le point de vue de la couche transport. Il  faut donc imaginer que le comportement au niveau transport est indépendant d'un mécanisme de réservation de ressources tel que RSVP, cela doit fonctionner même sur un réseau de type best effort.