Resumo

  • O RFC 10055 registra as APIs usadas para habilitar ECN sobre UDP no Chromium em Apple, Linux e Windows; é um documento Informational, sem impor uma API única aos sistemas.
  • A aplicação só consegue usar o sinal se ativar a opção correta, ler os dados auxiliares de cada datagrama e interpretar a representação específica da plataforma.

O roteador pode marcar o pacote corretamente. O kernel pode preservar os bits. Mesmo assim, o controle de congestionamento do transporte pode continuar sem saber o que aconteceu. O RFC 10055 trata dessa passagem: a interface de socket entre o campo ECN no IP e o código UDP que precisa alimentar uma resposta.

O documento registra experimentos realizados para fazer o ECN funcionar sobre UDP no Chromium em Apple, Linux e Windows. Seu status é Informational; ele não obriga os sistemas operacionais a implementar um conjunto comum de chamadas. O próprio RFC delimita seu alcance como um retrato da época em que foi escrito e recomenda consultar a documentação atual de cada plataforma.

O ECN ocupa dois bits do cabeçalho IP. O RFC 3168 define a notificação explícita de congestionamento, e a arquitetura L4S do RFC 9330 usa esses sinais de maneira mais frequente. Já o QUIC, que usa UDP, verifica os contadores ECN por caminho e pode desativar a marcação quando a validação falha, conforme o RFC 9000. Para validar, o transporte precisa observar as marcas que chegaram ao host.

No recebimento, o RFC 10055 distingue habilitar a notificação no socket de extrair a marca de cada pacote. Em Linux, Apple e FreeBSD, IPv4 usa IP_RECVTOS; IPv6 usa IPV6_RECVTCLASS. Depois, a aplicação lê os dados auxiliares com recvmsg(). No Linux, um socket IPv6 que também recebe IPv4 precisa habilitar adicionalmente IP_RECVTOS. O procedimento descrito para Apple e FreeBSD não exige esse ajuste extra.

O Windows segue outra rota. A documentação recomenda WSASetRecvIPEcn(), com os dados de controle disponíveis via WSARecvMsg. O RFC, porém, descreve ressalvas para sockets dual stack e endereços IPv4 mapeados em IPv6. O aplicativo deve verificar a configuração concreta e o tipo de mensagem retornada; identificar apenas o socket como IPv6 é insuficiente.

A estrutura do valor também varia. Linux, Apple e FreeBSD podem entregar o byte inteiro do campo DS, que contém DSCP e ECN. No Windows, IP_ECN e IPV6_ECN entregam somente o codepoint ECN. Um parser que pressupõe o mesmo formato para todas as plataformas pode extrair bits errados ou comparar valores que não representam a mesma coisa.

No envio, há marcação persistente por socket e marcação por pacote. Apple, FreeBSD e Linux oferecem a primeira opção na fotografia descrita pelo RFC; um servidor que multiplexa conexões com capacidades ECN diferentes pode precisar da segunda. Naquele momento, o Windows não oferecia marcação por socket. A escolha não é apenas ergonomia: ela define se o estado acompanha o socket ou cada conexão multiplexada. Além disso, gravar em IP_TOS ou IPV6_TCLASS pode afetar o DSCP em alguns sistemas. Uma atualização voltada ao ECN pode sobrescrever a classe de serviço configurada por outro componente, especialmente se houver escritores concorrentes.

Esse limite deve aparecer no diagnóstico. “Não recebemos CE” pode significar que o caminho não marcou, que o socket não foi configurado, que o kernel não enviou os dados auxiliares ou que o parser não reconheceu sua forma. O RFC também observa que suporte ECN desigual pode ajudar um par a identificar o sistema operacional; isso tem implicações de privacidade, mas o documento não fornece uma taxa ou medição do fingerprinting.

Uma matriz de testes deve registrar, por versão do sistema, família IP e modo dual stack, se a opção foi aceita, qual cmsg chegou, qual valor foi extraído, se o DSCP permaneceu intacto e se o transporte validou seus contadores. Receber um código é apenas um recibo da interface: não prova que o emissor adaptou sua taxa ou que o serviço melhorou.

A decisão de arquitetura pode manter o objetivo compartilhado simples — expor a marca correta por datagrama e preservar o DSCP — enquanto deixa cada sistema usar sua própria API. O contrato comum precisa ser observável e testável; a chamada de sistema não precisa ser idêntica.

Fontes