Auteur Sujet: DSCP : de la conservation d'un unique DSCP sur la vie d'un flux (Lu 986 fois)

levieuxatorange · « **le:** 02 octobre 2025 à 15:31:39 »

Dans le Thread https://lafibre.info/orange-debit/5g-home-debit-limite-a-5-mbs-avec-les-flux-dscp-0x08/
Il y a toute une partie des échanges concernant la conservation dans la durée (du premier Pkts au derniers Pkts) d'un marquage DSCP unique pour un même flux.

Ce thread pour échanger sur ce sujet

levieuxatorange · « **Réponse #1 le:** 02 octobre 2025 à 15:31:48 »

Note documentaire en vrac

RFC

Concernant la TOS (l' ancêtre de DSCP)
TOS modifiable pendant une session TCP : https://datatracker.ietf.org/doc/html/rfc1349#page-7
TOS par appli : https://datatracker.ietf.org/doc/html/rfc1060#page-21

DSCP :
Exploring DSCP modification pathologies in mobile edge networks https://tma.ifip.org/wp-content/uploads/sites/7/2017/06/mnm2017_paper13.pdf

3 RFC importantes:

https://datatracker.ietf.org/doc/html/rfc2474
https://datatracker.ietf.org/doc/html/rfc3260
et surtout: https://datatracker.ietf.org/doc/html/rfc2597 (qui définit AF41 dans le cas qui nous intéresse)
A noter qu' AF41 n'est pas "reservé" a la voix/visio. Historiquement c'est pour des trucs dont on veut garantir l' acheminement et rapidement.

L'application au WebRTC https://www.rfc-editor.org/rfc/rfc8837.html

QUIC semble conseiller d'avoir un unique DSCP par CNX https://datatracker.ietf.org/doc/html/rfc9308#name-quality-of-service-qos-and-

Deconseille de changer le DSCP sur une CNX TCP / UDP https://www.rfc-editor.org/rfc/rfc7657#section-5.1

Un exemple d'usage ou le DSCP est modifié "on the fly"
https://www.reddit.com/r/networking/comments/x9jtjl/same_tcp_session_different_dscp_markings/

FIREWALL :

Exemple de Fortigate qui peut matcher sur un DSCP https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/813032/dscp-matching-and-dscp-marking

PATTENT

CISCO sur la modification du DSCP dans un flux pour l'indiquer en avance dans le flux https://patents.google.com/patent/US20080089324A1/en

levieuxatorange · « **Réponse #2 le:** 02 octobre 2025 à 15:31:55 »

reserve

kgersen · « **Réponse #3 le:** 02 octobre 2025 à 16:41:23 »

Des choses intéressantes dans ces liens. il faut lire les maj qu'il y a eu depuis aussi.

3 RFC importantes:

https://datatracker.ietf.org/doc/html/rfc2474
https://datatracker.ietf.org/doc/html/rfc3260
et surtout: https://datatracker.ietf.org/doc/html/rfc2597 (qui définit AF41 dans le cas qui nous intéresse)

A noter qu' AF41 n'est pas "reservé" a la voix/visio. Historiquement c'est pour des trucs dont on veut garantir l' acheminement et rapidement.

vivien · « **Réponse #4 le:** 02 octobre 2025 à 16:44:55 »

Je montre le résultat d'un simple transfert descendant avec OpenSSH via scp user@pc:/home/user/100M.iso /tmp/ : On voit une évolution du DSCP des paquets émis au cours de la connexion.

En réalisant ce type de connexion depuis le réseau mobile (PC derrière un partage de connexion d'un mobile Orange ou box 5G Orange) vers un PC (avec le serveur OpenSSH) connecté à une Livebox FTTH Orange (avec la Livebox), on est limité à 5 Mbit/s.

levieuxatorange · « **Réponse #5 le:** 03 octobre 2025 à 08:50:23 »

Je me pose la question du fonctionnement DSCP :
- chez les opérateurs au sens large (moi je ne connais que Orange)
- chez les hébergeurs (hypersacler ou plus petit)
- dans des appli genre NPEF / OOKLA si le trafic est dissymétrique en DSCP (ce qui du coup en lisant les RFC me paraitrait logique ..)

Des captures ? Des analyses ?

On a un problème d'interfonctionnement je pense aussi, mais il faudrait déterminer c'est quoi l'état de l'art attendu 2025 ...

kgersen · « **Réponse #6 le:** 03 octobre 2025 à 17:03:39 »

en Cloud public, GCP respecte le marquage DSCP (qu'en sortie bien sur ): https://cloud.google.com/network-connectivity/docs/interconnect/how-to/cci/configure-traffic-differentiation mais uniquement sur du "Cloud Interconnect" (donc des liens dédiés a cela, en général rien en dessous de 10Gbps).

Le marquage se fait par copie de la requête entrante. Donc si on appelle une API GCP avec un marquage DSCP , la réponse utilisera le meme marquage.
Apres c'est juste géré par du L2, niveau CoS VLAN donc limité a 6 classes.

Mais bon ce n'est pas de l'IP public, des qu'on entre/sort vers Internet la DSCP est ignorée. Pas comparable avec Orange donc.

je ne sais pas pour AWS et Azure, j'imagine qu'ils ont une offre similaire sur les liens privés.

vivien · « **Réponse #7 le:** 03 octobre 2025 à 22:30:12 »

Chez Bouygues :

Sens montant : ils ne font pas confiance au DSCP des flux client et c'est re-tagué sur la box puis de nouveau au niveau du DSLAM / OLT pour gérer les cas où le client n'utilise pas la box opérateur. Si le téléphone est priorisé (c'est le seul flux montant qui peut être priorisé pour une box grand public, il me semble), le tag DSCP sur autre chose que 0 se fait en fonction de l'adresse IP cible.

Les flux internet sont également tagués en DSCP 0 en entre des peering / transit.

lpouzenc · « **Réponse #8 le:** 04 octobre 2025 à 18:22:33 »

Bonjour,

Merci pour toute l'activité autour du sujet !

Je vais condenser ce que je crois savoir autour du point SSH :

Sans connaître les 20+ans d'historique, je trouve surprenant, lors d'un rsync over ssh ou d'un scp qu'on ait par défaut certains paquets avec un DSCP au début, puis une bascule au bout de quelques paquets comme comportement par défaut. Mais ça l'est et depuis apparemment très longtemps (>10 ans).

Mais essayer de faire "corriger" (changer) ça côté OpenSSH n'apporte pas vraiment grand chose car on peut citer des cas d'usages de DSCP variable légitime pour une seule et même connexion ssh : on peut avoir un flux interactif pour un shell et un flux "bulk" parce qu'on a utilisé un tunnel / direction de ports ou du sftp.

Une façon basique de mettre en œuvre ça pour un essai est, je pense : ssh -D 8080 user@machine.fqdn.tld

Ceci ouvre le port 8080 local et attends des clients SOCKS5 de proxy (champ qu'on peut configurer dans un firefox, dans les paramètres/proxy) + ça ouvre un shell interactif sur la machine cible. Un download dans le firefox qui passe par le proxy SOCKS5 localhost:8080 ne devrait pas nuire à l'interactivité de la session shell.

Aussi, il est bon de faire attention à quelle page de man ssh on lit. Il faut *vraiment* prendre celle de sa distro et de la bonne version car par exemple debian a des patch "temporaires" depuis 2019 toujours appliqués en 2025 pour ne pas suivre ce qui est dans le dépôt git upstream d'OpenSSH (et utilisé sur fedora par exemple) à propos de la directive de configuration IPQoS. Les patchs modifient à la fois le code source C qui parse l'option IPQoS et la page de man distribuée dans debian. Dans le cas de debian des vielles valeurs de TOS sont utilisées à ce jour, 04/10/2025 dans la configuration par défaut. Dans le cas de toutes les distribution linux non Debian-based que j'ai pu regarder, des valeurs plus modernes mais différentes de CS0 sont utilisées par défaut.

Extrait page de man ssh_config Debian :
IPQoS :[...] The default is lowdelay for interactive sessions and throughput for non-interactive sessions.

Extrait page de man ssh_config non Debian :
IPQoS :[...] The default is af21(Low-Latency Data) for interactive sessions and cs1 (Lower Effort) for non-interactive sessions.

La discussion entre les développeurs d'OpenSSH pour basculer des vielles valeurs TOS aux valeurs DSCP qu'ils ont choisi date de 2018 et est ici :
https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-April/036788.html

Comme je trouvait fort de café que Debian utilise des valeurs TOS en 2025, j'ai bugreport chez debian. Si je comprends correctement la réponse succincte du packageur : à la prochaine release de OpenSSH, il droppe ces patchs de 2019 :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111446

Mais on aura donc par défaut af21 puis au bout de quelques paquets cs1 quand on fait un bête scp, et je ne crois pas qu'on aura un changement global de ça dans le code d'OpenSSH un jour, au mieux ils répondront : ok désolé que vous ayez un opérateur majoritaire en France qui applique des bwlimit à 5mbits s'il y a eu des paquets taggué en interactive au début d'une connexion TCP, vous avez l'option IPQoS dans la conf, mettez cs0 mais on va pas risquer d’abîmer plein d'autres cas d'usages établis pour le reste du monde à cause de vous.

Amicalement,
Ludovic

levieuxatorange · « **Réponse #9 le:** **Hier** à 09:05:27 »

Hello

Je suis en phase avec le principe que ce n'est pas un "bug" mais bien une feature demandée de pouvoir ficher la CoS/DSCP sur une valeur unique sur tout le flux.

Que Orange ait choisi de gérer cela comme ça (avec un "héritage" de la CoS des premiers paquets) sur le fixe est sujet à discussion. Mon soucis est que ceux qui ont fait ce choix sont partis. Il va falloir faire un peu de rechallenge la dessus.

Par contre, cela doit rester étanche au réseau Orange Fixe, cela est certain. Je vais voir commence cela se passe pour corriger cela.

Je n'arrive pas à me faire d'opinion sur le changement de QoS pendant la durée d'une session TCP. On trouve des chose très divergentes là dessus.
Et en même temps c'est un usage établis depuis pas mal d'année d'après les trace que vous avez trouvé.
Mais cela apparait maintenant comme facteur perturbateur, ce qui est quand même révélateur d'un soucis de cohérence global ..

LeVieux

levieuxatorange · « **Réponse #10 le:** **Hier** à 09:27:06 »

J'ai une question pour votre sagacité :

Si on prend un tunnel quel qu'il soit (tunnel SSH ou Wireguard)
Ni y'aurait il pas une logique à ce que que le DSCP / CoS du flux qui est tunnelé soit recopié dans l'enveloppe externe, c'est à dire le tunnel en lui même.

Cela pourrait donner la chose suivante :
- un tunnel WireGuard est établi entre deux sites.
- dans ce tunnel circulent deux flux, un interactif (telnet imaginons pour pas mélanger avec le cas SSH) l'autre de transfert de fichier
- il y aurait donc une logique à ce que les paquet telnet soient en DSCP "interactif CS4" et les paquets transfert de fichier en "bulk CS1"
- on aurait donc sur le même flux WireGuard des paquets de classification très différents..

Commentaires ?

LeVieux

vivien · « **Réponse #11 le:** **Hier** à 10:13:25 »

Laisser des informations sur le type de flux à l'extérieur du VPN peut être contreproductif pour certains usages, mais cela pourrait être intéressant pour d'autres usages.

À l'époque de l'ADSL, certains opérateurs avaient priorisé les paquets [SYN], [SYN-ACK] et les requêtes DNS, car la perte de ces paquets entrainait une latence importante pour le client.
Ces pratiques ont cessé, l'opérateur en question voyant un risque vis-à-vis du règlement sur la neutralité du net.

Laisser la possibilité à l'utilisateur de prioriser certains flux via un tag DSCP en échange d'une limite de débit pour éviter les abus, n'est pas forcément illégal vis-à-vis du règlement sur la neutralité du net (cela demande une étude du régulateur pour savoir si on est à côté de la ligne jaune ou si on la dépasse), mais un des points importants du règlement, c'est la transparence : l'opérateur doit détailler les niveaux de priorité et limite de débits associés pour chaque DSCP qu'il permet au client d'utiliser.