[ippm] Re: In re: Update of the Simple Two-way Active Measurement Protocol Class-of-Service Extension - ECN

[Greg White <[e-mail]>]

At IPPM today, I presented the 3 options discussed below.   In offline discussion the authors agreed that we prefer option 3:   A “new” SR would always set RPE = 0b1x.  If it has set IP-ECN=EC1 then it sends RPE=0b11.  If it is unable to set IP-ECN=EC1 then it sends RPE=0b10.  Thus the upper bit indicates “I’m a new SR” and the lower bit indicates “I’ve set IP-ECN as you asked”, and there are no ambiguities.

Unless there are any objections we will make the update in the draft.

Thanks go out to Will Hawkins for identifying this issue and providing the initial proposed resolution.

-Greg

From: Greg Mirsky <[e-mail]>
Date: Tuesday, October 21, 2025 at 6:41 PM
To: Greg White <[e-mail]>
Cc: Will Hawkins <[e-mail]>, "IETF IPPM WG ([e-mail])" <[e-mail]>
Subject: Re: In re: Update of the Simple Two-way Active Measurement Protocol Class-of-Service Extension - ECN

Hi Greg,
thank you for taking a broader view of the problem at hand. I think that with the behavior tagged as Option 2 we'll get more certainty about the capability of the Session-Reflector by doing the verification in two steps:

  1.  Session-Sender sets EC1 = 0b00
  2.  Session-Sender sets EC1 = 0b01
Now, if the reflected packet #1 has RPE = 0b00 - that is an "old" Session-Reflector
If packet #2 has RPE = 0b01 - we have a "new" Session-Reflector that can set the ECN vlue in a reflected packet
If the packet #2 has RPE = 0b00 - it is a "new" Session-Reflector, but it is not able to control the value of the ECN field in the reflected packet.

WDYT?

Regards,
Greg

On Tue, Oct 21, 2025 at 3:21 PM Greg White <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

Comparing the text I sent earlier to your suggested change, it seems to me that both of them leave an ambiguity in the case where the SS sent EC1=0b00.  And, in both versions the ambiguity results in the SS being unable to be sure whether the SR set the return packet IP-ECN to 0b00.


  1.  With the text I sent earlier, the SS would not be able to differentiate between an “old” SR and a “new” SR that can’t set IP-ECN to 0b00.
  2.  With your modification, the SS would not be able to differentiate between a “new” SR (fully compliant) and a “new” SR that can’t set IP-ECN to 0b00.

Since return path ECN measurements from “old” SRs aren’t possible anyway, it seems to me that the situation with 1 is a bit better. If RPE=01, then the SS can confidently record the measurement as having been done with a return packet IP-ECN of 0b00.  If RPE=00, the SS would know that it can’t be certain about the return IP-ECN.  It might make the assumption that the default ECN value for the SR is 0b00 (and hence there are no “new” SRs that can’t set IP-ECN to 0b00) and ascribe the measurement to being IP-ECN==0b00, but this would knowingly be an assumption that it can’t validate.

If we take option 2, then the SS can’t reliably make a return path Not-ECT measurement from any SR, old or new.  If RPE=00, then it knows that the SR is an “old” SR and it would have to make assumptions about what it might have set for IP-ECN. If RPE=01 then it has no way of knowing whether the “new” SR was able to set IP-ECN=0b00 or not.

You are almost certainly correct that the default IP-ECN value will be 0b00 on the vast majority of SRs, and if that is indeed the case for 100% of SRs then this is a non-issue since there would be no “new” SRs that can’t set IP-ECN to 0b00, and we could flip a coin between options 1 & 2.  But if there exists any slight chance that some system defaults to a different value, then I would argue for option 1.

An option that would eliminate the ambiguity entirely would be to assign the upper bit of the RPE field:   A “new” SR would always set RPE = 0b1x.  If it has set IP-ECN=EC1 then it sends RPE=0b11.  If is unable to set IP-ECN=EC1 then it sends RPE=0b10.  Thus the upper bit indicates “I’m a new SR” and the lower bit indicates “I’ve set IP-ECN as you asked”.

-Greg



From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, October 21, 2025 at 1:18 PM
To: Will Hawkins <[e-mail]<mailto:[e-mail]>>
Cc: "IETF IPPM WG ([e-mail]<mailto:[e-mail]>)" <[e-mail]<mailto:[e-mail]>>, Greg White <[e-mail]<mailto:[e-mail]>>
Subject: Re: In re: Update of the Simple Two-way Active Measurement Protocol Class-of-Service Extension - ECN

Hi Will,
thank you for your thorough analysis and thoughtful proposal. I have a bit different expectation of the Session-Reflector's (new) behavior in the scenario you consider:
but if a new Sender wants a not-ECT ECN value in the reflected packet
and a new Reflector cannot oblige, the Sender would receive

ECN1 = 0
RPE = 0
AFAIK, the ECN value will be set to 0b00 by default for an IP packet. If that is correct, we may use that and update text as follows:
OLD TEXT:
The Session-Reflector MUST set the ECN value in the IP header of the
reflected STAMP test packet to the value of the EC1 field. The
Session-Reflector MUST set the RPE field in the CoS TLV in the
reflected test packet to the value 0b01.
NEW TEXT:
The Session-Reflector MUST set the ECN value in the IP header of the
reflected STAMP test packet to the value of the EC1 field. If
the Session-Reflector was able to set the ECN value in the IP header of
the reflected packet as instructed, or the value of the EC1 equals Not-ECT (0b00),
the Session-Reflector MUST set the RPE field in the CoS TLV in the
reflected test packet to the value 0b01.

Then, a new Session-Reflector will set RPE=0b01 in response to EC1=0b00 regardless if it was able to set the ECN value. And from an "old" Session-Reflector Session-Sender will receive the reflected packet with RPE=0b00 even if EC1=0b00.
WDYT?

Regards,

On Fri, Oct 17, 2025 at 2:15 PM Will Hawkins <[e-mail]<mailto:[e-mail]>> wrote:
Hello all!

Thank you _all_ for your continued efforts to "expand"  STAMP through
TLVs! Although "base" STAMP provides a tremendous benefit for the community,
the additional TLVs really make it awesome.

I know that our Montreal meeting is coming up and I wanted to offer
support for the WG's consideration of the Update of the Simple Two-way
Active Measurement Protocol Class-of-Service Extension - ECN draft.

As I was reviewing Teaparty's implementation of the update to the CoS
as specified in the latest draft, I wanted to double check that I
understand some implicit semantics. And, if I do understand them, I
was hoping to suggest a change (it can be very small!) to make it
explicit.

Here is the language from 3-7

The Session-Reflector MUST set the ECN value in the IP header of the
reflected STAMP test packet to the value of the EC1 field. The
Session-Reflector MUST set the RPE field in the CoS TLV in the
reflected test packet to the value 0b01. As a result, the
Session-Sender can detect whether the recommended value for ECN field
in the reflected packet was used by inspecting the value of the RPE
field in the received reflected test packet.
https://www.ietf.org/archive/id/draft-whimir-ippm-stamp-cos-ecn-00.html#section-3-7

On my initial reading of the new draft, I thought that language seemed
to preclude any possibility of a Session Reflector communicating a
failure to set the ECN value in the IP header of the reflected packet
to the ECN1 value (for reasons of local policy, or because an
implementation is running with insufficient privileges in the OS).

And, of course, I have no reason to disagree with Greg White's assertion that

"It could also be possible (but less likely IMO) for a network policy
to prohibit a SR from setting a non-zero ECN value."

but I still think that it's an important feature of the draft and I
wanted to confirm how the language of the draft actually _does_ make
it possible for a "new" Session Sender (talking to a new Session
Reflector) to decipher that the Reflector failed to set the requested
ECN value:

1. The Sender would (presumably) set a non-zero value for ECN1.
2. A (new) Reflector would copy the value of ECN1 into the reflected test packet
3. A (new) Reflector would, in the case of a failure to set the value
of the ECN in the IP header of the reflected test packet, set RPE to
0.

The same sequence for a new Sender talking to an old Reflector:

1. The Sender would (presumably) set a non-zero value for ECN1.
2. A (old) Reflector would set all reserved values to 0.

And, voila!, the important difference is in Step 2: The Sender, upon
receiving the reflected test packet, would consider

- A non-zero ECN1 in combination with a zero RPE to indicate a failure
to set the value
- A zero ECN1 in combination with a zero RPE to indicate that the
Reflector does not support the new draft.

Cool! If I do understand that correctly, I think that a small change
(a single sentence) would be helpful to a first-time reader.

As I was writing this message, I struggled thinking about this last
case: detecting a failure by a new Reflector to do the bidding of a
new Sender that wants a not-ECT value for the reflected test packet.
As Greg W said,

"I agree that moving the new RP bit to a new RP2 field would solve
that problem."

but if a new Sender wants a not-ECT ECN value in the reflected packet
and a new Reflector cannot oblige, the Sender would receive

ECN1 = 0
RPE = 0

and have no way of knowing that the Reflector supported the new
version of the draft but just failed to accommodate its request.
Having said that, I am not sure that this situation is realistic,
likely to happen, or something that should be handled.

I hope that this discussion is helpful but I am the first to
acknowledge that you are the experts and I am a simple programmer. So,
please feel free to take or leave any or all of it.

No matter what, thank you for continuing to refine the draft. It's a
testament to your analysis that we can make this change backward
compatible!
Will