Resumo

  • RFC 9616 acrescenta timestamps aos Hello e IHU do Babel para estimar RTT entre vizinhos sem sincronizar relógios.
  • O RTT passa por suavização, uma função de custo com patamares e histerese; o resultado é uma decisão operacional deliberadamente estável, não uma medição integral do serviço.
  • Uma implantação mista pode permanecer livre de loops e ainda selecionar caminhos subótimos, porque algumas adjacências conhecem atraso e outras continuam usando salto ou perda.

O mecanismo de evolução em RFC 9616 é silencioso. Timestamp aparece como um sub-TLV dentro de mensagens que o Babel já conhece. Uma implementação que não entende a extensão ignora esse sub-TLV e continua analisando o restante. O roteador novo não exige que o antigo aprenda tudo antes de manter vizinhança.

Isso evita uma migração coordenada de toda a rede. Também cria uma obrigação de leitura: “funcionou em modo misto” significa que o protocolo continuou operando; não significa que todos os custos passaram a representar a mesma propriedade.

Uma adjacência atualizada pode converter atraso em custo. Uma adjacência antiga pode continuar com contagem de saltos. Um trecho sem fio pode privilegiar perda. A rota final combina essas avaliações. Ela não é inválida, mas sua explicação não cabe em uma única etiqueta chamada “latência”.

Por que o Babel precisava enxergar dentro do túnel

A especificação-base RFC 8966 permite algoritmos de métrica diversos. Essa liberdade ajuda o Babel a operar em redes cabeadas e malhas sem fio. O problema surge quando túneis comprimem geografia: uma ligação local e outra intercontinental aparecem como um salto.

No losango usado pelo RFC, A, B e D estão em Paris; C está em Tóquio. De A para D, B e C fornecem caminhos com igual contagem. Sem um sinal adicional, a rota distante pode receber aproximadamente metade do tráfego, embora provavelmente entregue maior atraso e custo monetário.

A extensão mede o tempo de ida e volta. A envia um Hello com t1. B registra t1', devolve esses valores num IHU e inclui outro Hello marcado em t2'. Quando A recebe em t2, calcula RTT = (t2 - t1) - (t2' - t1').

Cada diferença usa um relógio só. As origens podem ser arbitrárias e não é necessária sincronização. O algoritmo remonta ao trabalho de Mills em RFC 891, com contexto temporal relacionado em RFC 5905.

O registro IANA Babel Parameters reserva o tipo 3 para Timestamp. O Hello leva quatro octetos; o IHU, oito. Corpos curtos são ignorados e dados extras não bloqueiam o campo conhecido. O fio permanece pequeno e extensível.

O ponto do timestamp pertence à evidência

O instante de transmissão deve ser capturado o mais tarde possível antes de entregar o pacote à pilha. O de recepção, o mais cedo possível depois de recebê-lo. Antecipar ou atrasar esses pontos mistura fila local e escalonamento com a propriedade do link.

Por isso o RFC descreve uma técnica que insere PadN e o substitui no último momento. O formato sozinho não prova que dois produtos medem a mesma superfície. Versão, ponto de instrumentação e fonte do relógio precisam acompanhar o dado.

Os contadores usam microssegundos em 32 bits e dão a volta perto de 71 minutos. Reinicializações também mudam a origem. Uma janela recomendada de três minutos descarta amostras futuras, antigas ou incoerentes. A vizinhança pode sobreviver enquanto uma amostra não merece alimentar o RTT.

Taxa de aceitação, idade, descarte e eventos de reboot fazem parte do recibo. Uma média final sem esses campos pode parecer tranquila por falta de observação.

Três barreiras entre atraso e rota

RTT bruto é ruidoso. Uma rajada cria pico. Pior: uma rota de baixo atraso atrai tráfego, o tráfego cria fila, a fila eleva atraso e a rota perde preferência. Quando o tráfego sai, ela volta a parecer melhor. A seleção retroalimenta a variável observada.

O estudo A delay-based routing metric documenta essa dificuldade. Os autores relatam ausência de oscilação em testes reais e períodos de minutos em cenários adversos artificiais. O resultado sustenta as salvaguardas sob condições testadas, não uma garantia geral.

Primeiro vem a média exponencial: RTT := α RTT + (1 - α) RTTn. Alpha recomendado fica entre 0,8 e 0,9; o padrão é 0,836. A memória reduz outliers e adia mudanças genuínas.

Depois vem o mapeamento limitado. Abaixo de rtt-min, o custo permanece C. Entre mínimo e máximo, cresce linearmente. Acima de rtt-max, a penalidade para de crescer. Os padrões recomendados são 10 ms, 120 ms e 150.

Por fim, histerese impede que pequenas diferenças substituam a rota continuamente. Estabilidade é comprada com informação descartada e tempo de reação.

Os patamares não conhecem o negócio

Com 10 ms no limite inferior, 1 e 9 ms são equivalentes para essa parcela do custo. Isso é útil quando qualquer link local basta. É inadequado quando o produto depende exatamente dessa diferença.

Com 120 ms no limite superior, 130 e 600 ms recebem a mesma penalidade adicional. O teto contém instabilidade e mantém links ruins como último recurso. Se todas as alternativas forem ruins, ele elimina uma distinção que ainda pode importar.

Reduzir rtt-max estabiliza e comprime mais valores. Aumentá-lo preserva discriminação e aceita mais movimento. A penalidade 150 não equivale a 150 ms de dano, perda, banda ou dinheiro. É um peso no cálculo.

Parâmetros padrão continuam sendo escolhas. Alguém deve declarar o que é local, o que é evitável, quanta dívida de convergência é aceitável e quais sinais de serviço podem contestar o custo.

A histerese mantém também decisões antigas

RFC 9616 admite que a resposta lenta pode conservar uma rota subótima por segundos ou minutos depois de uma mudança real. Em overlay fixo, a troca pode evitar reordenação e flapping. Em rede móvel, pode representar uma topologia que já não existe.

Poucas trocas provam calma, não adequação. Testes devem alterar propagação, capacidade e carga separadamente; cruzar 10 e 120 ms; reiniciar vizinhos; aguardar wrap; mover um nó. Cada ensaio deve ligar mudança física, primeira amostra, média, custo, seleção, FIB e primeiro pacote.

O RTT medido ainda pertence a uma adjacência. Não inclui automaticamente filas posteriores, perda de ponta a ponta, retransmissão, servidor ou dependência de aplicação. Uma rota de menor custo pode carregar um serviço pior sem contradizer o cálculo.

Um inventário por adjacência

O rollout correto não é uma porcentagem de equipamentos. É uma matriz de pares: quem envia Timestamp, quem o entende, que métrica substitui a ausência e qual caminho atravessa a fronteira. Um nó antigo que se torna trânsito pode mudar o sentido de várias rotas sem qualquer sessão cair.

Testar a mistura exige retirar suporte, reiniciar cada lado, tornar o nó não estendido caminho preferido e observar a reversão. Compatibilidade preserva conectividade e segurança de loop; não promete uniformidade nem ótimo global.

Esse limite não repete RFC 9647. O modelo YANG torna configuração e estado observáveis. RFC 9616 define como uma amostra específica participa do custo. Ver um campo não prova sua origem nem seu efeito.

A opção de privacidade muda o cálculo

Os timestamps têm origem arbitrária, logo não revelam diretamente horário civil, fuso ou boot. Ainda assim, relógios precisos podem ajudar inferência de localização. O nó pode omitir Timestamp e fazer vizinhos voltarem à contagem de saltos.

Essa recusa é parte do desenho. Ela preserva decisão local, mas altera evidência de rota. A operação deve registrar interfaces emissoras, ameaça, fallback e impacto. Não se deve chamar a ausência de falha automática; tampouco ignorar que ela pode mudar o caminho.

O princípio é fino: padronizar apenas o necessário à interoperabilidade, permitir adoção ou recusa local e exigir execução observável antes de transformar recomendação em autoridade.

Cinco recibos, não um painel

Primeiro, proveniência temporal: implementação, ponto de captura, relógio, wrap, reboot, aceites e descartes. Segundo, transformação: alpha, limites, penalidade, custo nominal e histerese.

Terceiro, decisão: candidatos, custos, rota escolhida, causa e tempo para assentar. Quarto, execução: RIB, FIB, próximo salto, pacote e perda. Quinto, produto: distribuição de latência, vazão, conclusão e erro percebido.

Só a cadeia completa permite afirmar que a métrica melhorou um serviço sob condições definidas. O custo isolado prova apenas o julgamento do algoritmo configurado.

Fontes