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

[Sebastian Moeller <[e-mail]>]

Hi Koen,


> On Jul 28, 2026, at 18:17, Koen De Schepper (Nokia) <koen.de_schepper=[e-mail]> wrote:
> 
> 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:

[SM] As far as I can tell IPFIX is a per-flow information collection method... (with a broad definition what constitutes a flow, but as far as I understand everything acoess a node does not fall into that definition...)

>     • 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)
>     • How can I detect the level of CE “setting” on a link in a NW node?

[SM] You really can't unless your collector sees all traffic egressing from that node and veridically records each individual packet... what you can do is for each flow observed at your collector, you can collect and report counts for all 4 ECN codepoints, but even there you are not strictly guaranteed to see all packets of a flow (but you likely still do).

>     • 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)

[SM] You should be able to do that as packetDeltaCount and octetDeltaCount are valid fields as are the counters for the 4 ECN codepoints, you will likely have some temporal slack, but you should be able to reconstruct the average rates and marking probabilities within each reporting interval.

>     • 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?

[SM] I would guess as far as IPFIX goes these fall out naturally if your flow definition is sufficiently granular to separate out ECT(0) from ECT(1) traffic (and you likely can not use that for the actual filtering).

>     • 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?

[SM] No, only if your initial flow definition already separates out ECT(0) from ECT(1) flows, then you should be able see transitions from a reporting interval without CE marks to one with CE marks and vice versa.

>  Maybe a section with some suggestions on how to use these information elements for L4S might be useful (which can answer the above questions)?

[SM] You mean a detailed section discussing the interpretation of these ECN fields in the context of each ECN method? Not sure that is the best document for that, however if that is the road we take we should discuss this for rfc3168 and DCTCP as well (the latter probably can be folded mostly into the L4S section).



>  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)