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

[[e-mail]]

Hi Sebastian,


Thank you very much for your feedback, please see my replies inline.


Best regards,
Xueyan









Original


From: SebastianMoeller <moeller0=[e-mail]>
To: [e-mail] <[e-mail]>;宋雪雁00038118;
Date: 2026年07月24日 14:59
Subject: [tsvwg] Re: draft-song-opsawg-ipfix-ecn update


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?
 
 //Xueyan: Thank you for the suggestion. We will add a paragraph to clarify that the information elements defined in this document are applicable to all ECN deployments (e.g., RFC3168, DCTCP, L4S, etc.) and are not specific to L4S.
 
 
*) 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.
 
//Xueyan: Yes, you are right. This part is mainly from implementaion perspective to provide an example of how the collector can resue the ECN export data. It's not intended to limit the use be L4S only.


 
 
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).
 
 //Xueyan: Thank you for pointing out this. I will review the RFC8311 further and update the description accordingly and add it to reference as you suggested in next version.
Many thanks,
Xueyan


 
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)