Resumo

  • O algoritmo Eifel do RFC 3522 guarda a marca da retransmissão que iniciou a recuperação e examina o primeiro ACK aceitável. Se a marca devolvida for menor, há evidência de que o ACK respondeu ao envio original e de que a recuperação foi desnecessária.
  • Essa classificação não recompõe cwnd, ssthresh, RTO nem o desempenho percebido pela aplicação. Uma cadeia verificável precisa separar gatilho, evidência, exceções, estado anterior, ação de resposta e resultado observado.

O TCP não esperou pelo veredito. Um temporizador venceu ou uma sequência de ACKs duplicados atingiu o limiar; o emissor retransmitiu e restringiu sua capacidade de envio. Só depois surgiu a informação capaz de corrigir o diagnóstico de perda.

Publicado em abril de 2003 com status Experimental, o RFC 3522 trata a ambiguidade criada por uma retransmissão. Um número de ACK confirma bytes, mas não revela qual cópia os fez avançar. A opção TCP Timestamps acrescenta um marcador que pode distinguir o envio original da cópia posterior.

O limite de autoridade aparece no próprio algoritmo. A etapa (RESP) não executa resposta alguma. Detectar que a premissa era falsa não equivale a desfazer todas as mudanças realizadas enquanto ela parecia verdadeira.

O primeiro ACK aceitável identifica a história, não reescreve o passado

Ao entrar em recuperação, o emissor define SpuriousRecovery como falso e salva em RetransmitTS o Timestamp Value da retransmissão por timeout ou da fast retransmit que iniciou o episódio. Retransmissões posteriores não podem sobrescrever esse valor.

O próximo objeto de interesse é o primeiro ACK aceitável que reconhece dados antes não reconhecidos. Se o Timestamp Echo Reply for estritamente menor que RetransmitTS, ele corresponde a um envio anterior à retransmissão. Passadas as verificações conservadoras do algoritmo, o emissor pode classificar a recuperação como espúria.

A rapidez importa. Depois de um timeout falso, ACKs atrasados dos originais podem alimentar uma sequência go-back-N de novas cópias. Descobrir cedo que a primeira cópia era desnecessária permite limitar a propagação do erro.

Ainda assim, a sequência causal não muda: sinal de perda, redução de estado, retransmissão, ACK, classificação e eventual resposta. Um registro que preserva apenas a conclusão final apaga justamente as decisões que precisam ser auditadas.

Sintomas iguais podem nascer de mecanismos diferentes

Uma elevação súbita de latência pode deixar o RTO expirar antes do ACK. Reordenação pode produzir ACKs duplicados suficientes para fast retransmit. Duplicação de dados ou de reconhecimentos pode compor a mesma aparência externa.

A marca antiga responde a uma pergunta limitada: a recuperação iniciada para aquela transmissão era necessária? Ela não prova qual mecanismo da rede produziu o sinal, não mede congestionamento, não identifica um domínio operacional e não atribui culpa.

Os efeitos também divergem. Uma fast retransmit espúria costuma produzir uma cópia inútil e reduzir a janela. Um timeout espúrio pode impor slow start e provocar uma cascata de retransmissões quando os ACKs dos originais finalmente chegam.

Há ainda o fast timeout: o segmento foi realmente perdido, mas o temporizador disparou antes de surgirem ACKs duplicados. A recuperação continua justificada. Vencer uma corrida entre gatilhos não transforma perda verdadeira em alarme falso.

Igualdade significa ausência de distinção

O teste básico usa “menor que”, não “menor ou igual”. Se o relógio de timestamps for grosseiro, ou se o intervalo entre original e cópia for curto, ambos podem receber o mesmo valor. Nessa situação, o RFC não autoriza uma conclusão positiva.

Essa escolha sacrifica algumas oportunidades de otimização para não converter ambiguidade em certeza. A política de comparação é parte do padrão probatório, e não um detalhe de implementação.

Um recibo útil conserva os dois valores brutos, a granularidade do relógio, o operador comparativo e o ramo tomado. A anotação “Eifel executado” não distingue resultado positivo, negativo e inconclusivo.

A perda de todos os ACKs produz uma semelhança perigosa

Suponha que os dados originais tenham chegado, mas todos os ACKs do voo tenham desaparecido no caminho de volta. O emissor terá de expirar o temporizador. A nova cópia é desnecessária do ponto de vista dos bytes no receptor, porém o timeout era inevitável, e a redução de janela pode ser uma reação legítima a congestionamento no caminho dos ACKs.

Quando a duplicata chega, um receptor que segue as regras históricas de timestamps pode repetir a marca do último segmento original em ordem. Esse valor será menor que o da retransmissão e poderá imitar perfeitamente uma recuperação espúria.

A etapa 5 combina a disponibilidade de DSACK com a pergunta sobre o ACK cobrir todos os dados pendentes. Em certos casos ela encerra o procedimento sem reverter. Portanto, Eifel não é simplesmente echo < retransmit; as saídas que recusam uma conclusão também são produto do algoritmo.

Registrar apenas o booleano final perde o motivo pelo qual uma restauração foi permitida ou impedida.

Um receptor hostil pode fabricar uma prova convincente

Como o receptor devolve a marca, ele pode falsificar um valor antigo e fazer uma retransmissão necessária parecer inútil. O RFC 3522 descreve uma variante segura: o emissor mantém as marcas dos envios originais ainda pendentes e aceita como evidência apenas a igualdade exata com o original correspondente.

Essa proteção cobra memória e disponibilidade. Ela depende do ACK específico do original e, por isso, é mais sensível a perda ou reordenação de reconhecimentos. Um relógio de baixa granularidade também torna valores ausentes mais fáceis de adivinhar.

“Timestamps habilitados” não é uma garantia de segurança. A confiança depende do que ficou secreto, do que foi retido, da precisão do relógio, do comportamento do par e da política usada quando a prova não chega.

O estado não guardado não pode ser reconstruído pelo diagnóstico

No algoritmo de detecção, (RESP) significa não fazer nada. O documento menciona objetivos possíveis — restaurar controle de congestionamento, evitar retransmissões go-back-N, ajustar o limiar de ACKs duplicados ou tratar estimadores de RTT — e deliberadamente os deixa fora de escopo.

O RFC 4015 especifica depois um algoritmo de resposta Eifel. A separação é necessária: uma resposta precisa de preparação própria. Para restaurar janela ou limiar de slow start, o emissor deve ter salvo seus valores anteriores. A mera certeza de que a recuperação foi espúria não revela números já substituídos.

Também é preciso definir até onde voltar. Uma retransmissão pode ter sido desnecessária enquanto outro segmento da mesma janela foi realmente perdido. A discussão de DSACK no RFC 3708 torna explícito esse caso misto. Inocentar uma cópia não absolve todo o episódio de congestionamento.

O detector pode classificar o evento para o qual recebeu evidência. Ele não herda autoridade para restaurar variáveis que refletem fatos mais amplos.

Uma entrega posterior não apaga a intervenção anterior

Após a classificação, uma resposta pode ampliar a janela, corrigir um estimador ou liberar novos dados. Cada escrita precisa de sua própria trilha: valores anteriores à perda, valores depois do gatilho, saída do detector, versão da resposta, campos restaurados e campos preservados.

A rede ainda precisa entregar o fluxo. Restaurar cwnd não demonstra que a reordenação cessou, que a capacidade permaneceu constante ou que uma transação terminou. O roteiro TCP, RACK-TLP, CUBIC e outros trabalhos posteriores continuam separando sinais de perda, classificação e resposta segura.

O recibo final deve corresponder à promessa. Para entrega de bytes, registre intervalos reconhecidos. Para latência, meça o período adequado. Para uma operação da aplicação, retenha sua confirmação autenticada. Um eco de timestamp não pode assumir esses significados por conveniência.

Construa um recibo de perda reversível

Registre a negociação de timestamps e a granularidade do relógio. Preserve intervalo de bytes e marca do original, gatilho de perda, contagem de ACKs duplicados ou estado do temporizador e todas as variáveis de congestionamento anteriores ao gatilho.

Vincule criptograficamente, quando possível, a primeira retransmissão e seu RetransmitTS imutável. Guarde o primeiro ACK aceitável, intervalo reconhecido, Timestamp Echo Reply, blocos DSACK e decisão exata da etapa 5. Declare se a variante básica ou segura foi usada.

Na resposta, registre algoritmo e versão, variáveis salvas, variáveis restauradas, valores deliberadamente conservados e justificativa. Correlacione perdas verdadeiras posteriores, reordenação, novas retransmissões e mudanças de timer. Feche com a entrega observada e o resultado da aplicação.

Contadores agregados ajudam a localizar tendências, mas não recompõem uma restauração contestada. A cadeia por evento precisa sobreviver a reinícios, amostragem de telemetria e mudanças de implementação.

Limite das evidências

Este Artigo não identifica implementação TCP, sistema operacional, fornecedor, operadora, rede de acesso, caminho, receptor, usuário, fluxo, incidente ou implantação. Não afirma adoção, uso de timestamps, reordenação, perda, desempenho, consumo de bateria, segurança nem resultado comercial em sistema atual.

O RFC 3522 é tratado como documento Experimental de abril de 2003, não como Internet Standard. RFC 4015, RFC 5681, RFC 5682, RFC 6298 e RFC 7323 mantêm seus próprios status e escopos. RFC 9438, RFC 8985 e RFC 9002 são comparações posteriores, não provas de implementação do RFC 3522.

Os ensaios de Heng Lu sobre autoridade e código em execução são lentes editoriais declaradas. Ajudam a separar sinal formal, estado operacional e resultado observado; não documentam a intenção da IETF.

A conclusão estreita basta: um ACK pode corrigir o diagnóstico sem corrigir o estado. Nenhum sistema deveria declarar o resultado restaurado antes que uma resposta independente aja e que seu efeito seja medido.

Fontes