Pour mon cas, les paquets sortent avec le DSCP par défaut de OpenSSH qui n'est pas zéro, mais le tag est modifié par le réseau (je n'ai pas le même tag au départ et à l'arrivée). Maintenant, cela ne me semble logique qu'entre certains parie du réseau le DSCP soit modifié. Je suis plus étonné par le fait qu'un trafic client ne soit pas re-tagué pour éviter qu'un client puisse priorises ses propres flux (que cela soit volontairement ou invonlontairement).

Tu as bien regardé le tag des acquittements TCP ? Dans mon cas, c'est vraiment sur le tag du paquet "SYN" (connexion initiée depuis le réseau mobile vers une ligne FTTH) puis des acquittements TCP qui fait que j'ai ou pas la limitation dans l'autre sens (FTTH => Mobile). C'est assez étrange que le tag des acquittements aillent entraîner une limite du flux dans l'autre sens (avec les données) à 5 Mbit/s.

@levieuxatorange : J'avais manqué de lire une partie de ta réponse avant mon précédent message:

Contournement possible : en entré/sortie  de ta machine pouzenc, forcer le CS0. Si tu sais faire cela et que cela fait sauter la limitation, on a une vraie piste.
Si un gourou Linux peut trouver le commandes tc à mettre, cela serait une aide.
LeVieux

Je pense pouvoir construire la commande tc moi même (j'ai fais ça dans mes erreurs de jeunesses pour des liens radio...), mais le problème est que ... je suis déjà à l'objectif je crois : tous les paquets sortants de pouzenc.fr sont en CS0 sauf les RST en fin de flux.

Ou alors je comprends mal ce à quoi tu as pensé, dis-moi.

Je peux bien changer en CS0 en input sur pouzenc.fr mais comme je sais que c'est pas mon linux localement qui shape et que les paquets ne seront vu par aucun intermédiaire supplémentaire quand ils en sont là... je crains que ça soit vain. Tout l'art est de savoir où est l'équipement qui change "dans mon dos" les valeurs de CoS. Et ça semble pas chez TTN ni chez les opérateurs qu'il ont en peering/transit car on a essayé 3 routages possibles en suspendant des annonces BGP le temps des essais.

Ludovic

> Je fais regarder à l'interco IPv6 en bordure du RBCI, mais là y'a un truc sans même parler ce cela.

Merci !

J'essaie de reprendre les cas que tu as regardé :
tcp.stream eq 2 :
- c'est initié depuis chez moi, avec la commande : $ wget -6qO - https://pouzenc.fr/ip.php
- l'IP en 2a01:c... c'est le nuc chez moi (Orange). L'IP en 2a03 c'est le serveur pouzenc.fr.

 Ma lecture (fausse ?) de la situation : si on regarde n'importe quel des 10 premiers paquets de ce flux, et qu'on regarde pour un même paquet donné une capture puis l'autre, il me semble qu'on constate que :
-  le nuc envoi en CS0
- pouzenc.fr reçoit en 0x14 si on prends les 8 bits incluant l'ECN (ce qui est "5" si on regarde les 6 bits de l'ECN mais pas CS5, ça peut être d'ailleurs un blague de conf sur un CLI d'un routeur type cisco sur le chemin ça !)
- pouzenc.fr réponds en CS0
- le nuc reçoit en CS5 (0xa0 en incluant les bits d'ECN)

Donc je suis d'accord avec :  on voit que dès le 4ème Pkts, tu es en CoS 5.
Et j'ajoute : en fait, oui même dès le premier paquet... et ce n'est pas "moi" (aucune de mes 2 linux d'extrémité) qui choisi cette valeur, elle est altérée sur le chemin malgré moi.

"elles sont super tes captures !" : j'ai juste passé bcp plus de temps que de raisonnable car grande vacances Merci.

"on voit bien que tu reçois du CS05 dès le SYN/ACK. Et là c'est mort, la régulation va se mettre en place.". Oui. Sauf que je ne choisi pas de faire ça, je subit ça. J'ai émis 100% (certes sauf les RST à la fin et j'ignore pourquoi c'est comme ça) des paquets en CS0 dans les deux sens et ils arrivent altérés dans les deux sens, et ça shape.

tcp.stream eq 9 :
- c'est initié depuis chez moi, avec la commande : $ rsync -e 'ssh -6' /dev/shm/rand100Mio.dat root@pouzenc.fr:/dev/shm/rand6.dat
- numéro du premier paquet dans la capture côté nuc : 77132

Là, effectivement, mon nuc emet avec la CoS 4 au début de la conversation, puis en CoS 2 au bout d'un moment (dès le paquet 77167, donc environ 30 paquets après le début de l'échange), inconnue du dissecteur de Wireshark. Ça je peux forcer pour que ça ne se produise pas, on devrait avoir la même chose que le stream eq 2 si je le fais (mais en port 22 et pas 443). On peut remarquer qu'un intermédiaire a forcé cette CoS 4 à une CoS 5, tout comme quand j'envoi en CS0, ça devient CoS 5.

"Et pouzenc, il fait des trucs encore plus exotiques :". Je dirai : pas tant. Pour moi, il se contente de toujours répondre en CS0 (il a l'IP en 2a03) lorsqu'il reçoit du nuc (2a01:c) des DSCP étonnants mais en fait toujours identiques à la valeur CoS5, quelque soit la valeur d'origine émise.

Edit : Cette affirmation pour moi se vérifie bien avec le filtre "(ipv6) && (ipv6.src == 2a03:7220:8081:9f00::1)" sur la capture *depuis-pouzenc.fr.pcap". Les seules exceptions sont un float de RST durant une commande iperf3, elles sont là :
No.     Time            Source                  Destination                             Proto.  DSCP    Info
2988 14.594550 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e TCP CS0 5201 → 55496 [RST, ACK] Seq=1 Ack=2626130 Win=361984 Len=0 TSval=2624548727 TSecr=1558080889
2989 14.594784 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e TCP CS0 5201 → 55488 [PSH, ACK] Seq=5 Ack=166 Win=64256 Len=1 TSval=2624548728 TSecr=1558080890
2991 14.597031 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e TCP 5 5201 → 55496 [RST] Seq=1 Win=0 Len=0
2993 14.599494 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e TCP 5 5201 → 55496 [RST] Seq=1 Win=0 Len=0

La doc de ssh_config pour le paramètre IPQoS : Specifies the IPv4 type-of-service or DSCP class for connections. The default is af21 (Low-Latency Data) for interactive sessions and cs1 (Lower Effort) for non-interactive sessions. J'ai un peu du mal à faire les correspondances entre les valeurs acceptées dans la config et les valeurs qu'on lit uen fois décodé par Wireshark, mais tout le monde semble d'accord sur la valeur de CS0 en tout cas.

Le registre officeil des valeurs de ces champs DSCP pour IPv6 : https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml#dscp-registry-1

Merci pour le temps passé le nez dans les pcap...
Ludovic

As-t'on des nouvelles côté IPv6 + DSCP + RBCI Orange ?
Je parle de : "Je fais regarder à l'interco IPv6 en bordure du RBCI, mais là y'a un truc sans même parler ce cela. LeVieux"

Nop, pas encore c'est pas au sommet de la pile et y'a encore pas mal d'expert(e)s en congé

LeVieux

Y'a quand même un truc pas clean qui traine sur une des interco avec un remarquage à CS0 qui doit manquer.
Dans un sens comme dans l'autre d'ailleurs je dirais. Les marquages DSCP sont spécifiques à chaque réseau et une interco DSCP est toujours issue d'un accord des deux partie ...

Mais comme les interco de peering changent régulièrement, pas toujours évident de pas rater un truc.
Comme j'ai écrit auparavant, c'est comme les problème de MTU : tout sauf simple à trouver où est le point qui gène.

Dès que j'ai plus de monde de retour, je vais demander un point la dessus.

LeVieux

De mon côté, j'ai toujours le trafic en AF22 (0x50), mais on dirait que c'est pour tout, il n'y a pas de distinction (de ce que j'ai vérifié en tout cas), donc peut-être que ça revient au même que si tout était retagué en CS0. C'est peut-être un moyen de distinguer le trafic mobile du fixe plus loin sur le réseau ?

Exemple pour le DNS :