Resumo

  • ECMP oferece ao encaminhador vários próximos saltos de mesmo custo; isso não garante MTU, latência, ordem de chegada ou papel multicast equivalentes.
  • A RFC 2991 compara formas de manter um fluxo no mesmo caminho e limitar quantos fluxos são realocados quando muda o conjunto de próximos saltos.

Um traceroute registra por onde passaram suas próprias sondas. Ele não revela, necessariamente, todas as opções que o roteador tinha nem como outros fluxos foram distribuídos. É aí que a palavra “igual” engana: no ECMP ela descreve uma classificação de custo no roteamento, não a experiência física do caminho.

Em novembro de 2000, Dave Thaler e Christian Hopps publicaram a RFC 2991, um documento Informational sobre encaminhamento multipath. OSPF e IS-IS permitiam explicitamente Equal-Cost Multipath; algumas implementações também o usavam com RIP e outros protocolos. Se havia vários próximos saltos válidos para um destino, o equipamento de encaminhamento ainda precisava escolher um por pacote.

Alternar as saídas por rodada parece distribuir carga, mas pode fazer uma única conversa percorrer caminhos com MTUs e atrasos distintos. A descoberta do MTU de caminho deixa de ter uma condição estável. Se um pacote atrasar e chegar depois dos seguintes, o TCP pode interpretar a ordem como perda, disparar retransmissão rápida e consumir banda adicional. Bufferização e latência também aumentam. Ping e traceroute podem observar ramos diferentes e sugerir uma rota que não representa o conjunto inteiro. No multicast, o limite é estrutural: os protocolos tratados pela RFC construíam uma árvore única até a origem, o núcleo ou o ponto de encontro.

Cada árvore precisava de um só próximo salto em direção à raiz para evitar laços e duplicatas. A escolha por pacote não era apenas uma variação de desempenho.

A RFC chama de “fluxo” a granularidade em que o roteador mantém estado, se mantiver algum. Isso não equivale necessariamente ao microfluxo de cinco componentes da RFC 2474. A chave pode ser apenas o destino ou incluir origem, destino e protocolo. Fragmentos que não são iniciais talvez não tragam campos de transporte; incluir portas na seleção também pode impedir o reaproveitamento de dados de caminho, como o MTU, entre conexões dos mesmos extremos. A definição operacional de fluxo ficou com a implementação, mas não sem consequências.

Manter todos os pacotes do fluxo em um caminho reduz a variação dentro da conversa. Surge então a pergunta sobre mudanças no conjunto de candidatos: quando um próximo salto entra ou sai, quantos fluxos ativos precisam trocar de rota? O ECMP expõe o encaminhamento a mais alterações de membros, e uma oscilação pode ampliar o alcance de perda ou reordenação. A RFC passa a avaliar dois objetivos juntos: pouca perturbação e cálculo leve o bastante para o encaminhador.

O hash módulo N é barato: calcula-se um hash do fluxo e usa-se o resto da divisão pelo número de próximos saltos. Mas, quando N muda, (N-1)/N dos fluxos trocam de caminho, segundo a RFC. O hash por limiar divide o espaço de resultados em regiões; deslocar as fronteiras altera fluxos perto delas, embora a estimativa da RFC seja de um quarto a metade dos fluxos quando um membro é adicionado ou removido. A RFC 2992 analisa essa perturbação. O Highest Random Weight (HRW) calcula um hash para cada par fluxo-próximo salto e escolhe o maior. Uma mudança em um membro afeta cerca de 1/N dos fluxos, mas custa aproximadamente N vezes mais que módulo N.

Essas frações vêm de modelos algorítmicos, não de medições de roteadores em produção. Elas contam fluxos realocados, não bytes, clientes ou impacto no serviço. Poucos fluxos longos podem carregar muito mais tráfego que milhares de fluxos curtos.

O estado por fluxo muda o momento do custo. Quando o encaminhador já mantém estado, pode escolher a saída ao criar o registro, sem recalculá-la em cada pacote. A RFC recomenda HRW para encaminhamento unicast com estado e para multicast, cujo estado por origem/grupo já existe. Sem estado unicast por fluxo, o cálculo ocorre na chegada de cada pacote; se o CPU for mais escasso que a estabilidade, recomenda-se hash por limiar. É uma recomendação condicionada à arquitetura, não um vencedor universal.

Em 2011, a RFC 6438 ainda descrevia o conflito entre dividir a carga, evitar reordenação por fluxo e manter enlaces ocupados. Isso demonstra que o compromisso permaneceu relevante, mas não que todos adotaram as mesmas soluções da RFC 2991.

A lição histórica é separar as camadas. O custo de roteamento classifica candidatos; o seletor local distribui fluxos; os caminhos físicos determinam MTU e latência; o TCP reage ao que recebeu. Estabilidade custa processamento ou pode manter desequilíbrios; remapeamento custa perturbação sobre fluxos existentes. O rótulo “mesmo custo” não escolhe qual conta a rede deve pagar.

Fontes