OK j'essaie de te qualifier ça.

J'ai UN test à faire avant : Installer la box nordnet (sagemcom) pour voir si ça change quelque chose. (En ce moment je suis en direct derrière le modem sat).

Mais OK je ferais un rapport sur un sujet dédié.

Pour la partie TCP ACK, je te confirme que la réponse se fait au niveau du modem , à cause du timing . J'ai pas pris la capture , mais on voit que le 1er SYNC-ACK arrive en quelques millisecondes , impossible en sat. Le sentiment que j'ai c'est que ça impacte certaines applications, ptet mal codée je l'admets.

J'essaie de faire ça rapidement.

Les connections TCP sont quasi-systématiquement coupées en 3 sur les accès satellite GP GEO : appli client<>modem<>teleport<>dest.
Selon les fabriquant d'équipement ils appellent ça PEP (performance enhancement proxy) ou TCP Acceleration. Certaines solutions gardent les numéros de ports intacts et le range de numéro de séquence pour être plus "discrète".

Xiplink est un fournisseur assez connu de ce genre de *********. Il me semble que Viasat fait son propre truc. Il y avait un acteur français a un moment (UDcast) mais le rachat successif par OneAccess puis Ekinops a probablement tué leur produit (le site existe toujours http://www.udcast.com/ mais on dirait que c'est juste pour le support). Newtec si tu checkes ce flyer pour un hub complet ça mentionne direct un PEP. Il y a un truc open source assez vieux aussi. Pour info ça se fait aussi sur certain réseau de téléphonie mobile mais de ce que j'en sais avec des produits un chouilla moins merdique. La comme ça j'ai le MSP -multi service proxy- d'Ericsson en tête, openwave mobility fait aussi de la patouille dégueu avec les connexions TCP, et certains opérateur (Verizon...) font des publications sur le sujet.

Même les produits les plus discrets recopient pas tout le header TCP, la ou j'ai réussi à mettre en évidence des trucs pas clair lorsque les ports semblaient intact c'est en ajoutant une option TCP alacon (Et j'ai appris que certains produits utilisent aussi des options TCP non standard pour la nego entre le coté modem et le coté téléport). Tu peux aussi regarder avec certaines solutions coté émetteur tu vas recevoir des zero window si t'envoie un beaucoup de trafic, et si t'a la main de l'autre coté magie aucun paquet zero window n'aura été émis...

Il y a une vieille RFC qui contextualise bien ça. L'ETSI a pas mal de ressources sur le sujet y compris des des exemples de produits qui embarquent ce genre de techno (Hughes Annex D/p31 ici).

Dés fois je suis content que tout l'internet soit passé en https, cela limite sensiblement le terrain de jeux de ces boites qui aiment bien triturer les paquets.

Pareil. Fort heureusement ces solutions que j'adorent sont rarement compatibles IPv6 et pourront rien faire avec du QUIC.

Après coté satellite (enfin GEO) ils ont pas les moyens. Mais coté réseau mobile, j'ai vu du très très moche qui marche très bien en HTTPS, et même QUIC en fait, avec du matching+scoring de flow pour savoir si c'est du youtube ou autre service de video (en fonction des IP src/dst, du débit moyen, de la presence de burst de buffering, de la réaction à un packet drop volontaire pour QUIC, de la reaction a un paquet vide/un paquet avec du garbage, de la corrélation avec des requêtes DNS si lisible, et plein d'autres trucs pas con du tout), et dans l'esprit de TCP-RNA (radio network aware) ça te shape le flow a un débit SD sans aucune autre forme de procès... Et le pire dans l'histoire c'est que c'est même pas si compliqué que ça à faire avec du DPDK/VPP & co et des dev un minimum compétents.

Certains opérateurs pense bien faire, mais pas tous. Après les vendeurs de DPI ne se cachent pas de dire qu'ils te libèrent de la capa sur ton RAN en tapant sur la vidéo, suffit de regarder les produits d'ENEA (combinés avec ceux d'openwave depuis le rachat) qui est quasiment dans ce qui se fait de mieux dans le pire https://www.enea.com/products-services/traffic-management.

La plupart des acteurs qui faisaient du DPI ne bloquaient pas du tout les usages vidéos ni ne réduisent le débit sur la vidéo.

Le DPI servaient pour bloquer du contenu nuisible (ex:phishing), du contenu adulte ou identifier du trafic à ne pas compter dans le fair use.

Pour certains, c'est uniquement pour remonter des statistiques.

Je rappelle que le DPI est interdit pour un accès à internet public même si c'est du WiFi gratuit (mais le message n'est pas encore compris partout)

Après c'est pas forcément clair dans ce que je raconte, mais au final je connais assez mal les opérateurs français étant donné que j'ai longtemps travaillé dans les réseaux mobiles mais très peu sur la zone EMEA, et si c'est vrai qu'on semble relativement épargné en France et globalement en Europe de l'ouest, dans d'autres régions du monde les opérateurs n'ont pas beaucoup de limite dans le traffic management intrusif. Après il faut reconnaitre que le problème de scheduling radio dans son ensemble (c'est vrai en accès satellite, encore plus récemment avec le beam hopping en GEO et les constellations) est loin d'être trivial et que finalement taper sur le trafic en dehors du RAN c'est extrêmement facile et surtout pour un opérateur qui n'a pas ou peu de compétence radio c'est beaucoup plus facile de faire cela que de déployer du scheduling avec coordination multi-cell/multi-band/multi-ran et moins cher aussi à court terme.