Resumo

  • RFC 2354 comparou quatro famílias de reparo por latência, banda, processamento, conhecimento do codec e fidelidade, sem escolher uma solução universal.
  • Um buraco na sequência provava perda, não capacidade disponível; adicionar muitos pacotes de reparo podia fechar um ciclo de congestionamento, nova perda e mais reparo.

Colin Perkins e Orion Hodson publicaram o documento em junho de 1998 como RFC Informational. Não era padrão de Internet nem pesquisa exaustiva. O escopo incluía técnicas com participação do emissor e deixava ocultação puramente local no receptor fora da análise.

A primeira separação era entre unidade de mídia e pacote. Unidade significava um intervalo temporal gerado pelo codec; um pacote podia carregar várias. Recuperar os bytes originais, oferecer uma versão aproximada, dispersar um buraco perceptível ou receber uma cópia perfeita depois do prazo eram resultados diferentes.

RTP fornecia número de sequência e timestamp. O número mostrava ordem de transmissão e lacunas; o timestamp colocava unidades no tempo de reprodução. Como reparos podiam chegar fora de ordem, a aplicação precisava reconstruir playout pelo relógio da mídia. A sequência dizia o que faltou. O timestamp dizia quando deixaria de ser útil.

Proteger a perda que realmente ocorria

O RFC citou observações do Mbone em que muitos receptores de uma sessão grande tinham perda de cerca de 2% a 5%, com uma minoria pior. Perdas isoladas eram muito mais comuns que rajadas; rajadas longas eram raras. Era um retrato histórico, não uma distribuição universal.

Mesmo assim, o retrato disciplinava o projeto. O mecanismo deveria corrigir bem o caso isolado frequente e só então pagar pela rajada curta. Um código preparado permanentemente para grandes falhas podia consumir mais capacidade e atraso do que o evento justificava.

Retransmissão atuava depois da observação. O receptor pedia a unidade e o emissor repetia. A recuperação podia ser exata, mas exigia feedback, viagem adicional e espaço antes do playout. Em multicast, quase todo pacote podia faltar para alguém; pedidos não suprimidos transformavam perda individual em carga coletiva. O RFC a favorecia em usos tolerantes a atraso e sugeria combinar FEC para perdas simples com retransmissão para receptores atingidos por rajadas.

FEC independente da mídia enviava paridade ou dados codificados antes de saber a perda. XOR podia ser leve; códigos mais fortes protegiam rajadas com mais cálculo e latência. A vantagem era reconstrução exata sem nova consulta ao emissor. O custo era pagar redundância mesmo quando o caminho entregava tudo.

Redundância específica da mídia conhecia o codec. Uma versão de áudio com menor taxa podia preservar inteligibilidade; partes críticas de vídeo ou bits mais sensíveis podiam receber proteção seletiva. Isso economizava banda e atraso, mas mudava o recibo: havia conteúdo utilizável, não necessariamente uma cópia exata.

Interleaving reorganizava unidades. Um pacote perdido virava pequenos intervalos distribuídos, mais fáceis de ocultar do que um corte contínuo. Não acrescentava banda, mas exigia buffer e retardava a reprodução. Era adequado quando esperar custava pouco e inadequado quando uma conversa precisava responder.

A mesma técnica mudava de valor com o prazo

Em uma transmissão unidirecional, parecida com rádio ou televisão, qualidade podia valer mais que latência; interleaving, retransmissão e FEC tinham espaço. Em sessão interativa, ida e volta e buffer profundo prejudicavam o serviço, deixando FEC de baixa latência como opção mais plausível. Ainda assim, escolher proteção genérica ou dependente do codec continuava sendo decisão local.

O problema decisivo aparecia quando a perda era congestionamento. Enviar mais reparo aumentava a fila, derrubava novos pacotes e criava outra rodada de reparo. A seção de segurança alertava que excesso podia chegar a negação de serviço. Detectar uma lacuna não concedia orçamento infinito.

Sem controle de congestionamento padronizado para streaming, RFC 2354 usou uma aproximação do throughput TCP para estimar comportamento razoável. O próprio texto avisou que a média não capturava a dinâmica de TCP e que o RTT multicast era apenas estimativa aproximada.

RFCs posteriores mantiveram as funções separadas: RFC 4588 para retransmissão RTP, RFC 5109 para FEC genérica e RFC 8085 para a obrigação de aplicações UDP controlarem tráfego agregado. A evolução não criou um botão único de confiabilidade; tornou os contratos específicos.

O legado é uma contabilidade de cinco etapas: perda observada, carga de reparo admitida, unidade reconstruída, chegada antes do prazo e resultado perceptível. Se o painel mostra apenas “reparo ligado”, esconde a diferença entre trabalhar mais e entregar mais.