[tsvwg] Re: draft-song-opsawg-ipfix-ecn update

[Sebastian Moeller <[e-mail]>]

Hi Xueyan,

looks fine, however, I note the text in the abstract:

specifically in the context of the Low Latency, Low Loss, and Scalable Throughput (L4S) service. These Information Elements allow network operators to observe ECN codepoint usage within L4S deployments and evaluate the corresponding traffic performance.

and similar notes regarding L4S in other paragraphs.

But there seems nothing really L4S specific here*, rather the method will work exactly the same for rfc3168 ECN as for DCTCP- or L4S-style ECN usage.

So I would add a paragraph that describes once how the draft's new element will work for all known ECN users equally well (maybe enummerate these once) and be done with?




*) with the potential exception of:

The calculation of derived metrics (e.g., L4S CE marking ratios) from the base counters defined in Section 4 of this document is an implementation issue for the IPFIX Collector. Operators can utilize the per-flow counts such as ect1PacketTotalCount and cePacketTotalCount for such purposes, provided that CE-marked packets are attributed to their original ECT codepoint (e.g., ECT(1) for L4S) rather than aggregated indiscriminately, ensuring L4S and Classic ECN congestion signals are distinguished. The calculation strategy is out of the scope of this document.

But here the L4S specific thing is explicitly not done by the reporter, but by the collector... so again nothing L4S-specific here.




Also:
[RFC9331] specifies that ECT(1) is used to identify L4S-capable traffic. ECT(0) is used to identify classical traffic.


[SM] That seems a bit imprecise... rfc9331 does indeed say L4S uses ECT(1) and classic congestion control will use ECT(0) but that is an assertion, rfc3168 was allowed to use either ECT(0) or ECT(1) so there is no guarantee that the text in rfc9331 actually describes the reality in the field (however if there are rfc3168 users out there that use ECT(1) these seem to be quite rare). But I do think a reference to https://datatracker.ietf.org/doc/html/rfc8311 is in order, as that was required to make way for the L4S experiment in the first place by changing rfc3168's equivalence of ECT(0) and ECT(1).




On July 24, 2026 7:15:03 AM GMT+02:00, [e-mail] wrote:
Hi TSVWG,

Due to time constraints, we unfortunately did not have the chance to present and discuss the change of draft-song-opsawg-ipfix-ecn during the session.
To move the draft forward, I would like to share the link of presentation slides and latest v-03 for your review.
Presentation slides: https://datatracker.ietf.org/doc/slides-126-tsvwg-export-of-ecn-information-in-ipfix/ Latest drfat version: https://datatracker.ietf.org/doc/draft-song-opsawg-ipfix-ecn/ 
We would appreciate your review and feedback, and continued discussion on the list.

Best regards,
Xueyan (on behalf-of co-authors)