Resumo

  • A RFC 3208 dispensou ACKs de cada receptor: lacunas de sequência produziam NAKs, e elementos da rede guardavam as interfaces afetadas enquanto suprimiam pedidos repetidos.
  • O NAK Confirmation provava que o pedido negativo havia sido tratado naquele salto. Não provava que RDATA existia, atravessou o ramo correto, chegou ao receptor ou recompôs a aplicação.

Uma confirmação parece simples enquanto há dois participantes. O remetente envia, o destinatário responde, e a espera pode terminar. Numa árvore multicast, porém, exigir uma resposta positiva de milhares de receptores para cada pacote cria uma segunda inundação, dirigida de volta à fonte.

O Pragmatic General Multicast nasceu diante dessa assimetria. Sua meta não era produzir um livro de recibos, mas entregar uma sequência de dados a muitos receptores sem que o retorno de controle implodisse. A RFC 3208 fez da ausência de ruído o caso normal.

A fonte transmitia Original Data, ODATA, com números de sequência. Cada receptor acompanhava o que havia observado. Ao perceber um intervalo, emitia um negative acknowledgement seletivo, o NAK, para pedir apenas o que faltava.

Retirar o ACK significou mais que reduzir cabeçalhos. O PGM não possuía um modelo de membros do grupo. Receptores podiam entrar ou sair sem serem enumerados pela fonte. O protocolo não prometia entrega reconhecida a uma lista conhecida nem ordenação completa entre fontes distintas.

A garantia era formulada da perspectiva do receptor. Dentro da janela de transmissão aplicável, ele receberia ODATA ou RDATA, ou conseguiria detectar uma perda irrecuperável. A fonte não ganhava, por isso, autoridade para declarar o estado de uma população que desconhecia.

Quando encontrava uma lacuna, o receptor enviava o NAK em unicast ao último elemento PGM no caminho de chegada. Repetia o pedido até escutar, na interface correspondente, um NAK Confirmation, o NCF.

O elemento da rede emitia o NCF para baixo e encaminhava o NAK ao vizinho PGM seguinte, na direção da fonte. Cada elemento superior repetia o procedimento. A confirmação era local ao salto; não viajava pela árvore como recibo de ponta a ponta.

O conteúdo probatório do NCF era deliberadamente pequeno: o pedido foi ouvido e tratado neste ponto. A confirmação não carregava o pacote ausente. Não dizia que a fonte ainda o tinha, que um reparador havia respondido, que RDATA percorreria os ramos necessários ou que o receptor conseguiria usá-lo.

Ao receber o NAK, o roteador criava repair state. A chave identificava a sessão e a sequência perdida, e uma lista registrava as interfaces de onde viera a evidência da perda. Depois da confirmação, o datagrama NAK podia ser descartado; a obrigação persistia como estado.

Quando Repair Data, RDATA, voltava pela árvore, o roteador o encaminhava somente pelas interfaces registradas. O reparo alcançava a subárvore que pedira ajuda, em vez de ser redistribuído ao grupo inteiro. Sem estado compatível, o comportamento padrão era descartar RDATA.

Isso separava a existência do reparo da autorização de trânsito. A fonte podia criar o RDATA correto, mas um ramo sem estado não o receberia. Um NCF emitido no primeiro salto tampouco demonstrava que o pedido chegou à fonte ou que o caminho de retorno ficou pronto.

Source Path Messages, SPM, construíam a direção inversa. A fonte os intercalava com o fluxo de dados; cada elemento PGM atualizava o endereço do caminho. Receptores e roteadores aprendiam quem era o vizinho a montante para encaminhar NAKs pela inversa da distribuição original.

Os SPM também anunciavam os limites da transmit window. A borda traseira marcava o dado mais antigo ainda disponível para reparo. Se a lacuna fosse descoberta depois que a sequência saísse da janela, um pedido corretamente confirmado não poderia recriar a cópia apagada.

Como o NAK era o único gatilho para reparo, seu percurso precisava ser persistente. SPMs continuavam provocando verificações mesmo na ausência de ODATA recente. O receptor mantinha temporizadores diferentes para aguardar NCF e para aguardar RDATA. Escutar a confirmação não encerrava necessariamente a espera pelo reparo real.

Uma única perda podia afetar muitos membros. Para não substituir a implosão de ACKs por uma implosão de NAKs, cada receptor esperava um back-off aleatório. Se escutasse um NAK ou NCF correspondente durante esse intervalo, suprimia seu próprio envio e tratava o pedido alheio como representante da mesma lacuna.

Os roteadores também eliminavam duplicatas. Com repair state já existente para a sessão e sequência, podiam acrescentar uma nova interface sem encaminhar outro NAK para cima. No caso eficiente, a fonte via um pedido mesmo quando muitos receptores haviam perdido o pacote.

A mesma compressão que dava escala removia a contagem. O NAK visto pela fonte não indicava quantos receptores tinham se calado por supressão. O NCF ouvido num ramo não nomeava cada membro. Uma interface no estado não revelava quantas máquinas havia adiante nem quais ainda participavam.

Nem sempre a fonte original fornecia fisicamente RDATA. Um Designated Local Repairer, DLR, podia guardar cópias e responder mais perto dos receptores. Seu reparo preservava o Transport Session Identifier original para ocupar a posição correta. Continuidade da identidade da sessão não era prova da origem física dos bytes.

Anunciar um DLR, selecioná-lo e redirecionar NAKs eram fatos separados. O anúncio de disponibilidade não provava que a sequência pedida ainda estava armazenada. O redirecionamento não provava chegada ou resposta, e o TSI correto não provava aceitação pelo receptor.

A janela de transmissão também materializava uma política. No avanço orientado por dados, um NAK próximo à borda podia retardar a janela e preservar a chance de completar, ao custo de latência. No avanço orientado por tempo, a janela seguia apesar de pedidos pendentes, protegendo a pontualidade ao custo de perdas permanentes.

O NCF tinha a mesma forma sob políticas diferentes. Contar confirmações não mostrava quanto tempo a fonte conservaria uma sequência nem se a operação priorizava completude ou ritmo. A trajetória da janela precisava ser observada como evidência própria.

Forward Error Correction alterava o material do reparo, não a fronteira da afirmação. RDATA podia trazer uma cópia ou paridade para reconstrução. Um NCF associado a FEC confirmava o pedido por símbolos; o receptor ainda precisava receber quantidade suficiente e decodificar com sucesso.

O status Experimental da RFC 3208 delimitava sua força histórica. A declaração de aplicabilidade tratava controle de congestionamento, apoio de roteadores, retransmissão local e interface de programação como áreas de protótipo. A RFC 2357 fornecia critérios para avaliar multicast confiável; a RFC 3208 oferecia mecanismos concretos para experimentar, não prova de adoção ou desempenho.

A seção de segurança acompanhava os pontos em que representações criavam estado. Um SPM falso podia desviar NAKs. Um NAK falso podia consumir memória. Um NCF falso podia interromper o encaminhamento antes da fonte. RDATA falso podia remover estado legítimo e impedir a passagem de um reparo posterior.

O atacante não precisava falsificar a mensagem da aplicação. Bastava manipular quem parecia estar a montante, qual interface parecia afetada, se o pedido ainda estava ativo ou qual reparo autorizava o encerramento do estado. Autenticação completa de fontes, receptores, DLRs e elementos de rede estava além da simplicidade do mecanismo básico.

A lição histórica não é que o NCF fosse inútil. Ele era essencial para impedir que a única via de pedido morresse em silêncio. Seu valor dependia do limite exato: o NAK foi ouvido neste ponto. Rebatizar essa frase como “o reparo chegou” converteria a disciplina de escala do PGM numa ficção de entrega.