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

levieuxatorange · « **Réponse #12 le:** **Hier** à 10:21:57 »

Citation de: vivien le Hier à 10:13:25

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

vivien · « **Réponse #13 le:** **Hier** à 10:50:42 »

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.

thenico · « **Réponse #14 le:** **Hier** à 12:38:25 »

Concernant Wireguard, le site officiel nous apprends:

Citer

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.

kgersen · « **Réponse #15 le:** **Hier** à 17:09:53 »

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).

renaud07 · « **Réponse #16 le:** **Hier** à 21:00:11 »

+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.

thenico · « **Réponse #17 le:** **Hier** à 21:32:13 »

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.

vivien · « **Réponse #18 le:** **Hier** à 22:47:17 »

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.