Mécanismes de fiabilisation pro-actifs - ISAE

44 Chapitre 3. Modélisation d'un protocole de compression d'en-têtespossède le mérite de pouvoir détecter et corriger rapidement un contexte non reçu, cequi est plus délicat dès que la compression est activée. Nous pouvons comparer cetteproblématique à celle du codage vidéo où, comme dans le cas de H.264 par exemple,la perte de certaines frames peut être dommageable pour les frames suivantes.Dans le domaine de la compression protocolaire, il n'existe pas à ce jour de mécanismesde compression permettant de favoriser un en-tête plus important qu'unautre (sauf dans le cas d'eCRTP dans l'absolu). Par ailleurs, une idée reçue sur lacompression protocolaire, est d'utiliser les mécanismes de voie de retour (modes O etU de ROHC par exemple) dès lors qu'ils sont disponibles. Si ces modes permettenteectivement une compression plus ecace, nous étudierons alors les conséquencesd'un tel mécanisme sur la métrique du temps moyen de déconnexion, et nous verronsl'inuence certaine du champ d'application sur la pertinence d'un mécanisme deretour.3.2 La couche protocolaire et le canal de Gilbert-ElliottDans le modèle d'Interconnexion de Systèmes Ouverts (OSI) classique, le protocolede compression d'en-têtes est situé entre la couche liaison et la couche réseau ouplus généralement, en remplacement de la couche réseau et de la couche transport(selon les protocoles compressés). D'une manière schématique, comme présenté sur laFigure 3.1, la couche de compression protocolaire (HC) reçoit directement des tramesde la couche liaison, et elle transmet directement à la couche applicative les donnéesdépourvues des en-têtes qu'elle aura décodé.Comme nous l'avons évoqué rapidement dans le chapitre précédent, dans tous lesmécanismes de liaison récents (Ethernet,...), lorsque que le CRC échoue, l'ensemblede la trame est généralement éliminé. Tout ce qui est transmis à la couche adjacentehaute est donc considéré comme valide. Du point de vue de cette couche, et doncdans notre cas, du protocole de compression, le canal de la couche liaison peut êtrevu comme un canal à eacements, où tout ce qui est reçu est correct et auquel estassocié un taux de perte de trames : Frame Error Rate (F ER). Ces pertes aectentalors de manière uniforme, l'en-tête de la compression et les données transportées.Nous avons également vu que suite à ces pertes reçues, de nouvelles pertes peuventapparaître au niveau de la décompression, celles-ci étant imputables aux mécanismesde compression. Nous avons vu qu'ainsi, lorsque la décompression échoue, l'ensembledu paquet est inutilisable n'est donc pas transmis à la couche applicative.Nous avons donc considéré que le protocole de compression d'en-têtes reçoit destrames d'une couche de liaison se présentant comme un canal à eacements avec untaux de perte F ER, et transmet à la couche application des paquets valides avec untaux de perte paquets (PER), et par dénition P ER F ER. Bien entendu, dans cetaux P ER, le taux F ER n'est pas imputable à la couche HC mais à la couche liaison.La donnée qui va principalement nous intéresser est donc le taux de pertes imputable àla compression rapporté au taux de perte en entrée. Nous étudierons également deuxautres métriques : l'ecacité de cette compression, et le temps moyen de déconnexion,