Auteur Sujet: Ethernet omniprésent : quel surcout pour l'overhead?  (Lu 12815 fois)

0 Membres et 1 Invité sur ce sujet

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 607
  • La Madeleine (59)
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #12 le: 12 août 2016 à 18:21:16 »
Que je sache, MPLS se base sur IP pour le controle, et sur un protocole de niveau 2 pour les data

Ceci dit, en théorie tu as raison
Sur plusieurs de mes constructeurs, j'ai des fonctionnalités pour "supprimer" le switching sur un port
En théorie donc, et si ce port possède une IP "point à point", il peut deviner l'IP de son copain, et donc se passer complétement de mac / arp / ndp

En pratique, je ne sais pas si ce comportement existe

vivien

  • Administrateur
  • *
  • Messages: 36 225
    • Twitter LaFibre.info
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #13 le: 12 août 2016 à 18:23:13 »
A noter que http/2 va faire monter sensiblement la taille moyenne des paquets pour le surf en agrégeant les différent GET dans un même paquet et en enchaînant les réponses dans des paquets de talle max et en réduisant le nombre de requêtes DNS (vu que en http/2 il est conseillé de tout mettre sur le même domaine alors que pour une page en clair en http 1.1 c'est le conseil inverse pour optimiser le temps de chargement.

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 4 585
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #14 le: 12 août 2016 à 18:55:55 »
Que je sache, MPLS se base sur IP pour le controle, et sur un protocole de niveau 2 pour les data
Oui, mais le MPLS, quand il encapsule des paquets IP, c'est très peu d'overhead en comparaison d'Ethernet.
* Ethernet : 20 octets
* MPLS : 4 octets

A noter que http/2 va faire monter sensiblement la taille moyenne des paquets pour le surf en agrégeant les différent GET dans un même paquet et en enchaînant les réponses dans des paquets de talle max et en réduisant le nombre de requêtes DNS (vu que en http/2 il est conseillé de tout mettre sur le même domaine alors que pour une page en clair en http 1.1 c'est le conseil inverse pour optimiser le temps de chargement.
Ah, ça c'est une bonne nouvelle. C'est vrai qu'en regardant des captures réseau de surf web, on voit que c'est loin d'être optimisé, et qu'il y a une foultitude de petits paquets. Des gros paquets, ça allège la charge des routeurs, ça prend moins de place, etc... Ca devrait accélérer le surf pour les liaisons lentes.

Ca compensera peut-être un peu l'overhead monstrueux d'IPv6 (40 octets au lieu de 20).  ;)

Leon.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 607
  • La Madeleine (59)
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #15 le: 12 août 2016 à 19:03:58 »
Oui, mais le MPLS, quand il encapsule des paquets IP, c'est très peu d'overhead en comparaison d'Ethernet.
* Ethernet : 20 octets
* MPLS : 4 octets
Je me permets de te reprendre
MPLS, tu as :
- le contrôle (c'est à dire, la gestion du protocole), qui fonctionne sur IP (et peut-être autre chose)
- les données, qui fonctionnent sur un autre protocole de niveau 2 (en théorie, n'importe lequel, c'est le M de MPLS : "Multi Protocol Label Switching")

Citer
Ca compensera peut-être un peu l'overhead monstrueux d'IPv6 (40 octets au lieu de 20).  ;)
Au moins 40 octets pour l'IPv6, puisque ce dernier possède des headers supplèmentaires optionnels : https://en.wikipedia.org/wiki/IPv6_packet#Extension_headers

D'un point de vue bande passante, l'IPv6 est une catastrophe (nécessaire et, in fine, non importante)
D'un point de vue routeur, l'IPv6 est en revanche une bénédiction :)

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 4 585
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #16 le: 12 août 2016 à 19:09:05 »
Je n'ai pas compris où tu voulais me reprendre
MPLS, tu as :
[...]
- les données, qui fonctionnent sur un autre protocole de niveau 2 (en théorie, n'importe lequel, c'est le M de MPLS : "Multi Protocol Label Switching")
De ce que j'ai compris, on peut encapsuler de l'IP over MPLS, de l'Ethernet over MPLS, etc...
Et l'IP over MPLS, ça ne fait que 4 octets d'overhead.
IP over ethernet over MPLS, ça en fait beaucoup plus, mais ça n'est pas ça dont je parle.

Leon.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 607
  • La Madeleine (59)
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #17 le: 12 août 2016 à 19:17:43 »
IP over ethernet over MPLS over ethernet, si tu préfères
Ou ethernet over MPLS over ATM

Bref

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 4 585
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #18 le: 12 août 2016 à 19:24:55 »
Oui, mais non. Les équipements longue distance, ils savent directement transporter du MPLS. Pas besoin de "MPLS over ethernet", pour ces liens longue distance.

Leon.

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 501
  • Malissard (26)
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #19 le: 12 août 2016 à 19:37:17 »
Le but d'utiliser MPLS en longue distance c'est aussi pour des problématiques fonctionnelles de continuité d'un backbone à un autre. Le gain vis-à-vis des headers du protocole, bof.

Je rejoins ce qu'a dit Jack: Ethernet est archi-standard, connu, maitrisé. Aucun protocole n'a atteint un tel niveau d'optimisation au niveau hardware et/ou ne nécessite de matériel exotique. Il n'y a qu'à regarder le catalogue de Cisco, Ethernet est omni-présent à tous les niveaux de gamme.

J'ai du mal à lui voir un remplaçant/concurrent.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 607
  • La Madeleine (59)
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #20 le: 12 août 2016 à 19:42:36 »
Les équipements longue distance, ils savent directement transporter du MPLS
Source ?

corrector

  • Invité
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #21 le: 13 août 2016 à 02:33:34 »
Juste une supposition sans fondement précis : peut-être que la perte de 4% est négligeable dans tous les cas présentés, par rapport aux alternatives ?
Et en particulier, la sortie de ces liens est directement utilisable par des équipements réseaux "standards" et "courants".
Pardon mais là tu mélanges vraiment tout, et d'ailleurs la question leon est incompréhensible (tout comme les réponses d'ailleurs) : est-ce qu'il veut parler d'Ethernet présentation logicielle de trames, ou de Ethernet II, format de trames codées, ou de IEEE 802.2 LLC SAP/SNAP?

Pourquoi mentionner Wifi qui n'est pas du tout de l'Ethernet, qui ne fonctionne pas comme de l'Ethernet, n'a aucun rapport avec Ethernet II et qui des trames plus petites?

N'importe quoi est "directement utilisable" comme n'importe quoi d'autre une fois que tu as appliqué la conversion adéquate.

Donc pourquoi transporter le formalisme d'Ethernet, avec :
- adresse Ethernet source (6 octets)
- adresse Ethernet destination (6 octets)
- numéro Ethernet de protocole encapsulé (ARP, IPv4, IPv6...) (2 octets)
soit en tout 14 octets. Je ne sais pas d'où tu sors 20 octets!

La question n'a vraiment aucun sens.

Enfin la Freebox xDSL ne transporte pas de l'Ethernet, même en mode SOI-DISANT bridge.

Finalement Ethernet est une bannière derrière laquelle tout le monde se range, point.
« Modifié: 13 août 2016 à 03:08:19 par corrector »

corrector

  • Invité
Ethernet omniprésent : quel surcout pour l'overhead?
« Réponse #22 le: 13 août 2016 à 03:16:07 »
Je rejoins ce qu'a dit Jack: Ethernet est archi-standard, connu, maitrisé. Aucun protocole n'a atteint un tel niveau d'optimisation au niveau hardware et/ou ne nécessite de matériel exotique. Il n'y a qu'à regarder le catalogue de Cisco, Ethernet est omni-présent à tous les niveaux de gamme.

J'ai du mal à lui voir un remplaçant/concurrent.
Voilà, tu recraches un gloubi-boulga techno-commercial infâme et honteux.

Ce qui tu fais semblant de raconter n'a aucun sens. Quel est donc ce soi-disant "Ethernet" standardisé? Il est décrit où?

Je call ton bluff.

corrector

  • Invité
AAL5
« Réponse #23 le: 13 août 2016 à 03:26:22 »
Voilà, ça montre que l'on se préoccupe bien de l'overhead dans les liaisons 3G/4G, mais pas dans les liaisons backbone classique, et c'est ça que j'ai du mal à comprendre. Ici, pour le RoHC que tu nous montre, on ne parle pas du tout de l'overhead Ethernet, on ne l'utilise naturellement pas, et en plus on compresse les en-tête IP.
OK, mais pour les gros équipements de coeur de réseau (routeurs, et surtout équipements optiques longue distance), c'est du matériel archi spécifique. Donc je comprends que l'interface "utilisateur" de ces équipements doit être standardisée (et Ethernet le fait très bien), mais je ne vois pas de raison d'utiliser Ethernet côté "interface longue distance", vu que c'est systématiquement du "point à point".

Le plus étrange, c'est qu'avec les techno d'il y a 15 ou 20 ans (SONET), l'overhead était apparemment très regardé. J'ai l'impression qu'aujourd'hui, c'est juste "on se fait plaisir".
Imaginez l'overhead sur des paquets VoIP, c'est juste du délire. Il y a 4 fois plus d'informations liées au protocole, que de vraie donnée utile (voix compressée). Et je ne vous parle pas de l'IPv6 qui gaspille encore plus de bande passante. 
Pour moi la désinvolture en matière de surcharge protocolaire est bien plus importante sur une liaison ADSL où on impose une couche ATM qui ne sert strictement à rien mais qui a entête de 5 octets, plus 8 octets pour la "convergence" ALL5, soit 32% de surcharge dans le cas optimal, bien loin des 4% de l'Ethernet!

Et "personne" n'a gueulé!

 

Mobile View