Summary

  • La revisión 02 del borrador STAMP CoS ECN incorpora EC1, la marca ECN solicitada para la respuesta, y RPE, que informa si el reflector pudo aplicarla. EC2 sigue comunicando el valor ECN recibido en el extremo de ida.
  • El reflector escribe RPE=0b11 cuando aplica el valor pedido y 0b10 cuando debe devolver cero. Uno que solo conoce RFC 8972 devuelve 0b00 en esos bits antes reservados: no demuestra el comportamiento ECN del regreso.
  • Si se envían varias sondas marcadas ECT durante un tiempo de ida y vuelta, el emisor debe atender a CE y poder reducir el tráfico de prueba o la carga de respuestas que controla.

En STAMP, un emisor lanza una prueba y un reflector responde. El trabajo parece inocente hasta que la campaña aumenta la frecuencia. Cada sonda usa capacidad de red; cada respuesta también. Un sistema que necesita averiguar cómo actúan las colas puede convertirse en otro cliente de esas colas y, a veces, en un cliente bastante insistente.

El RFC 8972 permitía que el reflector copiara a EC2 el valor ECN recibido en el paquete de prueba. Esa copia ayuda a observar la ida. El regreso necesitaba una condición adicional: pedir que el reflector enviara un paquete con una marca ECN específica. Sin saber si esa petición se cumplió, recibir un paquete sin CE puede ser una respuesta a una pregunta que nunca se hizo a la red.

El texto del 2 de noviembre de 2026 asigna parte de los antiguos bits reservados a EC1 y RPE. El primero contiene el valor que el emisor quiere en la cabecera IP de vuelta. El segundo explica la acción del reflector. 0b11 indica que colocó la marca solicitada. Si su política o plataforma se lo impide, coloca 0b00 en la cabecera y devuelve 0b10. Al cotejar esos campos con la cabecera del paquete recibido, el emisor separa lo que llegó al reflector de lo que este intentó enviar y de lo que finalmente volvió.

También aparece una prueba de compatibilidad. Un equipo que solo implementa RFC 8972 trata los bits nuevos como reservados y responde con RPE=0b00. Es una forma de descubrir que falta la capacidad, no una manera de certificar que el regreso estuvo libre de congestión. El valor 0b10 cumple otra función: impide que el fallo local del reflector se confunda con una propiedad de la ruta. Antes de atribuir un resultado a la red, hay que demostrar que el paquete usado para medirla tenía la marca prevista.

La obligación de reaccionar cierra el circuito. Con varios paquetes ECT(0) o ECT(1) dentro de un RTT, el emisor tiene que leer EC2 y poder bajar su tasa de envío al observar CE. Si solicita ECT en las respuestas mediante EC1, debe mirar la cabecera de vuelta y poder reducir la carga de respuestas que induce. Si un control adicional permite varias respuestas por prueba, debe poder cambiar sus parámetros en las solicitudes posteriores. La red no distingue entre tráfico de clientes y tráfico de una medición arrogante.

El borrador no impone una fórmula única para frenar; remite a los requisitos de respuesta de RFC 3168 y RFC 9330. Para experimentos que necesitan mantener una tasa bajo CE, exige un entorno controlado acordado por los operadores afectados y límites de velocidad, duración e impacto. Esa excepción tiene nombres y bordes. No sirve para justificar una flota de sondas que ignore sus alarmas todos los días.

De la marca al acto

Una diferencia entre la marca de salida y EC2, o entre el valor solicitado y la cabecera que regresa, indica que algo alteró el campo. Los extremos por sí solos no identifican el dispositivo intermedio. Tampoco una sola respuesta sin CE describe todos los flujos de la ruta. Para afirmar que una implementación cumple este borrador hace falta una captura fechada de ambos sentidos, los valores EC1/EC2/RPE, la tasa de prueba y el cambio real de comportamiento tras CE.

La especificación sigue siendo un borrador activo del grupo de trabajo. Su apuesta operativa es concreta: medir una congestión no da licencia para producir más de ella. Una medición termina cuando el sistema muestra tanto la señal recibida como su respuesta.

Borrador 02 · RFC 8972 · RFC 8762