Resumo

  • Um aviso de duplicidade pode mostrar que uma retransmissão específica foi desnecessária, mas não que todos os segmentos daquela janela chegaram sem perdas.
  • A RFC 3708 só admite concluir que uma mudança de congestionamento pode ser desfeita quando todas as unidades retransmitidas na janela anterior foram confirmadas e marcadas como duplicadas, sem que uma condição de parada tenha ocorrido.

O exemplo que revela o problema quase parece uma armadilha. O emissor retransmite os segmentos N e N+1. Só N se perdeu; N+1 apenas demorou. Quando o receptor sinaliza N+1 como duplicado, o emissor descobre que aquela retransmissão foi desnecessária. Não descobre que a rede não perdeu nada: N continua sendo evidência de perda real. Restaurar o estado de congestionamento de toda a janela apagaria um sinal que ainda importa.

Essa distinção é o centro da RFC 3708, publicada como Experimental em fevereiro de 2004. O documento descreve maneiras conservadoras de usar avisos de duplicidade: o DSACK do TCP e as notificações de número de sequência de transmissão duplicado (TSN) do SCTP. Ele separa dois usos. Uma pilha pode contar avisos para monitoramento ou contabilização. Para desfazer mudanças no controle de congestionamento, o emissor precisa do algoritmo de desambiguação, bem mais rigoroso.

Primeiro, o algoritmo verifica se o intervalo de sequência ou TSN informado foi retransmitido. Se foi retransmitido mais de uma vez naquela janela, o processamento para e o estado anterior de congestionamento não é restaurado. Se o emissor nunca retransmitiu aquela unidade, a notificação pode indicar que a própria rede duplicou o pacote. Nesse caso, a RFC 3708 manda interromper o uso do algoritmo pelo restante da conexão: os avisos seguintes ficariam mais difíceis de atribuir às retransmissões desnecessárias do emissor.

Mesmo uma notificação que corresponde a uma retransmissão não basta. O emissor examina todas as unidades retransmitidas na janela de dados anterior. Só conclui que todas foram espúrias e que a janela não teve perdas se cada uma foi confirmada e marcada como duplicada. Se restar uma retransmissão sem essa marca, o aviso não permite conclusão. Há ainda uma salvaguarda para a tabela SACK TCP vazia e um DSACK iniciado em SND.UNA, combinação compatível com a perda de uma janela inteira de ACKs. Nesse cenário, continuar reduzindo a taxa é a opção conservadora.

O método exige memória: além do estado normal de recuperação SACK, a implementação acompanha quais números de sequência ou TSNs já foram confirmados como duplicados. Isso autoriza uma inferência limitada, não certeza sobre a honestidade do receptor ou todos os eventos do caminho. A seção de segurança da RFC 3708 alerta que um receptor pode marcar dados reordenados como duplicados durante uma perda real, levando o emissor a alterar perigosamente o estado de congestionamento.

A RFC 2883 define como o receptor codifica dados duplicados em blocos D-SACK, mas não determina a resposta do emissor. A RFC 3522, por sua vez, usa outra evidência: o Eifel pode detectar uma retransmissão espúria mais rápido com timestamps TCP, ao custo de incluir a opção Timestamp em cada pacote. A RFC 3708 é mais lenta, mas mantém duas perguntas separadas: uma retransmissão foi desnecessária? A evidência permite declarar toda a janela sem perdas? O documento não prescreve a ação posterior à detecção.

Fontes: RFC 3708, status da RFC 3708, RFC 2883, RFC 3517, RFC 3522, RFC 2960, RFC 4960.