Resumen

  • RFC 935 discutió las propuestas de RFC 914 y RFC 916 para comunicarse con fiabilidad por una línea asíncrona lenta. Robinson comparó los marcos delimitados por caracteres, por bits y por longitud, y recomendó delimitación transparente, CRC de 16 bits y controles LAPB.
  • Los 13 bytes de Thinwire se cuentan antes de añadir el enlace: ocho caracteres extra producen 21 enviados, frente a 19 con los seis de RATP. Con unos 120 caracteres transmitidos por segundo, 120 × 13/21 y 120 × 13/19 dan aproximadamente 74 y 82 caracteres Thinwire por segundo. La diferencia era pequeña comparada con la tarea de implementar y sostener una excepción.

La columna que no cabía en la tabla

El ordenador personal de mediados de los ochenta no tenía ancho de banda para desperdiciar. Thinwire, descrito en RFC 914, y el protocolo RATP de RFC 916 respondían a esa realidad. Robinson no negó el problema. Hizo algo más molesto para un inventor: aceptó sus números y preguntó qué otras cosas pagaba la red.

La cuenta de RFC 935 para una trama corta de Thinwire II es concreta. Los 13 bytes pertenecen a la trama Thinwire antes del enlace. Ocho caracteres añadidos son 8/13, el 61 % de esa trama, y suman 21 caracteres transmitidos; seis son 6/13, el 46 %, y suman 19. Si la línea transporta unos 120 caracteres por segundo, las cuentas 120 × 13/21 y 120 × 13/19 entregan cerca de 74 y 82 caracteres Thinwire. Solo uno de cada 13 es dato tecleado por el usuario en este ejemplo; por eso Robinson estima alrededor de 5,6 y 6,3 caracteres tecleados por segundo.

Son estimaciones para ese patrón de tramas; convertirlas en una medida de Internet sería vender como observación lo que era un supuesto de diseño. La diferencia existe y cabe en menos de un carácter útil por segundo.

¿Por qué no quedarse con el número menor? Porque los protocolos no vuelven a encontrar el comienzo de una trama dañada de la misma manera. El encuadre por caracteres utiliza marcas de apertura y cierre y escapa las marcas que aparezcan dentro de los datos. El encuadre por bits emplea una secuencia de bandera y rellena bits; normalmente requiere un enlace síncrono. DDCMP escribe una longitud en la cabecera. Si esa longitud llega corrupta, el receptor necesita detectar el daño y localizar otra cabecera. Robinson observó que la supuesta ausencia de caracteres de escape en el contador ocultaba ese coste de resincronización.

La línea ruidosa se niega a respetar una hoja de cálculo hecha solo con tramas sanas.

Un acuse de recibo también puede salir mal

Las propuestas nuevas empleaban comprobaciones simples por suma o XOR, baratas para el procesador. RFC 935 defendió un CRC de 16 bits en el enlace. El campo de control decide numeración y reconocimientos: un error allí puede provocar pérdida o duplicación antes de que TCP corrija lentamente los efectos. Robinson sostuvo que el CRC y las sumas de TCP/IP detectan patrones distintos; repetir controles aditivos deja errores que pueden cruzar ambos. Calculó de cinco a seis instrucciones por carácter para un CRC en software con tabla de consulta, ante unos 120 caracteres por segundo. Un circuito de la pasarela podía asumir esa tarea.

El diseño recomendado juntaba un marco transparente DLE STX … DLE ETX CRC CRC con el control LAPB. Permitía llevar acuses sobre el tráfico de vuelta y mantener hasta siete tramas pendientes en cada dirección. En una línea punto a punto sobraba el campo de dirección que trae el estándar multipunto. Robinson prefirió conservarlo para compartir la práctica y el hardware existentes. El precio era la sobrecarga declarada de ocho caracteres. Podía quitar la dirección o tomar el contador de RATP y ahorrar algo más; eso obligaría a todos a implementar una variante particular.

El texto termina con dos observaciones de época. Su combinación se parecía, según Robinson, a una especificación de enlace de Telenet de hacia 1976, y él preveía que X.25/X.32 dominaría pronto el acceso. La predicción pertenece al autor de 1985. El artículo no necesita inventar una historia de adopción posterior para que su argumento muerda: un fabricante de chips tiene incentivo para respaldar procedimientos ampliamente usados; una regla privada tiene que comprar esa ayuda con cada byte que presume ahorrar.

Fuentes