Resumo

  • RFC 9768 define o receptor como refletor mecânico genérico de informações ECN; a resposta do controle de congestionamento fica fora de escopo.
  • ACE usa três bits essenciais e sofre com voltas rápidas do contador; três contadores opcionais de 24 bits medem bytes com mais detalhe, mas podem ser removidos ou perder espaço.
  • A operação precisa guardar a reconstrução e a decisão do emissor como etapas separadas, sem converter uma marca CE em medida de fila ou ordem de redução.

O número no painel não basta

O ECN clássico de TCP consegue devolver no máximo uma indicação por RTT. Vários pacotes CE dentro do mesmo intervalo acabam comprimidos numa resposta binária. Isso limita algoritmos que querem reagir à proporção de marcação. Publicado em abril de 2026 no Standards Track, RFC 9768 atualiza o feedback e a negociação TCP de RFC 3168 com o Accurate ECN.

A mudança é propositalmente estreita. O receptor conta codepoints nos segmentos aceitáveis e repete o estado. O emissor, que sabe quais codepoints colocou nos pacotes, reconstrói os incrementos, avalia a coerência e escolhe seu algoritmo. AccECN não determina se a resposta será DCTCP, CUBIC, uma resposta escalável de L4S ou outra futura.

Essa separação explica a expressão “refletor mecânico genérico”. O receptor fornece evidência reutilizável. Ele não se torna um controlador remoto do emissor.

A trilha essencial de três bits

ACE reaproveita três flags TCP e carrega os três bits inferiores do contador de pacotes CE do receptor. Como o valor atual é repetido, um ACK isolado perdido não apaga necessariamente a informação. Mas um módulo de oito dá voltas depressa.

Depois do valor seis, observar um pode significar incremento mínimo de três ou uma diferença maior que inclua voltas completas. ACKs atrasados, perdidos, filtrados ou fora de ordem mudam a reconstrução. RFC 9768 exige feedback frequente e recomenda limites ainda menores conforme os dados sem confirmação, porém o emissor ainda precisa registrar quando escolheu uma hipótese conservadora.

ACE conta pacotes TCP aceitáveis com CE, incluindo controle e retransmissões, com exceção do SYN. Não conta bytes únicos entregues à aplicação. Essa distinção impede comparar um gráfico ACE diretamente com o volume de negócio.

Três trilhas detalhadas de bytes

A opção AccECN transporta os 24 bits inferiores dos contadores de payload recebido com CE, ECT(0) e ECT(1). Cabeçalhos não entram; payload retransmitido entra novamente. O módulo amplo quase elimina uma volta invisível durante uma lacuna plausível de ACK e permite estimar proporções de marcação.

O custo é depender de opção TCP. SACK disputa os mesmos bytes e tem prioridade quando a opção mínima de AccECN não cabe ao lado de dois blocos SACK. Middleboxes podem retirar opções desconhecidas. Proxies terminam uma conexão e iniciam outra. GRO e LRO alteram agrupamento e tempo no ponto observado. A opção pode sumir no meio da conexão.

Por isso os contadores de bytes complementam ACE e nunca o substituem. O canal obrigatório é grosseiro; o canal detalhado é condicional. O emissor estabelece bases modulares e reconcilia ambos, considerando que um conta pacotes e o outro bytes.

O contrato começa no handshake

Combinações de AE, CWR e ECE negociam AccECN no three-way handshake e permitem fallback para ECN clássico ou nenhum ECN. A opção não vai no SYN inicial, cujo espaço é crítico; sua passagem é testada no SYN/ACK e no primeiro ACK. Assim, negociar AccECN não prova que os contadores de 24 bits estarão disponíveis.

Valores iniciais não nulos ajudam operação sem estado e revelam dispositivos que zeram bits. Ao mesmo tempo, uma implementação não deve exigir uma única sequência inicial: reservar flexibilidade evita prender futuras extensões. Reordenamento pode produzir legitimamente um primeiro ACE zero.

O caminho também pode alterar campos ECN numa única direção. O receptor não sabe o que o emissor colocou originalmente. A validação pertence ao emissor de dados, que compara histórico de envio, ACE e opção. Apenas segmentos aceitáveis, sujeitos às verificações TCP atuais, podem avançar os contadores.

Reconciliação antes da atribuição

Se os bytes CE sobem mas o contador de pacotes não pode acompanhar, o emissor investiga retransmissão, unidades, perda de ACK, wrap, mudança de opção e manipulação do caminho. Sem explicação válida, pode desabilitar ECT naquela metade da conexão. É uma contenção local, não uma identificação forense do equipamento responsável.

O codepoint CE afirma que o pacote chegou marcado. Não informa comprimento de fila, limiar, fabricante, operador ou dano à aplicação. Também não impõe uma redução específica. Um painel que transforma contagem em “congestionamento causado pela rede X” misturou a camada de observação com a de inferência.

O recibo deve registrar por direção: flags negociadas, ECN enviado e recebido, série ACE, deltas modulares, bases e deltas dos três contadores de bytes, formato e presença da opção, sequência e lacunas de ACK, pressão de SACK, retransmissões, offload, proxy, resultados de reconciliação, decisão sobre ECT, algoritmo e ação do emissor. Fila, vazão e latência da aplicação entram como observações independentes.

Testes devem perder ACKs, esconder uma volta inteira, reordenar o primeiro retorno, remover a opção após a negociação, encher o espaço com SACK, zerar bits e alterar ECN assimetricamente. O resultado correto pode ser menos precisão; nunca deve ser uma certeza inventada.

Fontes