Resumo

  • A revisão 21 do QUIC multipath mantém recuperação e congestionamento por caminho, mas não prova que esses caminhos atravessem gargalos diferentes.
  • Dois controladores localmente corretos podem disputar o mesmo recurso e obter, em conjunto, uma vantagem indevida; a política de escalonamento e qualquer acoplamento continuam sendo decisões da implementação.
  • A avaliação precisa combinar evidência de gargalo, decisões do escalonador, comportamento diante de fluxos concorrentes e entrega percebida pela aplicação.

O teste foi aprovado em dois painéis. O caminho A mostrou uma evolução de janela plausível. O caminho B também. Nenhum excedeu o limite que o fornecedor havia definido para si. No roteador de acesso, porém, um fluxo comum perdeu espaço enquanto os dois caminhos da mesma conexão avançavam como concorrentes separados.

Não havia necessariamente um defeito em cada controlador. Havia uma pergunta não respondida sobre o conjunto.

A revisão 21 de “Managing multiple paths for a QUIC connection” foi aprovada pela IESG em 18 de março de 2026 e encaminhada ao RFC Editor no dia seguinte. Em 2 de outubro, aguardava um segundo editor. Ainda não é RFC. Essa condição importa tanto quanto a diferença entre o que o texto especifica e o que uma implementação escolhe.

O documento define negociação, identificadores de caminho, espaços separados de números de pacote, associação com connection IDs, validação, PATH_ACK, sinais AVAILABLE e BACKUP, abandono e recuperação por caminho. Com isso, dois extremos podem manter vários percursos de uma conexão sem inventar vocabulários incompatíveis.

Ele também exige estado de congestionamento por caminho. Essa separação é necessária: perdas, atrasos e PMTU podem diferir. Mas Path ID é identidade de protocolo, não laudo topológico. Múltiplos Path IDs podem usar o mesmo quarteto de endereços e portas. Mesmo quartetos diferentes podem convergir no mesmo rádio, enlace de acesso, túnel, porta de trânsito ou fila de nuvem.

O gargalo não lê o Path ID

Um controlador reage ao que observa. Se dois controladores enxergam sinais parcialmente independentes, ambos podem aumentar sua oferta até que o recurso compartilhado imponha perda ou fila. Cada trajetória local pode parecer coerente. Para o fluxo que compete com a soma delas, o resultado pode ser injusto.

O RFC 6356 tratou desse problema no contexto de controle de congestionamento acoplado para multipath TCP: uma conexão com vários subfluxos não deveria conquistar em um gargalo compartilhado mais capacidade do que um fluxo regular obteria. A revisão 21 de QUIC multipath referencia o ecossistema de recuperação e congestionamento, mas não fornece por si só uma política universal que resolva toda topologia e todo escalonador.

O ponto não é transplantar mecanicamente um algoritmo. É reconhecer que justiça é uma propriedade relacional. Ela depende dos fluxos concorrentes, do gargalo efetivo, do horizonte de medição e da ação conjunta dos caminhos. Não pode ser certificada examinando duas máquinas de estado isoladas.

Disponibilidade não é independência

A validação de caminho confirma que o par recebe no endereço e ajuda a controlar amplificação. AVAILABLE informa que o caminho pode receber tráfego conforme a lógica do outro extremo. BACKUP pede que ele permaneça em reserva enquanto existir outro caminho utilizável. Nenhum desses estados afirma que a capacidade seja exclusiva.

Também não afirmam preço, consentimento ou objetivo. Um caminho celular e um Wi-Fi podem sair pelo mesmo backhaul. Dois túneis podem compartilhar o mesmo provedor. Um par pode marcar ambos disponíveis sem conhecer a cota do usuário. Se todos forem BACKUP, o projeto não impõe qual deve ser o primeiro. O extremo pode ainda ignorar a preferência recebida.

O escalonador, portanto, participa do resultado. Ele decide quais pacotes entram em cada controlador e quanta evidência cada caminho produz. Um caminho que recebe mais tráfego oferece mais amostras; outro, pouco explorado, parece incerto. A política pode reforçar a própria escolha inicial.

Medir o agregado exige um concorrente

Um ensaio que envia somente a conexão multipath mostra utilização, não justiça. É preciso introduzir fluxos de referência e variar a hipótese de gargalo. Se os dois caminhos forem realmente independentes, a soma pode crescer sem prejudicar um concorrente em um recurso único. Se compartilharem o gargalo, o teste deve observar se a conexão multipath toma uma parcela desproporcional.

Os sinais úteis incluem correlação entre fila e perda, resposta de um caminho quando o outro reduz carga, vazão do fluxo de referência, tempo de conclusão da aplicação e estabilidade após mudança do escalonador. A topologia declarada pelo fornecedor é uma fonte, não o veredito final.

PATH_ACK acrescenta um cuidado. A confirmação pode voltar por caminho diferente daquele que levou o pacote. O RTT observado reúne ida, volta e decisão do escalonador. Rotular a amostra como latência de um único caminho pode induzir o sistema a deslocar tráfego e alterar a própria competição que tenta medir.

PMTU também é específica por caminho, inclusive quando Path IDs compartilham o mesmo quarteto. Retransmitir por outro caminho pode exigir novo enquadramento. A revisão 21 deixa a estratégia detalhada de retransmissão fora do escopo: mesmo caminho, outro caminho ou vários são escolhas possíveis. Duplicar dados pode reduzir um prazo em certos casos e agravar um gargalo compartilhado em outros.

Um recibo de justiça operacional

Para sustentar uma afirmação, o operador deveria guardar:

  1. Path IDs, connection IDs, quartetos e idade da validação;
  2. sinais AVAILABLE/BACKUP enviados e recebidos;
  3. estado de congestionamento e perda por caminho;
  4. hipótese e evidência de gargalo compartilhado;
  5. versão, entradas e motivo do escalonador;
  6. fluxos concorrentes usados como referência;
  7. PMTU, rota do PATH_ACK e decisões de retransmissão;
  8. bytes, classe de aplicação e prazo atribuídos;
  9. custo, cota, segurança e consentimento consultados;
  10. vazão, fila e perda no recurso agregado; e
  11. conclusão observada pela aplicação.

Esse recibo permite separar falhas distintas. Talvez a topologia compartilhe um gargalo que o inventário chamava de independente. Talvez o escalonador tenha concentrado sondas. Talvez o controle agregado seja agressivo. Talvez a aplicação não tenha melhorado por esperar a ordem de um stream. Cada hipótese exige uma correção diferente.

A aprovação da IESG não certifica nenhuma delas. O histórico de revisão mostra que política de escalonamento, quantidade de caminhos, cota e consentimento foram preocupações explícitas. O documento pode estar tecnicamente pronto para avançar enquanto as escolhas comerciais e operacionais continuam pertencendo ao implantador.

Por isso, uma afirmação honesta evita “dois caminhos dobraram a capacidade”. Ela diz que dois contextos de protocolo foram validados, que determinada política os utilizou sob uma topologia observada, que a competição agregada se comportou de tal maneira e que a aplicação obteve certo resultado. Essa formulação não diminui o multipath; ela torna seu valor verificável.

Fontes