XCP-i: eXplicit Control Protocol pour l’interconnexion de réseaux haut-débit hétérogènes D.M. Lopez Pacheco1, C. Pham2, L. Lefèvre1 1 INRIA RESO UMR LIP CNRS/ENS/INRIA/UCBL C. Pham 2 Université de Pau et des Pays de l’Adour Laboratoire LIUPPA http://www.univ-pau.fr/~cpham Congduc.Pham@univ-pau.fr LIUPPA
TCP & réseaux haut débit Fibre Optique 40 Gbps 200000km/s, delai de 5ms tous les 1000kms Cœurs de réseaux: liens optiques, DWDM, débit de plusieurs dizaines de gigabits/s Temps tranmission <<< temps propagation Répliquer une BD de 10Go ne devrait pas poser de problèmes!
La dure réalité: TCP sur un lien à 200Mbits/s Haut débit performances de bout en bout! TCP n’est pas adapté pour les « Long Fat Networks »! Pertes de paquets
Ce que votre maman ne vous a jamais dit sur TCP! Standard TCP TCP 40 Gbps 0.3Gbps Si vous voulez tranférer un fichier de 1Go avec une pile TCP standard, cela vous prendra plusieurs minutes, même avec un lien à 40Gbits/s (combien en €?)!
Revenons aux origines! Contrôle de flux pour les récepteurs Contrôle de congestion pour le réseaux 1ère congestion observée en 1986 par V. Jacobson. TCP est devenu synonyme de contrôle de congestion: TCP Reno en 1988. From Computer Networks, A. Tanenbaum
Contrôle de congestion de TCP Temps Sequence No La fenêtre de congestion double à chaque aller-retour paquet ack From Computer Networks, A. Tanenbaum cwnd croît exponentiellement (slow start), puis linéairement (congestion avoidance) avec 1 segment de plus par RTT Si pertes, divise le seuil par 2 (multiplicative decrease) et redémarre avec cwnd=1 segment
Repousser les limites de TCP Source: M. Goutelle, GEANT test campaign Large congestion window Socket buffer=64Mo Fast retransmit Optimisation des temporisateurs (RTO) Configuration standard (vanilla TCP) n’est pas adaptée dans la plupart des OS, tout est sous-dimensionné: Buffer d’émission, réception Taille de la fenêtre de contrôle de flux Buffer système Taille des blocs par défaut On peut atteindre 1Gbits/s si tout est bien optimisé
Les nouvelles enseignes de TCP H-TCP XCP BIC TCP FAST TCP HS-TCP S-TCP TSUNAMI
High Speed TCP [Floyd] Un représentant des approches de bout-en-bout Réseaux haut débit = faible taux de pertes Modifie la fonction de réponse pour augmenter le taux d’utilisation Packet Drop Rate P Congestion Window W RTTs Between Losses ------------------ ------------------- ------------------- 10^-2 12 8 10^-3 38 25 10^-4 120 80 10^-5 379 252 10^-6 1200 800 10^-7 3795 2530 10^-8 12000 8000 10^-9 37948 25298 10^-10 120000 80000 Table 2: TCP Response Function for Standard TCP. The average congestion window W in MSS-sized segments is given as a function of the packet drop rate P. HSTCP Congestion Window W RTTs Between Losses ------------------- ------------------- 12 8 38 25 263 38 1795 57 12279 83 83981 123 574356 180 3928088 264 26864653 388 From draft-ietf-tsvwg-highspeed-01.txt
HSTCP et AIMD Sans perte: cwnd=cwnd+a Perte: cwnd=cwnd*b TCP: a=1, b=0.5 HSTCP a=f(cwnd) b=f(cwnd)
XCP [Katabi02] Approche à assistance des routeurs, généralise le concept ECN (FR, TCP-ECN) Un routeur XCP détermine la bande passante disponible en observant les trafics d’entrée et de sortie Un feedback est envoyé vers la source par le biais des ACKs: pas d’état par flux, émulation d’un AIMD par flux feedback=.rtt.(Or-Ir)-Q =0.4, =0.226 Q: persistent queue size Q H_feedback EC FC source Input rate: Ir Output rate: Or XCP packet header H_cwnd (set to the sender’s current cwnd) H_rtt (set to sender’s RTT estimate) H_feedback (initialized to sender’s demands)
XCP vs TCP Simulation sur ns-2 XCP plus stable et performant que TCP
Equité de XCP TCP et HSTCP ne sont pas vraiment très équitables... Pacheco et Pham, MICC-ICON 2005
Limites de XCP XCP demeure cantonné à des plate-formes 100% XCP Pas d’interopérabilité entre les équipements Mauvaise performance si des routeurs IP classiques (non-XCP) se trouvent dans le goulot d'étranglement. Peu d’équité entre protocoles différents Performance fortement dégradée si différents protocoles de bout en bout sont exécutés dans le même réseau.
Routeur XCP-Routeur IP Moins performant que TCP!
Propositions pour une version interopérable de XCP Le problème d'interopérabilité empêche fortement la mise en place incrémentale de XCP XCP-i (i = interoperable) attaque ce problème : sans ajouter d’états par flux, en gardant les mécanismes de contrôle de XCP. Problème n°1: Découvrir le nuage non-XCP ?
Détection du nuage non-XCP ? XCP packet header xcp_ttl = TTL xcp_ttl = TTL xcp_ttl -- TTL -- TTL -- xcp_ttl != TTL TTL -- xcp_ttl = TTL H_cwnd H_rtt H_feedback Xcp_ttl Découvrir le nuage non-XCP : Utiliser le champs IP TTL Nouveau champ xcp_ttl_ dans l’entête XCP Décrémenter xcp_ttl_ dans chaque routeur XCP-i Comparer xcp_ttl_ avec le champ TTL de l'en-tête IP Problème n°2: Déterminer les ressources du nuage non-XCP ?
Déterminer les ressources dans le nuage non-XCP ? last_xcp_router_ = S S = R0 R0 = R2 XCP packet header H_cwnd H_rtt H_feedback Xcp_ttl Last_xcp_router Connaître le dernier routeur XCP-i traversé (R0). Nouveau champ last_xcp_router_ dans l’entête XCP Remplir avec l'adresse du dernier nœud émetteur Estimer l'état du réseau dans le nuage non-XCP (R0 -> R2) Déclencher une procédure d'estimation de bande passante BP (algorithmes existants: packet train, pathirp…) Problème n°3: Prendre en compte l’estimation dans le calcul du feedback?
Routeur virtuel XCP-i pour le calcul du feedback Communiquer BP au routeur qui a demandé la procédure (R2). AIMD Table de hachage Création du routeur virtuel XCP-iv f = α.rtt.BP - β.Q (.rtt.(Or-Ir)-Q) Substituer chaque nuage non-XCP par un routeur virtuel. Or Ir BP R0 Nuage non XCP R2 80Mbps 30Mbps 80Mbps XCP-i … 30 R0 30Mbps 80Mbps R2 Table de hachage XCP-iv XCP-i Lien virtuel Lien physique 80Mbps
Performance de XCP-i dans un réseau hétérogène Simulation ns-2 Même niveau de performance que dans un réseau 100% XCP
Équité entre flux XCP-i Distribution équitable des ressources Stabilité des flux Emetteurs j0 , j1
Sensibilité à la précision des estimations? Sous-estimation Sous-utilisation Pas de timeout Sur-estimation Timeout en fonction de la capacité en buffer des routeurs
Conclusions Propositions sur l'interopérabillité des protocoles dans des réseaux hétérogènes. XCP-i est le premier pas vers un protocole basé sur l'assistance des routeurs interoperable. XCP-i conserve le contrôle de XCP tel quel XCP-i est performant dans une large gamme de topologies.
Travaux en cours Implémentation de XCP-i dans un noyau Linux. Déploiement et validation de XCP-i à grand échelle sur la plate-forme Grid5000. Equité avec des protocoles de bout en bout (TCP). Surestimation de bande passante dans des cas particuliers