Summary

  • A versão 02 do rascunho STAMP CoS ECN usa EC1 para pedir um valor ECN no pacote refletido e RPE para informar se o refletor conseguiu aplicá-lo; EC2 conserva a marca do pacote recebido na ida.
  • O refletor capaz de aplicar a marca informa RPE=0b11; se precisar usar zero, informa 0b10. Um equipamento que só conhece RFC 8972 devolve 0b00 nos bits que antes eram reservados, sem habilitar o teste novo do caminho de volta.
  • Com várias sondas ECT dentro de um tempo de ida e volta, o emissor deve observar CE e conseguir diminuir os pacotes próprios e os retornos que induz.

O protocolo STAMP divide a tarefa entre um emissor e um refletor. O primeiro manda um pacote de teste; o segundo responde. Esse arranjo mede caminhos sem exigir uma conversa longa entre as pontas. Também facilita aumentar a cadência até que o instrumento passe a disputar capacidade com o tráfego que pretende estudar. A sonda tem peso, mesmo quando sua finalidade é apenas observar.

Pelo RFC 8972, o refletor já podia copiar para EC2 o ECN do pacote recebido. Era uma amostra da ida. Para investigar a volta faltava controlar a marca ECN do pacote de resposta. Se o refletor saísse com a marca errada, uma resposta sem CE não diria nada sobre o tratamento de um pacote ECN-capaz no retorno.

O rascunho de 2 de novembro de 2026 preenche essa lacuna com dois campos nos antigos bits reservados. Em EC1, o emissor pede o valor ECN da resposta. Em RPE, o refletor declara sua ação. Se consegue usar o valor solicitado, escreve 0b11. Se política local ou limite da plataforma impede isso, marca o cabeçalho IP com 0b00 e responde 0b10. O emissor então lê o cabeçalho real que chegou. Há três registros a conciliar: o pacote recebido pelo refletor, a escolha feita por ele e o retorno visto na origem.

Um refletor mais antigo trata EC1 e RPE como reservados e deixa RPE=0b00. O emissor descobre assim que a ponta não implementa a extensão. Isso evita um erro estatístico tentador: lançar uma medição sem a condição necessária e publicar o silêncio resultante como saúde da rota. O mesmo vale para 0b10: o refletor avisou que não pôde enviar a marca pedida; a ausência de CE não pode ser creditada ao caminho de volta.

O texto avança da leitura para o comportamento. Se o emissor manda vários testes ECT(0) ou ECT(1) em um RTT, precisa examinar o EC2 devolvido e ter capacidade de reduzir a taxa ao observar CE. Se solicita ECT na resposta por EC1, precisa examinar o ECN do pacote refletido e poder reduzir o fluxo de respostas provocado. Com um mecanismo que solicita várias respostas por teste, também deve ajustar os parâmetros futuros. A responsabilidade acompanha quem controla a campanha, não apenas quem transmitiu fisicamente cada pacote.

O rascunho deixa a fórmula exata de redução para quem implementa, sob as regras de reação a congestionamento de RFC 3168 e RFC 9330. Para medir deliberadamente uma rota sob sobrecarga mantendo a taxa mesmo diante de CE, exige ambiente controlado, acordo dos operadores testados e limites de velocidade, duração e impacto. Um teste programado para esse fim tem uma autorização específica; uma rotina de monitoramento não ganha passe livre porque seu painel se chama observabilidade.

O que o relatório precisa mostrar

Uma diferença entre a marca de saída e EC2, ou entre o pedido EC1 e o cabeçalho recebido, indica mudança em algum ponto do trajeto. Só as duas pontas não identificam o equipamento intermediário. Um pacote de volta sem CE tampouco representa todos os fluxos. A prova de implementação exige captura datada dos dois sentidos, os três campos, cadência de sondas, quantidade de respostas e a reação efetiva do emissor à marca de congestionamento.

A proposta segue como rascunho ativo do grupo de trabalho do IETF. Sua pergunta é imediata para quem opera medições: quando o alarme toca, o teste diminui a própria carga ou apenas continua anotando o barulho que ajuda a produzir?

Rascunho 02 · RFC 8972 · RFC 8762