Resumo

  • O parâmetro vazio reset_stream_at precisa ser anunciado pelo par antes de RESET_STREAM_AT ser enviado. Ele autoriza o formato de transporte, não o significado dos primeiros bytes.
  • Reliable Size é um mínimo entregue, não um corte exato nem uma promessa eterna. Valores posteriores só podem cair; uma mensagem antiga que chega depois não restaura o piso maior.
  • WebTransport impõe separadamente que o cabeçalho de sessão fique dentro do prefixo confiável. É essa regra de aplicação que mantém o stream abortado identificável.

O documento foi aprovado, mas ainda não virou RFC

Marten Seemann e Kazuho Oku apresentaram a revisão 11 de QUIC Stream Resets with Partial Delivery em 6 de setembro de 2026. O Datatracker registra um Internet-Draft Standards Track do grupo QUIC, submetido ao IESG, com revisão IANA “OK — Actions Needed” e estado “Approved-announcement to be sent”. Há uma decisão de aprovação; ainda faltam o anúncio formal e a publicação editorial como RFC. Este texto não antecipa número nem status.

A revisão veio após a teleconferência do IESG de 3 de setembro e responde a comentários concretos. Ela acrescenta a proibição de uso sem negociação, define Reliable Size como mínimo, descreve retransmissão da informação atual, separa testes de consistência, limita o efeito do reordenamento e recomenda zero após STOP_SENDING.

As mudanças expõem uma cadeia de autoridade. O receptor permite a extensão. O emissor declara erro, tamanho final e um compromisso atual. A aplicação conhece o que o cabeçalho significa. O receptor pode depois retirar o interesse. Nenhuma dessas decisões absorve automaticamente as outras.

A permissão vem do estado criado pelo par

O suporte aparece no parâmetro reset_stream_at, valor 0x1d, cujo conteúdo deve ser vazio. Conteúdo não vazio causa TRANSPORT_PARAMETER_ERROR. A revisão 11 diz expressamente que o endpoint MUST NOT enviar o frame tipo 0x24 sem anúncio do par.

Ter código numa biblioteca, conhecer a versão do software ou recordar outra conexão não basta. A autoridade é o handshake desta conexão. O emissor não pode transformar a própria capacidade de serializar o frame em consentimento do receptor.

Com 0-RTT, os dois lados guardam se o servidor havia anunciado a extensão. Se o servidor aceita early data, não pode retirar essa capacidade na conexão retomada. Ele pode rejeitar o 0-RTT, mas não aceitar o contexto anterior e, ao mesmo tempo, negar a condição usada pelo cliente para montar os frames precoces.

Mesmo uma negociação perfeita só prova que o frame pode ser interpretado. Ela não diz qual prefixo associa o stream à sessão nem torna o primeiro mínimo irrevogável.

O piso é mínimo e só se move para baixo

RESET_STREAM_AT traz Stream ID, Application Protocol Error Code, Final Size e Reliable Size. Final Size preserva a contabilidade total do stream. Reliable Size determina a menor quantidade que deve chegar à aplicação apesar do reset. Se for maior que Final Size, a conexão termina com FRAME_ENCODING_ERROR.

Dados perdidos abaixo do piso precisam ser retransmitidos. Acima dele, o emissor não deveria retransmitir, mas a pilha receptora pode entregar bytes que já chegaram. O campo não é uma ordem de apagar, nem limita a aplicação a exatamente aquele número.

Um frame posterior pode reduzir o valor. RESET_STREAM equivale, para entrega, a levar Reliable Size a zero. O movimento é monotônico: diminuir é permitido; aumentar, não. A informação que carrega o valor vigente e os dados abaixo dele continuam sendo reenviados até reconhecimento.

Isso entrega ao emissor uma opção de recuo. Ele pode abandonar parte do compromisso antes anunciado, porém não pode recuperar um compromisso maior depois. Para o receptor, vale o menor número válido visto, não o maior registrado historicamente.

Reordenamento não reabre a obrigação antiga

Imagine um anúncio de 80 bytes, seguido por uma redução para 8. O pacote com 8 pode chegar primeiro. Quando o antigo 80 aparece, o receptor mantém 8. A rede não deve poder inverter uma decisão que o protocolo só deixa avançar para baixo.

Na revisão 10, o texto mandava ignorar o frame que elevasse Reliable Size. Era possível interpretar isso como descarte também das verificações de Error Code e Final Size. A revisão 11 ignora apenas o aumento. O Error Code deve permanecer igual entre resets; Final Size deve coincidir nos resets e em STREAM com FIN. Mudanças levam a STREAM_STATE_ERROR ou FINAL_SIZE_ERROR.

Os campos compartilham o frame, não a mesma validade temporal. O piso pode estar obsoleto e os demais campos ainda exigirem verificação. Um parser que descarta tudo perde evidência de inconsistência.

A aplicação precisa declarar o prefixo essencial

O draft QUIC permite que protocolos de aplicação fixem um limite abaixo do qual Reliable Size não pode cair. Essa delegação é necessária. O transporte conhece offsets; não sabe que os primeiros bytes identificam sessão, assinatura, assinatura de objeto ou assinatura de subscrição.

Na revisão 16 de WebTransport over HTTP/3, um reset de stream de dados deve usar RESET_STREAM_AT com Reliable Size cobrindo pelo menos o cabeçalho WebTransport. O ID ali contido vincula o stream à sessão. Sem ele, chega um erro sem dono claro e o receptor pode não saber qual estado ou quota ajustar.

O draft Media over QUIC Transport usa regra próxima, porém mais flexível: Reliable Size deveria incluir o cabeçalho do subgroup stream para identificar a subscrição e contabilizar streams resetados em PUBLISH_DONE. Um cabeçalho perdido pode deixar estado preso até timeout.

MUST e SHOULD não são sinônimos. Eles mostram que cada aplicação governa sua própria perda aceitável. QUIC oferece o mecanismo de piso decrescente; WebTransport e MoQ dão significado e consequência ao prefixo.

STOP_SENDING altera o beneficiário da confiabilidade

STOP_SENDING informa que a aplicação receptora não quer mais dados. A revisão 11 recomenda Reliable Size zero quando a resposta ainda usa RESET_STREAM_AT. Retransmitir um prefixo positivo depois da retirada de interesse consome congestion window, crédito, buffer e tempo sem um beneficiário disposto a processá-lo.

O zero cria uma saída definida para o reset normal e prova que o valor inicial não é dívida perpétua. Um intermediário pode precisar de cabeçalho para encaminhar o erro ou fechar contabilidade em outro salto. Nesse caso, o protocolo superior deve registrar a exceção, sua extensão, seu prazo e quem arca com a persistência.

Confiabilidade é obrigação limitada, não poder para ignorar cancelamento. Sem proprietário e condição de término, o recurso útil vira retenção de recursos alheios.

Recursos continuam comprometidos depois do nome “reset”

Final Size continua sujeito ao flow control do stream e da conexão. Sem crédito suficiente, o emissor pode precisar adiar RESET_STREAM_AT. Ultrapassar o limite resulta em FLOW_CONTROL_ERROR. O frame pede ACK; sua informação e os bytes confiáveis são reenviados em caso de perda.

O lado emissor só chega a Data Recvd depois que o piso vigente e seu prefixo são reconhecidos. O receptor espera os dados correspondentes. Até esse momento, persistem riscos de compromisso e exaustão de recursos.

Uma operação séria acompanha anúncio da extensão, primeiro e menor Reliable Size, Final Size, retransmissões, bloqueio de crédito, momento de STOP_SENDING, tempo até o estado terminal e objetos mantidos até timeout. Contar apenas frames de reset produz uma métrica bonita e incompleta.

Limites da apuração

As fontes comprovam texto, histórico e raciocínio de revisão. Não comprovam adoção, desempenho, interoperabilidade ou incidente em produção. Nenhum navegador, CDN, relay, stack QUIC ou serviço de mídia foi testado. O estado IANA ainda pede ações; não afirmamos que todo registro solicitado já seja definitivo.

As versões citadas de WebTransport e MoQ também são drafts. Servem como exemplos de contrato de aplicação, não como previsão do texto final. A própria revisão 11 ainda pode mudar durante publicação.

O achado durável é uma separação: permissão de frame, mínimo atual, cabeçalho indispensável e vontade de parar têm donos diferentes. O running code deve preservar essa separação em estado, teste e telemetria.

Fontes