He Sebastian,
Thank you for furthter comments, please see my reply inline.
Best regards,
Xueyan
Original
From: SebastianMoeller <[email protected]>
To: 宋雪雁00038118;
Cc: [email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected] <[email protected]>;[email protected]
<[email protected]>;
Date: 2026年01月14日 19:06
Subject: [tsvwg] Re: [OPSAWG]Re: Re: Fw: New Version Notification for
draft-song-opsawg-ipfix-ecn-00.txt
Hi Xueyan
4.15. l4sCeMarkRatioTotal
Name: l4sCeMarkRatioTotal
ElementID: TBD15
Description: The proportion of L4S packets marked with the CE
codepoint, calculated over the total lifetime of the Flow. This
element represents the total CE marking rate for L4S traffic
within the Flow. It is calculated as:
CE-marked L4S packets (total count) / Total L4S packets (total
count)
Where L4S packets are those identified by the ECN codepoint
ECT(1). The result is a ratio ranging from 0.0 to 1.0.
Here is a challenge, once a packet is marked CE you can not veridically deduce
whether it was ECT(0) or ECT(0) (or Not-ECT), so you need to expect that flows
use either ECT(0) or ECT(1) consistently. But since you actually keep counts of
ECT(0) and ECT(1) packets, maybe make this conditional on ect0PacketTotalCount
being zero for this flow?
>>Xueyan: Agree with you. A regular L4S flow should use ECT(1) mark
>>continuously. We will add some text to the operation section to clarify this
>>point.
You already argue similarly here:
When measuring the proportion of packets marked with the CE
codepoint, the CE marking rate for L4S traffic should be calculated
specifically for flows identified as ECT(1) (L4S traffic identifier)
prior to marking, rather than aggregating all CE-marked packets
irrespective of their original ECT codepoint. This ensures the
performance of L4S services can be accurately monitored and
distinguished from Classic ECN traffic, which may have different
congestion response characteristics.
But you still have the unfortunate ambiguity of CE and the fat that flows can
change their ECN codepoint.
Regards
Sebastian
> On 14. Jan 2026, at 04:00, <[email protected]>
> <[email protected]> wrote:
>
> Hi Sebastian and Ingemar,
> Thank you for further clarification and sharing the valuable insights. I
> agree that we should strike a balance between standands and real deployments.
>
> Given the L4S CE marking may be probabilistic, to ensure the reliability of
> the statistical data and reduce the bias risk of sampling results,
> probabilistic sampling methods should follow RFC5475.
> The following proposed text to operation section:
> "In L4S deployments, CE marking may be either probabilistic or deterministic,
> as determined by the specific AQM implementation. The IEs on the statiscal
> count of CE-mark packets and L4S CE marking ratio are defined to enable
> operators to perfom quantitative monitoring and management of L4S service
> performance, typically based on flow data that may be acquired via packet or
> flow sampling. Implementations should employ sampling methods (see RFC5475)
> that preserve the statistical representativeness of these IEs and reduce bias
> risk of sampling results."
> Are you fine with this?
>
> Best regards,
> Xueyan
>
> Original
> From: SebastianMoeller <[email protected]>
> To: 宋雪雁00038118;
> Cc: [email protected] <[email protected]>;[email protected]
> <[email protected]>;[email protected]
> <[email protected]>;[email protected] <[email protected]>;[email protected]
> <[email protected]>;
> Date: 2026年01月13日 17:31
> Subject: Re: [tsvwg] [OPSAWG]Re: Re: Fw: New Version Notification for
> draft-song-opsawg-ipfix-ecn-00.txtHi Xueyan,
>
>
> > On 13. Jan 2026, at 10:03, <[email protected]>
> > <[email protected]> wrote:
> >
> > Hi Sebastian,
> > Thank you for further clarification, agree with your points.
> > For L4S, the dual-queue coupled AQM mechanism uses probalisitic ECN marking
> > for L4S traffic,
>
> [SM3] Respectfully, that might be true for the DualQ RFC9332, but the actual
> sch_dualpi2 AQM in the Linux kernel uses a deterministic step marker for the
> L-queue if there is not enough C-traffic to drive the pi2 component*.
> At first it might be somewhat surprising that the same folks hat created
> rfc9332 with its probabilistic ramp-style L4S-AQM to actually end up
> implementing a deterministic step marker in practice, but rfc9332 contains
> the following "hedge":
> "As a first concrete example, the pseudocode below gives the DualPI2
> algorithm. DualPI2 follows the structure of the DualQ Coupled AQM framework
> in Figure 1. A simple ramp function (configured in units of queuing time)
> with unsmoothed ECN marking is used for the Native L4S AQM. The ramp can also
> be configured as a step function. The PI2 algorithm [PI2] is used for the
> Classic AQM. PI2 is an improved variant of the PIE AQM [RFC8033]."
>
> as of today it turns out for the actual sch_dualpi2b in Linux "The ramp can
> ONLY be configured as a step function". Which might change or might not
> change in the future.
>
> *) If the marking is driven however by non-L4S traffic in the C-queue the
> marking, even in the L-queue will be probabilistic, so for the current
> internet traffic mix, L4S marking likely is probabilistic.
>
>
> That said, I am not sure that has any bearing on the validity IPFIX's
> sampling approach, any sampler will overlook rare events more often than
> common events, but is agnostic to the nature of these events, no? Maybe the
> IPFIX draft could just avoid reasoning about marking determinism or lack
> there of completely?
>
> Regards
> Sebastian
>
>
>
> > the IPFIX IE for tracking L4S CE mark ratio is proposed in this draft, we
> > hope this makes sense.
> >
> > Best regards,
> > Xueyan
> >
> > Original
> > From: SebastianMoeller <[email protected]>
> > To: Sebastian Moeller <[email protected]>;
> > Cc: [email protected] <[email protected]>;宋雪雁00038118;[email protected]
> > <[email protected]>;[email protected]
> > <[email protected]>;[email protected] <[email protected]>;[email protected]
> > <[email protected]>;
> > Date: 2026年01月13日 16:04
> > Subject: Re: [tsvwg] [OPSAWG]Re: Re: Fw: New Version Notification for
> > draft-song-opsawg-ipfix-ecn-00.txtDear 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]
