Resumo

  • PADDING é um frame de um byte, sem conteúdo nem valor semântico; acrescenta bytes, mas não transporta dados da aplicação, STREAM ou CRYPTO.
  • Um pacote formado apenas por PADDING fica em trânsito e consome a janela de congestionamento sem provocar os ACK que a abrem; o RFC 9000 diz que o emissor SHOULD acrescentar periodicamente outros frames ack-eliciting.
  • O cliente MUST expandir para pelo menos 1200 bytes todo datagrama UDP que carregue Initial; o servidor MUST fazer isso somente quando o datagrama carregar um pacote Initial ack-eliciting. Nenhuma dessas regras prova progresso.

Um operador vê um datagrama UDP de 1200 bytes e registra “Initial útil”. Em seguida, observa o crescimento dos bytes em trânsito e conclui que o transporte avançou. O erro está em juntar fatos de registros diferentes: comprimento do datagrama UDP; limites e tipos dos pacotes QUIC; quantidade de bytes de PADDING; presença de frames que provocam ACK; bytes em trânsito; mudanças na janela de congestionamento; ACK; estado do handshake; e resultado da aplicação.

Um frame QUIC PADDING tem o tipo 0x00 e consiste somente no byte identificador. Não tem conteúdo nem valor semântico. Pode aumentar o tamanho do pacote, ajudar a atingir o tamanho mínimo de Initial e reduzir parte das informações disponíveis para análise de tráfego. Não carrega dados da aplicação, STREAM ou CRYPTO, confirmação, resultado ou sinal de conclusão. Seus bytes não provam processamento útil pelo par, avanço do handshake ou entrega à aplicação.

Um datagrama pode levar um Initial com PADDING e outros frames, ou vários pacotes reunidos por coalescência de pacotes. O comprimento sozinho não mostra quais bytes fizeram o handshake avançar. Essa avaliação exige análise autorizada das fronteiras dos pacotes e dos frames protegidos. Um pacote que contém PADDING também pode conter um frame ack-eliciting e ser confirmado. O ACK é apenas evidência limitada do processamento do pacote segundo a semântica do QUIC; não transforma PADDING em conteúdo de handshake ou da aplicação.

Um pacote ack-eliciting contém um frame diferente de ACK, PADDING e CONNECTION_CLOSE. PADDING sozinho não faz o receptor enviar ACK. Ainda assim, um pacote que contém PADDING fica em trânsito para fins de controle de congestionamento. Um pacote somente de PADDING consome a janela, mas não gera os ACK que a abrem. Por isso o RFC 9000 diz que o emissor SHOULD acrescentar periodicamente outros frames ack-eliciting. O aumento de bytes em trânsito não equivale a progresso útil.

A regra dos 1200 bytes é específica. O cliente MUST expandir todo datagrama UDP que carregue um pacote Initial para pelo menos 1200 bytes, usando PADDING ou coalescência de pacotes. O servidor MUST fazer o mesmo para um datagrama que carregue um pacote Initial ack-eliciting. A regra testa o suporte a uma MTU razoável do caminho; a expansão do cliente também reduz a amplificação disponível ao servidor antes da validação do endereço. Não exige 1200 bytes de conteúdo de handshake e não significa que todo Initial use PADDING.

Antes da validação do endereço, todos os bytes de payload UDP atribuíveis à conexão entram no limite de três vezes do servidor, inclusive os bytes PADDING. Ausência de significado não significa custo zero. PADDING pode alterar tamanhos observáveis e reduzir alguma informação da análise de tráfego, mas não garante privacidade nem esconde tempo, direção, número de pacotes ou todos os comprimentos. A retenção segura e o registro separado são recomendações editoriais, não requisitos do QUIC.