Resumo

  • O FQ-PIE classifica a cinco-tupla visível em buckets finitos, mantém estado PIE por fila e distribui serviço com um escalonador derivado de DRR.
  • Uma marca ECN ou um descarte comprova a ação daquele nó, mas não a reação do emissor, o fim do congestionamento ou a equidade entre clientes.
  • Classificação, medição, decisão de congestionamento, serviço da fila e resultado precisam de recibos separados e relacionáveis.

Dois sinais, duas cadeias de prova

Considere dois pacotes que chegam ao mesmo gargalo. O primeiro é ECN-capable e recebe uma marca. O segundo não oferece a mesma opção e é descartado. Um painel pode somar ambos como “sinais de congestionamento”, mas as consequências não são equivalentes. A marca ainda precisa atravessar o caminho, ser refletida pelo receptor e alterar a conduta do emissor. O descarte ainda precisa ser percebido e atribuído pelo mecanismo de transporte.

O nó local sabe apenas o que viu e o que decidiu. Ele não sabe, naquele instante, se a taxa caiu, se outra fila a jusante domina a latência ou se o aplicativo terminou melhor. Transformar a marca em “congestionamento resolvido” seria acrescentar fatos não observados. Transformar o descarte em culpa de um cliente cometeria o mesmo erro em outra direção.

A revisão 02 de Flow Queue PIE, Internet-Draft do TSVWG datada de 6 de julho de 2026, combina filas por fluxo com o controlador PIE. O documento expira em 7 de janeiro de 2027. O Datatracker o apresenta como documento ativo do grupo de trabalho, com estado IESG I-D Exists; o texto propõe status Experimental. Portanto, não é um RFC.

O bucket não conhece o cliente

O classificador usa protocolo, endereços de origem e destino e portas de origem e destino. Essa cinco-tupla é submetida a hash e mapeada em uma tabela finita de filas. A escolha contém o custo da implementação, mas não cria uma identidade comercial ou social.

Duas cinco-tuplas não relacionadas podem colidir no mesmo bucket e compartilhar estado PIE e oportunidade de serviço. No sentido oposto, um único aplicativo pode abrir várias conexões, ocupar diversos buckets e receber várias oportunidades de escalonamento. Um relatório de “equidade por fila” pode ser rigorosamente verdadeiro e ainda não responder como a capacidade foi dividida entre assinantes, contas, empresas ou aplicações.

O recibo de classificação deve manter a chave visível, a época de perturbação do hash, o tamanho da tabela, o bucket escolhido e sinais de colisão. Sem isso, um número de fila parece uma identidade durável, quando é apenas um endereço operacional sujeito à configuração.

Um túnel pode conter uma multidão

Encapsulamento opaco muda a unidade que o classificador enxerga. Muitas sessões dentro de uma VPN podem surgir como um único fluxo externo. Ao lado, tráfego não encapsulado do mesmo ator pode formar várias cinco-tuplas. Não existe interpretação universalmente correta: em uma fronteira, o túnel pode ser a unidade desejada; em outra, o compromisso de serviço pode ser por assinante ou aplicação.

A solução não é expor identidade interna sem limites. Isso pode ferir privacidade e segurança. A solução de governança é declarar a unidade observável, declarar a unidade protegida e registrar a qualidade do vínculo entre elas. Quando o vínculo não existe, a incerteza deve permanecer visível.

PIE controla estado amostrado

Para cada fila, PIE ajusta a probabilidade de descarte conforme a diferença entre o atraso medido e um alvo, além da direção da mudança. O RFC 8033 usa 15 milissegundos como exemplo de alvo e como intervalo padrão de atualização. Esses números descrevem um controlador; não prometem que cada pacote ficará abaixo de 15 milissegundos.

O mecanismo inclui tolerância a rajadas. Enquanto houver crédito, uma chegada pode escapar da decisão aleatória mesmo com atraso temporariamente acima do alvo. Isso evita punir uma rajada curta como se fosse congestionamento persistente. Para avaliar o comportamento, é preciso observar alvo, crédito restante, probabilidade, amostra, atualização e recuperação ao longo do tempo.

PIE pode estimar atraso a partir do tamanho da fila e da taxa de saída pela Lei de Little, ou usar timestamps. O rascunho recomenda timestamps diretos para FQ-PIE porque estimar a taxa de saída de cada fila é difícil. Mover um pacote da fila do host ao anel do driver não significa que ele já foi transmitido no enlace.

Mesmo uma amostra direta pode ser autêntica e pouco representativa. A atualização pode usar o atraso do pacote mais recentemente retirado da fila. Se a taxa ou o padrão de chegadas mudou, esse valor envelheceu. Ponto de medição, horário, idade da amostra, valor anterior, atualização e estado de offload pertencem ao mesmo registro.

Saturação não é certificado de culpa

Se a capacidade total de pacotes estiver esgotada, o novo pacote é descartado sem processamento adicional. O evento prova não admissão local. Não identifica automaticamente um “fluxo gordo”, um cliente culpado ou a melhor remediação.

FQ-PIE também não replica o procedimento de limite saturado do FQ-CoDel que procura a maior fila em bytes e descarta uma parcela em massa. O rascunho argumenta que uma queda em massa poderia deixar o enlace subutilizado porque PIE já atua na entrada. A ausência dessa atribuição deliberada precisa aparecer na interpretação: um descarte de capacidade não é uma sentença sobre responsabilidade.

Serviço de DRR não é igualdade de conclusão

O escalonador derivado de deficit round robin usa quantum e deficit para visitar filas ativas. Uma visita registrada, deficit positivo e bytes enviados comprovam serviço para aquele bucket. Não comprovam tempo de conclusão igual. Tamanho de pacote, RTT, algoritmo de congestionamento, demanda, gargalos posteriores e quantidade de fluxos por ator continuam alterando o resultado.

Um enlace ocupado também não resolve a questão distributiva. Ele pode coexistir com colisões, um túnel enorme em uma fila e um aplicativo espalhado por oito. Utilização, atraso médio, contagem de filas e experiência do cliente têm denominadores diferentes e não devem ser fundidos em um selo de equidade.

O rascunho cita implementações em Linux, FreeBSD e ns-3. Isso demonstra disponibilidade de código, não a configuração de uma interface específica, os parâmetros realmente usados, a posição do timestamp ou o resultado em produção. Interação com BBR, limiar entre marca e descarte, fluxos curtos, melhorias de PIE e hashes alternativos aparecem como trabalho experimental em aberto.

Fontes