A scalable and accessible roadmap

Our published roadmap provides an overview of current development priorities, and an extensive breakdown of ongoing and future changes. It’s a dedicated space where various services are discussed for planning features, improvements, and product scalability.

• Web Hosting: Hosting solutions for websites and applications.
• Telecommunications Services (Telecom): IP telephony services and connectivity.
• Collaboration (Collab): Tools like Microsoft Exchange, Zimbra, professional/business emails, and Microsoft 365.
• VPS/Bare Metal Eco: Affordable hosting solutions for virtual private servers (VPS) and dedicated servers.

We’ve published this roadmap to help you stay up to date on product development, especially the ones you use, and actively contribute to improving them. Thanks to this roadmap, you can share your ideas, voice your concerns, as well as suggest essential functional changes and how they can make our products even better.

A communication tool

This space is primarily designed to encourage the sharing of ideas and opportunities for improvement. Our goal is to give our users a space where they can freely share their thoughts and suggestions, and be actively involved in improving our products and fulfilling our roadmap. Your suggestions help us understand what our users want, so we can tailor our solutions to match your needs.

Please keep in mind that this roadmap is not a support channel; it’s not meant for ticket or technical support requests. If you have any issues or need customer support, please reach out through the usual channels — the OVHcloud Control Panel, official documentation, or the OVHcloud community.

How do I take part?

Want to help us enhance our services? It’s quite straightforward! Check out our GitHub roadmap to see the exciting features we have in the works, including planned improvements, or even ideas from other community members. You can:

• Share your thoughts: we welcome any suggestions you may have for new features, or improvements that could elevate our collaborative and telecom solutions, and hosting and domain name solutions. Also, VPS and Bare Metal Eco (BM Eco) services are featured on both the current roadmap as well as the dedicated Public Cloud roadmap.
• Voting and leaving comments: get in on discussions, share your thoughts, and support ideas that matter to you.
• Track updates: stay in the loop with our live progress, ongoing deployments, and upcoming projects.

A constantly evolving approach

At OVHcloud, we believe working together is key to building products that truly serve our customers. This published roadmap gives you the peace of mind and foresight to effectively plan your projects. We’re always looking to extend the reach of our services, and we can’t do that without you.

In conclusion

Publishing our Hosting, Telecom and Collaboration roadmap shows how committed we are to making transparency and collaboration central to our approach. We’ve made this GitHub space available, so you can keep up with how we tailor and scale our services, and play an active role in enhancing them. Your input, ideas, and feedback are building blocks that help us develop products that are specially built for you. We’re shaping the future of our services with your input — your experience and expectations matter!

Join us now and make a difference in improving OVHcloud solutions! Check out our changelog and roadmap for our Cloud solutions, also on GitHub.

The OVHcloud network has 34 PoPs (Points of Presence); located in Europe, North America and Asia-Pacific. With a global capacity of around 21Tbps, the OVHcloud network can handle much more traffic than other providers.

At OVHcloud, network traffic is constantly growing to meet the needs of millions of internet users, who utilise our 31 data centers across the globe.

Over the past few years, OVHcloud have been working to improve the infrastructure of our worldwide backbone network.

Scaling up our network further

With almost two years of research and development, the OVHcloud network team has come up with a brand new infrastructure. Each datacenter is connected to multiple PoPs (Point of Presence). PoPs share traffic with various other OVHcloud datacenters as well as exchanging traffic with different providers (known as Peers).

The current architecture, known internally as ‘sticky router’, is based on a router for routing and a switch which plays the role of the power board. For a few years, it had worked quite well (and at a low cost), but the method eventually reached its limit in terms of bandwidth. We needed to find and design another system which could handle the increasing traffic. Our requirements were simple; we needed a low cost, low-power efficient, and scalable infrastructure.

Providing the best possible connectivity for our worldwide customers has been the company’s driving force since it was created by Octave Klaba. To do this, we wanted to be connected to local providers as far as possible, requiring multiple ports in 10Gbps or 100Gbps.

Re-thinking our PoP topologies, we considered new scalable technologies, including:

• Port capacity: would have to be based on 100Gbps and 400Gbps ports, and have a good cost efficiency. This would help eliminate any bottlenecks in the network. It also needed to maintain 10Gbps links for those providers who were not ready for 100Gbps ports.
• Easy to upgrade: The new architecture needed to be easy to upgrade, in terms of capacity. This is partly for the growth of the company, but also to maintain availability when network maintenance is required on the PoPs.
• Power: The team needed to find the best hardware for maximising power-consumption efficiency; especially in countries like Singapore where it’s expensive.
• Security: A key requirements would be to work with our security teams to find the best solution for protecting the network against threats (massive DDoS attacks).

After almost 1 year of research and tests, the design team came up with a brand new architecture; which was scalable, power efficient, easy to install and robust. The new architecture was named SMAUG, after the dragon in The Hobbit.

Overview of SMAUG

To be adaptable, the architecture has multiple capacity options, depending on how big the PoP is. This is because different amounts of traffic are exchanged at different datacenters. Each capacity option has its own specificity, with the objective of no bottlenecks.

Spine and Leaf infrastructure

SMAUG is a ‘Spine and Leaf’ infrastructure. This means the ‘spine’ (called SBB for SuperBackBone) aggregates the leaves and connects each datacenter. The ‘leaf’ devices (called PB for PeeringBox) are used for connecting providers and also internal services such as xDSL equipment or OVHcloud Connect.

SMAUG infrastructure also provides another way to connect a datacenter where there is a minimum of two PoPs, both in a different location. For example, in Singapore, our datacenter is connected to two PoPs, which have more than 30 kms between them – this meets the rule of not using the same power source for two PoPs.

To ensure redundancy, both the PoPs need to be connected to each other with a huge amount of capacity – in 100Gbps or 400Gbps, depending on the PoPs. The transmission team was also involved in developing a new infrastructure called ‘GALAXY’. GALAXY was based on a different constructor – combined with a simple-to-deploy, scalable, operational model, with less energy consumption.

The role of the leaf is pretty simple and is similar to the top of the rack in a datacenter. It has a huge amount of uplink capacity towards the spines and has the configuration for connecting BGP peers; such as transit providers, private interconnection (PNI) and Internet eXchange.

The spine role is more complex and has added functionality, including:

• Long-haul links: It has the connection of the links, based on 100Gbps, towards datacenter(s) and PoP(s).
• Routing: It has the entire routing table in order to take the best path towards the OVHcloud datacenters or towards the external networks.
• Protection: The VAC team has been involved in it by developing a new protecting tool (for more information: https://www.ovh.com/blog/using-fpgas-in-an-agile-development-workflow/) in order to help to protect the entire OVHcloud network from DDoS attacks.
• Mitigation: It also helps the detecting system used by the VAC infrastructure (https://www.ovh.co.uk/anti-ddos/)

Testing and deploying

After the design team and management were sure it was the best architecture for the OVHcloud network, we started testing different brands, providing all the functionality was implemented correctly. After all the tests had been completed in the laboratory, and we were confident that the solution was viable, we started the deployment of the infrastructure in Singapore. This region was one of the most important in terms of traffic growth. It was also easier because we already had the dark fibers for the links between the datacenter and the PoPs.

In January, we ordered all the devices and transceivers, then prepared the migration plan in order to schedule the whole deployment at the end of March. At the end of February, we prepared the configuration and tested the brand new devices. When everything was in order, we sent all of them to Singapore PoPs.

At the beginning we planned to do this migration mid-march 2020 and we were supposed to send our technicians from France to Singapore, but due to COVID-19 we had to change our plans. We had to find another solution and ask our local technicians working in our Singaporean datacenter to do the job. The migration plan was more complicated due to the new reorganization that needed to be in place for the pandemic.

After a long discussion between the management, the network team and the Singaporean OVHcloud technicians, it was decided to do the migration of the first PoP at the beginning of April and the second one at the end of April. The migration began by racking the brand new devices in two new racks, preparing the wiring for the migration, and doing some checks before the hotswaps.

Migrating to SMAUG

The pressure for this migration to be successful was high, as we did not want it to impact our customers. On the first night of the migration – once we had dried out the traffic from the first PoP – we asked the technicians to move all the long-haul links to the Singapore DC, and for Australia, France and USA, to new devices. After some tests, we put the new devices in production. The first step of the migration went well.

The next day wasn’t quite so smooth, as it was the first time we were putting our new Peering Box in production with our new border protection system, based on FPGA servers. After we removed the traffic from our peers, traffic was then leaving the OVHcloud network via the second PoP. Then we moved the fibers to the new Peering Box via a hot swap from our datacenter supplier. After we got everything plugged into the new equipment, we then began putting production back in slowly. We needed to do this in conjunction with our security team, in order to check that this new border protection system was working properly and not dropping legitimate traffic.

On the last day of migration, another technology had been put in place by our transmission team. The goal here was to add capacity between the Singapore datacenter and the PoP where we installed these new devices. After we isolated the traffic between both ends, we migrated the dark fiber to the new DWDM optical system (Galaxy) in order to add 400Gbps of capacity to the datacenter. As it was new, we had some trouble explaining how to fix some cabling issues in the system. After it was all fixed and ready, one by one, we put 4x100Gbps links in production.

After completing all these different steps we analysed and fixed some issues in order to make the second PoP faster with the same schedule.

Once both PoPs were in production we monitored how it was handling the traffic and the DDoS attacks. We also contacted our close customers to ensure that there were no issues.

In conclusion

This new infrastructure, SMAUG, brings significant improvements in power and space efficiencies as well as reducing complexity in the overall network design. It will also help OVHcloud to keep up with increasing applications and service demands.

Looking ahead, we believe the flexibility of SMAUG design will help OVHcloud to leverage faster network capacity and be ready for future technologies.

Thanks to the teams and industry partners that helped make this new infrastructure possible.

En tant que promoteur et hébergeur de solutions en SaaS, OVH est bien placé pour savoir combien la connexion à Internet est devenue vitale pour les entreprises. Externaliser l’hébergement de ses outils de travail dans le cloud a des avantages évidents : sécurité accrue, travail collaboratif facilité, économies substantielles… En contrepartie, toute coupure de connexion provoque le chômage technique immédiat d’une partie plus ou moins importante des salariés. En outre, les entreprises ne sont pas toutes égales en matière d’accès au haut débit. Trop nombreuses sont celles dont l’activité est, aujourd’hui encore, bridée par une faible vitesse de connexion au réseau mondial. « Lorsque nous avons étudié les solutions disponibles sur le marché pour agréger plusieurs liens, nous avons été surpris par leur coût élevé, qu’il s’agisse de l’acquisition du boîtier ou de l’abonnement au service. » À l’inégalité territoriale s’ajoutait donc une inégalité entre petites et grandes entreprises. Majoritairement américains, les services d’agrégation existants avaient également en commun d’être particulièrement opaques sur leur fonctionnement. « Cela peut être inquiétant pour une entreprise d’installer un tel équipement, ouvrant la porte de son réseau interne et interceptant son trafic. » Il y avait donc une place à prendre. Restait à développer la technologie, en quelques mois.

Privilégier une solution hardware ou software pour agréger ?

Lorsque l’équipe a commencé à réfléchir à la problématique de l’agrégation de liens, elle s’est logiquement appuyée sur l’expérience et les équipements déployés par OVH sous sa casquette de FAI (une activité initiée en 2011, et circonscrite à la France). Les premières tentatives consistèrent à faire du bonding MLPPP (Multi Link Point to Point Protocol) : « Nous pouvions agréger deux lignes provenant de DSLAM différents, mais reliées à un même LNS appartenant à OVH (L2TP Network server, le routeur qui termine la liaison entre l’utilisateur et le FAI, NDR). Malheureusement, lors des tests, la connexion s’est révélée très instable, et l’offre n’aurait concerné que les lignes xDSL dégroupées par OVH ou gérées en collecte. »

Menée en parallèle, la seconde tentative a nécessité l’accord de l’ARCEP. Il s’agissait d’expérimenter le bonding VDSL, c’est-à-dire la fusion, au sein d’un même DSLAM, de plusieurs lignes, comme cela se pratique pour le SDSL (jusqu’à 4 paires). « Le bonding ADSL est possible, mais peu performant. Avec les équipements disponibles sur le marché, nous pouvions agréger jusqu’à deux lignes VDSL. Néanmoins, même en laboratoire, dans des conditions optimales, nous ne parvenions pas à bénéficier d’une connexion stable. Qui plus est, la cible des clients éligibles était encore plus restreinte qu’avec le bonding MLPPP, puisque seuls les abonnés en dégroupage total chez OVH et situés à proximité d’un DSLAM auraient pu bénéficier de ce service. Or, l’ambition était de proposer une solution qui fonctionne partout, y compris à l’international, là où OVH n’est pas FAI. Par ailleurs, il nous semblait essentiel de parvenir à agréger des accès opérés par des opérateurs différents, et utilisant des technologies variées, ceci pour sécuriser l’accès à Internet des utilisateurs. Nous sommes donc repartis de zéro. »

MPTCP : agréger pour mieux régner

L’équipe s’est mise en quête d’une solution software pour faire de l’agrégation. Soit un service Over The Top, qui s’abstrait des FAI et des technologies sous-jacentes. « Il n’est plus question ici de fusionner physiquement des liens Ethernet, comme dans le cas du bonding. L’agrégation software consiste à dispatcher les paquets entre les différents liens, en tenant compte de leur capacité, avant de les réordonner au sein d’une infrastructure hébergée par OVH. »

Plusieurs logiciels furent testés, avec des résultats mitigés : « Le principal problème rencontré ? L’agrégation était réalisée “par le bas”, c’est-à-dire que la bande passante agrégée était égale à x fois la capacité de la moins puissante des connexions. Ceci en raison de l’algorithme de répartition des paquets entre les liens disponibles (round-robin). Par ailleurs, les applications testées se révélaient gourmandes en CPU/RAM. » Puis l’équipe a découvert Multipath TCP (MPTCP), une extension du protocole TCP disponible sous forme de patch du kernel Linux, sur laquelle travaille l’Université Catholique de Louvain, en Belgique. « En plus de permettre d’agréger jusqu’à huit connexions (1) de latences différentes, MPTCP permet de maintenir une session sur plusieurs liens (fail-over actif). Autrement dit, un téléchargement peut se poursuivre malgré la perte d’un lien, sans repartir de zéro. Et une fois le lien à nouveau opérationnel, la bande passante disponible pour le téléchargement augmente à nouveau. Une véritable prouesse technique ! » Avec MPTCP, la connexion peut atteindre une vitesse proche de la somme des débits de l’ensemble des interfaces réseau disponibles. Les applications n’ouvrent qu’une connexion TCP, mais celle-ci est en fait démultipliée (multipléxée), distribuée sur tous les liens puis démultiplexée. « Un mécanisme complexe, mais totalement transparent pour les applications comme pour l’utilisateur. »

Pas étonnant qu’Apple ait débauché le principal développeur de MPTCP, alors qu’il était encore étudiant et achevait sa thèse au sujet de ce protocole. Implémenté sur iOS (le système d’exploitation mobile des iPhone et iPad), MPTCP est utilisé par l’application de reconnaissance vocale Siri pour maintenir la connexion avec les serveurs de la firme de Cupertino dans le cas où vous sortez, par exemple, de la zone de couverture de votre réseau WiFi, en basculant sur la connexion 3/4G. Une autre exploitation intéressante de MPTCP est le projet Gigapath lancé pendant l’été 2015 par l’opérateur Korean Telecom, qui vise à agréger les connexions 4G et Wi-Fi sur un mobile pour atteindre une bande passante dépassant les… 800 Mbps – Il faut savoir que la Corée a le réseau cellulaire le plus rapide au monde. (2)

OverTheBox : une application open source

Convaincue qu’en maîtrisant le hardware du futur boîtier l’équipe bénéficierait d’une plus grande réactivité dans la correction des bugs, elle s’est rapprochée de différents équipementiers dans le but de designer une OverTheBox sur mesure. « Une fausse bonne idée, car nous ne pouvions pas nous engager sur des volumes comparables à ceux des principaux opérateurs. Résultat : le coût unitaire d’un boîtier aurait été en contradiction avec notre cahier des charges, qui visait à développer une solution très accessible. »

MPTCP étant implémenté au sein du kernel, ce protocole s’avère très peu consommateur de CPU/RAM. Il était donc envisageable de s’orienter vers un matériel standard pour constituer la OverTheBox. Un mini-PC de type NUC d’Intel a été retenu par l’équipe, en raison de ses caractéristiques techniques : processeur Atom(TM) à faible consommation d’énergie, qui ne requiert pas la présence d’un ventilateur, source de bruit et de pannes ; présence d’interface réseau gigabits et d’un port USB 3.0 capable de recevoir une clé 3 ou 4G sans en brider le débit, chiffrement AES matériel, c’est-à-dire réalisé directement par un jeu d’instructions intégré au processeur, et conformité aux normes européennes. Le tout pour un coût raisonnable. Seul problème, a priori, de ce boîtier : la présence d’un seul et unique port Ethernet. « Jusque-là, il semblait assez évident qu’OverTheBox devait collecter physiquement l’ensemble des liens à agréger, et donc disposer d’au moins 4 quatre ports Ethernet. Mais l’un d’entre nous a eu une “révélation” : et si au lieu d’ajouter un nouveau switch, on essayait de réutiliser ceux dont sont d’ores et déjà dotés les box à agréger (des modems-routeurs) ? En connectant les modems en série (daisy chain), on peut réutiliser les services de chacune des box – le WiFi par exemple, dont le NUC est dépourvu. Et on gagne sur tous les plans : OverTheBox consomme moins d’électricité que si elle avait comporté un switch et une puce WiFi, et l’installation est simplifiée, puisqu’il n’est pas nécessaire de toucher à son réseau local (on peut conserver le même plan d’adressage au sein de son LAN).

La conception suivante a été donc retenue : conserver les box en tant que routeurs, tout en partageant le même réseau local. Autrement dit : rassembler les WAN sur un même LAN, dont OverTheBox viendra prendre le contrôle en tant qu’unique serveur DHCP. En pratique, on branche OverTheBox sur la première des box, puis on désactive le service DHCP de cette box après qu’OverTheBox a découvert le réseau. Les box supplémentaires sont ajoutées suivant le même protocole. « Nous souhaitions proposer le système le plus simple possible, « zero pain ». Le résultat est proche de l’auto-configuration. D’ailleurs, on peut aussi tout brancher simultanément. OverTheBox se débrouillera toute seule et vous indiquera les serveurs DHCP à désactiver. Cela fonctionne à condition que deux modems n’aient pas la même IP au sein du LAN. Par précaution, nous préconisons que chaque box soit sur un sous-réseau différent. »

OpenWrt, une distribution légère basée sur un noyau Linux, historiquement développée pour remplacer le firmware des routeurs WRT54G fabriqués par Linksys, a été sélectionné pour fournir le programme de base d’OverTheBox. « Nous avons choisi ce système d’exploitation libre pour bénéficier d’un moteur robuste et éprouvé, supporté par une large communauté, dont le code a déjà été audité. Il aurait été idiot de repartir de zéro, et inutile d’installer sur les boîtiers une distribution lourde telle que Debian. Nous avons donc adapté OpenWrt à nos besoins. Nous avons ensuite souhaité rendre notre travail open source, pour donner la possibilité aux utilisateurs de comprendre comment le service fonctionne, et de contribuer à l’améliorer. » On retrouve ainsi sur Github la version d’OpenWrt modifiée pour OverTheBox . « Nous étudions avec un grand intérêt les pull-requests que nous recevons par l’intermédiaire de Github. Nous y voyons une possibilité d’enrichir rapidement les fonctionnalités d’OverTheBox, grâce à l’apport de la communauté d’utilisateurs. Par ailleurs, le fait que le projet soit open source permet à quiconque d’installer l’image logicielle sur un équipement qu’il possède déjà, ou un matériel mieux adapté à ses besoins. » (3)

Les principales modifications apportées à OpenWrt ont consisté à développer un daemon qui permet d’assurer la communication entre OverTheBox et les infrastructures d’OVH, dès sa première connexion à Internet. Ceci permet au boîtier d’être configuré à distance et mis à jour automatiquement. « Faire en sorte qu’un utilisateur se connecte sur http://overthebox.ovh et soit redirigé vers l’adresse IP privée locale de son OverTheBox, pour accéder à l’interface de configuration sans avoir à chercher par lui-même à quelle adresse l’équipement est joignable, voilà une fonctionnalité triviale qui nous a donné du fil à retordre ! Pour cela, nous avons choisi de conserver la première IP privée depuis laquelle elle se connecte à notre infrastructure, pour permettre la redirection ultérieure. »

La release channel a fait, elle aussi, l’objet d’un soin tout particulier : « Etant donné qu’OverTheBox prend le contrôle de l’accès à Internet de ses utilisateurs, il faut considérer cet équipement comme critique. Aussi, nous avons répartis les boîtiers suivant trois catégories : unstable, testing et stable. La première catégorie est réservée à l’équipe de développement, qui reçoit les mises à jour susceptibles de faire planter OverTheBox. La seconde catégorie est accessible aux utilisateurs volontaires pour tester les nouvelles fonctionnalités en avant-première, en contrepartie de quoi ils encourent le risque de subir quelques bugs. Enfin, la catégorie stable permet de diffuser à l’ensemble du parc les mises à jour en principe exemptes de bugs. »

Tunnellisation et proxy

Si vous avez suivi jusque-là, nous avons donc du côté de l’utilisateur un LAN, sur lequel sont branchés plusieurs WAN. En tant que seul serveur DHCP actif, OverTheBox est maître de ce LAN. Aussi, lorsqu’une connexion est établie entre un membre du LAN et Internet, elle transite via OverTheBox, qui dispatche — grâce au protocole MPTCP — les paquets entre les différents liens fonctionnels disponibles. Autrement, dit, lorsqu’un ordinateur du réseau envoie des éléments à un serveur distant, les paquets transitent sur Internet en partie par le lien du FAI 1, en partie par le lien du FAI 2, en partie par le lien du FAI 3, etc. Ce fonctionnement a un effet collatéral bénéfique sur la sécurité : « Par défaut, les échanges transitant par OverTheBox sont chiffrés selon la méthode AES 256, ce qui constitue une première protection. Le fait que les paquets d’une même connexion empruntent différents chemins constitue, quant à lui, une parade efficace à toute tentative d’interception des données. Seule une partie, aléatoire et donc inexploitable, des échanges pourrait être captée par un dispositif installé sur l’un des chemins. »

Les paquets étant dispatchés entre plusieurs liens et acheminés via différents FAI, il est nécessaire, en bout de chaîne, de les réagréger (packet reordering) pour que l’équipement de l’utilisateur et le serveur distant réceptionnent l’intégralité des messages. C’est précisément la tâche qui est réalisée au sein des infrastructures d’OVH dans le sens « utilisateur vers Internet », tandis qu’OverTheBox s’en charge dans l’autre sens : Internet vers l’utilisateur. Grâce à la partie du dispositif hébergée par OVH, l’utilisateur bénéficie d’une adresse IP publique unique, géolocalisée* et de confiance (IP de FAI) pour sortir sur Internet (4). Ce dispositif permet également aux utilisateurs d’OverTheBox de bénéficier de la protection anti-DDoS développée par OVH, le trafic illégitime étant mitigé par le VAC (5) le cas échéant.

Lorsque ce système a été testé pour la première fois par l’équipe, en laboratoire puis au domicile de plusieurs personnes, il a semblé tout à fait fonctionnel. « OverTheBox permettait de bénéficier de débits montants et descendants cumulés jusqu’à 95 % de la somme des débits offerts par les différentes connexions. Un excellent ratio ! Mais, lorsque nous avons étendu les tests à d’autres collaborateurs, des problèmes sont apparus : l’un d’entre eux rassemblait, grâce à OverTheBox, trois connexions ADSL de 5 Mbps chacune environ, et constatait un débit extrêmement instable, oscillant. Nous nous sommes aperçus que le débit baissait fortement lorsque la bande passante était saturée – une situation que nous n’avions pas provoquée avec un usage classique lors des tests en laboratoire agrégeant des connexions à très haut débit. Nos investigations ont mis à jour qu’en faisant passer une session TCP (gérée par MPTCP) à l’intérieur d’un tunnel TCP (Internet), le mécanisme natif de contrôle de congestion du protocole TCP des deux sessions simultanées dysfonctionne. » En cas de congestion, le mécanisme de la première session télescope celui de la seconde session au sein de laquelle il est encapsulé. Incapables de coopérer, les mécanismes se rendent aveugles l’un l’autre et dégradent la qualité. Un vrai problème, étant donné l’importance du protocole TCP dans les échanges sur Internet (http, mails, etc.).

Il a donc fallu réfléchir à une alternative, en l’occurrence le recours à un proxy : « Au lieu d’encapsuler une session TCP dans une autre (TCP over TCP), nous modifions la session originale grâce à un proxy socks (shadowsocks). » En revanche, l’encapsulation fonctionnant parfaitement pour les autres protocoles tels qu’UDP (utilisé pour la téléphonie sur IP, les visioconférences, les serveurs de jeu, etc.) ou ICMP, celle-ci a été maintenue pour les paquets non TCP. Ce faisant, il était difficile de réfléchir à la QoS comme on le fait d’ordinaire : « Nous avons été pragmatiques : que recouvre bien souvent la demande de QoS chez les utilisateurs ? Dans 99 % des cas, il s’agit de pouvoir prioriser le trafic lié à la téléphonie, de sorte à ne pas dégrader la qualité des appels VoIP en cas de surcharge sur le réseau. Aussi, nous avons donné une priorité absolue aux paquets UDP… avec un résultat qui est encore à améliorer, car il est nécessaire pour certains utilisateurs disposant d’une faible bande passante et/ou générant un gros volume de communications téléphoniques, de faire une distinction parmi les paquets UDP pour ne prioriser que ceux qui sont réellement liés à la VoIP. Nous y travaillons actuellement. Pour ce qui est de la TV par Internet, le problème n’est pas tant la QoS, mais plutôt le fait de pouvoir forcer les connexions à transiter par le réseau de l’opérateur qui fournit la boxTV. Cela concerne les utilisateurs professionnels dont le bureau est situé au sein de leur domicile, et ils ont maintenant la possibilité de spécifier à OverTheBox que les connexions d’un équipement du réseau en particulier doivent passer par l’un des liens uniquement. »

L’infrastructure cloud du service OverTheBox, ou la mise en pratique de la politique « Eat your own food »

L’infrastructure, côté OVH, est répartie sur deux sites pour en assurer la haute disponibilité. « Aujourd’hui, il s’agit des datacentres de Gravelines et Strasbourg, mais notre service comptera certainement parmi les premiers clients des nouveaux centres de données qu’OVH projette de déployer à travers le monde en 2016 et dans les années à venir. Le service OverTheBox est sensible à la latence, il nous faudra donc rapprocher au maximum les infrastructures des utilisateurs. Ou, pourquoi pas, laisser le choix aux utilisateurs du pays depuis lequel ils souhaitent sortir sur Internet. »
Pour chaque utilisateur d’OverTheBox, un container Docker est lancé sur une instance Public Cloud. Au sein de ce container, on retrouve les services nécessaires à la réception et à la réagrégation des paquets (les mêmes que ceux qui tournent dans OverTheBox, à l’autre bout du « tunnel »).

« Le choix de Docker s’est imposé pour sa simplicité de mise en œuvre, et la vitesse avec laquelle on peut redémarrer un container sur le site secondaire en cas de problème sur la machine qui l’héberge. » Chaque container dispose de sa propre adresse IP, qui est basculée sur une machine du site secondaire le cas échéant, grâce à l’API OVH. « Nous nous sommes mis dans la peau d’un client d’OVH, et nous utilisons nos infrastructures comme il pourrait le faire. Cela nous permet de faire progresser les services, en apportant un feedback à nos collègues en charge de Public Cloud par exemple. »

Plus de 50 versions du soft entre la présentation d’OverTheBox au Summit et sa commercialisation

Depuis le lancement du projet, l’équipe avait une échéance en tête : le 24 septembre 2015, date du troisième Summit d’OVH aux Docks de Paris. L’objectif était de profiter de cet événement pour lancer en avant-première le service, et recruter des bêta-testeurs pour la phase de test ouverte au public. Avec pas loin de 300 OverTheBox distribuées le jour J, et presque autant de bêta-testeurs actifs, remontant leur feedback régulièrement, l’opération fut un succès. Et a permis de faire progresser le service d’une manière très rapide : « Entre le Summit et la commercialisation d’OverTheBox, trois mois se sont écoulés. Nous avons corrigé des bugs, amélioré l’interface et constaté avec surprise qu’OverTheBox se prêtait à des usages auxquels nous n’avions pas pensé : par exemple agréger une connexion partagée par un smartphone. »

Le service tel qu’il est commercialisé aujourd’hui va encore beaucoup évoluer. « Nous avons livré les briques essentielles, et nous avons bien entendu des éléments dans la roadmap tels que la compatibilité avec l’IP v6, la surveillance des backdoors internes chez le client, la possibilité d’accéder à un vRack depuis OverTheBox ou de réaliser ses backups sur hubiC, aux moments où le réseau est le moins utilisé… Une autre partie de la roadmap est encore vierge aujourd’hui, et se remplira des fonctionnalités proposées par les utilisateurs, suggérées par les partenaires et revendeurs. » Enfin, l’équipe espère aussi que les fabricants de modems-routeurs s’empareront du service et l’installeront sur leur matériel pour le faire découvrir à leurs clients.

Notes :
(1) Le protocole MPTCP supporte théoriquement l’agrégation jusqu’à 8 liens (tests en laboratoire), mais OverTheBox ne garantit aujourd’hui la stabilité de la connexion sur l’agrégation de 4 liens maximum.

(2) Commercial usage of Multipath TCP , publié sur http://blog.multipath-tcp.org

(3) Les pré-requis recommandés sont : 1 Go de RAM + le chiffrement AES hardware.

(4) Aujourd’hui, seules des IP FR sont disponibles, mais la géolocalisation des IP au sein d’autres pays européens est prévue dans la roadmap.

(5) En savoir plus sur la protection anti-DDoS mise en place par OVH