Summary

  • STAMP CoS ECN draft revision 02, dated 2 November 2026, adds EC1 to request an ECN value on the reflected packet and RPE to report whether the reflector applied it. Existing EC2 reports the arriving test packet's ECN value at the reflector.
  • A capable reflector reports RPE=0b11 when it set the requested value, or 0b10 when it fell back to zero. An older RFC 8972 reflector treats these bits as reserved and returns zero, so its reply cannot establish the new reverse-path test.
  • If an ECN-marked sender sends multiple probes within a round-trip time, it must observe congestion-experienced marks and be able to reduce the traffic it sends or induces in either direction. A sustained-rate congestion experiment needs a controlled environment agreed by the network operators.

The monitoring station launches one packet, receives a reply, and learns something about the path. Launch enough packets fast enough and it becomes another traffic source competing for that path. The distinction matters most when the station deliberately uses ECN-capable markings to find where packets acquire the CE congestion mark. A probe that collects CE but keeps its schedule unchanged is a reporter standing in the queue with a megaphone.

RFC 8762 gives STAMP its simple two-way measurement roles: Session-Sender transmits tests and Session-Reflector sends replies. The Class of Service extension in RFC 8972 already let the reflector copy the incoming packet's ECN value into the EC2 field of the reply. That gives the sender a view of what reached the far end. It did not provide an independent requested ECN marking for the reflected packet, so a clean reply could not test how an ECN-marked packet fared on its way home.

The working-group draft's revision 02 uses space RFC 8972 left reserved. EC1 names the value the sender wants in the return packet's IP header. RPE tells the sender what the reflector did. If local policy and platform support allow the requested value, the reflector applies it and writes 0b11. If it cannot apply that value, it sets the return packet's ECN bits to 0b00 and writes 0b10. The sender compares EC2, RPE and the actual return header. These are three separate observations: what arrived at the reflector, what it attempted to send back, and what arrived home.

The distinction saves the operator from a tempting false result. Suppose a reflector cannot set the requested mark. A return packet with no CE is then no evidence that the return path spared an ECN-capable packet; no such packet was launched. The RPE response prevents that absence from being sold as a measurement. It also exposes mixed deployments: a reflector that understands only RFC 8972 ignores the new bits as reserved and returns RPE=0b00. The sender can identify the missing capability instead of treating an old device's silence as a healthy path.

Now follow the probe rate. The draft says that when the sender places ECT(0) or ECT(1) on outward packets and sends more than one within a round-trip time, it must watch returned EC2 and be capable of reducing its sending rate on CE. When it requests ECT(0) or ECT(1) through EC1 for the reflected packets, it must watch the ECN bits of the replies and be capable of reducing the rate that produces them. If a control extension can elicit multiple reflected packets from one test, the sender must be able to adjust future reply-control parameters as well. The sender controls both the packets it launches and, through its requests, much of the reply load.

The draft leaves the exact reduction algorithm to implementations, subject to the congestion-response obligations in RFC 3168 and RFC 9330. That is a concrete division of labour. The wire fields report marks and capability. The measurement operator chooses a rate policy, confirms that the sender actually acts on CE, and records the resulting test load. An alarm saying “congested” while the probe fleet continues at full speed has read the signal and ignored the cost it imposes.

There is an explicit exception for a controlled experiment designed to characterize marking under overload. The draft permits maintaining a specified rate despite CE only when the operators of the tested networks agree, with bounds on rate, duration and spillover. That is a narrower and more useful statement than a blanket instruction to “keep measuring.” It describes when the experiment may resist the signal and who owns the resulting traffic.

What a result can actually prove

The sender can compare an outward ECN value with EC2, and a requested return value with RPE plus the returning IP header. Divergence can reveal that some part of a path or endpoint changed the field. The two endpoints alone do not identify the intervening device that did it. Likewise, a single reply without CE describes that test packet, not every flow or every moment on the route. The missing evidence for a deployment claim is a timestamped packet trace with both headers, EC2, EC1, RPE, probe rate and the sender's response to observed CE.

The draft remains an active IETF working-group document, rather than a published RFC. Its operational idea is already sharp. Measurement traffic has no special exemption from the congestion it observes. If the system can ask the network for evidence in both directions, it must also show that it knows when to get out of the way.

Draft revision 02 · RFC 8972 CoS extension · RFC 8762 STAMP · RFC 3168 ECN