Il est possible de jouer plus fin avec, une priorisation limitée en terme de trafic. Les équipements actuels savent faire ça.

Après pourquoi le faire pour la VoIP et pas pour le gaming ou le SSH ?

Sans parler de la neutralité du réseau qui est un peu entachée...

Parce que la VoIP c'est de la voix ? Et qu'avoir des coupures sur ce genre de service est difficilement acceptable (appels d'urgence...) ? On peut faire le parallèle avec le RTC, y'a t-il des coupures dessus ? Non, le débit est garanti de bout-en-bout. Je ne vois pas pourquoi sous prétexte qu'elle change de média de transport, elle devrait être traitée comme un protocole classique.

Vu que maintenant tout est sur ip et non plus séparé, la téléphonie devrait être prioritaire sur la TV elle même prioritaire sur le reste.

Pour moi, y aurait soucis de neutralité si HTTP était prioritaire sur FTP par exemple. Pour ce qui est téléphonie et TV, je n'y vois aucun inconvénient, vu qu'à la base ces services ne sont pas issus d'internet et de part leur nature "critique", les prioriser sur le reste ne me choque pas.

Comment tu veut tagguer sans abus un flux RTP ou SIP traversant plusieurs AS?
C'est pour cela que la VoIP n'est garantie que sur un morceau d'AS (eyeball =>  serveur voip de l'ISP, VRF du VPN MPLS, etc ...).

Je ne vois pas où est la difficulté là dedans. Si un paquet est taggué au départ, c'est quoi le soucis pour qu'il reste tel-quel tout au long de son parcours ? Un routeur, de base, n’est pas censé modifier les paquets qu'il reçoit.

Et 10 minutes après l'application de ce paramètres sur les routeurs, tu as 3/4 de la populations qui installera un pseudo-booster reconfigurant la stack IP pour èmettre un DSCP 46.

Faudrait déjà que les 3/4 de la population sache ce qu'est un paquet IP et la notion de QoS...

Enfin bref, j'ai bien compris que ça ne se ferait jamais. Mais techniquement rien ne l'empêche. Hâte de voir à quoi ça va ressembler une fois que le monde entier sera passé au tout IP.