Mon blog

Le groupe de travail de l'IRTF DTN (Delay-Tolerant Networking) continue son travail de création de protocoles de communication standards capables de fonctionner dans l'espace lointain, ou dans des milieux similaires. Après le protocole Bundle du RFC 5050, qui décrit un protocole de niveau Application pour le transfert de données, voici le protocole Licklider, de niveau Transport.

LTP (Licklider Transmission Protocol), ainsi nommé en l'honneur du pionnier de l'Internet, est donc sur le même créneau que des protocoles comme TCP, chargé de fournir un service de transport aux applications (ce que le RFC 5050 nomme un convergence layer). Il est normalisé dans le RFC 5326 et des extensions sont prévues par le RFC 5327. Notre RFC 5325, lui, expose les motivations derrière ce protocole.

Les milieux où LTP sera utilisé sont caractérisés (sections 1 et 2 du RFC) par des délais de transmission très longs (une heure pour joindre Jupiter depuis la Terre), une fiabilité faible des transmissions et le fait que celles-ci ne soient possibles que par intervalles, lorsque les deux astres ne sont pas masqués par un troisième. Le principal « client » de LTP sera donc la NASA. (Le problème général des communications spatiales avait été décrit dans le RFC 4838.)

La section 2.1 fait également remarquer que les limites de ces communications spatiales ne sont pas uniquement physiques (vitesse de la lumière) mais également économiques. Les antennes capables de communiquer avec les vaisseaux spatiaux, comme celles du DSN, sont rares et leur location coûte cher.

La même section 2.1 explique pourquoi ces caractéristiques condamnent les protocoles réseaux traditionnels : on ne peut pas attendre un accusé de réception avant de continuer à transmettre, vue la longueur du RTT ; on ne peut pas négocier des paramètres de transmission avec l'autre partie, la fenêtre de transmission est souvent trop courte pour cela ; l'évaluation du RTT par des mesures est en général impossible. LTP sera donc un protocole unidirectionnel, l'interactivité n'étant en général pas possible dans l'espace.

La section 2.2 détaille les limites de TCP ou SCTP pour ce problème. Avec une équation d'état comme celle du RFC 5348, une transmission de la Terre à Mars à seulement dix kilobits par seconde nécessiterait un taux de perte des données inférieur à 10^(-5), ce qui est irréaliste dans l'espace.

La section 3 explique les grandes lignes du protocole (il faut lire le RFC 5326 pour avoir la vraie norme). LTP transmet des blocs de données qui sont composés de deux parties, la « rouge » (ces données doivent faire l'objet d'un accusé de réception, sinon elles sont retransmises) et la « verte » (jamais retransmises). Chacune des deux parties peut être vide. Ainsi, une application de transfert de fichiers mettra typiquement toutes les données dans la partie rouge et rien dans la verte. LTP permet donc à l'application de choisir la sémantique de TCP ou bien d'UDP et ceci pour chaque bloc de données.

Vue la nature unidirectionnelle de LTP, il n'y a pas de négociation avec l'autre partie : la transmission des données se fait « en aveugle », LTP stockant les parties rouges pour pouvoir les retransmettre s'il n'y a pas d'accusé de réception. Seule la couche Liaison peut donner des indications à LTP (la section 3.1.1 détaille ces indications).

Justement, quand retransmettre ? Comme LTP ne peut pas mesurer le RTT, il doit dépendre de calculs réalisés avant la transmission (la section 3.1.3 détaille ces calculs), en se basant sur la vitesse de la lumière et les délais connus, par exemple dus à la disponibilité des antennes. Cela permet d'évaluer à partir de quand une non-réponse est le signe de données perdues. Il faudra alors retransmettre (section 3.2).