Pradeep Sindhu, CTO de Juniper : "Nos architectures sont en avance sur nos concurrents"

Juniper et la commutation Ethernet

LeMagIT : Juniper est entré sur le marché de la commutation Ethernet il y a environ 6 ans… Mais vous n’avez pas vraiment réussi à vous imposer sur le marché des entreprises. Pourquoi ? Et comment entendez-vous résoudre ce problème ?

Pradeep Sindhu : Nous sommes entrés sur le marché de la commutation en 2008. Je pense qu’au cours des 7 dernières années, nous n’avons pas bien réussi à tirer parti de notre portefeuille produit. Ce dernier manquait par exemple de commutateurs à très haute performance. Notre réponse a été Qfabric, mais cette technologie  a été vue par l’industrie et les médias comme une architecture propriétaire. Les choses sont ce qu’elles sont…

Pradeep Sindhu, CTO de Juniper

Depuis 2008, la tendance est à des datacenters de plus en plus grands. Appelons, cela le cloud computing. Cela affecte toutes les entreprises. Cisco n’a pas le verrou qu’il a sur les entreprises dans ces marchés hyperscale. Notre faiblesse par rapport à Cisco tend donc à disparaître.

Nous avons aujourd’hui un portefeuille complet de commutateurs et n’avons d’excuses à présenter à personne.

En fait je pense que nos architectures sont en avance sur tous nos concurrents et que nous sommes idéalement positionnés pour la croissance. Il va y avoir une course impitoyable à l’efficacité dans la commutation et je ne crois pas que la multiplication des petits commutateurs est de nature à répondre aux besoins de l’hyperscale et des grands datacenters d’entreprise. Si une solution est 20 % plus efficace économiquement que l’autre, à votre avis, quelle sera celle que les clients choisiront ? 

LeMagIT : Vous venez d’annoncer une nouvelle famille de commutateurs Ethernet avec un focus sur le 40 et le 100 Gigabit.  Jusqu’alors l’adoption du 100 Gigabit dans les datacenters a été très limitée par le coût des interfaces optiques 100G. Il semble que beaucoup aient décidé d’attendre les nouvelles interfaces 25/50/100 Gigabit et ne veulent pas utiliser les interfaces 100 Gigabit 10x10G, préférant miser sur les futures interfaces 4x25 Gigabit annoncées comme bien moins chères. Ces interfaces font elles partie de votre stratégie ?

Nous ne sommes pas spécifiquement attachés aux interfaces 10x10. Nous pensons que la bonne interface est le 4x25 Gigabit, en fait 4x28 Gigabit. Comme vous le savez, cela a du sens d’adopter les interfaces 4x25, mais le problème est la lenteur des organismes de normalisation. Je sais que cela permet d’occuper pas mal de monde, mais cela est un problème pour l’industrie.

Je ferai plusieurs remarques à propos des interfaces optoélectroniques en général. Dans le Datacenter, plusieurs fabricants ont poussé très fortement la paire torsadée. Je pense que c‘était une erreur, et que les utilisateurs devraient s’en souvenir la prochaine fois qu’ils discuteront avec ces fournisseurs. La paire torsadée pour le 10Gigabit est une abomination, car elle est extrêmement consommatrice en énergie alors que tout le monde tente de réduire la consommation dans les datacenters.

Nous pensons que la bonne interface pour le 100 Gigabit Ethernet est le 4x25 Gigabit.

Pradeep Singhu, CTO de Juniper

Le cuivre, de façon générale est un mauvais support pour transmettre des données sur des distances supérieures à une dizaine de mètres. Il y a des raisons physiques fondamentales à cela. Un autre problème est le fait que la plupart des datacenters s’appuient sur la fibre multimode.

La fibre multimode est trois fois plus chère que la fibre monomode et il n’est pas possible de l’utiliser pour des interfaces WDM. De plus elle n’est pas adaptée aux longues distances. Mis à part ces défauts, je n’ai pas de reproches à lui faire (rire….).

Ma prédiction est que dans les datacenters, comme dans le WAN,  les utilisateurs vont commencer à utiliser la fibre monomode avec des diodes lasers émettrice de bord (edge emitting lasers). C’est la façon rationnelle de résoudre le problème. 25x4 va devenir le standard et nous avons l’intention de l’adopter.

Je pense que vous avez raison de dire que le coût des interfaces actuelles est élevé. L’industrie des composants optoélectroniques doit produire des innovations plus vite et doit faire baisser les prix plus vite. C’est un problème que nous étudions de près car pour l’instant les semi-conducteurs dans l’industrie réseau ont entre deux et trois ans d’avance sur les composants optoélectroniques. Éventuellement nous aurons peut-être à faire quelque chose dans ce domaine pour aller plus vite plutôt que de dépendre de quelqu’un d’autre.

LeMagIT : Vous semblez critiquer les implémentations de réseaux Clos à grande échelle. Il semble pourtant qu’Arista, la société dirigée par Andy Bechtolsheim, soit passée de 0 à 1 milliard de revenus en quelques années du fait du succès de ces architectures auprès des clients. À votre opinion, cette architecture est-elle viable ?  Ou est-elle fondamentalement incorrecte à long terme ?

Je connais Andy Bechtolsheim depuis plus de 25 ans, j’ai fait mes études avec lui. Je ne pense pas qu’Arista ait assumé que ses équipements seraient utilisés pour des grands réseaux Clos. Leurs équipements sont utilisés pour construire des réseaux de cette façon, mais cela n’était forcément le but initial.

Leur vision était plutôt que les puces en silicium sont des produits de commodité et que la valeur ajoutée est dans le logiciel. Je pense d’ailleurs  que sur ce dernier point Andy est en train de changer d’avis.

Je ne pense pas qu’ils aient fait un mauvais choix. S’il existe de bons composants disponibles sur le marché, un fournisseur serait fou de ne pas les utiliser. Juniper utilise ainsi des composants du marché depuis pas mal de temps dans ses commutateurs modulaires.

Mais le fait est que pour construire des switchs de grande capacité sans avoir à passer par 27 étages de Clos, il faut produire des commutateurs en châssis et pour cela, nous n’avons malheureusement pas trouvé de composant adéquat sur le marché.

La façon dont nos concurrents ont choisi de construire leurs produits en bâtissant des réseaux Clos dans leurs commutateurs et en s’appuyant sur ECMP [Equal Cost Multiple Path, N.D.L.R.] ne fonctionne pas bien. Cela se traduit par des performances médiocres et imprévisibles. Ils ne vous le diront jamais, mais si vous testez ces machines,  c’est ce que vous constaterez.

La technologie clé de commutation de cellules, inventée par Juniper en 2004, nous permet d’éviter le recours à ECMP en interne. Nous avons ainsi une parfaite répartition de charge dans les commutateurs et routeurs et pouvons atteindre un taux d’utilisation de 100 %. Avec ECMP, vous avez un taux d’utilisation de 60 à 70 % de la capacité et en cas de saturation, cela peut tomber à un tiers ou un quart.

Le futur des architectures réseau

LeMagIT : Intel parle beaucoup d’architectures serveur à l’échelle du rack (aussi dites « rackscale »). Si ses efforts se concrétisent, les commutateurs Top of the Rack pourraient devenir une espèce menacée et 40 % des ports Ethernet du Datacenter pourraient disparaître. Pour vous c’est un problème ?

À mon avis, le décollage des architectures Rackscale ne sera pas si simple au vu de la façon dont elles sont imaginées. Mettre des infrastructures en réseau ne consiste pas simplement à fournir un grand nombre d’interfaces 100 Gigabit, il  faut aussi assurer les bonnes fonctionnalités. 

Les commutateurs de haut de rack ont aussi un rôle bien précis et important : on peut utiliser des optiques pas chères dans le rack et d’autres plus coûteuse entre les racks; et puis ils permettent d’assurer une sur-souscription des ressources réseau d’un facteur de l’ordre de 2,5 pour 1 à 3 pour 1. Si on les élimine, ce niveau de sursouscription disparaît. 

Les entreprises vont-elles alors dépenser deux ou trois fois plus dans les interconnexions entre racks ? Probablement pas. Je pense qu’il faut réfléchir précisément avant toute décision. À mon avis, si les commutateurs ToR disparaissent, ce sera pour une autre raison

LeMagIT : Dans les grands datacenters, les grands serveurs sont progressivement remplacés par des serveurs bi-socket, sensés être moins coûteux. Mais il faut leur fournir de la connectivité, protéger leur alimentation, les gérer de façon efficace…  Ces serveurs se sont multipliés. Cela est peut-être bon pour les vendeurs de commutateurs, mais à terme, ne pensez-vous pas que l’on risque de rencontrer des problèmes d’efficacité ?

Je pense que nous avons déjà atteint ce point. Le pendule commence à changer de direction. Le problème est le suivant. L’écosystème Intel ne rend pas facile une marche en arrière et je peux expliquer pourquoi : Le modèle d’Intel vise à ce que toute la valeur ajoutée soit dans ses puces. Tout le travail autour est à faible valeur. Les cartes mères sont construites de façon simple et stupide avec six couches… Si vous voulez concevoir des serveurs plus sophistiqués, il faut faire le travail vous-même; vous n’aurez aucune aide d’Intel.

Il y a des façons d’améliorer  cette approche, mais la question est de savoir si l’industrie sera capable de le faire. Et puis Intel a réussi à convaincre tout le monde que les cycles CPU x86 sont les seuls disponibles et qu’ils sont gratuits. On en est pourtant très loin, mais c’est une vraie prouesse marketing que d’avoir réussi à le faire croire.  Le problème est que la fréquence ne peut plus guère évoluer, le nombre d’instructions par cycle a atteint un plafond est qu’Intel ne peut presque plus jouer que sur le nombre de cœurs. Il faut accroître les I/O et les puces manquent de broches. C’est un vrai problème pour l’industrie

LeMagIT : Et en plus la performance des composants SERDES n’évolue pas de façon drastique…

Intel n’utilise en fait même pas les SERDES  à 25 Gbit/s car s’il le faisait, cela remettrait en question sa stratégie de manufacturing à bas coût. Dans sa course à la banalisation, Intel bat la campagne pour dire qu’il ne faut pas acheter les technologies comme les nôtres, et qu’il faut bâtir des commutateurs autour de l’architecture x86 à base de composants Intel.

La seule façon d’avoir plus de performances est de spécialiser les composants en fonction des besoins

Praddep Sindhu, CTO de Juniper

Entre 1969 et 2014, il y a une tendance générale à la consolidation des architectures de computing, au point qu’il n’y en a plus que deux sur le marché, Intel et ARM. La seule échappatoire est la spécialisation fonctionnelle. La seule façon d’avoir plus de performances est de spécialiser les composants en fonction des besoins et je ne vois pas d’autre solution magique pour obtenir plus de performances.

Cette spécialisation est de nouveau rendue possible par la compétitivité retrouvée d’acteurs comme TSMC, GlobalFoundries, Samsung ou UMC en matière de technologies de gravure. Alors qu’ils avaient sans doute 2 ans de retard sur Intel il y a 4 ans, ils n’ont plus que 9 à 12 mois de retard en matière de lithographie…

À mon avis, cela va donner un nouvel élan à la spécialisation fonctionnelle et on va aussi voir l’émergence des architectures 3D pour regagner des marges en matière de performance, ce que nous avons d’ailleurs fait avec notre dernier ASIC de commutation.

Juniper et les SDN

LeMagIT : Pour en revenir aux réseaux, on parle de plus en plus de SDN et de séparation entre plan de contrôle et plan de données.

Il y a une grande incompréhension dans l’industrie que les médias peuvent sans doute aider à clarifier. Il est évident que la nature même des réseaux est d’être physiquement distribués. Il y a eu deux avancées au cours des 50 dernières années dans les réseaux. La première a été l’invention de la commutation de paquets et la seconde la découverte automatique de topologies, incarnée par les protocoles de routage. Ce que cela nous a donné est un niveau phénoménal d’automatisation. L’internet fonctionne malgré tous les incidents que peuvent connaître les équipements. L’industrie a défini un élément, le routeur, qui a deux fonctions principales : le packet forwarding et le calcul de routes. Ces deux fonctions étaient historiquement liées. Juniper les a séparées. On a été les premiers à le faire. Pour nous le travail de forwarding de paquet ne doit pas être fait par des CPU généralistes. Par contre le calcul de route est idéal pour ces puces.  On est pour cette séparation, mais il faut que les deux fonctions continuent à cohabiter dans cette boîte que l’on appelle un routeur.

Si on veut retirer le control plane du routeur, ce que certains veulent faire,  mon avis est que la résultante est un équipement qui est inutile. Car  je me retrouve avec un réseau d’équipements sans control plane et un control plane centralisé. Je perds la localité et j’ai un problème plus grave. Il faut un réseau pour que le control plane centralisé parle aux équipements. Comme l’initialiser. Il y a un problème de l’œuf et de la poule de la taille d’un éléphant. Les professeurs à Berkeley et Stanford ont complètement raté ce point et c’est aussi le cas de certains responsables réseaux d’opérateurs qui sont tombés amoureux de ce concept. Notre vue est que le réseau doit être bâti avec des control plane locaux mais qu’il faut un control plane de plus haut niveau qui sert deux fonctions : l’optimisation de chemins (qui ne peut être distribuée). La seconde est la fonction de résolution d’échelle. Si j’ai 1 000 routeurs de bordure et 1000 routeurs de peering et que je veux bâtir un réseau « any to any », j’ai un problème de scaling.

LeMagIT : Si l’on applique cette réflexion au datacenter, la réponse de Juniper, avec son architecture SDN Contrail, a été d’apporter un routeur CE dans les serveurs…

Contrail est exactement cela. Le concept a été inspiré du concept de CE-PE dans MPLS.

LeMagIT : Nuage Networks, la filiale SDN d’Alcatel Lucent, a une approche un peu similaire….

Oui, mais Nuage est arrivé un peu plus tard. Nicira de son côté avait une approche religieuse et les VLAN sont une façon terrible de résoudre le problème du fait de leurs limitations.

Avec les fabriques réseau, on a pensé voir émerger des réseaux de datacenter de niveau 2 à plat…

Moi aussi je crois au père Noël !

LeMagIT : À l’inverse, d’autres estiment qu’il faut généraliser le niveau 3 à l’échelle du datacenter…

C’est l’approche que nous privilégions. C’est approche de Contrail mais aussi de toutes les sociétés qui font du web à grande échelle. Personne ne veut toucher au niveau 2 car cette technologie ne « scale » pas. Cela ne vaut pas dire qu’Ethernet en tant qu’interface est  une mauvaise chose. Au Parc [ le Palo Alto Research Center de Xerox, N.D.L.R.], Ethernet a été inventé conjointement avec PUP (le protocole Parc Universal Packet) qui est un peu le grand-père d’IP. C’est pourquoi Ethernet fonctionne aujourd’hui si bien avec IP.