Auteur Sujet: DSCP : de la conservation d'un unique DSCP sur la vie d'un flux (Lu 1368 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.

levieuxatorange · « **Réponse #19 le:** **Aujourd'hui** à 08:43:34 »

@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

MaxLebled · « **Réponse #20 le:** **Aujourd'hui** à 08:54:48 »

Citation de: vivien le Hier à 22:47:17

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

vivien · « **Réponse #21 le:** **Aujourd'hui** à 08:59:44 »

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.

Citation de: levieuxatorange le Aujourd'hui à 08:43:34

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

kgersen · « **Réponse #22 le:** **Aujourd'hui** à 14:38:07 »

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.

buddy · « **Réponse #23 le:** **Aujourd'hui** à 14:44:03 »

Citation de: vivien le Aujourd'hui à 08:59:44

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 ?