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

levieuxatorange · « **le:** **Hier** à 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:** **Hier** à 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:** **Hier** à 15:31:55 »

reserve

kgersen · « **Réponse #3 le:** **Hier** à 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:** **Hier** à 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:** **Aujourd'hui** à 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 ...