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

[[e-mail]]

Hi Koen,


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


Best rgards,
Xueyan



Original


From: KoenDeSchepper(Nokia) <[e-mail]>
To: 宋雪雁00038118;[e-mail] <[e-mail]>;
Date: 2026年07月29日 00:17
Subject: RE: [tsvwg] draft-song-opsawg-ipfix-ecn update



Hi Xueyan,
 
Thanks for bringing this draft for the important topic of ECN monitoring (especially for L4S) to the IETF.
 
I’m not so familiar with IPFIX, so some questions from the viewpoint of a potential user:

Are these IEs related to the ECN field that is observed from passing traffic at the observation point?


Or is it related to what the network node is applying/changing in the ECN field(s) (only related to nodes that are changing ECN for setting CE, I hope)
//Xueyan: The IEs defined in this document are mainly for observed ECN fields in the passing traffic at an observation point, don't track the active changes made by the node itself. If users want to know the CE marking ratio or the ECN fields change, it's best to place it at or after the bottleneck, so it depends on what the operator wants to measure.




How can I detect the level of CE “setting” on a link in a NW node? 


Can I derive the rate per flow that this node is limiting to? (if you know the node’s per link mark “setting” rate, you can calculate the estimated maximum rate per flow on that link by r = 1/p – 1 in Mbps)
//Xueyan: Yes, you can derive CE marking rate using the basic IE counters defined in the docuemnt, such as combing ect1PacketTotalCount and cePacketTotalCount, you can calulate the CE marking ratio and then estimate the per-flow rate using your formula. For L4S traffic, we assume the CE marking is mainly for ECT(1) and there is no difference of ECT(1) and ECT(0) per-flow. To clarify this, we have added below text to section 5:

 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.


Do you plan to provide extra counters that are related to “the setting” of ECN codepoints or do you foresee a mechanism to derive it in some way?

       //Xueyan: We think the current IEs are enough. Do you have any specific use cases in mind that the current IEs cannot cover? If you see any gaps, we are happy to add extra IEs to fill the gap.



Can these ECN changes also be done per original codepoint. This would be useful to know if ECT0 is transitioned into CE or ECT1 to CE. But not all (if any) HW might be capable of directly providing this info?



      //Xueyan: Yes, tracking CE marking per original codepoint is very important. Now we added an assuption that "CE-marking packets can be attributed to their origina ECT codepoints", do you think it's enough just have the assumption?
 
Maybe a section with some suggestions on how to use these information elements for L4S might be useful (which can answer the above questions)?
 
Regards,
Koen.
 
 

From: [e-mail] <[e-mail]> 
 Sent: Friday, July 24, 2026 7:15 AM
 To: [e-mail]
 Subject: [tsvwg] draft-song-opsawg-ipfix-ecn update


 


 


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.

 
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)