La Fibre
Télécom => Réseau => 
TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: 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
-
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
-
reserve
-
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.
-
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.
(https://lafibre.info/images/orange/202509_transfert_ssh_linux_filtre_paquets_emis.webp)
-
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 ...
-
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.
-
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.
-
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
-
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
-
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
-
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.
-
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.
Là on va toucher à la question du réglementaire en effet. Et pose la question de ce qu'est la neutralité du NET.
Actuellement je dirais que c'est :
- CS0 pour tout le monde
- CSxx pour qq services opérateurs très limités (il me semble que sur le réseau Orange RBCI c'est VoIP de la LB, les réponses DNS et les flux Multicast TV. Les réponses DNS aussi il me semble ...Mais rien d'autre)
Mais surtout cela n'a réellement d'intérêt que si c'est quelque chose que l'on peut utiliser à l'interface entre les opérateurs.
Là des facto pour les gens de la fibre qui peuvent mettre autres chose qu'une LB, ils ont accès à ces classes de CoS.
Je ne sais pas d'ailleurs si elle sont documentées qq part ??? Va falloir que je demande en interne.
Mais en dehors du point réglementaire, cela aurait il un sens ?
LeVieux
-
La priorisation à du sens quand il y a pénurie.
Il y a quelques années, les situations de pénuries de bande passante étaient fréquentes.
Quand j'étais étudiant, j'ai réalisé un stage dans les réseaux de la SNCF en 2001. Je me souviens de l'établissement de maintenance TGV de Châtillon. Plusieurs milliers de salariés connectés par une liaison à 64 Kbit/s. Ce débit ne suffisait pas pour l'envoi des mails en temps réel et le serveur de mail local envoyait les mails en attente d'expédition au fur et à mesure dans la nuit.
Tu téléphonais à ton correspondant pour savoir où était l'envoi de la documentation et on te disait que le mail était parti et que tu devrais le recevoir le lendemain...
Aujourd'hui un simple particulier peut avoir 8 Gbit/s. Les usages ont augmenté, mais plus lentement que le débit.
Il y a de plus en plus d'usage en simultané et souvent la congestion, c'est le Wi-Fi. Permettre que les usages interactifs soient prioritaires à de gros flux sur le Wi-Fi aurait probablement plus du sens que de la priorisation sur le WAN qui n'est plus aujourd'hui le secteur limitant. Mais avec HTTP/3, il va devenir impossible de savoir si un flux est interactif ou pas.
Aujourd'hui les clients ne se plaignent plus d'un mauvais débit (sauf problématique en limite de couverture Wi-Fi), mais des coupures.
-
Concernant Wireguard, le site officiel nous apprends: (https://www.wireguard.com/protocol/#diffserv-considerations)
The "DiffServ" bits in an IP packet are generally split into two portions: one describing the quality of service, via the DSCP value, and the other containing bits used for Explicit Congestion Notification (ECN). All handshake packets have a DSCP value of 0x88 (AF41), so that these packets are the least likely to be dropped, as they're essential for the control functionality of the tunnel, and the ECN is set to 00. All transport data packets have a DSCP value of 0, because the DSCP value of the inner packet is never copied to the outer packet, so that we don't leak information about the data inside the encrypted inner packet. However, we do copy the ECN bits to and from the inner packets, in accordance with the logic described in RFC6040.
-
C'est l'histoire de l'informatique résumé la... la RFC (rfc2597#section-5) de l'époque recommande de préserver l'AF du traffic dans le tunnel, la sécurité (plus récente) recommande ne le pas le faire...
Toutefois, je ne pense que ce soit a Wireguard de l'imposer, ca doit être paramétrable (opt-out au pire).
-
+1 que l'on laisse le choix à l'utilisateur. D'autant plus quand on voit que les clients android et windows sont en CS0 car pas accès à ce qu'il faut pour modifier le DSCP.
C'est un peu cocasse de la part d'un VPN libre de ne pas pouvoir avoir la main sur ce genre de paramètre sans devoir recompiler sa propre version.
Et côté Orange, je suis pour ne pas toucher aux flux et laisser les classes en place, au moins on a un comportement cohérent entre une LB et un routeur perso.
-
Il n'y a pas de négociation d'option dans Wireguard ce qui obligerait à définir l'option aux extrémités.
De plus, Wireguard utilise UDP Generic Segmentation Offload donc un outer packet peut contenir plusieurs inner packets.
-
Moi, mon rêve, ce serait de pouvoir un flux déprioriser de bout en bout un flux, pour de la sauvegarde en arrière-plan.
Quand tu sauvegardes un PC portable connecté en Wi-Fi, il est compliqué de ne pas impacter trop l'utilisateur.
La solution que j'ai trouvée, c'est de bien brider le débit pour être sûr que l'utilisateur n'ait pas de pb.
-
@vivien : mais du coup tu fais comment si dans ton tunnel tu as deux trafics différents ?
C'est là où je suis d'accord :
- le fait de mettre dans l'outer tunnel le DSCP de l'inner pkt permettrait de différencier les 2 flux sans avoir de négo flux par flux entre les deux extermité
- cela devrait être le choix du user de pouvoir faire soit :
- tout mettre au même DSCP pour obfuscer le contenu
- mettre cela dans l'outer pour répondre au rève de Vivien (désolé Vivien j'ai pensé au déssin animé Raiponce et je t'ai visualisé dans le costume des gars qui chantent j'ai un reve dans la taverne ...) sans plus de complexité de négo ou de bridage.
LeVieux
-
La solution que j'ai trouvée, c'est de bien brider le débit pour être sûr que l'utilisateur n'ait pas de pb.
Ça, ou l'implémentation d'algorithmes d'évitement de congestion ultra-sensibles et ultra-réactifs uniquement pour ces usages. Il y en a qui sont utilisés pour le streaming video en temps réel ; je pense notamment à Parsec, qui a construit son propre protocole et algorithme de congestion, réglé par défaut pour être extrêmement sensible à toute saturation, et qui n'hésite donc jamais à réduire son propre débit.
Mais dans les faits, oui, c'est souvent une limitation du débit toute simple qui est choisie par des applications.
Par exemple, l'application Dropbox sur Android, lorsqu'elle sauvegarde les photos/vidéos automatiquement, se limite systématiquement à 35 Mbps (4,4 Mo/s), et ce, peu importe la qualité de réception Wi-Fi. Si on initie l'envoi d'un fichier soi-même, par contre, là, ça va à fond la caisse...
-
35 Mb/s cela peut être beaucoup pour certains en Wi-Fi (j'ai des personnes de ma famille qui ont une Neufbox 4 de 2007, Wi-Fi uniquement en 2,4 GHz). C'est du FTTH, mais le Wi-Fi est très limitant. Pour comparer, c'est le Wi-Fi de la Livebox 2.
@vivien : mais du coup tu fais comment si dans ton tunnel tu as deux trafics différents ?
Je n'utilise pas Wireguard et il y a juste un tunnel SSH pour la sauvegarde incrémentielle pendant que l'utilisateur continue d'utiliser son PC (habituellement, je lance une sauvegarde durant les visios-conférence, ce qui me permet d'être sûr que la personne ne va pas éteindre son PC pendant la sauvegarde).
Si cela vous intéresse, mon script bash est disponible sur Sauvegarde incrémentielle et différentielle d'un serveur ou PC Linux (https://lafibre.info/ubuntu/sauvegarde-serveur/).
-
On en revient au besoin d'une api box/gateway ouverte. Les applications interrogent la box/gateway et du coup connaissent la BP dispo (max & temp réel) et adapte leur réglage et trafic en fonction.
Apres pour de l'usage 'background' style sauvegarde c'est a l'application de se limiter volontairement ou a l'OS de permettre a l'utilisateur de limiter une application. Une API box permettrait de mettre la limite en %age plutot qu'en absolue.
-
35 Mb/s cela peut être beaucoup pour certains en Wi-Fi (j'ai des personnes de ma famille qui ont une Neufbox 4 de 2007, Wi-Fi uniquement en 2,4 GHz). C'est du FTTH, mais le Wi-Fi est très limitant. Pour comparer, c'est le Wi-Fi de la Livebox 2.
SFR n'a pas fait une campagne de rappel/changement pour ses boxs ?? Je suis quasi sur que oui.
Un simple appel au SC suffit à la faire changer non ?
-
Non, aucune proposition de changer la box. Quand elle est passée de l'ADSL au FTTH, il y a juste eu un ONT externe de rajouté à sa Neufbox 4 de 2007.
Orange a encore des Livebox 2 de 2009 (une connaissance équipée de Livebox 2 est passée à la fibre hier, Orange a mis une Livebox S). Si vous avez besoin, je peux faire des photos avant son renvoi à Orange.
Chez Free, il y a encore des Freebox v5 de 2006 (il y a une campagne pour les sortir du parc).
Chez Bouygues, il me semble qu'il y a eu des campagnes pour sortir les veilles box (Thomson TG787 et Sagem F@st3504b).
-
Bon
J'ai lu beaucoup, donc interne, doc externe.
L'AF42 est vraiment considéré comme "de la Voix" et donc ratelimité comme tel car prioritaire.
Deux évolutions majeurs dernièrement :
- dans le monde du mobile, depuis 2 ou 3 ans on "fait confiance" au device client (principalement sur le réseau 5G). Cela pose la question de la "frontière" du réseau opérateur ...
- il y avait avant un remarquage à DSCP ZERO entre le monde du fixe et du mobile. Ce n'est plus vrai sur toutes les dernières offres ...
Et cela pose question :
- par rapport au choix du "domaine de gestion DSCP" du RBCI qui considère qu'un flux dispose d'une CoS unique tu toutes la durée du flux et tague donc la priorité sur les premiers Pkts
- ce qui est une choix parfaitement légitime pour un opérateur sur son "domaine de gestion DSCP"
- mais ce domaine fuit (questions de je ne sais plus qui qui a un comportement différent en v4 et en V6 vers un même peer ...)
- et d'autres domaines (opérateur tier et mobile orange) fuient aussi vers le RBCI entrainant les comportements que l'on a vu.
La description ci dessus et le comportement de WireGuard pose plusieurs questions :
- le marquage AF42 est bon en "local d'un domaine de gestion DSCP" mais pose question à l'interop entre domaine
- le changement de QoS est tout à fait possible dans les RFC, mais dans toutes les litératures et discussion que j'ai pu avoir c'est pas l'attendu, loin de là ...
- l'AF42 est communément associé à de la voix. Le choix AF31 aurait paru plus pertinent pour WG. Mais cela n'aurait rien changé à la limitation de 5 Mb. C'est à clarifier pour moi, mais je pense que cela tombe dans la même classe de service.
Point de vu neutralité du NET, tout remarquer en BE à l'entrée est la solution la plus simple, mais pas toujours en adéquation avec les convergences fixe / mobile et les demandes d'assurer les acheminement voix pour les appels d'urgence (qui est un cas d'exception à la doctrine de neutralité). D'où d'ailleurs je pense l'usage AF42 par WG et pas AF31 .
LeVieux
-
- par rapport au choix du "domaine de gestion DSCP" du RBCI qui considère qu'un flux dispose d'une CoS unique tu toutes la durée du flux et tague donc la priorité sur les premiers Pkts
- ce qui est une choix parfaitement légitime pour un opérateur sur son "domaine de gestion DSCP"
moi ca me pose probleme qu'un opérateur 'suive' un flux sur son backbone (du moins pour du trafic IP publique). quid du timeout ? c'est suivi ou et comment ?
Et je n'en vois pas la raison sauf peut-etre a palier a / améliorer des applications legacy voix 'mal faites' qui ne taguent pas correctement tous leurs paquets ? donc la effectivement ce genre de facon de faire aide l'application, mais aux détriments de celles qui sont bien faites, comme wireguard, qui ne tagguent que les paquets ayant besoin de QoS.
ps: c'est AF41 pas AF42 non ?
-
Deux évolutions majeurs dernièrement :
- dans le monde du mobile, depuis 2 ou 3 ans on "fait confiance" au device client (principalement sur le réseau 5G). Cela pose la question de la "frontière" du réseau opérateur ...
Ça parait assez incroyable... ???
-
moi ca me pose probleme qu'un opérateur 'suive' un flux sur son backbone (du moins pour du trafic IP publique). quid du timeout ? c'est suivi ou et comment ?
Suivi est peut être fort comme mot. En tout cas on considère qu'un flux est d'une COS unique et consistante. Donc quand la box (qui est une des frontières du réseau) assure un marquage, elle le fait avec cette politique.
Après c'est appliqué en considérant que le marquage à l'entrée est bon. Donc la politique de gestion de l'acheminement (file, priorité, shaping, drop) est réglé la dessus avec uniquement prise en compte du paquet en lui même.
Je me mélange toujours entre les AF, il faut que je relise .....)
LeVieux
-
Ça parait assez incroyable... ???
Confiance limité (on n'autorise pas tout ...) , mais je crois que c'est lié à la reconnaissance de qualité d'opérateur sur le territoire France) de WhatsApp ou je sais plus quel autre soft
@vivien, cela te parle ?
LeVieux
-
Non, aucune proposition de changer la box. Quand elle est passée de l'ADSL au FTTH, il y a juste eu un ONT externe de rajouté à sa Neufbox 4 de 2007.
Il y a pourtant eu des campagnes pour proposer le remplacement des boxs inférieures à NB6VAC.
-
je rebondis sur cette discussion : en creusant le sujet DSCP, je suis retombé ici et un point m’a fait tiquer. On parle de “conserver un DSCP unique sur toute la vie d’un flux”, alors que pas mal d’apps changent de marquage en cours de session (ex. SSH interactif vs transfert). Du coup, la cohérence dépend surtout d’où se situe la trust boundary : classifier/remark au plus près de la source (edge d’accès), puis “trust” en amont ; à l’inverse, aux frontières de domaine, certains opérateurs blanchissent ou remappent les DSCP, ce qui explique des écarts de comportement. Côté design Cisco, la recommandation classique est justement d’étendre la trust boundary vers l’accès et de faire confiance aux marquages en cœur quand on maîtrise l’edge, sinon on re-classe à l’entrée du domaine.
Cisco
Doc intéressante:
http://cisco.com/c/fr_ca/support/docs/routers/sd-wan/222695-understand-qos-fundamentals-and-class-de.html (http://cisco.com/c/fr_ca/support/docs/routers/sd-wan/222695-understand-qos-fundamentals-and-class-de.html)
https://pingmynetwork.com/network/ccna-200-301/what-is-quality-of-service (https://pingmynetwork.com/network/ccna-200-301/what-is-quality-of-service)