[ippm] Re: New Version Notification for draft-whimir-ippm-stamp-cos-ecn-00.txt

[Greg White <[e-mail]>]

Gorry & Ruediger,

Thanks for the review and the comments.  It seems to me then that there are perhaps two aspects that should be dealt with in the STAMP RFC series.  One relates to a general capability to detect and respond to congestion signals so as to not cause problems on operational paths. The other relates to the specific capability of doing so when the ECN field is available for use in gathering congestion signals, via the use of the TLV in this draft (either the original CoS TLV, which only provides one-way ECN information, or the updated version which provides bi-directional ECN information).

For the general capability, which IMO should apply regardless of whether this TLV is being used, there are a number of situations to explore, including high rate basic STAMP protocol exchanges, high rate STAMP exchanges with the Return Address Sub-TLV (RFC9503), STAMP exchanges that use the Reflected Test Packet Control TLV (draft-ietf-ippm-asymmetrical-pkts) to induce a particular rate from the SR. While there has been some progress in this area in the asymmetrical packets draft (and tangentially in the capacity protocol draft), perhaps this general topic really ought to be addressed by an update to RFC 8762?

In the case that the CoS TLV is being used to enable control of the ECN field, I am happy to include text that describes this case.  How about a new section along the lines of: 

Congestion Response
RFC3168 and RFC9330 mandate that applications that send packets marked with the ECT0 or ECT1 codepoints implement a response to congestion notifications from the network. While the STAMP protocol doesn't include the concept of a connection between a Session-Sender and a Session-Reflector, there are situations in which the Session-Sender may send multiple STAMP packets to the same Session-Reflector within the round-trip time between them, and there are situations in which the Session-Sender may elicit multiple STAMP packets from a Session-Reflector in response to a single sent STAMP packet.  As such, the Session-Sender is generally responsible for dictating both its sending rate, and the sending rate of the packets sent in response by an individual Session-Reflector, and so is not exempt from this mandate.  Moreover, when using this CoS TLV with either an ECT0 or an ECT1 value in the IP-ECN field the Session-Sender gains the ability (via observing a CE reflected value in the EC2 field) to detect that congestion was present on the path from the Session-Sender to the Session-Reflector.  Similarly, when using this CoS TLV with either an ECT0 or an ECT1 value in the EC1 field, the Session-Sender gains the ability (via observing a CE in the IP-ECN field of the reflected packet) to detect that congestion was present on the path from the Session-Reflector to the Session-Sender.  If a Session-Sender sends multiple STAMP+CoS packets to a Session-Sender within an RTT with either the ECT0 or ECT1 value in the IP-ECN field, it MUST observe the reflected EC2 field and reduce its sending rate upon observation of a CE value.  If a Session-Sender sends multiple STAMP+CoS packets to a Session-Sender within an RTT with either the ECT0 or ECT1 value in the EC1 field, it MUST observe the IP-ECN value in the reflected packets and reduce its sending rate upon observation of a CE value.  If a Session-Sender sends a STAMP+CoS+Reflected-Test-Packet-Control packet to a Session Sender, with either the ECT0 or ECT1 value in the EC1 field, it MUST observe the IP-ECN value in the reflected packets and adjust the Reflected Test Packet Control parameters in any future STAMP packet sent to the same Session-Reflector based on the observation of CE values.


-Greg


On 8/12/25, 6:46 AM, "Gorry Fairhurst" <[e-mail] <mailto:[e-mail]>> wrote:


On 12/08/2025 12:44, [e-mail] <mailto:[e-mail]> wrote:
> Hi Gorry,
>
> if measurements by creating load or congestion, respectively, are part of the drafts functional design, your comment addresses the reaction on "CE". If a measurement creates congestion, should there be an additional functional specification how to react if there's never a "CE" mark in feedback? You mention some "simplified load control" in the "CE" case. Is there an additional need for a generally working congestion detection and for a simplified load control? If the measurement is designed to induce congestion, to be clear.
>
> Regards,
>
> Ruediger
>
There are indeed probably a few things to explore.


I think you may be heading in an interesting direction, if one sees loss 
but no congestion-marked packets for an ECT() flow, that would seem like 
you either have some non-congestion loss or something unexpected. This 
sounds more like a CCWG area of expertise, but the framework under which 
it operares sounds like IPPM.


Gorry


> -----Ursprüngliche Nachricht-----
> Von: Gorry Fairhurst <[e-mail] <mailto:[e-mail]>>
> Gesendet: Dienstag, 12. August 2025 12:55
> An: [e-mail] <mailto:[e-mail]>
> Cc: Gorry Fairhurst <[e-mail] <mailto:[e-mail]>>
> Betreff: [ippm] Re: New Version Notification for draft-whimir-ippm-stamp-cos-ecn-00.txt
>
> I think this could be a useful draft, and it is good to see support for measurements on the return path.
>
> One thing that I really think this I-D ought to address is that if the tests generate an appreciable load (which seems likely to be important to measure congestion marking), then the flow that advertises an ECN-Capable Transport, actually needs to follow the rules for flows that are marked in this way.
>
> This means the flow needs to detect and reflect any CE-marking (which I think this spec does).
>
> It also could mean that a tester ought to detect (and ignore) CE marks when ECT is not set; but more importantly when the flow is marked as ECT(?), I think the source now must REACT to reflected CE-marks to reduce the load it generates, this could be a full ECN alagorithm, or perhaps could be a simplified load control which might make the measurement easier to interpret. I'd be interested to understand how this could be realised, and see more.
>
> Gorry
>
>
>
> _______________________________________________
> ippm mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>




_______________________________________________
ippm mailing list -- [e-mail] <mailto:[e-mail]>
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>