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

Stlgr, Hequin0x et 1 Invité sur ce sujet

levieuxatorange

  • Expert Orange
  • Expert
  • *
  • Messages: 303
DSCP : de la conservation d'un unique DSCP sur la vie d'un flux
« Réponse #12 le: Aujourd'hui à 10:21:57 »
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

  • Administrateur
  • *
  • Messages: 51 023
    • Bluesky LaFibre.info
DSCP : de la conservation d'un unique DSCP sur la vie d'un flux
« Réponse #13 le: Aujourd'hui à 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

  • Expert.
  • Abonné OVH
  • *
  • Messages: 1 044
  • FTTH >500 Mb/s (13)
DSCP : de la conservation d'un unique DSCP sur la vie d'un flux
« Réponse #14 le: Aujourd'hui à 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.