Resumo

  • O RFC 3448 deu ao receptor a medição da taxa recebida, dos eventos de perda e do tempo, mas deixou com o emissor o RTT e o cálculo de uma taxa compatível com TCP.
  • A taxa final ainda passava pelo teto de X_recv, pelo aumento controlado, pelo pacing e pelo temporizador sem feedback; suavidade não comprovava capacidade, justiça exata ou entrega.

Um fluxo mais calmo ainda precisava ceder

O sobe-e-desce da janela TCP servia bem à transferência de arquivos, mas podia ser ruim para telefonia e mídia contínua. Publicado em janeiro de 2003, o RFC 3448 apresentou o TFRC como controle de congestionamento baseado em taxa para fluxos unicast de melhor esforço.

A promessa era limitada de propósito. Ser “razoavelmente justo” significava ficar, em geral, dentro de um fator dois da taxa de um fluxo TCP nas mesmas condições. Não significava igualdade instantânea, reserva de banda nem qualidade audiovisual garantida.

O documento tampouco especificava transporte completo, confiabilidade ou formato obrigatório. O mecanismo podia ser usado com RTP ou pela própria aplicação. O texto, o registro do RFC Editor, o Datatracker, o histórico, as referências, as citações posteriores e a busca de erratas registram a especificação, não uma implantação específica.

O receptor trocava contagem por contexto

Perder vários pacotes próximos não era igual a perder a mesma quantidade espalhada no tempo. O receptor reunia perdas ou marcações ocorridas em cerca de um RTT num único evento. Essa escolha aproximava o sinal da reação que TCP teria a um episódio de congestionamento.

Os intervalos entre eventos eram ponderados; o inverso da média produzia p. Um intervalo atual muito longo podia descontar parte da história. Assim, cinco perdas juntas poderiam contar como um evento, enquanto cinco perdas afastadas poderiam contar como cinco.

O resumo era útil, mas incompleto. Ele não preservava a multiplicidade dentro do evento, não apontava o gargalo e não identificava a causa física. O RFC 3168 permitia que ECN sinalizasse congestionamento sem descartar um pacote, mas a marca ainda não provava entrega à aplicação.

Além disso, o receptor media X_recv e devolvia dados de tempo. Ele afirmava quanto havia chegado no passado recente. Não reservava a capacidade futura.

A decisão ainda tinha três freios locais

O emissor extraía RTT dos tempos devolvidos e aplicava a equação contextualizada pelo RFC 2915. Tamanho de pacote, RTT, p e um termo de timeout formavam X_calc, aproximação da taxa de um TCP Reno.

O fio não recebia automaticamente X_calc. Em congestion avoidance, a taxa ficava limitada também a duas vezes X_recv, além de um piso baixo associado ao intervalo máximo de recuo. A equação continha um relatório excessivamente otimista; a chegada observada continha um modelo excessivamente otimista.

O terceiro freio era temporal. O crescimento normal não deveria ultrapassar uma duplicação por RTT, e os pacotes deveriam ser espaçados. Mesmo um feedback sintaticamente válido precisava atravessar cálculo, teto e pacing.

Um receptor malicioso podia omitir perdas ou inflar sua taxa. As regras locais reduziam seu poder, mas não transformavam o relatório em verdade independente.

Sem resposta, o espaço de ação encolhia

Quando o feedback cessava, o temporizador expirava. O emissor reduzia a taxa permitida — em muitos casos dividindo sua cópia de X_recv por dois — e recalculava. Na inicialização sem RTT e sem retorno anterior, podia cortar diretamente a taxa.

O silêncio tinha várias causas possíveis: perda no caminho reverso, falha no caminho direto, receptor encerrado ou período ocioso. O protocolo não precisava escolher uma narrativa. Bastava reconhecer que faltava evidência e recuar.

Esse comportamento separava autoridade de informação. O receptor alimentava a decisão; o emissor não transferia a ele o dever de proteger a rede.

Evolução não apagou as fronteiras

O RFC 2914 colocou o controle de congestionamento no campo da estabilidade da Internet. Os RFC 2581 e RFC 3390 deram o contexto TCP; o RFC 3550, o contexto RTP.

O RFC 4342 levou TFRC ao DCCP CCID 3. O RFC 4828 tratou a variante de pacotes pequenos. O RFC 5348 substituiu o RFC 3448. Essa sequência prova revisão, não adoção universal.

p não era causa; X_recv não era capacidade; X_calc não era licença. A taxa escolhida não provava encaminhamento, decodificação ou experiência. Um gráfico liso podia coexistir com feedback antigo, atraso ou perda na aplicação.

As camadas de realidade de Heng Lu preservam os recibos separados entre observação, agregação, mensagem, cálculo, ação e resultado. A primazia do código em execução explica por que o emissor aplicava controles próprios. A especificação inicial mínima ajuda a entender a contenção do escopo: congestionamento, não confiabilidade ou contrato da aplicação. É uma leitura editorial posterior.

O legado do RFC 3448 foi conservar responsabilidade onde a ação acontecia. Observar dava voz ao receptor; não lhe dava propriedade sobre a rede seguinte.

Fontes