Resumen

  • RFC 2354 separó la detección de una pérdida, la reconstrucción de datos y la llegada a tiempo para reproducirlos; ninguna de esas pruebas sustituía a las otras.
  • La reparación utilizaba la misma ruta que había perdido el original, de modo que un aumento reactivo de paquetes podía cerrar un círculo de congestión y pérdida.

El documento de Colin Perkins y Orion Hodson apareció en junio de 1998 como RFC Informational. No definía un estándar de Internet ni pretendía cubrir todo el campo. Se limitaba a técnicas de reparación en las que intervenía el emisor y asumía el marco RTP sobre un transporte no fiable, normalmente UDP.

Su vocabulario impedía una confusión básica. Una unidad era un intervalo temporal del medio producido por el codificador. Un paquete podía contener una o varias unidades. Por eso perder un paquete, perder un instante perceptible y no reconstruir los bytes originales eran hechos relacionados, pero no idénticos.

RTP aportaba número de secuencia y marca temporal. El primero indicaba el orden de envío y permitía descubrir huecos. La segunda indicaba cuándo correspondía reproducir las unidades. Como muchas técnicas enviaban copias o unidades fuera de orden, la aplicación debía reconstruir la línea temporal mediante las marcas, no mediante el orden de llegada. La secuencia decía qué faltaba; el reloj decía cuánto tiempo quedaba.

El patrón de pérdida decidía qué seguro comprar

RFC 2354 citó mediciones del Mbone donde la mayoría de receptores de una sesión grande sufría pérdidas del dos al cinco por ciento y una minoría registraba más. Las pérdidas de un solo paquete eran mucho más frecuentes que las ráfagas; las ráfagas largas aparecían pocas veces. Era evidencia histórica y contextual, no una descripción eterna de Internet.

Ese perfil orientaba el gasto. Convenía corregir con eficiencia el caso aislado sin negar que las ráfagas cortas también eran visibles. Proteger siempre contra una ausencia muy larga podía imponer más demora o redundancia de la que justificaba la frecuencia del evento.

La retransmisión actuaba después del diagnóstico. El receptor solicitaba lo perdido y el emisor lo repetía. Podía devolver datos exactos, pero necesitaba realimentación, otro envío y suficiente margen antes de la reproducción. En multicast, casi cualquier paquete podía faltar en algún receptor, por lo que solicitudes no coordinadas convertían problemas locales en carga compartida.

El RFC veía una complementariedad: FEC para pérdidas aisladas frecuentes y retransmisión adicional para quienes sufrían una ráfaga y podían aceptar demora. No todos los receptores debían comprar la misma reparación ni esperar el mismo resultado.

La FEC independiente del medio adelantaba el pago. Paquetes de paridad o códigos permitían reconstruir originales sin volver al emisor. Operaciones sencillas como XOR tenían poco coste computacional; códigos más complejos podían cubrir ráfagas a cambio de cálculo y latencia. La ruta transportaba ese seguro incluso cuando no ocurría pérdida.

La redundancia específica del medio aprovechaba el códec. Una segunda versión de menor calidad ocupaba menos que una copia exacta y podía preservar continuidad con un solo paquete de retraso. También era posible duplicar las partes decisivas de un vídeo o proteger sólo los bits más sensibles. La eficiencia se conseguía renunciando a que toda reparación fuese una réplica exacta.

El entrelazado cambiaba la geometría temporal. Distribuía unidades originalmente contiguas entre paquetes separados. Si desaparecía uno, el receptor obtenía pequeños huecos dispersos en lugar de un corte largo. No aumentaba el ancho de banda, pero exigía almacenamiento y retrasaba la reproducción. Servía mejor cuando la aplicación podía esperar.

Interactividad y difusión no firmaban el mismo contrato

Para radio o televisión unidireccional, la calidad podía justificar espera. Entrelazado, FEC o retransmisión eran opciones razonables. Cuando bastaba una reparación aproximada, el entrelazado evitaba carga adicional. Para una conversación interactiva, en cambio, el viaje de ida y vuelta y la espera de reordenación dañaban el propio servicio. Quedaba la FEC de baja latencia, con una elección todavía abierta entre protección genérica y diseño dependiente del códec.

Así apareció la paradoja operativa. Detectar pérdida invitaba a enviar más. Pero si la pérdida era señal de congestión, los paquetes de rescate entraban en la cola que ya no cabía. Más reparación producía más pérdida; la nueva pérdida justificaba todavía más reparación. RFC 2354 advirtió que el extremo podía constituir denegación de servicio.

En aquel momento no había una solución estándar de control de congestión para medios continuos. El documento propuso una comparación aproximada con el caudal de TCP para acotar un comportamiento razonable. También dejó clara su insuficiencia: el promedio no capturaba la respuesta dinámica de TCP y una estimación RTT de un grupo multicast apenas representaba una media.

RFC 1889 ya había descrito RTP como un marco deliberadamente incompleto: ofrecía tipo de carga, secuencia, tiempo y monitorización, pero no entrega o calidad garantizadas. Más tarde, RFC 4588 y RFC 5109 especificaron mecanismos separados de retransmisión y FEC. RFC 8085 exigió que las aplicaciones UDP controlaran el tráfico agregado y reaccionaran a congestión reduciendo su tasa.

La historia no es una marcha hacia una función única de “recuperación”. Es una disciplina de recibos. Hueco detectado, bytes repetidos, grupo FEC resuelto, unidad reconstruida, llegada antes del plazo y experiencia aceptable son estados distintos. Sólo al conservarlos separados puede saberse si la reparación reparó algo.