Resumen

  • RFC 3448 hizo que el receptor informara la tasa de llegada, los eventos de pérdida y el tiempo, mientras el emisor medía RTT y calculaba una tasa inspirada en TCP.
  • El resultado seguía limitado por X_recv, el aumento por RTT y el temporizador sin respuesta; una tasa fluida no demostraba capacidad, igualdad exacta ni entrega a la aplicación.

Suavizar la tasa no significaba apropiarse del enlace

La ventana de TCP podía producir oscilaciones demasiado bruscas para voz y vídeo. RFC 3448, publicado en enero de 2003, definió TFRC para ofrecer un ritmo más estable a flujos unicast de mejor esfuerzo que competían con TCP.

Su promesa era acotada. “Razonablemente justo” quería decir que la tasa estaría por lo general dentro de un factor de dos de un flujo TCP bajo las mismas condiciones. No prometía igualdad instantánea, capacidad reservada, latencia ni calidad multimedia.

Tampoco era un transporte completo: no especificaba fiabilidad ni un formato único de paquetes. Podía incorporarse a RTP o a una aplicación. El texto, el registro del RFC Editor, el expediente Datatracker, su historial, sus referencias, sus citas posteriores y la búsqueda de erratas documentan el estándar, no una implantación concreta.

La pérdida se convirtió en episodio

El receptor veía secuencia, tiempo, pérdidas y marcas ECN. TFRC no trataba cada paquete perdido como una orden independiente. Las pérdidas reunidas dentro de aproximadamente un RTT formaban un solo evento, para aproximar la reacción de TCP a un episodio de congestión.

Los intervalos entre eventos se ponderaban y promediaban; su inverso producía p. Si el intervalo actual sin pérdidas se alargaba, el descuento histórico podía reducir la influencia de eventos antiguos. Cinco pérdidas juntas y cinco separadas en varios RTT generaban señales distintas.

Ese resumen sacrificaba detalle. No conservaba la multiplicidad interna del episodio, no identificaba el cuello de botella y no diagnosticaba la causa física. RFC 3168 permitía que una marca ECN contara como señal sin pérdida, pero tampoco convertía la marca en recibo de la aplicación.

El receptor calculaba además X_recv y devolvía información temporal. Informaba lo que había llegado recientemente; no hipotecaba capacidad futura a favor del emisor.

Tres límites seguían bajo control del emisor

Con el tiempo reflejado, el emisor estimaba RTT. Después aplicaba la ecuación descrita en el contexto de RFC 2915: tamaño de paquete, RTT, p y temporización de retransmisión producían X_calc, una aproximación a TCP Reno.

La tasa enviada no era simplemente X_calc. Durante evitación de congestión quedaba limitada por el mínimo entre la ecuación y dos veces X_recv, sin bajar de un suelo muy pequeño ligado al intervalo máximo de retroceso. El modelo y la observación se vigilaban mutuamente.

El tiempo imponía el tercer límite. El aumento normal no debía superar una duplicación por RTT y los paquetes se espaciaban para evitar ráfagas. Un informe válido seguía necesitando interpretación local antes de alterar el cable.

Un receptor defectuoso podía exagerar X_recv u ocultar pérdidas. La ecuación y el aumento controlado reducían su poder, pero no certificaban su relato.

Cuando faltó la respuesta, faltó autoridad

El temporizador sin feedback resolvía una situación incómoda: el emisor no sabía si el silencio era pérdida en el retorno, fallo de ida, cierre del receptor o inactividad. No intentaba adivinar. Reducía la tasa permitida, normalmente bajando a la mitad la copia de X_recv, recalculaba y reiniciaba el temporizador.

La acción segura no necesitaba una causa segura. Esta separación entre respuesta y diagnóstico impidió que la ausencia de datos se transformara en permiso. La responsabilidad de no congestionar permanecía en el extremo que emitía.

La evolución mantuvo separados los recibos

RFC 2914 situó el control de congestión dentro de la estabilidad de Internet. RFC 2581 y RFC 3390 aportaron el contexto TCP; RFC 3550, el de RTP.

RFC 4342 adaptó TFRC a DCCP CCID 3. RFC 4828 trató los paquetes pequeños. RFC 5348 sustituyó finalmente RFC 3448. La secuencia prueba revisión, no éxito universal.

La tasa de eventos no era una causa. X_recv no era capacidad. X_calc no era permiso. La tasa elegida no era reenvío, y el reenvío no era reproducción correcta. Un gráfico suave podía ocultar pérdidas, demora o una estimación manipulada.

Las capas de realidad de Heng Lu separan observación, agregación, mensaje, cálculo, acción y resultado. La primacía del código en ejecución explica por qué el emisor conserva controles propios. La especificación inicial mínima ayuda a ver la modestia del alcance: congestión, no fiabilidad ni contrato de aplicación. Es una lectura editorial posterior.

El legado de RFC 3448 fue una arquitectura de responsabilidad. El observador podía aportar evidencia; el actor seguía obligado a decidir con prudencia.

Fuentes