Resumo

  • O RFC 3366 tratou a persistência do ARQ de enlace como um orçamento de tempo: quanto se tenta recuperar um quadro antes de desistir. Não é um aumento gratuito de confiabilidade.
  • Uma retransmissão pode ajudar um fluxo e, ao mesmo tempo, acrescentar atraso acumulado, variação ou bloqueio aos demais; a confirmação do quadro não prova que a aplicação recebeu os dados a tempo.

Um quadro não é o pacote inteiro

A história começa abaixo do IP. O Automatic Repeat reQuest, ou ARQ, detecta um quadro ausente ou corrompido e tenta enviá-lo novamente. Conforme o enlace, um quadro pode carregar parte de um pacote IP, um pacote inteiro ou partes de vários. A confirmação responde a uma pergunta limitada: o protocolo local aceitou este quadro? Ela não confirma a chegada do pacote ponta a ponta nem que ele ainda seja útil à aplicação.

Publicado como Best Current Practice 62, o RFC 3366 pediu aos projetistas que respeitassem essa fronteira. Ele não especifica uma tecnologia de rádio nem impõe uma contagem universal de tentativas. Explica como o ciclo local de recuperação de um enlace interage com o tráfego de Internet que passa por ele.

O orçamento de tentativas gasta tempo compartilhado

O documento chama de “persistência” a disposição de tentar de novo. Um enlace pode fixar o número de tentativas ou deixar temporizadores e procedimentos de falha determinarem quando parar. Contagem não é relógio: propagação, disputa pelo meio compartilhado, filas, tamanho do quadro e processamento mudam o tempo decorrido.

Por isso, a confiabilidade depende do contexto. O controle local do enlace costuma reagir antes do ciclo ponta a ponta do TCP e pode corrigir um erro do canal antes que o emissor retransmita. Mas o quadro recuperado também pode chegar tarde o bastante para afetar o temporizador de transporte. Se o enlace preserva a ordem, pacotes completos que chegaram depois podem ficar parados atrás do quadro ainda em nova tentativa. Em um canal compartilhado, essas tentativas consomem tempo de transmissão que outros nós poderiam usar.

A persistência perfeita deixa a troca clara: continuar indefinidamente enquanto o receptor ainda puder aceitar o quadro. Isso pode fazer sentido para uma transferência cujo objetivo é a entrega confiável. Em um caminho IP com vários enlaces, porém, a recuperação repetida pode duplicar trabalho já previsto ponta a ponta; ela não garante a mesma confiabilidade do transporte entre os hosts. Para streaming e outras aplicações UDP sensíveis ao tempo, um pacote atrasado talvez valha menos do que um pacote perdido.

O que o enlace pode saber sem adivinhar

Parece natural reservar persistência longa ao tráfego que “parece confiável” e pouca ao restante. O RFC 3366 explica por que observar não basta. O enlace pode ver comportamento de controle de congestionamento sem conhecer o prazo da aplicação nem se ela prefere integridade ou atualidade. Portas podem induzir ao erro ou ser remapeadas; túneis juntam fluxos diferentes; a criptografia limita a inspeção; e uma marca de serviço pode ser sobrescrita ou ter significado apenas local.

A recomendação, portanto, é condicional. Se as classes de serviço puderem ser distinguidas com segurança, políticas de retransmissão distintas podem ajudar. Caso contrário, todos os fluxos herdam o mesmo comportamento. Quando a classificação segura não é viável, o BCP geralmente favorece persistência baixa: recuperar alguns quadros sem deixar que um pacote incompleto mantenha a fila bloqueada indefinidamente. O texto também registra a exceção: persistência alta pode ajudar o TCP em algumas condições de erro variável ou depois de uma interrupção transitória. Não há configuração ideal para todos os casos.

Publicado em 2004, o RFC 3819 amplia o conselho para o projeto de sub-redes e trata a tensão entre perda, atraso médio e variação do atraso. Reforça a flexibilidade; não transforma o exemplo de duas a cinco tentativas do RFC 3366 em regra atual nem em medida das práticas implantadas.

A confirmação continua local

A lição duradoura do RFC 3366 também é sobre evidência. Um ACK de quadro registra um evento local. A saída do pacote do enlace, sua aceitação pelo transporte e sua chegada em tempo à aplicação são eventos posteriores, cada qual exigindo evidência própria. A retransmissão pode reduzir perdas do canal e, ao mesmo tempo, aumentar a variação, atrasar o retorno de informação de congestionamento ou consumir o tempo de outros fluxos.

O projetista escolhe um orçamento local; o caminho acumula suas consequências. Sem conhecer o restante da rota ou a necessidade de atualidade da aplicação, um equipamento não pode converter “mais tentativas” em promessa de serviço melhor. O BCP 62 pediu que essa incerteza fizesse parte do projeto, e não ficasse escondida sob o rótulo de confiabilidade.

Fontes

Lu Heng não escreveu o RFC 3366. Os ensaios são identificados como lentes analíticas para distinguir recomendação, implementação, configuração e resultado observado.