Resumo

  • O RACK só considera perdido um segmento antigo depois que um segmento enviado mais tarde foi reconhecido e o antigo permaneceu sem ACK além de um RTT estimado somado a uma janela limitada de reordenação.
  • O TLP envia no máximo uma sonda antes do RTO para provocar nova evidência. A sonda não é um veredicto: RACK detecta a perda, e o controle de congestionamento decide quando a recuperação pode transmitir.

A regra dos três fica sem matéria-prima

A retransmissão rápida tradicional interpreta três ACKs duplicados como indício de um buraco anterior. A regra funciona quando há dados suficientes depois do buraco para fazer o receptor responder repetidamente. Uma resposta curta, um fluxo limitado pela aplicação ou uma perda no fim da janela pode não gerar nenhum trio. Sem esse movimento, o remetente cai no temporizador de retransmissão, um mecanismo conservador justamente porque precisa funcionar quando os indícios mais específicos acabam.

O reconhecimento seletivo oferece uma descrição melhor do que chegou. O RFC 2018 permite ao receptor informar blocos de bytes fora da fronteira cumulativa. O RFC 6675 usa esse placar na recuperação baseada em SACK, mas o principal limiar de perda ainda conta sequências descontínuas ou bytes acima de um buraco. Reordenação, duplicação e agrupamento de ACKs podem tornar a contagem precipitada ou tardia. Quantidade em espaço de sequência não mede há quanto tempo uma transmissão está exposta ao caminho.

Recent ACKnowledgment, ou RACK, transfere o teste para o tempo de envio. Yuchung Cheng, Neal Cardwell, Nandita Dukkipati e Priyaranjan Jha assinam coletivamente o RFC 8985, que o IETF levou ao Standards Track em fevereiro de 2021. Os perfis oficiais de Cardwell no IETF e no Google Research comprovam sua identidade, seu trabalho em redes e sua ligação com o documento. Não sustentam autoria solitária nem controle atual sobre todas as pilhas que usam o algoritmo.

Uma entrega posterior abre, mas não encerra, o caso

O RACK guarda o horário da transmissão mais recente de cada segmento pendente, inclusive quando há retransmissão. Se um ACK ou SACK prova que chegaram dados enviados depois de um segmento S ainda sem reconhecimento, surge a primeira premissa: o caminho entregou algo que saiu depois de S.

Ainda falta o tempo. S só pode ser marcado como perdido se continuar pendente por ao menos o RTT estimado mais a janela de reordenação. O RFC descreve temporizadores virtuais por segmento, sem obrigar uma implementação a criar um temporizador físico para cada um. É possível manter apenas a próxima expiração derivada do conjunto em voo.

A resolução do relógio passa a ter consequência funcional. O RFC 8985 exige que o horário mais recente seja preservado com granularidade menor que um quarto do RTT mínimo. O texto estima quatro ou oito octetos de estado por segmento, conforme a representação; é uma referência de implementação dentro do RFC, não um custo universal.

O ACK prova apenas a entrega de uma faixa TCP. Não revela a causa da ausência de S, não localiza congestionamento, não atesta o comportamento de middleboxes, não autentica o caminho e não garante que a aplicação consumiu os bytes. RACK produz uma conclusão útil para o transporte a partir da ordem e do tempo observáveis; não produz causalidade completa.

A desordem recebe um orçamento de espera

Pacotes podem chegar fora de ordem sem se perder. Por isso o limiar inclui uma janela de reordenação. Conforme as condições do RFC, ela pode começar em zero ou numa pequena fração do RTT mínimo. Se um Duplicate SACK mostrar que uma retransmissão foi espúria, o remetente obtém evidência de reordenação mais profunda e pode ampliar a tolerância. O documento recomenda adaptação via DSACK e limita a janela ao RTT suavizado.

Uma janela estreita acelera a correção da perda real, mas duplica um original apenas atrasado. Uma janela larga evita falsos positivos, porém prolonga a falha genuína. Chamar o método de temporal não o torna infalível; torna explícito, mensurável e limitado o tempo concedido a uma explicação alternativa.

Uma decisão auditável deveria registrar o último envio do segmento suspeito, o horário do segmento posterior entregue, o ACK ou SACK que comprovou a entrega, o RTT estimado, a janela vigente e qualquer DSACK que a alterou. Um contador agregado de perdas RACK conserva a sentença e descarta os fatos do processo.

Uma única sonda na cauda silenciosa

Tail Loss Probe cuida do ponto em que o relógio de ACK para por falta de dados posteriores. Seu prazo costuma girar em torno de duas vezes o RTT suavizado, sujeito às regras do RFC sobre ACK atrasado e proximidade do RTO. TLP precisa de uma medição recente de RTT e não permite mais de uma sonda pendente.

Quando o prazo vence, o remetente envia dados novos se houver conteúdo e a janela de congestionamento permitir. Caso contrário, retransmite o segmento pendente de maior número de sequência. O objetivo é solicitar um ACK capaz de esclarecer a cauda. Uma sonda pode exceder temporariamente uma janela cheia em um pacote, mas não desaparece da contabilidade: o ACK seguinte precisa compensá-la.

A sonda não prova que a cópia original se perdeu. Ela pergunta. A resposta pode oferecer a entrega posterior de que RACK precisa ou mostrar que o original chegou e apenas faltava dinâmica de ACK. Se a própria sonda sumir, o RTO permanece como proteção final. TLP produz um evento observável; RACK interpreta o evento.

O detector não controla o ritmo da recuperação

Mesmo após marcar perda, RACK não ganha licença para retransmitir a qualquer momento. O RFC 8985 determina que a transmissão espere a permissão do algoritmo de controle de congestionamento. O RFC 5681 estabelece as obrigações clássicas e o RFC 6937 recomenda Proportional Rate Reduction para modular o envio durante a recuperação.

Essa divisão impede que um sensor mais rápido vire um atuador mais agressivo. A detecção informa que as premissas são suficientes para tratar S como perdido; o controlador decide quantos bytes de reparo a rede pode absorver. Até a sonda além da janela cheia é uma exceção pequena, descrita e contabilizada.

O RTO do RFC 6298 também continua necessário. Ele preserva o progresso quando os sinais de granularidade fina falham e aplica recuo conservador. SACK descreve intervalos entregues, RACK julga pelo tempo, TLP solicita feedback na cauda, controle de congestionamento limita a recuperação e RTO ampara o silêncio restante.

Tempo preciso não é atestado de saúde

Entregar o pacote posterior não certifica a rota, a identidade do destino, a ausência de middlebox nem o sucesso da aplicação. Reordenação legítima, perda sem fio, mudança de caminho e congestionamento podem deixar traços parecidos para o remetente. O veredicto de transporte não deve ser promovido a diagnóstico forense.

A análise de segurança do RFC 8985 herda as preocupações de SACK e aponta uma resistência específica a ACK splitting: reconhecer um byte adicional não avança o horário da transmissão entregue mais recente usado por RACK. Isso limita uma tática; não autentica feedback nem garante honestidade geral dos ACKs.

O RFC 9002 aplica limiares temporais à detecção de perdas em QUIC e reconhece RACK-TLP em sua linhagem. QUIC possui espaços de número de pacote, regras de ACK e interfaces de congestionamento próprias. A semelhança de princípio não prova igualdade de estado, parâmetros ou autoridade.

O alcance correto dos números de 2013

O artigo “Reducing Web Latency: the Virtue of Gentle Aggression”, de 2013 e com Cardwell entre os autores, estudou uma amostra de tráfego de frontends do Google. Naquele ambiente delimitado, 77% das perdas observadas foram reparadas via RTO, não pela recuperação rápida. A combinação experimental testada reduziu a latência média em 23% e o percentil 99 em 47%.

Os resultados explicam o interesse histórico pela cauda de transações curtas. Não medem a Internet atual, não revelam a implantação presente do Google e não prometem o desempenho do RFC 8985. O ensinamento que sobrevive é mais contido: fluxos curtos podem ficar sem pacotes capazes de gerar evidência muito antes de ficar sem tempo de espera.

Fontes