[Bda] ATM (blabla explicatif)

[skaya@enix.org]

(je CC: ce mail au BDA, histoire que tout le monde puisse
profiter de 2 ou 3 explications sur l'ATM)

[tests IP/ATM]
> Si, c\'est sur, mais tant qu\'on a le matos sous la main, 

ouaip, c clair que si j'avais que ca a foutre je t'aurais fait
des tests de ouf, mais faut quand meme que j'avance mon stage
(il faut que vers la fin du mois, on ait trouvé l'intitulé du
stage, parceque pour l'instant on hésite entre "faire en sorte
que nux tienne le coup avec une table de routage de 320000
entrées et le traffic qui va avec" et "autre chose" ;))

> Je me demande toujour pourquoi on lit partout \"atm is very unefficient in 
> carrying ip\" (avec les fautes d\'orthographes en moin bien sur ;) )

y a 2 grandes raisons : l'overhead des en-tetes, et le paradigme de
fonctionnement - IP est completement "stateless", alors qu'ATM 
vient du monde des operateurs telephoniques et il faut etablir 
un circuit avant de pouvoir communiquer.

IP, c'est des paquets qui font quelques centaines a quelques milliers
d'octets, avec des en-tetes de 20 a 60 octets. ca fonctionne en mode
completement deconnecte, c'est a dire qu'il n'y a pas besoin d'etablir
une connexion avant d'emettre.
ATM, c'est des cellules de 53 octets, avec 5 octets d'en-tete. quand
tu veux envoyer qqchose a qq1, tu commences par etablir une connexion,
ce qui te coute quelques cellules, puis tu peux balancer tes donnees.

prenons un cas extreme : la resolution DNS. avec IP "classique", on 
se prend pas la tete, on envoie un paquet UDP - c'est la requete -
et on en recoit un autre - la reponse. simple, efficace. eventuellement,
il y a un coup d'ARP entre temps, mais rien de grave.

en ATM, il faudrait etablir une connexion avec le serveur DNS,
ce qui prendrait qq paquets a soit tout seul. ou alors, garder la
connexion avec le DNS ouverte en permanence, mais sur un gros site
ca ferait plusieurs milliers de connexions ouvertes sur le serveur
DNS - pas terrible, surtout si en plus de faire DNS il fait NIS,
NFS, serveur de temps, etc etc.

une fois les connexions etablies, l'overhead des en-tetes peut jouer.
dans un bon sens : en LANE, on peut emuler un LAN avec un MTU de
9000 octets si ca nous chante, ce qui permet d'avoir des megapaquets
IP, et les en-tetes deviennent encore plus insignifiantes que sur
de l'Ethernet - pour du transfert de donnees "bulk" genre FTP.

par contre, pour du quake (par exemple), on additionne l'overhead
IP et l'overhead ATM (en clair, ca veut dire qu'on perd 10% de bande
passante juste a cause des en-tetes ATM. dans le cas precedent,
on les perdait mais on les regagnait parcequ'on economisait sur les
en-tetes IP).

dernier point : il n'y a pas de broadcast en ATM. donc quand on
"emule" le broadcast, en fait ca veut dire qu'on envoie les paquets
sur une machine centrale qui les repete a tout le monde ... pas top
efficace. c'est ce dernier point qui implique que les protocoles
LANE soient si "compliques" : pour faire du LANE, il faut un serveur
LES, un serveur BUS, et parfois un serveur LECS. ca rajoute des
"single point of failure" dans le reseau ... 

donc voila pourquoi votre fille est muette - euh, pourquoi
on dit que l'ATM c'est pas top efficace pour trimbaler de l'IP.

maintenant, l'interet de l'ATM : prenons un operateur. il 
s'installe un reseau ATM dans tout le pays, avec des liens
de 155 a 622 mbps, voire 2,4 gbps. ensuite, il y a le client
"trucmuche" qui veut relier le site A et le site B. il tire
une LS de chaque site jusqu'au point de raccordement le plus
proche, ensuite l'operateur ouvre un PVC (permanent virtual
circuit) entre les 2 points de raccordement. un peut comme
s'il avait un reseau IP et qu'il fasse un bon vieux VPN entre
les 2 points de raccordement, a part que l'ATM offre "de base"
des notions de qualite de service et de controle d'admission
standardisees ("je veux etablir entre ces deux points un 
circuit de 10 mbps, autorisant des cretes a 20 mbps pendant
tant de secondes, le tout régulé par une paire de token bucket 
filters, le premier de 100 cellules et le deuxieme de 1000 
cellules")

autre interet de l'ATM pour l'admin cycomien : ca fait 155 
mbps, et 155 c'est plus grand que 100, en attendant d'avoir
des cartes gigabit :)

>> au passage : c\'est un peu con que LANE taxe du proc,
>> [...] parceque c\'est le seul mode qui
>> se configure vraiment tout seul et qui permet de faire
>> du \"bridging\" avec l\'ethernet de facon transparente.

pour l'aspect "config automatique" c'est pas dramatique,
le BDA peut se faire sa conf tout seul, mais le CLIP
ne permet pas de faire du bridging ATM/Ethernet niveau 2
(alors qu'en LANE on peut).