240 likes | 394 Views
XCP-i: eXplicit Control Protocol pour l’interconnexion de réseaux haut-débit hétérogènes. D.M. Lopez Pacheco 1 , C. Pham 2 , L. Lefèvre 1. 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. 1 INRIA RESO
E N D
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 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 1 INRIA RESO UMR LIP CNRS/ENS/INRIA/UCBL LIUPPA
TCP & réseaux haut débit • 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! Fibre Optique 40 Gbps 200000km/s, delai de 5ms tous les 1000kms
Pertes de paquets 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 »!
Ce que votre maman ne vous a jamais dit sur TCP! • 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 €?)! Standard TCP TCP 40 Gbps 0.3Gbps
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
La fenêtre de congestion double à chaque aller-retour paquet ack Sequence No Temps Contrôle de congestion de TCP • 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 From Computer Networks, A. Tanenbaum
Large congestion window Socket buffer=64Mo Source: M. Goutelle, GEANT test campaign Repousser les limites de TCP • 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
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 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. 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)
Q H_feedback feedback=.rtt.(Or-Ir)-Q =0.4, =0.226 Q: persistent queue size 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 EC FC source Input rate: Ir Output rate: Or XCP packet header
6s 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 • 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 ? XCP packet header xcp_ttl = TTL xcp_ttl = TTL xcp_ttl -- TTL -- xcp_ttl != TTL TTL -- xcp_ttl = TTL TTL -- Problème n°2: Déterminer les ressources du nuage non-XCP ?
Déterminer les ressources dans le nuage non-XCP • 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…) ? last_xcp_router_ = S S = R0 R0 = R2 XCP packet header Problème n°3: Prendre en compte l’estimation dans le calcul du feedback?
Ir Or BP XCP-i Table de hachage R2 30Mbps 80Mbps R0 30 XCP-iv XCP-i … 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. R0 R2 Nuage non XCP 80Mbps 30Mbps 80Mbps 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