Hi Xueyan, please see [SM] below.
On January 13, 2026 8:09:10 AM GMT+01:00, [email protected] wrote: >Hi Joel, >Thank you for further suggestions. The consideration for risk of bias in >sampling result is very reasonable, for example CE is marked probalisticlly >rather than marked every packet when potential congestion occurs. We will add >relevant text to section 5 to provide some operational considerations. [SM] DCTCP (and L4S) potentially employ probabilistic marking, rfc3168 does not. Please do not assumd all CE marks are dctcp-style... But even dctcp style marking can be deterministic, e.g. as in fq-codel's ce threshol marking or dualpi2's step threshold. Respectfully, may I ask, what is your rational for considering CE marks probabilistic? Regards Sebastian > >Best regards, >Xueyan > > > > > > > > > >Original > > >From: jmh.direct <[email protected]> >To: 宋雪雁00038118;[email protected] <[email protected]>; >Cc: [email protected] <[email protected]>;[email protected] ><[email protected]>;[email protected] <[email protected]>; >Date: 2026年01月13日 13:06 >Subject: [OPSAWG]Re: [tsvwg] Re: Fw: New Version Notification for >draft-song-opsawg-ipfix-ecn-00.txt > > >_______________________________________________ >OPSAWG mailing list -- [email protected] >To unsubscribe send an email to [email protected] > >Tgank you for the replies. It probably would help to reference traffic >sampling as the assumed behavior. This could be coupled with some discussion >of why the risk of bias in the result of sampling a varying stream, likely >with some patterns in its variation, is low. > >Yours, >Joel > > > > >Sent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone > > > >-------- Original message -------- >From: [email protected] >Date: 1/12/26 11:04 PM (GMT-05:00) >To: [email protected] >Cc: [email protected], [email protected], [email protected] >Subject: Re: [tsvwg] Re: [OPSAWG]Fw: New Version Notification for >draft-song-opsawg-ipfix-ecn-00.txt > > > >Hi Joel, >Thank you for taking time to read the draft, and providing new aspects we need >to consider, we will make updates to the draft to reflect your comments. >Please also see my reply inline. > >Best regards, >Xueyan (on behalf-of co-authors) > > > > > > > > >From: JoelHalpern <[email protected]> >To: 宋雪雁00038118; >Cc: [email protected] <[email protected]>;[email protected] ><[email protected]>;[email protected] <[email protected]>; >Date: 2026年01月12日 23:56 >Subject: [tsvwg] Re: [OPSAWG]Fw: New Version Notification for >draft-song-opsawg-ipfix-ecn-00.txt > >The discussion prompted me to read this draft. I have two different questions >about it: >1) In what way is it related to L4S? Yes, L4S uses ECN. But ECN is not >restricted to L4S. >>>Xueyan: The main consideration for L4S service is that L4S introduces a new >>>ECN codepoint ECT(1) for traffic identification, it helps the diferenciation >>>between classical and L4S traffic and uses CE codepoint for potential >>>congestion mark. The monitoring of ECN can provide Operators with valuable >>>insights, including the ratio of L4S traffic in the network, statistics of >>>network congestion and granular visibility for the performance of L4S >>>services. >But the ECN monitoring in this draft is not limited to L4S, for example, we >also provide the monitoring IEs for ECN(0) and non-ECT, with a flexible design >to satisfy user's monitoring requirements. > >2) Even if we assume this only reports packets with ECN bits enabled (not 00), >generating an IPFIX report for every data packet across many flows (in some >environments, all flows) seems to be tremendous overhead. Since as I >understnad it this is for management monitoring of operability, not for >congestion response, that seems a massive overhead. Am I misreading the draft? >>>Xueyan: Yes, we agree that doing this per packets would create too much >>>overhead. In real deployment, IPFIX performs probalistic sampling for data >>>collection based on user requirements instead of extracting data per packet. >>>The specifi data export is determined by IPFIX configurations and device >>>capabilities, but the general rule is to avoid creating heavy overhead to >>>network nodes. >Best regards >Xueyan > >Yours, >Joel >On 1/11/2026 9:54 PM, [email protected] wrote: > > > >Hi Greg, > >Thank you for the good question. >Yes, ECN is an end-to-end protocol, TCP sender intiates the signalling and TCP >receiver responds. And I think IPFIX works in IP layer, so the target data >extraction is at network nodes. For the information elements proposed in this >drfat, the IPFIX extraction position may be different based on monitoring >purposes. We plan to add the following text to section 5, does it work for you? >The IPFIX IEs defined in this draft may have their information extraction >positions adjusted based on different ECN monitoring purposes in the network. >Among them, the basic ECN field elements are used to reflect the ECN >codepoints carried in the IPv4 header, the IPv6 Traffic Class octet, or the >MPLS EXP field. These fields can be flexibly extracted at any node along the >path that has IPFIX export capability. For tunnel ECN negotiation status IEs, >the IPFIX data can only be provided by the specific tunnel endpoints that >participate in the negotiation. For cumulative statistics IEs, the statistical >data may be processed with a higher priority at traffic aggregation or egress >nodes. > >For the mpls-ecn draft you shared, it appers to define a new ECN opcode >encapsulated in MNA packets for MPLS data plane. I think it's actually >relevant to the ipfix-ecn draft, if MPLS WG adopts it, we would like to add >the ECN export from MPLS MNA packets to our draft. > >Best regards, >Xueyan > > > > > > > > > >From: GregMirsky <[email protected]> >To: 宋雪雁00038118;Joel Halpern <[email protected]>; >Cc: [email protected] <[email protected]>;[email protected] <[email protected]>;mpls ><[email protected]>; >Date: 2026年01月11日 06:00 >Subject: Re: [OPSAWG]Fw: New Version Notification for >draft-song-opsawg-ipfix-ecn-00.txt > > >Hi Xueyan,thank you for sharing the updated draft. A relatively new draft >draft-halmir-mpls-ecn on supporting ECN in the MPLS using MNA might be of >interest to you and others involved in the matter. And I have a question. As I >understand the ECN, it is a host that is expected to act on the information >collected in the ECN field along the path of a packet. If that is correct, >who's the intended target of the IPFIX notification about the ECN? Is the >intention to act on ECN information obtained on a segment, e.g., a tunnel, >rather than based on the e2e ECN information? I read Section 5, but was left >with these questions. > > Regards, >Greg > > > > >On Fri, Jan 9, 2026 at 1:53 AM <[email protected]> wrote: > > >Hello OPSAWG and TSVWG, > >We submited a new draft and posted it in the IETF datatracker >https://datatracker.ietf.org/doc/draft-song-opsawg-ipfix-ecn/ >The following IPFIX information elements are introduced for L4S ECN monitoring: >- ECN field capture in protocol layer, including ECN field in IPv4/IPv6 ECN >field, MPLS EXP and tunnel ECN negotiation status >- ECN codepoint statistics, including incremenatl and total count for non-ECT, >ECT(0), ECT(1) and CE packets >- L4S performance indicator, providing short-term and long-term view of >congestion experienced by L4S traffic > >Your review, comments and questions are welcome. > >Best regards, >Xueyan > > > >Original > >From: [email protected] <[email protected]> >To: 宋雪雁00038118;刘尧00165286; >Date: 2025年12月26日 16:33 >Subject: New Version Notification for draft-song-opsawg-ipfix-ecn-00.txt > >A new version of Internet-Draft draft-song-opsawg-ipfix-ecn-00.txt has been > successfully submitted by Xueyan Song and posted to the > IETF repository. > > Name: draft-song-opsawg-ipfix-ecn > Revision: 00 > Title: Export of L4S ECN in IP Flow Information Export (IPFIX) > Date: 2025-12-26 > Group: Individual Submission > Pages: 14 > URL: https://www.ietf.org/archive/id/draft-song-opsawg-ipfix-ecn-00.txt > Status: https://datatracker.ietf.org/doc/draft-song-opsawg-ipfix-ecn/ > HTML: https://www.ietf.org/archive/id/draft-song-opsawg-ipfix-ecn-00.html > HTMLized: https://datatracker.ietf.org/doc/html/draft-song-opsawg-ipfix-ecn > > > Abstract: > > This document defines a set of IP Flow Information Export (IPFIX) > Information Elements for monitoring the Low Latency, Low Loss, and > Scalable throughput (L4S) service. Specially, these elements enable > network operators to monitor the Explicit Congestion Notification > (ECN) information of L4S deployment and performance of traffic. > > > > The IETF Secretariat > > > > > > > > >_______________________________________________ > OPSAWG mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
