Problèmes haut débit

Réseaux Haut Débit :
où est le maillon faible ?
Années 1980
LAN 10 Mb/s mais WAN ~ 100 Kb/s
Années 2000
LAN 100 M, 1G, 10G ou + , WAN 2,5Gb/s, 10G , …
IEEE 802.3ba : étude de ethernet 40G (LAN) et 100G (WAN)
Exemple Renater5 (ouvert 2008)
Liaisons à 10G
Fibres noires pour Grilles de calcul (WDM)
RHD 2009
1
RHD 2009
2
•Haut débit : niveau physique
• Niveau physique : fibre
• 10 Giga et au delà
• Multiplexage en longueur d’onde
• WDM, DWDM
• par exemple 10 Giga par λ
• très grandes distances
• câbles transocéaniques
• => très grands progrès
• pas le facteur limitatif
RHD 2009
3
Haut Débit niveaux 2 et 3
Commutateurs Giga ethernet
Catalyst 3560 24 10/100/1000T + 4 SFP :
4800 $ (niveau 2) 7000 $ (niveau 2/3)
Routeurs haute performance
Juniper M160
Chassis 50 000 $
carte OC192/sonet (1 port 10G) 335 000 $
carte routage 20 000 $
carte 2 ports 1 G 43 000 $
Cisco 12816 (jusqu’à 16 slots à 40G)
Cisco 12816 chassis $217,500
Cisco 12816 1280Gbps Switch Fabric Card $45,000
Cisco 12000 1-Port 10GE Card, 1550nm $165,000
=> limiter le nombre de routeurs (VLAN)
RHD 2009
4
Comment commuter à haut-débit ?
accélérer le « routage »
meilleurs algorithmes de « longest match »
MPLS
accélérer la commutation elle-même
switch fabric bus, cross connect, anneau, …
sans blocage = la commutation interne ne ralentit pas
pas toujours vérifié
si on avait 24 ports 1G sur un bus à 10G ?
nécessite que débit fabric >> ∑ débit lignes
RHD 2009
5
Switch simple
Ex : routeur PC
architecture simple
accès mémoire simultanés
bus IO de débit > somme débits interfaces
double copie des paquets
cartes interfaces simples
process centralisé
amélioré si DMA carte => mémoire
RHD 2009
6
cartes « intelligentes »
RHD 2009
7
Cartes intelligentes (2)
buffers, FIB, calculs
distribués sur les cartes
accès direct carte à carte
limitation : accès au bus
débit
concurrence
CPU
signalisation (proto routage => RIB)
contrôle cartes, charge FIBs
opérations + complexes (tunnels, …)
RHD 2009
8
CEF cisco express forwarding
RHD 2009
9
dCEF Distributed CEF (doc cisco)
RHD 2009
10
Switch haute performance
RHD 2009
11
Switch haute performance(2)
« switch fabric »
circuit de commutation
circuit à N entrées et N sorties
entrée (et sortie) des paquets en //
remarque : systèmes « crossbar » en téléphonie
plus simple si petits paquets de taille fixe
voir ATM
que se passe-t-il si 2 paquets pour la même sortie (contention) ?
RHD 2009
12
Ex : crossbar avec arbitre et buffer
si plusieurs demandes
pour même sortie
arbitre sélectionne
autres paquets : buffer
coûteux NxN buffers
RHD 2009
13
N bus broadcast
Paquet contient adresse sortie
Analogue ethernet …
RHD 2009
14
switch et blocage
2 types de blocage
dans le switch
en sortie
Solutions
surcapacité du switch (ou switchs //)
buffers
contrôle (arbitre => buffers en entrée)
RHD 2009
15
Switchs cascadés
Elément de base 2x2
Si adresse 0 => haut
sinon bas
si conflit :
buffer
RHD 2009
-Eléments de base
cascadés
-utilisent bits
successifs adresse
16
Ex : Banyan (self routing)
000
100
X
001
110
contention interne ou en sortie possible
RHD 2009
17
Solutions
Buffering dans cellules intermédiaires
coûteux
réservation du chemin
solutions basées sur le tri des entrées
Batcher Banyan : pas de contention interne
tri (Batcher sort)
détection doublons (conflits de sortie : trap)
doublons réinjectés à l’entrée
mélange (shuffle exchange)
Banyan
RHD 2009
18
Tri par fusion
1
3
4
6
1
2
2
4
3
2
3
4
4
5
5
2
5
7
5
6
7
6
8
6
7
8
RHD 2009
19
exemple composite
Batcher-Banyan
RHD 2009
20
Où mettre les buffers ?
en entrée ?
RHD 2009
21
Buffers en entrée
le switch n’a pas besoin d’être plus rapide que les liens de
sortie
arbitre gère les conflits de sortie
problème du Head of Line Blocking HoL
si la tête de la file bloquée (= sortie occupée)
=> paquets suivants dans la file bloqués
même si leur sortie est libre
RHD 2009
22
Buffers en sortie
RHD 2009
23
Buffers en sortie
Très courant
permet de gérer les flux concurrents
pour une sortie = utilisation lien sortant
Pas de HoL blocking
Buffers doivent être rapides
pour ne pas bloquer les entrées
au pire N fois vitesse de ligne
RHD 2009
24
Buffers partagés
adresses transmises par switch
données en mémoire double accès
RHD 2009
25
Solutions hybrides
buffers en entrée et en sortie
et/ou dans la fabric
complexes à analyser
utilisées en pratique
RHD 2009
26
Cas particulier : multicast
Eviter recopies multiples
bus en broadcast adaptés
augmente le risque de blocage dans les switchs
RHD 2009
27
RHD 2009
28
RHD 2009
29
Structure switch fabric cisco (12000)
RHD 2009
30
Files virtuelles en entrée
=> évite HoL blocking
Possibilité de plusieurs switch fabrics
fonctionnent en parallèle
augmentent débit
Ex : Cisco 12816 switch permet
40 G Full Duplex sur chaque carte interface (slot)
16 slots => 1,28 Tb/s
utilisé même pour ré-émission même carte (équitable)
http://www.cisco.com/en/US/products/hw/routers/ps167/products_tech_note09186a00801e1dc1.shtml
RHD 2009
31
Archi routeur cisco
FIB (Forwarding base)
distributed CEF (Cisco Express Forwarding)
• paquets segmentés en cellules de 44 octets +
entête pour fabric (analogue ATM)
• RP (Route Processor)
• reçoit/envoie messages routage
• calcule RIB
• envoie FIB/CEF aux cartes
• rem : peux prendre du temps ~ centaines ms
• le tout via fabric
RHD 2009
32
Arrivée paquet cisco 12000
engine 2
7 émission cellules vers fabric 1 par 1
6 requête fabric
5 paquet fragmenté en cellules
4 paquets dans CEF
3 mise en file virtuelle
2 consultation CEF dans PSA
(Packet Switching Asic)
1 arrivée trame
RHD 2009
33
Emission paquet
8 arrivée des cellules
9 allocation buffer/réassemblage
10 mise en file de sortie (ou
drop)
11 émission
RHD 2009
34
Haut débit
Et la couche transport ?
limitations de TCP ?
limitations des systèmes ?
RHD 2009
35
La couche transport
session
session
service de bout en bout
transport
transport
réseau (A)
réseau
réseau
réseau (B)
liaison
liaison
liaison
liaison
physique
physique
physique
physique
extrémité 1
lien 1
routeur 1
lien 2
routeur 2
RHD 2009
lien 3
extrémité 2
36
TCP (Transmission Control Protocol)
Décrit dans les RFC 793, 1122, 1323, …
constante évolution
Modèle de service TCP
orienté connexion, bidirectionnelle
fiable : gère les pertes, remet les données dans l’ordre
assure un contrôle de flux entre émetteur et récepteur
une connexion TCP est identifiée par deux extrémités (adresses
des sockets émetteur et destinataire)
les données sont véhiculées sous forme de flots d’octets
pas de délimitation des messages de bout en bout
équivalent d’un tube Unix
il existe un service de données urgentes
assure (implicitement) contrôle de congestion d’Internet
RHD 2009
37
TCP : principes
un message TCP (segment) est transmis dans un paquet IP
tout octet de données transmis sur une connexion TCP est
référencé par un n° de séquence (32 bits)
un message TCP est formé d’un en-tête d’au moins 20 octets
suivi éventuellement d’options et de données
la taille d’un segment est limitée par :
la charge utile d’IP (maximum 65 535 octets)
le «Path MTU discovery » peut être mis en oeuvre par TCP pour
éviter la fragmentation
la fragmentation ralentit beaucoup la transmission
TCP utilise une fenêtre d’anticipation en émission
fenêtre de taille variable (contrôle de flux et congestion)
et éventuellement en réception (SACK)
l’entité réceptrice acquitte avec le n° du prochain octet attendu
(ACK cumulatif)
RFC 1106 implémente la retransmission sélective
RHD 2009
38
Format entête TCP
bits 0
31
Port Source
Port Destination
Numéro Séquence
Numéro Acquittement
Taille entête et flags Fenêtre W
Checksum
Pointeur Urgent
Options éventuelles + bourrage
Données éventuelles (nb entier d’octets)
RHD 2009
39
Entête TCP : signification
taille de fenêtre W (16 bits) : contrôle de flux explicite
si = 0 : blocage de l’émetteur
si > 0 : indique combien d’octets peuvent être
transmis à partir de N° Acquittement
option :
certaines options utilisées à la connexion (négociation
des capacités)
d’autres utilisées en cours de connexion
RHD 2009
40
Exemples d’options
MSS (Maximum Segment Size) : taille maximale que
l’entité TCP peut recevoir dans son tampon
(minimum du MSS des deux extrémités).
le MSS est l’unité de mesure de la fenêtre de
congestion
Window scale
permet d’augmenter la taille de la fenêtre
Timestamp : horodatage
Possibilité de retransmission sélective (SACK
accepted)
RHD 2009
41
Transfert de données (1)
Transfert bidirectionnel simultané
Transfert de données
la gestion des fenêtres d’anticipation est liée :
aux réceptions d’acquittements
au rythme de lecture / écriture des applications
L’émetteur peut envoyer les octets compris entre
dernier N° ACK reçu
et
dernier N°ACK reçu + dernier W reçu
W permet donc au récepteur de ralentir émetteur
W = « crédit émission »
RHD 2009
42
Transfert de données (2)
Fiabilité
récepteur accepte dans l’ordre et acquitte
émetteur arme délai de retransmission RTO
associé au plus ancien octet non acquitté
si RTO se déclenche : retransmission (continue)
Efficacité dépend estimation RTO
très variable suivant connexion
principe
RTT calculé pour chaque paquet acquitté : dernierRTT
NouveauRTT = a*AncienRTT + (1-a)*dernierRTT
RTO = b * NouveauRTT
(0 < a < 1, b > 1)
algo de Karn : ne pas tenir compte paquets retransmis
RHD 2009
43
Exemple échange
Syn, S=100,A=0,W=4000
Syn,Ack, S=250, A=101, W=2000
Ack, S=101,A=251,W=4000,(1000)
S=1101,A=251,(1000)
(attente)
S=2101,A=1751,W=4000,(1000)
S=3101,A=1751,W=4000,(1000)
bloqué
S=251,A=1101,W=1000,(1500)
S=1751,A=2101,W=2000,(0)
X
perte
S=1751,A=2101,W=2000,(0) (pas accepté)
Retransmission timeout (RTO)
S=2101,A=1751,W=4000,(1000)
RHD 2009
44
Contrôle de flux (1)
Débit avec TCP standard
W < 64 Ko (souvent moins : paramètre
système)
au plus W par RTT
Ex :
RTT = 1ms (LAN) Esplanade Illkirch ~0,8 ms
64Ko /ms => 64 Mo/s ~500 Mb/s
RTT = 640ms (satellite)
64 Ko / 640 ms ~800 Kb/s
intérêt du paramètre Wscale (Window scale)
Wscale = n => multiplie W par 2n
RHD 2009
45
Wscale
Analyse des flux Osiris <=> Renater
- trace de 15’
- sur plus de 435 000 connexions
- moins de 126 000 utilisent option
wscale
- 60 000 wscale > 0
RHD 2009
46
Contrôle de flux (2)
Emetteur bloqué dans 2 cas
W = 0 (récepteur saturé)
=> attendre de recevoir segment avec W >0
La fenêtre d’émission est pleine
W octets envoyés et non encore acquittés
si perte d’un Ack : attendre Ack suivant (cumulatif)
si perte données : attendre RTO et retransmettre
si aucune erreur : attendre Ack (au plus RTT)
peut indiquer que W trop petit
RHD 2009
47
Contrôle de flux (3)
Exemple (Mac OS)
paramètres TCP
sudo sysctl -a | grep net.inet.tcp.*space
net.inet.tcp.sendspace: 32768
net.inet.tcp.recvspace: 32768
fenêtres limitées à 32 Ko
RTT 1ms => ~256 Mb/s
RTT 100 ms => 2,56 Mb/s
peut être changé, ex :
sudo sysctl -w kern.ipc.maxsockbuf=2000000
sysctl -w net.inet.tcp.sendspace=500000
sysctl -w net.inet.tcp.recvspace=500000
RHD 2009
48
Contrôle de congestion
Dans Internet, contrôle distribué dans les stations émettrices
TCP s’en charge, en diminuant le débit des données émises
=>TCP fait varier dynamiquement la taille de la fenêtre
d’émission
perte (et retransmission)
interprété par TCP comme congestion dans le réseau
=> TCP surveille les temporisateurs de retransmission pour
détecter une congestion
TCP gère deux fenêtres :
« fenêtre de contrôle de flux » : relative à la capacité du
récepteur (paramètre W)
« fenêtre de congestion » : relative à la capacité du
réseau (paramètre CW)
=> le nombre d’octets qui peut être envoyé doit être le
minimum de ces fenêtres
FE = min (W, CW)
RHD 2009
49
Contrôle de congestion (2)
TCP basique (Tahoe, années 80)
Débit initial : doit être faible (capacité réseau inconnue)
La fenêtre de congestion CW est mesurée en MSS
algorithme du « démarrage lent » (Jacobson 88)
à l’établissement de la connexion, CW = 1
émetteur envoie un segment de taille maximum
à chaque acquittement sans timeout, CW = CW +1
=> à chaque RTT sans perte CW double (croissance
exponentielle)
CW est limité à W
=> si W faible CW n’augmente plus
Lors d’une retransmission (Timeout)
considère qu’il s’agit d’une congestion
redémarre en slow start avec CW = 1
RHD 2009
50
Contrôle de congestion (3)
Tahoe (suite)
Pour éviter les oscillations
quand la fenêtre CW atteint un seuil S
on augmente CW de 1 par RTT (au lieu de 1 par ACK)
augmentation linéaire
phase d’évitement de congestion
Calcul de S : initialement S = Wmax (64 Ko ou limite système)
à chaque retransmission sur timeout
(= congestion)
on prend S égal à la moitié du dernier CW
S := CW/2
CW := 1
RHD 2009
51
Pertes aux temps 4, 13, 24, 36
RHD 2009
52
Contrôle de congestion (4)
Si perte, attente RTO : peu efficace
« fast retransmit » (TCP Reno)
Si 3 Ack dupliqués
3 paquets sont arrivés après un « trou »
réseau congestionné mais « pas trop »
fast retransmit (RFC 2581) retransmettre toiut de suite
sans attendre timeout
Fast recovery : ne pas repasser CW à 1
S := CW/2 CW := S
évitement de congestion
si Timeout
S := CW/2
CW := 1
slow start
RHD 2009
53
Perte et triple ACK au temps 4, 10,19,Timeout au temps 26
RHD 2009
54
Retransmission sélective
Nouveau mécanisme introduit RFC2018
négocié à la connexion
option SACK_permitted
si récepteur détecte une perte
N° Seq segment reçu > N° Seq segment attendu
récepteur envoie Ack avec
option SACK : contient n fois (début, fin)
indique réception de n blocs « isolés »
évite retransmission continue
permet de déclencher le fast retransmit/recovery
RHD 2009
55
Fenêtres : synthèse
Côté émetteur
Ni
DA S1
DE
Envoyé
Envoyé
et acquitté non tous acquitté
DA +FE
Peut être envoyé
si DE < DA + FE
Ni : Numéro initial choisi par l’émetteur
DA : dernier N° Ack reçu
S1 : segment acquitté par SACK
DE : dernier octet envoyé
FE: fenêtre émission, min(W, CW)
A chaque acquittement
DA avance
FE est recalculé
RHD 2009
56
Fenêtres : synthèse (2)
Côté récepteur
Ni
Reçu et
acquitté
PA
S1
S2
PA + W
Peuvent être acceptés
Ni : Numéro initial choisi par l’émetteur
PA : Prochain attendu = dernier N° Ack envoyé
W : Fenêtre réception (fonction des capacités)
S1, S2 blocs reçus dans le désordre (SACK éventuel)
non encore fournis à l’application
A chaque segment attendu reçu
PA avance
W est éventuellement recalculé
Acquittement éventuellement envoyé
RHD 2009
57
TCP : conclusion
Protocole stable
amélioration algo retransmission/congestion
Optimisation pour réseaux très haut débit
Wscale, SACK
Manque d’efficacité si réseau peu fiable
perte ≠ congestion
Exemple : réseaux sans fil
RHD 2009
58
TCP et haut débit
Problème des Long Fat Pipe
Formule de Mathis
(approchée, avec TCP Reno)
calcul des « dents de scie »
Si bande passante pas limitée par W
BP < MSS * C / (RTT * √p )
où p est la probabilité de perte de paquet
Ex MSS = 1500o, RTT = 100 ms, p = 1%
BP < 1500 * 8 * C /(0,1 * racine (0,01)) = 1,2 Mb/s
(en prenant C = 1)
Si p = 0,0001, BP < 12 Mb/s
RHD 2009
59
TCP et haut débit
fiabilité
RTT : limiter les routeurs : commutateurs
vitesse du signal : pas de gain possible (vitesse lumière)
Augmenter le MSS
réseaux spécialisés avec MSS > 1500 octets
exemple myrinet
proposition de jumbo frame (pb de compatibilité)
Améliorer retransmission TCP (dents de scie)
A défaut
régler taille fenêtres
ouvrir connexions parallèles ( ~ multiplie le MSS)
RHD 2009
60
sources
Renater
http://www.renater.fr/spip.php?rubrique12
Switching
An engineering approach to computer networking, S. Keshav,
Addison-Wesley
Architecture CRS1
documentation cisco
http://www.cisco.com/en/US/products/ps5763/index.html
TCP
les RFC
RHD 2009
61