Dear All,
> On 13. Jan 2026, at 08:25, Sebastian Moeller > <[email protected]> wrote: > > 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? [SM2] Rethinking and refining my argument, whether a CE mark is probabilistic or not is not really a function of marking-law (dctcp vs. rfc3168) but of the AQM that is used, some operate probabilistically, some do not. > > 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]
