Resumen

  • Los tráileres se elegían para paquetes con determinados atributos de tamaño. Por eso, una incompatibilidad podía permitir parte del tráfico y hacer desaparecer otra, sin que una prueba breve revelara la causa.
  • La técnica movía las cabeceras variables detrás de los datos dentro del mismo paquete de enlace, para facilitar el uso de páginas de memoria en recepción. Después se reconstruía el orden habitual.
  • La capacidad debía comprobarse entre los dos participantes del enlace. RFC 1122 exigió desactivación por defecto cuando no hubiera negociación dinámica por destino y limitó las respuestas ARP adicionales para evitar bucles.

El éxito que no había probado la excepción

Una conversación corta funciona. Más tarde, otro intercambio pierde paquetes. La tentación es tratar el primer éxito como un certificado de que las dos máquinas son compatibles y buscar la avería en otra parte. Pero ese razonamiento falla si el sistema escoge una representación distinta solo para determinadas clases de paquete.

El RFC 1122, de octubre de 1989, describió precisamente este peligro para las encapsulaciones con tráiler. Su selección dependía de ciertos atributos de tamaño; en la discusión del documento, afectaba normalmente a una fracción pequeña. Un desacuerdo podía dejar pasar paquetes ordinarios y convertir otros en pérdidas silenciosas.

No era una afirmación de que todos los paquetes grandes fallaran. Tampoco convierte cualquier pérdida relacionada con el tamaño en prueba de este mecanismo. La distinción decisiva era el formato elegido y la capacidad del receptor para interpretarlo. La comunicación que sí llegaba podía no haber ejercitado nunca esa excepción.

Para entender por qué existía la excepción hay que dejar momentáneamente el cable y mirar la memoria del ordenador que recibía.

El coste estaba después de la llegada

El RFC 893, publicado en abril de 1984, documentó una forma de enlace usada entonces por 4.2BSD UNIX y otros sistemas. Era una explicación informativa, no un protocolo oficial de ARPA Internet. Su motivación era reducir las copias de memoria a memoria en el receptor.

Mover datos desde un dispositivo y hacerlos accesibles a una aplicación podía implicar más de una copia. Una parte del coste aparecía entre espacios del sistema operativo y del usuario. En arquitecturas de memoria virtual adecuadas, cambiar la correspondencia de páginas ofrecía una alternativa a volver a trasladar todos los bytes.

Esa alternativa necesitaba una disposición apropiada. El razonamiento del RFC presupone normalmente datos alineados con el inicio de una página y una longitud múltiplo de ella, o completada hasta el límite, en sistemas cuya protección trabaja por páginas. Otras arquitecturas podían cambiar las condiciones.

Las cabeceras variables dificultaban cumplirlas. Aunque el prefijo del enlace fuera estable, la longitud de las cabeceras superiores podía desplazar el comienzo de los datos. Recolocarlos mediante una copia para que encajaran en la página anulaba precisamente una parte del ahorro deseado.

La solución consistía en que el emisor trasladara esas cabeceras detrás del bloque de datos. Así ofrecía al receptor una posición más favorable para aprovechar su gestión de memoria. No garantizaba que cada receptor pudiera evitar todas las copias ni que el enlace transportara bits a mayor velocidad.

Un cambio de orden que no cambiaba TCP

El tráiler no era otro paquete ni una cola añadida por la aplicación a un archivo. Pertenecía al mismo paquete de enlace. La información de tipo de enlace permitía reconocer la forma especial y localizar su parte final. Allí figuraban el tipo de protocolo original, información de longitud y las cabeceras desplazadas.

El receptor retiraba los elementos de la encapsulación y devolvía las cabeceras a su relación habitual con los datos antes de entregarlos al procesamiento superior. Por tanto, el orden físico de llegada no redefinía la secuencia de TCP ni el significado de los bytes para la aplicación.

El RFC 894, también de abril de 1984, proporciona el contraste: en la forma ordinaria de IP sobre Ethernet, la cabecera IP precede inmediatamente a sus datos. Que dos formas transporten IP no permite leer una con el procedimiento de la otra sin reconocer la diferencia.

Tampoco se ampliaba el tamaño permitido en Ethernet. La errata técnica 570, con estado Verified, corrige el uso de «mínimo» por «máximo» para los 1500 bytes mencionados en RFC 894. El relleno para alcanzar el mínimo de datos de Ethernet queda fuera de la longitud total IP. Reordenar cabeceras, completar un bloque y aumentar capacidad son operaciones distintas.

El ejemplo VAX de 512 bytes de datos del RFC 893 debe permanecer en su contexto. No fija el tamaño de página de los equipos actuales ni convierte las cabeceras IP y TCP en estructuras de longitud siempre idéntica. La historia no necesita inventar una medida moderna de rendimiento para explicar el motivo de la técnica.

Lo que se ahorraba y lo que se aplazaba

Los autores no presentaban una ganancia gratuita. El receptor tenía que poder y querer participar; el coste de alinear no debía superar lo ahorrado; la parte final debía ser pequeña frente a los datos; y las copias evitadas tenían que justificar la complejidad adicional.

Había además una consecuencia temporal. Si la cabecera llegaba al final, era necesario conservar el paquete completo antes de procesar esa información. Un receptor que aprovechara la cabecera temprana para rechazar tráfico o escoger recursos podía perder una ventaja.

RFC 893 reconocía como válida la crítica al retraso en identificar el tipo. Su respuesta describía un caso DMA en el que el paquete entero ya se recibía antes de iniciar ese procesamiento. Esa observación limita el coste para aquel caso; no demuestra que toda arquitectura DMA actual se comporte igual.

El cálculo pertenecía, en buena medida, a la máquina beneficiaria. El emisor podía facilitar una disposición, pero no saber por simple analogía si el receptor ahorraría trabajo. Los beneficios comunicados por los autores sobre su implementación tampoco equivalen a una prueba independiente realizada hoy.

No todos los vecinos tenían que actualizarse

RFC 894 permitía la forma alternativa entre sistemas que consintieran en la misma Ethernet. Ningún host estaba obligado a implementarla. Para enviarla era preciso tener conocimiento positivo de que el destinatario podía interpretarla.

Las descripciones de 1984 exponían una limitación práctica de la 4.2BSD de entonces: la elección se hacía por interfaz al arrancar. En el medio compartido hacía falta cooperación uniforme o no enviar tráileres por aquella interfaz. La negociación por vecino mediante ARP aparecía como una mejora prevista o considerada.

En 1989, RFC 1122 especificó que ambos participantes del enlace, fueran hosts o pasarelas, debían haber demostrado soporte. Si no existía negociación dinámica por destino, la configuración debía desactivar el uso por defecto. El criterio no obligaba a todos a adoptar la optimización; impedía tratar como compatible a quien no se había comprobado.

Los documentos permiten comparar esas reglas, no fechar la primera implementación de todos los proveedores ni afirmar que todas las versiones de BSD conservaran el mismo comportamiento. El cambio verificable es el paso de una suposición amplia a una capacidad acotada por interlocutor.

Resolver una dirección no resolvía la compatibilidad

El RFC 826 define ARP en términos de correspondencia entre una dirección de protocolo y una dirección de hardware en el enlace seleccionado. El encaminamiento determina antes el siguiente salto. El resultado no certifica que el vecino lea cualquier encapsulación opcional.

La negociación descrita en RFC 1122 conservaba el intercambio ARP normal para IP. Quien quisiera recibir tráileres añadía una respuesta Trailer ARP: misma estructura general de respuesta, pero con el tipo de protocolo correspondiente dentro de ARP. No sustituía la respuesta IP básica ni requería una petición Trailer ARP previa.

Conviene separar los campos. El tipo Ethernet exterior que transporta ARP no es el campo de protocolo del contenido ARP; este tampoco es el código de operación que distingue solicitud de respuesta. Mezclarlos convierte una señal de capacidad en una secuencia de paquetes que el documento no especifica.

Los dos papeles podían anunciar recepción. El receptor de una petición ordinaria podía añadir la respuesta especial junto a la respuesta IP. El solicitante original podía anunciar su propia capacidad al recibir la respuesta IP que correspondía a su petición. Cada anuncio hablaba de quien lo enviaba.

Un equipo configurado para usar la técnica podía registrar la capacidad del vecino, por ejemplo mediante una marca en su entrada ARP. Ese dato no era una autenticación criptográfica, una promesa de rendimiento ni una confirmación de que una aplicación había recibido datos.

El alcance seguía siendo el enlace. El RFC 1009, de junio de 1987, explica que una pasarela puede responder mediante proxy ARP con su propia dirección de interfaz para un destino externo al que puede encaminar. Identificar a ese vecino no permite atribuir su capacidad a todos los saltos ni al extremo final de la comunicación.

Una pregunta pendiente detenía las respuestas

La respuesta adicional necesitaba una condición para terminar. Un host de comportamiento incorrecto podía contestar a una respuesta Trailer ARP con una respuesta IP ARP normal. Si el otro extremo respondía a cada respuesta IP con otro anuncio especial, los dos mensajes podían alimentarse mutuamente.

RFC 1122 restringía el anuncio emitido tras recibir una respuesta IP al caso en que esta resolvía una petición aún pendiente: la dirección de hardware seguía sin conocerse antes de procesarla. Añadir el anuncio a una respuesta normal a una petición recibida era un caso distinto y permitido.

La regla dependía de la historia local del intercambio. No inventaba un temporizador o un número de reintentos para cortar la cadena. Preguntaba si todavía existía un trabajo que aquella respuesta acababa de resolver.

Así se cerraban dos excesos de inferencia. Una respuesta ARP no probaba por sí sola la capacidad de leer tráileres; una respuesta IP cualquiera tampoco autorizaba a continuar anunciando esa capacidad. Tanto el formato especial como su conversación de preparación necesitaban límites explícitos.