J'ai répondu avant que tu édites ton post et le complète.
Ok pour la répartition de charge sur un LAG, c'est un des cas que je connais (par contre c'est pas pour assurer l'ordre d'acheminement, les paquets sont numérotés individuellement précisément pour pouvoir être remis dans le bon ordre à destination, parce qu'en chemin, le réseau fait comme il peut).
Alors, effectivement TCP est capable de gérer le déséquencement, mais seulement si l'écart de séquence entre les paquets est inférieur à la taille de la fenêtre. Sinon le segment est rejeté et il faut le retransmettre.
En pratique le déséquencement tend à tuer le débit TCP, ou du moins à le faire chuter grandement. Ensuite, il y a UDP et autres. Aucune stack RTP que j'ai pu voir ne sait gérer le reséquencement: si déséquencement il y a, tous les paquets "en retard" sont considérés perdus, on attend pas les retardataires afin de réduire la latence au maximum.
Ok également en mesure conservatoire de défense du réseau en cas d'attaque.
Le dernier qui me semble valide, c'est le filtrage tcp/25.
Orange fait ca en effet et c'est discutable. Aujourd'hui avec DMARC, SPF et DKIM, quelles sont les chances que du spam envoyé depuis une connexion résidentielle arrive dans une inbox ?
Ce qui est sûr, c'est que ca m'empêche d'auto-héberger mes serveurs mails.
Y'en aurait d'autres ?
Je suis sûr qu'on peut en trouver d'autres :
- priorisation du traffic "control plane" (BGP/IGP/ssh pour administrer les équipements du réseau/netflow/etc.) sur tout le reste pour pouvoir stabiliser le réseau en cas de boucle de routage, DDOS, saturation extrême ou autre,
- priorisation du traffic TV multicast (qui n'est pas retransmis par nature) pour éviter les gels d'image ou les pixélisations,
- priorisation du traffic téléphone (très sensible à la gigue) pour assurer une bonne qualité d'appel
viennent à l'esprit.
Actus Free