Résumé

  • RFC 935 répondait aux propositions de liaison fiable de RFC 914 et RFC 916 pour les lignes asynchrones lentes. Robinson passa en revue le cadrage par caractères, le cadrage par bits et le comptage de caractères, puis proposa un cadrage transparent par caractères, un CRC de 16 bits et les commandes LAPB.
  • Le RATP épargnait deux caractères de liaison sur une petite trame Thinwire. Robinson demandait si ce gain pouvait payer une nouvelle procédure alors que les méthodes connues apportaient déjà reprise après erreur, plusieurs trames en vol et matériel réutilisable.

Le prix caché de la petite colonne

Le projet Thinwire de RFC 914 et le RATP de RFC 916 répondaient à une difficulté réelle : faire travailler un ordinateur personnel avec une passerelle par une liaison série lente. Quand un caractère met du temps à passer, supprimer du contrôle semble une victoire. Robinson ne contestait pas cette contrainte. Il contestait la manière de désigner le vainqueur.

Sa propre arithmétique est précise. Le point de départ est une trame Thinwire II de 13 octets, avant l'ajout de la liaison. Huit caractères de contrôle valent 8/13, soit 61 % de cette trame, et portent le total transmis à 21; les six de RATP valent 6/13, soit 46 %, pour un total de 19. À environ 120 caractères transmis par seconde, les fractions utiles à Thinwire sont 120 × 13/21 ≈ 74 et 120 × 13/19 ≈ 82. Un seul des 13 caractères Thinwire est un caractère tapé par l'utilisateur dans cet exemple, d'où les estimations de Robinson d'environ 5,6 et 6,3 par seconde.

Il s'agit d'un calcul pour de très petites trames, pas d'une mesure générale du réseau. Le gain existe; sa taille exige qu'on présente aussi le coût de l'exception.

Les méthodes rivales ne récupèrent pas une liaison abîmée de la même façon. Le cadrage par caractères place des délimiteurs et échappe ceux qui apparaissent dans les données. Le cadrage par bits emploie un motif de drapeau et insère des bits pour qu'il ne surgisse pas dans la charge; son usage ordinaire suppose une transmission synchrone. DDCMP indique la longueur dans l'en-tête. Cela évite les échappements, mais une longueur corrompue fait perdre au récepteur sa position : il faut protéger l'en-tête et retrouver le début suivant.

Robinson refuse donc de traiter le coût des échappements comme une constante et celui de la resynchronisation comme zéro.

Le CRC protège aussi la commande

Les vérifications simples proposées dans les nouveaux textes, somme ou OU exclusif, plaisaient aux processeurs modestes. Robinson défendait un CRC de 16 bits. Une erreur dans le champ de commande d'une liaison peut provoquer perte ou duplication de trames, avant que TCP ne récupère lentement le transfert. Il expliquait aussi qu'un CRC et les contrôles de TCP/IP ne laissent pas passer les mêmes familles d'erreurs; empiler deux contrôles additifs conserve des angles morts communs.

Son estimation du calcul logiciel était de cinq à six instructions par caractère avec une table de recherche, à une cadence maximale d'environ 120 caractères par seconde. Du matériel de la passerelle pouvait prendre une partie du travail.

Sa recette combinait DLE STX … DLE ETX CRC CRC pour la trame et LAPB pour la numérotation et les acquittements. Les acquittements pouvaient voyager avec le trafic en sens inverse; sept trames pouvaient rester en vol dans chaque direction. L'adresse d'une procédure multipoint paraissait superflue sur ce fil point à point. Il la gardait pourtant, afin de rester dans le monde des réalisations existantes. Huit caractères de contrôle par trame étaient le prix déclaré de ce choix. Retirer l'adresse ou emprunter le comptage de RATP ferait économiser un peu, au prix d'une nouvelle variante à installer partout.

Les fabricants de circuits avaient une raison de prendre en charge des procédures répandues. Robinson plaça ce fait industriel au milieu de sa démonstration technique : un avantage de deux caractères doit se confronter aux logiciels, aux puces et aux diagnostics qu'il faudra produire. Son post-scriptum évoque une parenté avec une liaison Telenet conçue vers 1976 et prédit une montée prochaine de X.25/X.32. C'est sa prévision de 1985. Le texte ne fournit ni essai comparatif d'un déploiement nommé ni verdict ultérieur sur l'adoption.

Sa question la plus utile reste celle de la ligne en panne : qui retrouve la prochaine trame lorsque le compte de longueur a été faussé ?

Sources