Discussion :

[TiteFlora]

Bonjour à tous !

Voilà en fait je passe bientôt un examen de réseau et dans les anales je suis tombée sur cette question :

Dans une architecture Internet, un mécanisme de détection d'erreur est mis en œuvre au moins à 3niveaux : au niveau des trames Ethernet, des entêtes IP et des entêtes TCP/UDP. Pourquoi ? Si on veut minimiser le nombre de fois que la détection d'erreur est réalisée, à quel(s) niveau(x) vous la maintiendriez / supprimeriez ?


Du coup je suppose qu'étant donné que des protocoles d'une couche supérieure comme TCP et IP peuvent se reposer sur des protocoles de couche inférieure qui n'assurent pas la détection d'erreurs du coup il convient d'en implémenter une à chaque niveau ?

Sachant que la détection des erreurs au niveau Ethernet se fait sur les données brutes avec la CRC, qu'au niveau de la couche IP le checksum est appliqué uniquement sur l'entête et qu'au niveau de la couche TCP et UDP c'est la totalité de la trame qui est vérifiée, on pourrait donc se contenter de garder le checksum sur la couche 4 du modèle OSI.

J'ai bon ?

Merci !

[Invité]

Salut,

quelle que soit la couche considérée, le mécanisme de détection d'erreurs est destiné à détecter "la très grande majorité" des erreurs mais pas toutes...

Par exemple, le CRC Ethernet ne sait pas détecter certains "burst errors" (notamment lorsque la "bit-distance" entre le 1er et le dernier bit erronés est supérieur à 32). De même, le calcul de l'IP Checksum donnera la même valeur si on modifie l'ordre de certains mots, ou si on insère/enlève des '00' dans certains endroits du paquet.

Donc chaque couche essaie "d'épurer" au maximum ses données, l'objectif étant d'en détecter le plus possible. Parce qu'il est inutile d'envoyer des PDU corrompues à la couche supérieure.

Ceci dit, ces dernières années, la qualité des couches basses s'est énormément améliorée et la détection d'erreurs intrinsèque aux couches PHY/MAC/LLC est de moins en moins sollicitée. Mais comme expliqué plus haut, il y a des "incidents" qui passent au travers des mailles du filet, cf à ce sujet

http://dl.acm.org/citation.cfm?id=347561&bnc=1

"Traces of Internet packets from the past two years show that between 1 packet in 1,100 and 1 packet in 32,000 fails the TCP checksum, even on links where link-level CRCs should catch all but 1 in 4 billion errors. For certain situations, the rate of checksum failures can be even higher: in one hour-long test we observed a checksum failure of 1 packet in 400. We investigate why so many errors are observed, when link-level CRCs should catch nearly all of them.We have collected nearly 500,000 packets which failed the TCP or UDP or IP checksum. This dataset shows the Internet has a wide variety of error sources which can not be detected by link-level checks."

Quant à la question sur le maintien/suppression de détection d'erreurs, je pense que dans un monde idéal on pourrait laisser cette tâche aux couches les plus hautes. Mais là encore, basé sur le fait qu'il y a une probabilité non nulle pour une appli de recevoir un segment TCP avec un checksum correct mais un contenu corrompu, je n'ose imaginer les effets de bord si la détection d'erreur n'est pas revisitée (en gros, je ne prends plus l'avion, je n'utilise plus ma carte bancaire, etc).

Steph

[TiteFlora]

Merci beaucoup pour ta réponse très intéressante !

[gangsoleil]

Pour polemiquer, on pourrait se demander ce qu'est une erreur.

Par exemple en TCP, une absence de paquet est une erreur, de meme que des paquets arrivant dans le desordre. En revanche, en UDP, ce n'en sont pas (du point de vue strictement protocolaire).


Et aussi, on pourrait parler des codes correcteurs d'erreur, et des differentes utilisations : on n'a pas les memes pertes/degradations sur un reseau filaire ou sur un reseau aerien par exemple, et donc les solutions a mettre en oeuvre ne sont pas les memes.

[Invité]

gangsoleil,

non, non, ça n'est pas polémique du tout, au contraire

Le post initial de TiteFlora était orienté "error detection", ma réponse s'est donc limitée à ce sujet...

Ton intervention est plus relative (enfin je pense) aux mécanismes de "error recovery". Deux choses différentes mais qui sont bien les deux facettes du même problème de base, à savoir transmettre avec intégrité des data depuis un point vers un autre.

Steph