QUIC, la fin de TCP pour 2019, enfin… plutôt 2021 ! Partie 2/3 : Quand ?

Cet article est le second dans une série de 3 : QUIC, la fin de TCP pour 2019 !

Partie 1/3 : Pourquoi et Comment ?

Partie 2/3 : Quand ?

Partie 3/3 : Et après ?

Comme annoncé précédemment dans la Partie 1/3 : “Pourquoi et Comment ?”, QUIC va prendre la relève de TCP, inévitablement. La question suivante est donc logiquement le “Quand ?”

---

QUIC pour Quand ?

Update 28 mai 2021 : Voilà c’est enfin fait ! l’IETF a sorti ses RFC après près de 2 ans de retard ! RFC 8999, 9000 (QUIC transport), 9001 et 9002. C’est historique : le RFC 793 pour TCP de septembre 1981 est détrôné !
Le prédictions ci-dessous sont donc elles-mêmes à décaler de 2 ans.

Je vais me permettre ici une petite prise de risque avec quelques prédictions chiffrées. En effet, tout cela me semble si évident et imminent que je suis très étonné que pratiquement personne n’en parle, ni ne l’annonce à grand renfort de tambours et trompettes virtuelles ! C’est peut-être le signe de mon erreur mais tant pis, risquons-nous.

Voici mon pronostic :

• QUIC va entrer en déploiement massif à la sortie de l’été 2019 2021, autant dire demain !
• Le déploiement sera tellement massif que je prédis 30 à 40% du trafic Web en QUIC c’est à dire en UDP dés fin septembre 2019 2021
• A la fin 2019, j’estime que 50 à 75% du Web aura basculé (il y a une incertitude ici en fonction d’un effet de référencement Google)
• Enfin, je prédis la fin de TCP, c’est à dire un trafic résiduel de 10 à 15% au bout d’un an soit mi-20202022, autrement dit l’inversion des proportions TCP/UDP d’aujourd’hui sur Internet.

Cette prédiction mérite d’être étayée. Voici mon analyse.

L’enjeu autour de QUIC est tel que l’IETF a décidé en 2018 de geler tous les travaux sur les évolutions de TCP pour consacrer le travail de normalisation entièrement à QUIC.

L’IETF entre donc dans la phase finale de son processus de normalisation (publication des RFC) pour QUIC. QUIC en est à sa 44ème version du protocole et le groupe IETF finalise ses tests d’interopérabilité des fonctionnalités standardisées entre différentes implémentations. J’ai compté 21 implémentations des drafts IETF, dont 14 en test d’interop, voir ci-dessous.

Matrice d’interopérabilité des implémentations de QUIC en Mars 2019

Par ailleurs, le RFC le plus important pour la généralisation est la normalisation de HTTP/2, la norme actuelle du Web, dans le transport QUIC. Le document (draft IETF) aurait du être finalisé en novembre 2018. Malgré un report, une étape clé a eu lieu : la future norme HTTP-over-QUIC en question a été actée comme norme HTTP/3 ! C’est donc écrit depuis 6 mois : le futur du Web est en QUIC.
HTTP-over-QUIC est donc encore un draft en version 20 et s’intitule déjà HTTP/3. La sortie est annoncée pour Juillet 2019 dans le programme de l’IETF 105 à Montréal :

Calendrier prévisionnel du groupe de travail QUIC à l’IETF
Source : https://datatracker.ietf.org/wg/quic/about/

Si ce calendrier tient, alors la rentrée sera intense.

Voici un scénario :

1. Google est impatient de « tourner le bouton » à nouveau depuis son test de 2016. A l’époque, cela a déjà fait 7% du trafic à lui seul en QUIC. Et comme Youtube représente aujourd’hui 11% du Web d’après des statistiques récentes, gageons que Google pèserait instantanément au moins 10% du Web en QUIC en quelques jours.
2. NetFlix est le 1er flux du web à 15% (en 2019, pré-confinements !). Il a aussi l’avantage de maitriser un grand nombre d’applications clientes sur les Set Top Box opérateurs et les mobiles. Donc, s’il voit Youtube prendre un avantage compétitif (Google annonce réduire de 15 à 18% le temps de buffering Youtube en QUIC), il ne mettra pas longtemps à basculer. Misons sur encore 10% du Web.
3. Akamai est le CDN dominant du Web et également l’un des acteurs les plus actifs sur les expérimentations de QUIC et ce depuis 2016 également. Leur réseau supporte déjà QUIC avec Chrome. J’ai trouvé quelques statistiques de trafic d’Akamai dans l’Internet à 10-15% mi-2017. Il n’y a aucun doute sur le fait qu’il pèse déjà dans le flux QUIC existant sur l’Internet et que cela ne pourra que grandir.
4. Microsoft, avec Hotmail + Office365 côté serveur et Internet Explorer + Windows côté client, ne risque pas de rester à la traine. Nous observons déjà chez nos clients de l’UDP/443 vers les subnets de Microsoft… Assurément Microsoft est prêt pour QUIC.
5. Certains acteurs (ci-dessus ou autres), sont très impatients. En effet les statistiques de l’Internet montrent déjà la croissance de QUIC depuis 2017 avec un fond à 5-10% et quelques pics à 30% ! Le nombre d’IPv4 compatibles QUIC a également bondi en Mars 2018. Tout cela me fait pencher pour 30% au moins de l’Internet en QUIC dés septembre.
6. Enfin, je fais un petit pari qui changerait aussi la donne. Google favorisant les pages les plus rapides dans son ranking, cela avait déjà accru le passage à HTTP/2. Comme QUIC donnera encore de meilleurs « Page Load time », je parie donc que cela va indirectement favoriser le classement des sites marchands ou médias supportant QUIC et donc accélérer la migration… pourquoi pas justement avant Noël où l’enjeu économique est colossal. 50% voir 75% de QUIC à la fin de 2019 2021, c’est envisageable.

Tout cela cumulé me pousse à penser que si le groupe QUIC à l’IETF tient son calendrier, alors le mien pourrait bien avoir du sens aussi.

Voici quelques statistiques qui éclairent les volumétries et la rapidité des évolutions possibles :

Top trafic Internet par types, notamment vidéo, en octobre 2018
Source : Sandvine

Etude du mix protocolaire de l’Internet d’un opérateur en Europe en % depuis début 2017.
Source : A First Look at QUIC in the Wild – Jan Rüth1, Ingmar Poese2, Christoph Dietzel3, and Oliver Hohlfeld1 at arxiv.org

Nombre de serveur (IPv4) compatibles QUIC
Source : https://quic.netray.io/stats.html

Comme toutes les prédictions, la mienne est forcément fausse. Elle sert à marquer les esprits. Néanmoins, ce serait un sophisme de balayer l’ensemble de la tendance d’un simple revers de main.

Voici pourquoi je pourrais (je vais) me tromper sur le calendrier :

• Evidemment, si l’IETF ne parvient pas à livrer les documents RFC clés en juillet, l’ensemble va glisser de 5 mois au moins.
• Le ranking et SEO Google : si QUIC n’a pas à nouveau un effet de vitesse significatif sur les pages web marchandes comme avec HTTP/2, donc sur leur ranking Google, alors le e-Commerce et les médias n’ont pas de raison de se presser. C’est le point clé de la bascule du Web vers QUIC tant Google a le pouvoir de vie ou mort sur les sites Web. C’est là-dessus que mon calendrier rapide joue le plus gros.
• Blocage de QUIC : si pour des questions de sécurité, de monitoring, de qualité de service,… des opérateurs se mettent à bloquer QUIC (il suffit d’interdire UDP/443) alors tout restera en TCP et cela freinera QUIC. Dans les réseaux privés d’entreprise, c’est une certitude et le calendrier proposé ne s’applique pas. D’ailleurs, aujourd’hui, la recommandation de PaloAlto, editeur de Firewall avancé, est tout simplement de bloquer QUIC ! Mais pour combien de temps puisqu’on parle là du futur standard HTTP/3 pour dans 3 mois. Néanmoins, sur l’Internet public, il y a 3-5% d’interdiction seulement, et cette évolution reste inconnue.
• Performance de QUIC : la délégation du chiffrement/déchiffrement TLS par des composants hardware spécialisés est aujourd’hui courante avec TLS sur TCP. Si cette capacité de délégation bute sur l’adaptation purement logicielle à TLS sur QUIC avec le hardware existant, cela pourrait sérieusement limiter les performances de QUIC par un traitement en CPU et nécessiter des évolutions de firmware ou hardware des terminaux plus profondes et plus lentes. Cela retarderait la généralisation massive que j’annonce rapide.
• Enfin, un certain nombre d’autres détails sont soulevés par un spécialiste (Robin Marx) qui se fait « l’avocat du diable » contre QUIC (de son propre aveu). Certaines subtilités sont intéressantes en effet mais je le soupçonne de ne pas y croire lui-même. A lire pour un avis d’expert plus équilibré que le mien.

Quoi qu’il soit, le résultat est clair : il va falloir se tenir prêt !

---

Et pour bien mesurer les enjeux et conséquences de cette migration, je vous propose une 3ème partie :

QUIC, la fin de TCP pour 2019 ! Partie 3/3 : Et après ?