Scribd Logo
Importer

Bienvenue sur Scribd !

  • 33 vues

    Relayage Ip5

    Transféré par

    Marouane Gaoua
    Le document décrit le fonctionnement du contrôle de congestion TCP Tahoe et Reno sans et avec l'algorithme Fast Retransmit à travers plusieurs scénarios. Il présente la séquence d'opérations effectuées par TCP lors de la perte de paquets ainsi que l'évolution des variables d'état comme le seuil de congestion ssthresh et la fenêtre de congestion cwnd.

    Droits d'auteur :

    © All Rights Reserved
    Téléchargez comme PDF, TXT ou lisez en ligne sur Scribd

    Relayage Ip5

    Transféré par

    Marouane Gaoua
    33 vues4 pages
    Le document décrit le fonctionnement du contrôle de congestion TCP Tahoe et Reno sans et avec l'algorithme Fast Retransmit à travers plusieurs scénarios. Il présente la séquence d'opérations effectuées par TCP lors de la perte de paquets ainsi que l'évolution des variables d'état comme le seuil de congestion ssthresh et la fenêtre de congestion cwnd.

    Titre original

    relayage ip5

    Copyright

    © © All Rights Reserved

    Formats disponibles

    PDF, TXT ou lisez en ligne sur Scribd

    Avez-vous trouvé ce document utile ?

    Ce contenu est-il inapproprié ?

    Le document décrit le fonctionnement du contrôle de congestion TCP Tahoe et Reno sans et avec l'algorithme Fast Retransmit à travers plusieurs scénarios. Il présente la séquence d'opérations effectuées par TCP lors de la perte de paquets ainsi que l'évolution des variables d'état comme le seuil de congestion ssthresh et la fenêtre de congestion cwnd.

    Droits d'auteur :

    © All Rights Reserved
    Téléchargez comme PDF, TXT ou lisez en ligne sur Scribd
    Télécharger au format pdf ou txt
    33 vues4 pages

    Relayage Ip5

    Transféré par

    Marouane Gaoua
    Le document décrit le fonctionnement du contrôle de congestion TCP Tahoe et Reno sans et avec l'algorithme Fast Retransmit à travers plusieurs scénarios. Il présente la séquence d'opérations effectuées par TCP lors de la perte de paquets ainsi que l'évolution des variables d'état comme le seuil de congestion ssthresh et la fenêtre de congestion cwnd.

    Droits d'auteur :

    © All Rights Reserved
    Téléchargez comme PDF, TXT ou lisez en ligne sur Scribd
    Télécharger au format pdf ou txt
    sur 4

    TD6 - TCP - Contrôle de congestion

    1 Contrôle de congestion de TCP Tahoe sans Fast Retransmit

    Supposons que l’émetteur TCP fonctionne selon les algorithmes Slow Start et Congestion Avoidance,
    mais n’implémente pas l’algorithme Fast Retransmit. De même, supposons que :

    • les segments n, n + 1, n + 2 ... n + k sont envoyés aux instants 0, 100, 200 ... k × 100ms,
    • le temps de transmission d’un segment est de 100ms,
    • le temps aller-retour (qui inclut le temps de propagation, la transmission et le traitement de ACK)
    est constant et égal à 1s,
    • le délai de delayedACK est 500ms,
    • le segment n est perdu,
    • aucun autre segment ni ACK n’est perdu,
    • tous les segments et ACK qui ne sont pas perdus arrivent en ordre (pas de déséquencement),
    • la temporisation pour le segment n est de 6s,
    • cwnd = ssthresh = 64 segments au moment 0,
    • la fenêtre annoncée par le récepteur est de 64 segments tout au long de l’échange.

    ✎ 1. Comment la perte du segment n est-elle détectée ? A quel moment ?


    2. A quel moment reçoit-on le ACK pour le segment n + 3 ? (nous supposons qu’il n’y a
    pas de pertes autres que celle du segment n)
    3. Juste après avoir retransmis le segment n, l’émetteur a 3 nouveaux segments prêts à être
    envoyés (n + k + 1 à n + k + 3).
    4. Même question pour n+k+3 : à quel moment reçoit-on le ACK pour le segment n+k+3 ?

    Indication : Question 1 : 6s, Question 2 = 7.1s et Question 4 : 9.9s

    cwnd = 64
    ssthresh = 64

    n° seg = n … n+10

    …
    … …

    0 1 2 3 4 5 6 7 8 9

    1
    2 Contrôle de congestion de TCP Tahoe avec Fast Retransmit -
    cas 1

    On considère une connexion TCP Tahoe entre un émetteur E et un récepteur R.

    • le temps de transmission d’un paquet est négligeable par rapport au délai de propagation de 50
    ms (on peut donc considérer la transmission comme instantanée) ;
    • l’application qui utilise TCP a toujours des données à envoyer, sauf indication contraire ;
    • la taille maximale de segment est de 1Ko ;
    • la taille initiale du seuil de congestion ssthresh est de 8Ko ;
    • l’intervalle de retransmission est de 500ms ;
    • delayed ACK n’est pas activé.

    Considérez le scénario suivant :

    • à t = 0ms la source TCP commence à émettre après avoir initialisé la connexion ;


    • à t = 600ms la source TCP n’a des données que pour un seul segment TCP ; lorsque ce segment
    est envoyé, il est perdu ;
    • après la récupération de la perte, la source TCP a de nouveau des données à émettre ;
    • la connexion se termine à t = 1600ms.

    ✎ Donnez la séquence chronologique des opérations effectuées par TCP. Précisez l’état de TCP
    vis-à-vis de la congestion, le nombre de segments envoyés, les valeurs des variables ssthresh
    et cwnd, ainsi que d’autres informations utiles.

    Indication : à 600ms, E émet le segment 35. A 1600ms, E reçoit les ACK des segments 48-54.

    état SS
    CC

    cwnd = 1
    thresh = 8

    0ms 500ms 1000ms 1500 ms

    2
    3 Contrôle de congestion de TCP Tahoe avec Fast Retransmit -
    cas 2

    Mêmes hypothèses que précédemment. On utilise toujours TCP Tahoe.

    Considérez le scénario suivant :

    • à t = 0ms la source TCP commence à émettre après avoir initialisé la connexion ;


    • à t = 600ms le premier segment (segment 35) des segments envoyés est perdu ;
    • Que se passe-t-il jusqu’à 1000ms ?

    ✎ Donnez la séquence chronologique.

    Indication : à 1000ms, E reçoit les ACK pour les segments 48 à 51.

    état SS
    CC

    cwnd = 1
    thresh = 8

    0ms 500ms 1000ms 1500 ms

    3
    4 Contrôle de congestion de TCP Reno - cas 3

    Même hypothèses que précédemment mais TCP Reno

    Considérez le scénario suivant :

    • à t = 0ms la source TCP commence à émettre après avoir initialisé la connexion ;


    • à t = 600ms le premier segment (segment 35) des segments envoyés est perdu ;
    • Que se passe-t-il jusqu’à 1000ms ?

    ✎ Donnez la séquence chronologique.

    état SS
    CC

    cwnd = 1
    thresh = 8

    0ms 500ms 1000ms 1500 ms

    Vous aimerez peut-être aussi