1. Introduction

1. Introduction

Ce document décrit une méthode de compression d'en-têtes IP adaptée aux liaisons série à faible débit.

La compression d'en-têtes est importante pour les liaisons à faible et moyen débit, car elle permet de :

• Maintenir l'unité de transmission maximale (Maximum Transmission Unit, MTU) aussi petite que possible sur la liaison

  La MTU est la taille maximale d'un paquet pouvant être transmis sur une liaison sans fragmentation. Une MTU réduite est importante pour les liaisons lentes afin d'éviter que le trafic interactif sensible à la latence ne soit retardé par de gros paquets en transit. Par exemple, pour limiter le délai de mise en file d'attente à 200 ms, il faut utiliser une MTU inférieure à 240 octets sur une liaison à 9600 bps. Cependant, sur ce type de liaison, IPv6 exige une MTU minimale de 1280 octets, et IPv4 n'impose pas de MTU réduite. L'utilisation avec des liaisons à petite MTU nécessite une fragmentation sur les liaisons lentes. Lorsqu'un paquet est fragmenté sur une liaison lente, des en-têtes supplémentaires doivent être envoyés : le nombre d'octets utilisés dans les en-têtes s'additionne pour tous les fragments et dépasse la taille de l'en-tête original. La compression d'en-têtes peut réduire considérablement le nombre d'octets de ces en-têtes supplémentaires, surtout lorsque le paquet original est petit, et donc réduire le temps d'envoi des paquets, augmentant ainsi la MTU maximale utilisable sur les liaisons lentes.

• Permettre l'utilisation de petits paquets pour le trafic à faible débit sensible à la latence

  Pour ce type d'applications, comme la voix, si les paquets sont grands, le temps de remplissage des paquets avec des données est significatif. Pour obtenir un faible délai de bout en bout, les petits paquets sont préférables. Sans compression d'en-têtes, le plus petit en-tête IPv6/UDP possible (48 octets) consomme 19,2 kbit/s à un débit de 50 paquets/seconde. 50 paquets/seconde équivaut à 20 ms d'échantillons vocaux par paquet. L'en-tête IPv4/UDP consomme 11,2 kbit/s à 50 paquets/seconde. Les en-têtes de tunnel ou de routage, par exemple pour la prise en charge de la mobilité, augmenteraient la consommation de bande passante des en-têtes de 10 à 20 kbit/s. Cela doit être comparé à la bande passante requise pour les échantillons sonores réels, par exemple 13 kbit/s avec le codage GSM. La compression d'en-têtes peut réduire considérablement la bande passante requise pour les en-têtes, par exemple à environ 1,7 kbit/s dans cet exemple. Cela permet une transmission vocale de meilleure qualité sur des modems à 14,4 et 28,8 kbit/s.

• Réduire la surcharge des en-têtes

  Aujourd'hui, la taille courante des segments TCP pour les transferts en masse sur les liaisons à moyen débit est de 512 octets. Lorsqu'un segment TCP est encapsulé dans un tunnel, par exemple en raison de l'utilisation de Mobile IP, l'en-tête IPv6/IPv6/TCP représente 100 octets. La compression d'en-têtes réduit la surcharge des en-têtes IPv6/TCP de 19,5 % à moins de 1 %, et la surcharge des en-têtes IPv4/TCP encapsulés de 11,7 % à moins de 1 %. Pour des débits allant jusqu'à quelques Mbit/s, c'est un gain significatif.

  La spécification IPv6 prescrit la découverte de la MTU de chemin, de sorte qu'avec IPv6, les transferts TCP en masse devraient utiliser des segments supérieurs à 512 octets lorsque c'est possible. Néanmoins, avec des segments de 1400 octets (l'encapsulation Ethernet RFC 894 permet une charge utile de 1500 octets, dont 100 octets pour les en-têtes IP), la compression d'en-têtes réduit la surcharge des en-têtes IPv6 de 7,1 % à 0,4 %.

• Réduire le taux de perte de paquets sur les liaisons avec pertes

  Comme moins de bits sont envoyés par paquet, pour un taux d'erreur binaire donné, le taux de perte de paquets sera plus faible. Cela conduit à un débit TCP plus élevé, car la fenêtre d'envoi peut s'ouvrir davantage entre les pertes, et à moins de paquets perdus pour UDP.

Les mécanismes décrits ici sont destinés à être utilisés sur des liaisons point à point. Cependant, des dispositions ont été prises pour permettre des extensions aux liaisons multi-accès et à la multidiffusion.

Les en-têtes pouvant être compressés comprennent les en-têtes de base TCP, UDP, IPv4 et IPv6 ainsi que les en-têtes d'extension. Pour les paquets TCP, le mécanisme de Van Jacobson [RFC-1144] est utilisé pour la récupération après perte. Deux mécanismes supplémentaires sont également décrits, qui améliorent l'efficacité de la compression d'en-têtes VJ sur les liaisons avec pertes. Pour les paquets non-TCP, le démarrage lent de compression et les rafraîchissements périodiques d'en-têtes permettent de minimiser la période de rejet de paquets après la perte d'un en-tête qui modifie le contexte. Des points d'extension sont prévus pour ajouter des schémas de compression d'en-têtes au-dessus d'UDP, comme la compression des en-têtes RTP.

La compression d'en-têtes repose sur le fait que de nombreux champs dans les paquets consécutifs appartenant au même flux de paquets sont constants ou changent rarement. Les champs qui ne changent pas entre les paquets n'ont pas besoin d'être transmis du tout. Les champs qui changent fréquemment, avec des valeurs petites et/ou prévisibles, comme les numéros de séquence TCP, peuvent être encodés de manière différentielle, de sorte que le nombre de bits requis pour ces champs soit considérablement réduit. Seuls les champs qui changent fréquemment et de manière aléatoire, comme les sommes de contrôle ou les données d'authentification, doivent être transmis dans chaque en-tête.

Le principe général de la compression d'en-têtes est d'envoyer occasionnellement des paquets avec des en-têtes complets ; les en-têtes compressés suivants font référence au contexte établi par l'en-tête complet et peuvent contenir des modifications incrémentielles du contexte.

Ce schéma de compression d'en-têtes n'exige pas que tous les paquets d'un même flux traversent la liaison compressée. Cependant, pour les flux TCP, les différences entre les en-têtes successifs peuvent devenir plus irrégulières et le taux de compression peut diminuer. Il n'est pas non plus nécessaire que les paquets de données TCP correspondants et les paquets d'accusé de réception traversent la liaison dans le sens opposé.

Ce schéma de compression d'en-têtes est utile sur les liaisons de premier ou dernier saut ainsi que sur les liaisons au milieu du réseau. Lorsque de nombreux flux de paquets (plusieurs centaines) traversent la liaison, un phénomène appelé gigue de CID peut se produire, dans lequel les en-têtes peuvent rarement correspondre à un contexte existant et doivent être envoyés sous forme non compressée ou avec en-tête complet. Les implémentations doivent utiliser des techniques telles que l'hystérésis pour s'assurer que les flux de paquets offrant le taux de compression le plus élevé conservent leur contexte. Cette technique est plus susceptible d'être nécessaire au milieu du réseau.