Resumen

  • RFC 3208 eliminó los acuses positivos por receptor y reforzó los NAK salto a salto; los elementos de red guardaban las interfaces desde las que se había observado una pérdida.
  • El NAK Confirmation acreditaba que una petición había sido atendida en un punto del camino inverso. No acreditaba la emisión de RDATA, su llegada ni la recuperación del grupo desconocido.

La escala cambió el significado de un recibo. En una conversación entre dos extremos, un ACK puede cerrar una espera. En una distribución multicast, pedir una respuesta positiva a miles de receptores después de cada paquete podía generar más presión que los propios datos.

Pragmatic General Multicast escogió la evidencia negativa. La fuente difundía Original Data, ODATA, con números de secuencia. Cada receptor observaba su propia secuencia. Cuando detectaba un hueco, pedía reparación mediante un negative acknowledgement selectivo, el NAK.

La ausencia de ACK no fue un simple ahorro de cabeceras. PGM carecía de una noción de pertenencia al grupo. Los receptores podían entrar o salir sin que la fuente lo supiera. El protocolo no servía a aplicaciones que necesitaran entrega reconocida a una lista conocida ni orden total entre varias fuentes.

La garantía quedó formulada desde el receptor. Dentro de la ventana de transmisión aplicable, un receptor obtenía los paquetes originales y reparados o podía detectar una pérdida irrecuperable. La fuente no recibía por ello una sentencia global sobre una población que no enumeraba.

Cuando aparecía un hueco, el receptor enviaba el NAK en unicast al último elemento PGM de la rama por la que había llegado el tráfico. Repetía la petición hasta escuchar un NAK Confirmation, NCF, difundido por ese elemento en la interfaz correspondiente.

El elemento de red reenviaba el NAK al siguiente vecino PGM aguas arriba y también lo repetía hasta recibir su NCF. Así continuaba la solicitud por el camino inverso hasta la fuente. Cada confirmación pertenecía a un salto. Los routers no propagaban el NCF como una constancia de extremo a extremo.

El contenido probatorio era estrecho: la petición negativa fue reconocida aquí. El NCF no contenía el paquete perdido. No afirmaba que la fuente aún lo conservara, que un reparador local lo hubiera enviado, que la reparación cruzara cada rama necesaria o que el receptor pudiera incorporarla.

Después del NAK, el router creaba estado de reparación. La clave combinaba la sesión y la secuencia perdida; la lista de interfaces registraba desde qué ramas había llegado evidencia de pérdida. Una vez confirmado el NAK, el paquete de petición podía desecharse. La obligación posterior residía en el estado, no en guardar el NAK ni en el NCF.

Cuando aparecía Repair Data, RDATA, el router lo reenviaba sólo por las interfaces registradas. La reparación quedaba confinada al subárbol que había pedido ayuda, en vez de volver a inundar el grupo. Sin estado coincidente, el comportamiento predeterminado era descartar RDATA.

Esa regla separaba la existencia del paquete de su permiso de paso. Una fuente podía emitir una reparación correcta y, aun así, una rama no la recibiría si la petición inversa no había instalado el estado necesario. Confirmar una petición en un salto no demostraba que el camino de regreso estuviera completo.

Los Source Path Messages, SPM, construían la dirección aguas arriba. La fuente los intercalaba con los datos y cada elemento PGM actualizaba la dirección de camino. Los receptores aprendían cuál era su vecino hacia la fuente; los routers podían reenviar el NAK siguiendo la inversa de la distribución original.

Los SPM también anunciaban los bordes de la ventana de transmisión. El borde trasero señalaba el dato más antiguo todavía disponible para reparación. Si el receptor descubría el hueco después de que la ventana lo hubiera abandonado, otra petición no podía recrear una copia inexistente. El resultado válido podía ser detectar la pérdida sin recuperarla.

Como los NAK eran el único disparador de reparación, PGM intentó hacerlos resistentes. Los SPM provocaban nuevas comprobaciones incluso cuando no circulaba ODATA reciente. El receptor mantenía temporizadores distintos para esperar la confirmación y para esperar RDATA. Un NCF sin reparación no necesariamente terminaba el ciclo.

La misma pérdida podía afectar a muchos miembros. Para evitar una implosión de NAK, cada receptor aguardaba un intervalo aleatorio. Si durante esa espera escuchaba un NAK o NCF coincidente, suprimía su propio envío y actuaba como si la solicitud ajena también representara su hueco.

Los routers eliminaban duplicados cuando ya existía estado de reparación. Podían añadir la nueva interfaz a la lista sin reenviar otra copia aguas arriba. En el caso habitual, una fuente veía un solo NAK aunque numerosos receptores hubieran observado la pérdida.

La compresión era precisamente el logro, pero borraba cantidades. El NAK que llegaba a la fuente no decía cuántos receptores habían callado por supresión. El NCF que tranquilizaba una rama no identificaba a cada miembro. Una interfaz en el estado de reparación no revelaba cuántos hosts había detrás ni cuáles seguían presentes.

La fuente original tampoco tenía que proporcionar físicamente RDATA. Un Designated Local Repairer podía guardar paquetes y responder. La reparación mantenía el Transport Session Identifier original para ocupar la secuencia correcta. La continuidad de la sesión no era una afirmación de que la fuente inicial hubiera emitido esos bytes.

La selección y redirección hacia un DLR añadían pasos. Un anuncio podía decir que el reparador estaba disponible; una redirección podía cambiar el destino de los NAK. Ninguna de esas señales demostraba que aún conservaba la secuencia solicitada, que contestó ni que el receptor aceptó la respuesta.

La ventana de transmisión expresaba una decisión de política. En el avance guiado por datos, un NAK para la zona próxima al borde podía retrasar el movimiento de la ventana. La fuente preservaba la posibilidad de completar a costa de latencia. En el avance guiado por tiempo, la ventana seguía aunque quedaran peticiones pendientes, protegiendo la puntualidad a costa de pérdidas irrecuperables.

El formato del NCF era idéntico bajo decisiones diferentes. Por eso la confirmación no permitía inferir cuánto tiempo conservaría la fuente el dato ni si había priorizado completitud o ritmo.

Forward Error Correction modificaba el material de reparación, no la cadena de evidencia. RDATA podía ser una copia o paridad con la que reconstruir. Un NCF de paridad confirmaba una cantidad pedida; el receptor todavía debía recibir suficientes fragmentos y decodificarlos. La solicitud reconocida no era el objeto recuperado.

El estatus Experimental delimitaba el documento. Su declaración de aplicabilidad describía como prototípicos el control de congestión, la ayuda de routers, la retransmisión local y la interfaz programática. RFC 2357 aportaba criterios para evaluar multicast fiable. RFC 3208 ofrecía una implementación protocolaria para experimentar, no pruebas de adopción o rendimiento.

La sección de seguridad siguió el rastro del estado. Un SPM falso podía desviar peticiones. Un NAK falso podía consumir memoria. Un NCF falso podía detener el reenvío antes de llegar a la fuente. Un RDATA falso podía desmontar el estado legítimo y bloquear la reparación auténtica posterior.

El atacante no necesitaba falsificar el mensaje de aplicación. Bastaba con alterar la representación que controlaba la ruta: quién parecía estar aguas arriba, qué interfaz había perdido, si una petición seguía viva o qué reparación cerraba el estado. La autenticación completa de fuentes, receptores, DLR y elementos de red quedaba fuera de la sencillez básica.

La lección histórica no es que la confirmación careciera de valor. Era indispensable para que la única vía de petición no se perdiera silenciosamente. Su fuerza procedía de un alcance exacto: el NAK fue oído en este punto. Confundir esa frase con «la reparación llegó» habría convertido la eficiencia de PGM en una ficción de entrega.