[OPSAWG]Re: [tsvwg] Re: Re: Re: Fw: New Version Notification for draft-song-opsawg-ipfix-ecn-00.txt
Ingemar Johansson S <ingemar.s.johansson=40ericsson.com-Tr9gZwTxerDR74oF6e/[email protected]> Fri, 16 Jan 2026 09:16:29 +0000
| Newsgroups | gmane.ietf.opsawg,gmane.ietf.tsvwg,gmane.ietf.mpls |
|---|---|
| Message-ID | <AM8PR07MB81370675DAF9B99A37059694C28DA@AM8PR07MB8137.eurprd07.prod.outlook.com> |
--===============5461412873427450332== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_00FF_01DC86D1.2D4389C0" ------=_NextPart_000_00FF_01DC86D1.2D4389C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0100_01DC86D1.2D4389C0" ------=_NextPart_001_0100_01DC86D1.2D4389C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi I think that the case where flows changes from ECT(1) to ECT0) should be = a rare case, the only case I can come up with is a fall back to ECT(0) = in e.g TCP Prague .=20 In any case, a monitoring node should be able to distinguish between = these cases as the notEctPacketTotalCount, ect0PacketTotalCount, = ect1PacketTotalCount and cePacketTotalCount represents accumulated = numbers. Speaking of this, if size matters then the variable length fields as = specified for QUIC (RFC9000) can be considered.=20 I am not sure that l4sCeMarkRatioTotal and l4sCeMarkRatioDelta are very = useful and can cause the possible ambiguity that Sebastian describes.=20 A monitoring note can easily calculate these metrics based on the = =E2=80=9C...TotalCount=E2=80=9D metrics and also has the possibly so = sort out the ECT(0)/ECT(1) ambiguity. /Ingemar=20 =20 =20 =20 =20 =20 =20 From: [email protected] <[email protected]>=20 Sent: Thursday, 15 January 2026 03:49 To: [email protected] Cc: Ingemar Johansson S <ingemar.s.johansson-IzeFyvvaP7pWk0Htik3J/[email protected]>; = [email protected]; [email protected]; [email protected]; = [email protected]; [email protected] Subject: Re: [tsvwg] Re: [OPSAWG]Re: Re: Fw: New Version Notification = for draft-song-opsawg-ipfix-ecn-00.txt =20 He Sebastian, Thank you for furthter comments, please see my reply inline. =20 Best regards, Xueyan =20 Original From: SebastianMoeller <moeller0=3D40gmx.de-Tr9gZwTxerDR74oF6e/[email protected] = <mailto:moeller0=3D40gmx.de-Tr9gZwTxerDR74oF6e/[email protected]> > To: =E5=AE=8B=E9=9B=AA=E9=9B=8100038118; Cc: ingemar.s.johansson=3D40ericsson.com-Tr9gZwTxerDR74oF6e/[email protected] = <mailto:ingemar.s.johansson=3D40ericsson.com-Tr9gZwTxerDR74oF6e/[email protected]> = <ingemar.s.johansson=3D40ericsson.com-Tr9gZwTxerDR74oF6e/[email protected] = <mailto:ingemar.s.johansson=3D40ericsson.com-Tr9gZwTxerDR74oF6e/[email protected]> = >;[email protected] <[email protected] <mailto:[email protected]> = >;[email protected] <[email protected] = <mailto:[email protected]> >;[email protected] = <[email protected] <mailto:[email protected]> >;[email protected] = <[email protected] <mailto:[email protected]> >;[email protected] <[email protected] = <mailto:[email protected]> >; Date: 2026=E5=B9=B401=E6=9C=8814=E6=97=A5 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] = <mailto:[email protected]> > <[email protected] = <mailto:[email protected]> > wrote: > =20 > 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. =20 > 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."=20 > Are you fine with this? > =20 > Best regards, > Xueyan > =20 > Original > From: SebastianMoeller <[email protected] <mailto:[email protected]> >=20 > To: =E5=AE=8B=E9=9B=AA=E9=9B=8100038118; > Cc: [email protected] <mailto:[email protected]> <[email protected] = <mailto:[email protected]> >;[email protected] = <[email protected] <mailto:[email protected]> = >;[email protected] <[email protected] <mailto:[email protected]> = >;[email protected] <[email protected] <mailto:[email protected]> = >;[email protected] <[email protected] <mailto:[email protected]> >; > Date: 2026=E5=B9=B401=E6=9C=8813=E6=97=A5 17:31 > Subject: Re: [tsvwg] [OPSAWG]Re: Re: Fw: New Version Notification for = draft-song-opsawg-ipfix-ecn-00.txtHi Xueyan, > =20 > =20 > > On 13. Jan 2026, at 10:03, <[email protected] = <mailto:[email protected]> > <[email protected] = <mailto:[email protected]> > wrote: > > =20 > > 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, > =20 > [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*. =20 > 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]." =20 > =20 > 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. > =20 > *) 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. > =20 > =20 > 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? > =20 > Regards > Sebastian > =20 > =20 > =20 > > the IPFIX IE for tracking L4S CE mark ratio is proposed in this = draft, we hope this makes sense. > > =20 > > Best regards, > > Xueyan > > =20 > > Original > > From: SebastianMoeller <[email protected] <mailto:[email protected]> > =20 > > To: Sebastian Moeller <moeller0=3D40gmx.de-Tr9gZwTxerDR74oF6e/[email protected] = <mailto:moeller0=3D40gmx.de-Tr9gZwTxerDR74oF6e/[email protected]> >; > > Cc: [email protected] <mailto:[email protected]> <[email protected] = <mailto:[email protected]> = >;=E5=AE=8B=E9=9B=AA=E9=9B=8100038118;[email protected] = <[email protected] <mailto:[email protected]> = >;[email protected] <[email protected] <mailto:[email protected]> = >;[email protected] <[email protected] <mailto:[email protected]> = >;[email protected] <[email protected] <mailto:[email protected]> >; > > Date: 2026=E5=B9=B401=E6=9C=8813=E6=97=A5 16:04 > > Subject: Re: [tsvwg] [OPSAWG]Re: Re: Fw: New Version Notification = for draft-song-opsawg-ipfix-ecn-00.txtDear All, > > =20 > > =20 > > > On 13. Jan 2026, at 08:25, Sebastian Moeller = <moeller0=3D40gmx.de-Tr9gZwTxerDR74oF6e/[email protected] = <mailto:moeller0=3D40gmx.de-Tr9gZwTxerDR74oF6e/[email protected]> > wrote: > > > =20 > > > Hi Xueyan, > > > =20 > > > please see [SM] below. > > > =20 > > > On January 13, 2026 8:09:10 AM GMT+01:00, [email protected] = <mailto:[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. > > > =20 > > > [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. > > > =20 > > > Respectfully, may I ask, what is your rational for considering CE = marks probabilistic? > > =20 > > [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. =20 > > =20 > > > =20 > > > Regards > > > Sebastian > > > =20 > > > =20 > > >> =20 > > >> Best regards, > > >> Xueyan > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> Original > > >> =20 > > >> =20 > > >> From: jmh.direct <[email protected] = <mailto:[email protected]> > =20 > > >> To: =E5=AE=8B=E9=9B=AA=E9=9B=8100038118;[email protected] = <[email protected] <mailto:[email protected]> >; > > >> Cc: [email protected] <mailto:[email protected]> <[email protected] = <mailto:[email protected]> >;[email protected] <[email protected] = <mailto:[email protected]> >;[email protected] <[email protected] = <mailto:[email protected]> >; > > >> Date: 2026=E5=B9=B401=E6=9C=8813=E6=97=A5 13:06 > > >> Subject: [OPSAWG]Re: [tsvwg] Re: Fw: New Version Notification for = draft-song-opsawg-ipfix-ecn-00.txt > > >> =20 > > >> =20 > > >> _______________________________________________ > > >> OPSAWG mailing list -- [email protected] <mailto:[email protected]>=20 > > >> To unsubscribe send an email to [email protected] = <mailto:[email protected]>=20 > > >> =20 > > >> 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. > > >> =20 > > >> Yours, > > >> Joel > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> Sent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone > > >> =20 > > >> =20 > > >> =20 > > >> -------- Original message -------- > > >> From: [email protected] <mailto:[email protected]>=20 > > >> Date: 1/12/26 11:04 PM (GMT-05:00) > > >> To: [email protected] <mailto:[email protected]>=20 > > >> Cc: [email protected] <mailto:[email protected]> , [email protected] = <mailto:[email protected]> , [email protected] <mailto:[email protected]>=20 > > >> Subject: Re: [tsvwg] Re: [OPSAWG]Fw: New Version Notification for = draft-song-opsawg-ipfix-ecn-00.txt > > >> =20 > > >> =20 > > >> =20 > > >> 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. > > >> =20 > > >> Best regards, > > >> Xueyan (on behalf-of co-authors) > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> From: JoelHalpern <[email protected] = <mailto:[email protected]> > =20 > > >> To: =E5=AE=8B=E9=9B=AA=E9=9B=8100038118; > > >> Cc: [email protected] <mailto:[email protected]> <[email protected] = <mailto:[email protected]> >;[email protected] <[email protected] = <mailto:[email protected]> >;[email protected] <[email protected] = <mailto:[email protected]> >; > > >> Date: 2026=E5=B9=B401=E6=9C=8812=E6=97=A5 23:56 > > >> Subject: [tsvwg] Re: [OPSAWG]Fw: New Version Notification for = draft-song-opsawg-ipfix-ecn-00.txt > > >> =20 > > >> 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. > > >> =20 > > >> 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 > > >> =20 > > >> Yours, > > >> Joel > > >> On 1/11/2026 9:54 PM, [email protected] = <mailto:[email protected]> wrote: > > >> =20 > > >> =20 > > >> =20 > > >> Hi Greg, > > >> =20 > > >> 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. > > >> =20 > > >> 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. > > >> =20 > > >> Best regards, > > >> Xueyan > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> From: GregMirsky <[email protected] = <mailto:[email protected]> > =20 > > >> To: =E5=AE=8B=E9=9B=AA=E9=9B=8100038118;Joel Halpern = <[email protected] <mailto:[email protected]> >; > > >> Cc: [email protected] <mailto:[email protected]> <[email protected] = <mailto:[email protected]> >;[email protected] <[email protected] = <mailto:[email protected]> >;mpls <[email protected] <mailto:[email protected]> >; > > >> Date: 2026=E5=B9=B401=E6=9C=8811=E6=97=A5 06:00 > > >> Subject: Re: [OPSAWG]Fw: New Version Notification for = draft-song-opsawg-ipfix-ecn-00.txt > > >> =20 > > >> =20 > > >> 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. > > >> =20 > > >> Regards, > > >> Greg > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> On Fri, Jan 9, 2026 at 1:53=E2=80=AFAM <[email protected] = <mailto:[email protected]> > wrote: > > >> =20 > > >> =20 > > >> Hello OPSAWG and TSVWG, > > >> =20 > > >> 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 > > >> =20 > > >> Your review, comments and questions are welcome. > > >> =20 > > >> Best regards, > > >> Xueyan > > >> =20 > > >> =20 > > >> =20 > > >> Original > > >> =20 > > >> From: [email protected] <mailto:[email protected]> = <[email protected] <mailto:[email protected]> > =20 > > >> To: = =E5=AE=8B=E9=9B=AA=E9=9B=8100038118;=E5=88=98=E5=B0=A700165286; > > >> Date: 2025=E5=B9=B412=E6=9C=8826=E6=97=A5 16:33 > > >> Subject: New Version Notification for = draft-song-opsawg-ipfix-ecn-00.txt > > >> =20 > > >> 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. > > >> =20 > > >> 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 > > >> =20 > > >> =20 > > >> Abstract: > > >> =20 > > >> 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. > > >> =20 > > >> =20 > > >> =20 > > >> The IETF Secretariat > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> =20 > > >> _______________________________________________ > > >> OPSAWG mailing list -- [email protected] <mailto:[email protected]>=20 > > >> To unsubscribe send an email to [email protected] = <mailto:[email protected]>=20 > > > -- =20 > > > Sent from my Android device with K-9 Mail. Please excuse my = brevity. > > =20 > > =20 > =20 =20 ------=_NextPart_001_0100_01DC86D1.2D4389C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta = name=3DGenerator content=3D"Microsoft Word 15 (filtered = medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"MS Gothic"; panose-1:2 11 6 9 7 2 5 8 2 4;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Aptos;} @font-face {font-family:"Microsoft YaHei"; panose-1:2 11 5 3 2 2 4 2 2 4;} @font-face {font-family:"Microsoft JhengHei"; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} @font-face {font-family:"\@Microsoft JhengHei";} @font-face {font-family:"\@Microsoft YaHei";} @font-face {font-family:"\@MS Gothic"; panose-1:2 11 6 9 7 2 5 8 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; font-size:12.0pt; font-family:"Aptos",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:#467886; text-decoration:underline;} span.zreadusername {mso-style-name:zreadusername;} span.EmailStyle26 {mso-style-type:personal-compose; font-family:"Aptos",sans-serif; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; mso-fareast-language:EN-US;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.WordSection1 {page:WordSection1;} --></style></head><body lang=3Den-SE link=3D"#467886" vlink=3D"#96607D" = style=3D'word-wrap:break-word'><div class=3DWordSection1><p = class=3DMsoNormal><span style=3D'mso-fareast-language:EN-US'>Hi<br><br>I = think that the case where flows changes from ECT(1) to ECT0) should be a = rare case, the only case I can come up with is a fall back to ECT(0) in = e.g TCP Prague . <br>In any case, a monitoring node should be able to = distinguish between these cases as the = notEctPacketTotalCount,</span><span = style=3D'font-size:10.5pt;font-family:Consolas;color:#212529'> = </span><span = style=3D'mso-fareast-language:EN-US'>ect0PacketTotalCount,</span><span = style=3D'font-size:10.5pt;font-family:Consolas;color:#212529'> = </span><span style=3D'mso-fareast-language:EN-US'>ect1PacketTotalCount = and cePacketTotalCount represents accumulated numbers.<br>Speaking of = this, if size matters then the variable length fields as specified for = QUIC (RFC9000) can be considered. <br><br><o:p></o:p></span></p><p = class=3DMsoNormal><span style=3D'mso-fareast-language:EN-US'>I am not = sure that l4sCeMarkRatioTotal and l4sCeMarkRatioDelta are very useful = and can cause the possible ambiguity that Sebastian describes. <br>A = monitoring note can easily calculate these metrics based on the = =E2=80=9C...TotalCount=E2=80=9D metrics and also has the possibly so = sort out the ECT(0)/ECT(1) ambiguity.<o:p></o:p></span></p><p = class=3DMsoNormal><span = style=3D'mso-fareast-language:EN-US'><br><br>/Ingemar = <o:p></o:p></span></p><p class=3DMsoNormal><span = style=3D'mso-fareast-language:EN-US'><o:p> </o:p></span></p><p = class=3DMsoNormal><span = style=3D'mso-fareast-language:EN-US'><o:p> </o:p></span></p><p = class=3DMsoNormal><span = style=3D'mso-fareast-language:EN-US'><o:p> </o:p></span></p><p = class=3DMsoNormal><span = style=3D'mso-fareast-language:EN-US'><o:p> </o:p></span></p><p = class=3DMsoNormal><span = style=3D'mso-fareast-language:EN-US'><o:p> </o:p></span></p><p = class=3DMsoNormal><span style=3D'mso-fareast-language:EN-US'> = <o:p></o:p></span></p><p class=3DMsoNormal><span lang=3Den-SE = style=3D'mso-fareast-language:EN-US'><o:p> </o:p></span></p><div = style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm = 4.0pt'><div><div style=3D'border:none;border-top:solid #E1E1E1 = 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal><b><span = lang=3DEN-US = style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span><= /b><span lang=3DEN-US = style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'> = [email protected] <[email protected]> <br><b>Sent:</b> = Thursday, 15 January 2026 03:49<br><b>To:</b> = [email protected]<br><b>Cc:</b> Ingemar Johansson S = <ingemar.s.johansson-IzeFyvvaP7pWk0Htik3J/[email protected]>; [email protected]; = [email protected]; [email protected]; [email protected]; = [email protected]<br><b>Subject:</b> Re: [tsvwg] Re: [OPSAWG]Re: Re: Fw: New = Version Notification for = draft-song-opsawg-ipfix-ecn-00.txt<o:p></o:p></span></p></div></div><p = class=3DMsoNormal><o:p> </o:p></p><div><p><span = style=3D'font-size:10.5pt;font-family:"Microsoft YaHei",sans-serif'>He = Sebastian,<o:p></o:p></span></p><p><span = style=3D'font-size:10.5pt;font-family:"Microsoft = YaHei",sans-serif'>Thank you for furthter comments, please see my reply = inline.<o:p></o:p></span></p><p><span = style=3D'font-size:10.5pt;font-family:"Microsoft = YaHei",sans-serif'><o:p> </o:p></span></p><p><span = style=3D'font-size:10.5pt;font-family:"Microsoft YaHei",sans-serif'>Best = regards,<o:p></o:p></span></p><p><span = style=3D'font-size:10.5pt;font-family:"Microsoft = YaHei",sans-serif'>Xueyan<o:p></o:p></span></p><div><div><p = style=3D'margin:0cm;line-height:15.0pt'><o:p> </o:p></p></div></div>= <div><p class=3DMsoNormal align=3Dcenter = style=3D'text-align:center;line-height:21.0pt;background:#E0E5E9'><span = style=3D'color:#1388FF'>Original<o:p></o:p></span></p><div = id=3DzwriteHistoryContainer><div><div><div><p class=3DMsoNormal = style=3D'background:#F5F6F8'><strong><span = style=3D'font-family:"Aptos",sans-serif;color:black'>From: </span></= strong><span class=3Dzreadusername><span = style=3D'color:black'>SebastianMoeller <<a = href=3D"mailto:moeller0=3D40gmx.de-Tr9gZwTxerDR74oF6e/[email protected]">moeller0=3D40gmx.de@dm= arc.ietf.org</a>></span></span><o:p></o:p></p></div><div><p = class=3DMsoNormal style=3D'background:#F5F6F8'><strong><span = style=3D'font-family:"Aptos",sans-serif;color:black'>To: </span></st= rong><span class=3Dzreadusername><span style=3D'font-family:"MS = Gothic";color:black'>=E5=AE=8B=E9=9B=AA=E9=9B=81</span><span = style=3D'color:black'>00038118;</span></span><o:p></o:p></p></div><div><p= class=3DMsoNormal style=3D'background:#F5F6F8'><strong><span = style=3D'font-family:"Aptos",sans-serif;color:black'>Cc: </span></st= rong><span class=3Dzreadusername><span style=3D'color:black'><a = href=3D"mailto:ingemar.s.johansson=3D40ericsson.com-Tr9gZwTxerDR74oF6e/[email protected]">ingem= ar.s.johansson=3D40ericsson.com-Tr9gZwTxerDR74oF6e/[email protected]</a> <<a = href=3D"mailto:ingemar.s.johansson=3D40ericsson.com-Tr9gZwTxerDR74oF6e/[email protected]">ingem= ar.s.johansson=3D40ericsson.com-Tr9gZwTxerDR74oF6e/[email protected]</a>>;[email protected] = <<a = href=3D"mailto:[email protected]">[email protected]</a>>;jmh.direct@joelhalp= ern.com <<a = href=3D"mailto:[email protected]">[email protected]</a>= >;[email protected] <<a = href=3D"mailto:[email protected]">[email protected]</a>>;opsawg@ie= tf.org <<a = href=3D"mailto:[email protected]">[email protected]</a>>;[email protected] = <<a = href=3D"mailto:[email protected]">[email protected]</a>>;</span></span><o:p></= o:p></p></div><div><p class=3DMsoNormal = style=3D'background:#F5F6F8'><strong><span = style=3D'font-family:"Aptos",sans-serif;color:black'>Date: </span></= strong><span style=3D'color:black'>2026</span><span = style=3D'font-family:"MS Gothic";color:black'>=E5=B9=B4</span><span = style=3D'color:black'>01</span><span style=3D'font-family:"MS = Gothic";color:black'>=E6=9C=88</span><span = style=3D'color:black'>14</span><span style=3D'font-family:"MS = Gothic";color:black'>=E6=97=A5</span><span style=3D'color:black'> = 19:06</span><o:p></o:p></p></div><div><p class=3DMsoNormal = style=3D'background:#F5F6F8'><strong><span = style=3D'font-family:"Aptos",sans-serif;color:black'>Subject: [tsvwg= ] Re: [OPSAWG]Re: Re: Fw: New Version Notification for = draft-song-opsawg-ipfix-ecn-00.txt</span></strong><o:p></o:p></p></div></= div><div><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'>Hi Xueyan<br><br>4.15. l4sCeMark= RatioTotal<br><br>Name: l4sCeMarkRatioTotal<br><br>ElementID: T= BD15<br>Description: The proportion of L4S packe= ts marked with the CE<br>codepoint, calculated&n= bsp;over the total lifetime of the Flow.&nb= sp;This<br>element represents the total CE marki= ng rate for L4S traffic<br>within the Flow.= It is calculated as:<br><br>CE-marked L4S = packets (total count) / Total L4S packets&n= bsp;(total<br>count)<br><br>Where L4S packets are tho= se identified by the ECN codepoint<br>ECT(1).&nb= sp;The result is a ratio ranging from = 0.0 to 1.0.<o:p></o:p></p><p>Here is a challenge= , once a packet is marked CE you = can not veridically deduce whether it was&n= bsp;ECT(0) or ECT(0) (or Not-ECT), so you&n= bsp;need to expect that flows use either&nb= sp;ECT(0) or ECT(1) consistently. But since = ;you actually keep counts of ECT(0) and&nbs= p;ECT(1) packets, maybe make this conditional&nb= sp;on ect0PacketTotalCount being zero for this&n= bsp;flow?<o:p></o:p></p><p>>>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.<o:p></o:p></p><p = class=3DMsoNormal><br><br>You already argue similarly = ;here:<br><br>When measuring the proportion of p= ackets marked with the CE<br>codepoint, the = ;CE marking rate for L4S traffic should&nbs= p;be calculated<br>specifically for flows identified&= nbsp;as ECT(1) (L4S traffic identifier)<br>prior = ;to marking, rather than aggregating all CE= -marked packets<br>irrespective of their original&nbs= p;ECT codepoint. This ensures the<br>performance = ;of L4S services can be accurately monitore= d and<br>distinguished from Classic ECN traffic,= which may have different<br>congestion response= characteristics.<br><br>But you still have the&= nbsp;unfortunate ambiguity of CE and the fa= t that flows can change their ECN code= point.<br><br>Regards<br> Sebastian<br><br><br><br= >> On 14. Jan 2026, at 04:00, <<= a = href=3D"mailto:[email protected]">[email protected]</a>>&n= bsp;<<a = href=3D"mailto:[email protected]">[email protected]</a>>&n= bsp;wrote:<br>> = <br>> Hi Sebastian and Ingemar,<br>> Thank= you for further clarification and sharing&= nbsp;the valuable insights. I agree that we= should strike a balance between standands&= nbsp;and real deployments. = <br>> Given the L4S CE marking may = be probabilistic, to ensure the reliability = ;of the statistical data and reduce the&nbs= p;bias risk of sampling results, probabilistic&n= bsp;sampling methods should follow RFC5475.<br>>&n= bsp;The following proposed text to operation&nbs= p;section:<br>> "In L4S deployments, CE = marking may be either probabilistic or dete= rministic, as determined by the specific AQ= M implementation. The IEs on the statiscal&= nbsp;count of CE-mark packets and L4S CE&nb= sp;marking ratio are defined to enable oper= ators to perfom quantitative monitoring and = ;management of L4S service performance, typicall= y based on flow data that may be = acquired via packet or flow sampling. Imple= mentations should employ sampling methods (see&n= bsp;RFC5475) that preserve the statistical repre= sentativeness of these IEs and reduce bias&= nbsp;risk of sampling results." = <br>> Are you fine with this?<br>> = <br>> Best regards,<br>> Xueyan<br>> = <br>> Original<br>> From: SebastianMoeller <= <a href=3D"mailto:[email protected]">[email protected]</a>> = <br>> To: <span style=3D'font-family:"MS = Gothic"'>=E5=AE=8B=E9=9B=AA=E9=9B=81</span>00038118;<br>> Cc:&nbs= p;<a href=3D"mailto:[email protected]">[email protected]</a> <<a = href=3D"mailto:[email protected]">[email protected]</a>>;jmh.direct@joelhalp= ern.com <<a = href=3D"mailto:[email protected]">[email protected]</a>= >;[email protected] <<a = href=3D"mailto:[email protected]">[email protected]</a>>;opsawg@ie= tf.org <<a = href=3D"mailto:[email protected]">[email protected]</a>>;[email protected]&nbs= p;<<a = href=3D"mailto:[email protected]">[email protected]</a>>;<br>> Date:&n= bsp;2026<span style=3D'font-family:"MS Gothic"'>=E5=B9=B4</span>01<span = style=3D'font-family:"MS Gothic"'>=E6=9C=88</span>13<span = style=3D'font-family:"MS = Gothic"'>=E6=97=A5</span> 17:31<br>> Subject: Re: = [tsvwg] [OPSAWG]Re: Re: Fw: New Version Not= ification for draft-song-opsawg-ipfix-ecn-00.txtHi Xueyan,= <br>> <br>> = <br>> > On 13. Jan 2026, at 10:0= 3, <<a = href=3D"mailto:[email protected]">[email protected]</a>>&n= bsp;<<a = href=3D"mailto:[email protected]">[email protected]</a>>&n= bsp;wrote:<br>> > = <br>> > Hi Sebastian,<br>> > Thank&n= bsp;you for further clarification, agree with&nb= sp;your points.<br>> > For L4S, the d= ual-queue coupled AQM mechanism uses probalisiti= c ECN marking for L4S traffic,<br>> = <br>> [SM3] Respectfully, that might be = true for the DualQ RFC9332, but the ac= tual sch_dualpi2 AQM in the Linux kernel&nb= sp;uses a deterministic step marker for the= L-queue if there is not enough C-traf= fic to drive the pi2 component*. = <br>> 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&n= bsp;deterministic step marker in practice, but&n= bsp; rfc9332 contains the following "hedge&= quot;:<br>> "As a first concrete example= , the pseudocode below gives the DualPI2&nb= sp;algorithm. DualPI2 follows the structure of&n= bsp;the DualQ Coupled AQM framework in Figu= re 1. A simple ramp function (configured&nb= sp;in units of queuing time) with unsmoothe= d ECN marking is used for the Native&n= bsp;L4S AQM. The ramp can also be conf= igured as a step function. The PI2 alg= orithm [PI2] is used for the Classic A= QM. PI2 is an improved variant of the&= nbsp;PIE AQM [RFC8033]." <br>> = <br>> as of today it turns out for&= nbsp; the actual sch_dualpi2b in Linux &quo= t;The ramp can ONLY be configured as a= step function". Which might change or= might not change in the future.<br>>&nb= sp; = <br>> *) If the marking is driven h= owever by non-L4S traffic in the C-queue&nb= sp;the marking, even in the L-queue will&nb= sp;be probabilistic, so for the current int= ernet traffic mix, L4S marking likely is&nb= sp;probabilistic.<br>> <br>> = <br>> That said, I am not sure that= has any bearing on the validity IPFIX= 's sampling approach, any sampler will over= look rare events more often than common&nbs= p;events, but is agnostic to the nature&nbs= p;of these events, no? Maybe the IPFIX = ;draft could just avoid reasoning about mar= king determinism or lack there of completel= y?<br>> = <br>> Regards<br>> Sebastian<br>&= gt; <br>> <br>> = <br>> > the IPFIX IE for tracking&nbs= p;L4S CE mark ratio is proposed in thi= s draft, we hope this makes sense.<br>>&= nbsp;> = <br>> > Best regards,<br>> > Xueyan<= br>> > = <br>> > Original<br>> > From: Sebast= ianMoeller <<a = href=3D"mailto:[email protected]">[email protected]</a>> = <br>> > To: Sebastian Moeller <<a = href=3D"mailto:moeller0=3D40gmx.de-Tr9gZwTxerDR74oF6e/[email protected]">moeller0=3D40gmx.de@dm= arc.ietf.org</a>>;<br>> > Cc: <a = href=3D"mailto:[email protected]">[email protected]</a> <<a = href=3D"mailto:[email protected]">[email protected]</a>>;<span = style=3D'font-family:"MS = Gothic"'>=E5=AE=8B=E9=9B=AA=E9=9B=81</span>00038118;jmh.direct@joelhalper= n.com <<a = href=3D"mailto:[email protected]">[email protected]</a>= >;[email protected] <<a = href=3D"mailto:[email protected]">[email protected]</a>>;opsawg@ie= tf.org <<a = href=3D"mailto:[email protected]">[email protected]</a>>;[email protected]&nbs= p;<<a = href=3D"mailto:[email protected]">[email protected]</a>>;<br>> >&nb= sp;Date: 2026<span style=3D'font-family:"MS = Gothic"'>=E5=B9=B4</span>01<span style=3D'font-family:"MS = Gothic"'>=E6=9C=88</span>13<span style=3D'font-family:"MS = Gothic"'>=E6=97=A5</span> 16:04<br>> > Subject: = ;Re: [tsvwg] [OPSAWG]Re: Re: Fw: New Versio= n Notification for draft-song-opsawg-ipfix-ecn-00.txtDear&= nbsp;All,<br>> > <br>> > = <br>> > > On 13. Jan 2026, at= 08:25, Sebastian Moeller <<a = href=3D"mailto:moeller0=3D40gmx.de-Tr9gZwTxerDR74oF6e/[email protected]">moeller0=3D40gmx.de@dm= arc.ietf.org</a>> wrote:<br>> > > &= nbsp; = <br>> > > Hi Xueyan,<br>> > = > = <br>> > > please see [SM] below.<b= r>> > > = <br>> > > On January 13, 2026 = ;8:09:10 AM GMT+01:00, <a = href=3D"mailto:[email protected]">[email protected]</a> = wrote:<br>> > >> Hi Joel,<br>> &g= t; >> Thank you for further suggestio= ns. 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&nb= sp;congestion occurs. We will add relevant = text to section 5 to provide some oper= ational considerations.<br>> > >  = ; = <br>> > > [SM] DCTCP (and L4S)&nbs= p;potentially employ probabilistic marking, rfc3168&n= bsp;does not. Please do not assumd all = ;CE marks are dctcp-style...<br>> > >&n= bsp;But even dctcp style marking can be&nbs= p;deterministic, e.g. as in fq-codel's ce t= hreshol marking or dualpi2's step threshold.<br>= > > > = <br>> > > Respectfully, may I ask,= what is your rational for considering = ;CE marks probabilistic?<br>> > = <br>> > [SM2] Rethinking and refining = ;my argument, whether a CE mark is pro= babilistic or not is not really a func= tion of marking-law (dctcp vs. rfc3168) but= of the AQM that is used, some op= erate probabilistically, some do not. &nbs= p; <br>> > = <br>> > > = <br>> > > Regards<br>> > >&nbs= p; Sebastian<br>> >&n= bsp;> = <br>> > > = <br>> > >> = <br>> > >> Best regards,<br>> >= ; >> Xueyan<br>> > >> &n= bsp; <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> Original<br>> > >= ;> = <br>> > >> = <br>> > >> From: jmh.direct <<a = href=3D"mailto:[email protected]">[email protected]</a>= > <br>> > >> To: <span = style=3D'font-family:"MS = Gothic"'>=E5=AE=8B=E9=9B=AA=E9=9B=81</span>00038118;[email protected]&n= bsp;<<a = href=3D"mailto:[email protected]">[email protected]</a>>;<br>>&= nbsp;> >> Cc: <a = href=3D"mailto:[email protected]">[email protected]</a> <<a = href=3D"mailto:[email protected]">[email protected]</a>>;[email protected]&nb= sp;<<a = href=3D"mailto:[email protected]">[email protected]</a>>;[email protected] = <<a = href=3D"mailto:[email protected]">[email protected]</a>>;<br>> >&nb= sp;>> Date: 2026<span style=3D'font-family:"MS = Gothic"'>=E5=B9=B4</span>01<span style=3D'font-family:"MS = Gothic"'>=E6=9C=88</span>13<span style=3D'font-family:"MS = Gothic"'>=E6=97=A5</span> 13:06<br>> > >> = ;Subject: [OPSAWG]Re: [tsvwg] Re: Fw: New V= ersion Notification for draft-song-opsawg-ipfix-ecn-00.txt= <br>> > >> = <br>> > >> = <br>> > >> ___________________________________= ____________<br>> > >> OPSAWG mailing&nbs= p;list -- <a = href=3D"mailto:[email protected]">[email protected]</a><br>> >&nbs= p;>> To unsubscribe send an email to&= nbsp;<a = href=3D"mailto:[email protected]">[email protected]</a><br>>&n= bsp;> >> = <br>> > >> Tgank you for the&nb= sp;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 bia= s in the result of sampling a varying&= nbsp;stream, likely with some patterns in i= ts variation, is low.<br>> > >> = ; = <br>> > >> Yours,<br>> > >&= gt; Joel<br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> Sent via the Samsung= Galaxy S20 FE 5G, an AT&T 5G = ;smartphone<br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> -------- Original message= --------<br>> > >> From: <a = href=3D"mailto:[email protected]">[email protected]</a><br>&g= t; > >> Date: 1/12/26 11:04 PM&nbs= p;(GMT-05:00)<br>> > >> To: <a = href=3D"mailto:[email protected]">[email protected]</a><br>> = > >> Cc: <a = href=3D"mailto:[email protected]">[email protected]</a>, <a = href=3D"mailto:[email protected]">[email protected]</a>, <a = href=3D"mailto:[email protected]">[email protected]</a><br>> > &g= t;> Subject: Re: [tsvwg] Re: [OPSAWG]Fw: = ;New Version Notification for draft-song-opsawg-ipfix= -ecn-00.txt<br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> Hi Joel,<br>> >&nbs= p;>> Thank you for taking time to&nbs= p;read the draft, and providing new aspects= we need to consider, we will make&nbs= p;updates to the draft to reflect your = ;comments.<br>> > >> Please also see= my reply inline.<br>> > >> &nb= sp; = <br>> > >> Best regards,<br>> >= ; >> Xueyan (on behalf-of co-authors)<br>&= gt; > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> From: JoelHalpern <<a = href=3D"mailto:[email protected]">[email protected]</a>> &nbs= p; <br>> > >> To: <span = style=3D'font-family:"MS = Gothic"'>=E5=AE=8B=E9=9B=AA=E9=9B=81</span>00038118;<br>> >&nb= sp;>> Cc: <a = href=3D"mailto:[email protected]">[email protected]</a> <<a = href=3D"mailto:[email protected]">[email protected]</a>>;[email protected]&nb= sp;<<a = href=3D"mailto:[email protected]">[email protected]</a>>;[email protected] = <<a = href=3D"mailto:[email protected]">[email protected]</a>>;<br>> >&nb= sp;>> Date: 2026<span style=3D'font-family:"MS = Gothic"'>=E5=B9=B4</span>01<span style=3D'font-family:"MS = Gothic"'>=E6=9C=88</span>12<span style=3D'font-family:"MS = Gothic"'>=E6=97=A5</span> 23:56<br>> > >> = ;Subject: [tsvwg] Re: [OPSAWG]Fw: New Version&nb= sp;Notification for draft-song-opsawg-ipfix-ecn-00.txt<br>>&= nbsp;> >> = <br>> > >> The discussion prompted&n= bsp;me to read this draft. I have&nbs= p;two different questions about it:<br>> >= >> 1) In what way is it re= lated to L4S? Yes, L4S uses ECN. = ; But ECN is not restricted to L4S.<br= >> > >>>> Xueyan: The main&nbs= p;consideration for L4S service is that L4S= introduces a new ECN codepoint ECT(1) = ;for traffic identification, it helps the d= iferenciation between classical and L4S traffic&= nbsp;and uses CE codepoint for potential co= ngestion mark. The monitoring of ECN can&nb= sp;provide Operators with valuable insights, inc= luding the ratio of L4S traffic in the= network, statistics of network congestion = and granular visibility for the performance = ;of L4S services.<br>> > >> But = ;the ECN monitoring in this draft is n= ot limited to L4S, for example, we als= o provide the monitoring IEs for ECN(0)&nbs= p;and non-ECT, with a flexible design to&nb= sp;satisfy user's monitoring requirements.<br>> &g= t; >> = <br>> > >> 2) Even if we a= ssume this only reports packets with ECN&nb= sp;bits enabled (not 00), generating an IPF= IX report for every data packet across = ;many flows (in some environments, all flow= s) seems to be tremendous overhead. S= ince as I understnad it this is for&nb= sp;management monitoring of operability, not for= congestion response, that seems a massive&= nbsp;overhead. Am I misreading the draft?<= br>> > >>>> Xueyan: Yes, we&nb= sp;agree that doing this per packets would&= nbsp;create too much overhead. In real depl= oyment, IPFIX performs probalistic sampling for&= nbsp;data collection based on user requirements&= nbsp;instead of extracting data per packet. = ;The specifi data export is determined by&n= bsp;IPFIX configurations and device capabilities,&nbs= p;but the general rule is to avoid cre= ating heavy overhead to network nodes.<br>>&n= bsp;> >> Best regards<br>> > >= > Xueyan<br>> > >> = <br>> > >> Yours,<br>> > >&= gt; Joel<br>> > >> On 1/11/2026 = ;9:54 PM, <a = href=3D"mailto:[email protected]">[email protected]</a> = wrote:<br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> Hi Greg,<br>> >&nbs= p;>> = <br>> > >> Thank you for the&nb= sp;good question.<br>> > >> Yes, ECN= is an end-to-end protocol, TCP sender = ;intiates the signalling and TCP receiver r= esponds. And I think IPFIX works in IP= layer, so the target data extraction = is at network nodes. For the information&nb= sp;elements proposed in this drfat, the IPF= IX extraction position may be different bas= ed on monitoring purposes. We plan to = add the following text to section 5, d= oes it work for you?<br>> > >>&= nbsp;The IPFIX IEs defined in this draft&nb= sp;may have their information extraction positio= ns adjusted based on different ECN monitori= ng purposes in the network. Among them,&nbs= p;the basic ECN field elements are used&nbs= p;to reflect the ECN codepoints carried in&= nbsp;the IPv4 header, the IPv6 Traffic Clas= s octet, or the MPLS EXP field. These&= nbsp;fields can be flexibly extracted at an= y node along the path that has IPFIX&n= bsp;export capability. For tunnel ECN negotiatio= n status IEs, the IPFIX data can only&= nbsp;be provided by the specific tunnel end= points that participate in the negotiation. = ;For cumulative statistics IEs, the statistical&= nbsp;data may be processed with a higher&nb= sp;priority at traffic aggregation or egress&nbs= p;nodes.<br>> > >> = <br>> > >> For the mpls-ecn dra= ft you shared, it appers to define a&n= bsp;new ECN opcode encapsulated in MNA pack= ets for MPLS data plane. I think it's&= nbsp;actually relevant to the ipfix-ecn draft,&n= bsp;if MPLS WG adopts it, we would lik= e to add the ECN export from MPLS = ;MNA packets to our draft.<br>> > >= ;> = <br>> > >> Best regards,<br>> >= ; >> Xueyan<br>> > >> &n= bsp; <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> From: GregMirsky <<a = href=3D"mailto:[email protected]">[email protected]</a>> = <br>> > >> To: <span = style=3D'font-family:"MS = Gothic"'>=E5=AE=8B=E9=9B=AA=E9=9B=81</span>00038118;Joel Halpern&nbs= p;<<a = href=3D"mailto:[email protected]">[email protected]</a>>;<br>>&= nbsp;> >> Cc: <a = href=3D"mailto:[email protected]">[email protected]</a> <<a = href=3D"mailto:[email protected]">[email protected]</a>>;[email protected]&nb= sp;<<a = href=3D"mailto:[email protected]">[email protected]</a>>;mpls <<a = href=3D"mailto:[email protected]">[email protected]</a>>;<br>> >&nb= sp;>> Date: 2026<span style=3D'font-family:"MS = Gothic"'>=E5=B9=B4</span>01<span style=3D'font-family:"MS = Gothic"'>=E6=9C=88</span>11<span style=3D'font-family:"MS = Gothic"'>=E6=97=A5</span> 06:00<br>> > >> = ;Subject: Re: [OPSAWG]Fw: New Version Notificati= on for draft-song-opsawg-ipfix-ecn-00.txt<br>> >&nbs= p;>> = <br>> > >> = <br>> > >> Hi Xueyan,thank you = for sharing the updated draft. A relatively= new draft draft-halmir-mpls-ecn on supporting&n= bsp;ECN in the MPLS using MNA might be= of interest to you and others involve= d in the matter. And I have a que= stion. As I understand the ECN, it is&= nbsp;a host that is expected to act on= the information collected in the ECN = field along the path of a packet. If&n= bsp;that is correct, who's the intended tar= get of the IPFIX notification about the&nbs= p;ECN? Is the intention to act on ECN&= nbsp;information obtained on a segment, e.g.,&nb= sp;a tunnel, rather than based on the = e2e ECN information? I read Section 5, = ;but was left with these questions.<br>> = ;> >> = <br>> > >> Regards,<br>> > >= ;> Greg<br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> On Fri, Jan 9, = 2026 at 1:53<span = style=3D'font-family:"Arial",sans-serif'>=E2=80=AF</span>AM <<a = href=3D"mailto:[email protected]">[email protected]</a>>&n= bsp;wrote:<br>> > >> = <br>> > >> = <br>> > >> Hello OPSAWG and TSV= WG,<br>> > >> = <br>> > >> We submited a new&nb= sp;draft and posted it in the IETF dat= atracker <a = href=3D"https://datatracker.ietf.org/doc/draft-song-opsawg-ipfix-ecn/">ht= tps://datatracker.ietf.org/doc/draft-song-opsawg-ipfix-ecn/</a><br>>&n= bsp;> >> The following IPFIX informatio= n elements are introduced for L4S ECN = monitoring:<br>> > >> - ECN field&nb= sp;capture in protocol layer, including ECN = ;field in IPv4/IPv6 ECN field, MPLS EXP&nbs= p;and tunnel ECN negotiation status<br>> >= >> - ECN codepoint statistics, inclu= ding incremenatl and total count for non-EC= T, ECT(0), ECT(1) and CE packets<br>> &g= t; >> - L4S performance indicator, pr= oviding short-term and long-term view of co= ngestion experienced by L4S traffic<br>> >= >> = <br>> > >> Your review, comments&nbs= p;and questions are welcome.<br>> > >&g= t; = <br>> > >> Best regards,<br>> >= ; >> Xueyan<br>> > >> &n= bsp; <br>> > >> = <br>> > >> = <br>> > >> Original<br>> > >= ;> = <br>> > >> From: <a = href=3D"mailto:[email protected]">[email protected]</a>&nbs= p;<<a = href=3D"mailto:[email protected]">[email protected]</a>>= <br>> > >> To: <span = style=3D'font-family:"MS = Gothic"'>=E5=AE=8B=E9=9B=AA=E9=9B=81</span>00038118;<span = style=3D'font-family:"MS Gothic"'>=E5=88=98</span><span = style=3D'font-family:"Microsoft = JhengHei",sans-serif'>=E5=B0=A7</span>00165286;<br>> > &g= t;> Date: 2025<span style=3D'font-family:"MS = Gothic"'>=E5=B9=B4</span>12<span style=3D'font-family:"MS = Gothic"'>=E6=9C=88</span>26<span style=3D'font-family:"MS = Gothic"'>=E6=97=A5</span> 16:33<br>> > >> = ;Subject: New Version Notification for draft-son= g-opsawg-ipfix-ecn-00.txt<br>> > >> &nbs= p; = <br>> > >> A new version of&nbs= p;Internet-Draft draft-song-opsawg-ipfix-ecn-00.txt has be= en<br>> > >> successfully submitted = by Xueyan Song and posted to the<br>>&nb= sp;> >> IETF repository.<br>> > &= gt;> = <br>> > >> Name: = draft-song-opsawg-ipfix-ecn<br>> > >> Revision= : 00<br>> > >> Title: &n= bsp;Export of L4S ECN in IP Flow Infor= mation Export (IPFIX)<br>> > >> Date= : 2025-12-26<br>> > >>= Group: Individual Submission<br>>&nb= sp;> >> Pages: 14<br>> = > >> URL: <a = href=3D"https://www.ietf.org/archive/id/draft-song-opsawg-ipfix-ecn-00.tx= t">https://www.ietf.org/archive/id/draft-song-opsawg-ipfix-ecn-00.txt</a>= <br>> > >> Status: <a = href=3D"https://datatracker.ietf.org/doc/draft-song-opsawg-ipfix-ecn/">ht= tps://datatracker.ietf.org/doc/draft-song-opsawg-ipfix-ecn/</a><br>>&n= bsp;> >> HTML: <a = href=3D"https://www.ietf.org/archive/id/draft-song-opsawg-ipfix-ecn-00.ht= ml">https://www.ietf.org/archive/id/draft-song-opsawg-ipfix-ecn-00.html</= a><br>> > >> HTMLized: <a = href=3D"https://datatracker.ietf.org/doc/html/draft-song-opsawg-ipfix-ecn= ">https://datatracker.ietf.org/doc/html/draft-song-opsawg-ipfix-ecn</a><b= r>> > >> = <br>> > >> = <br>> > >> Abstract:<br>> > &g= t;> = <br>> > >> This document = ;defines a set of IP Flow Information = Export (IPFIX)<br>> > >> Info= rmation Elements for monitoring the Low Lat= ency, Low Loss, and<br>> > >> &= nbsp; Scalable throughput (L4S) service. S= pecially, these elements enable<br>> > >= ;> network operators to monitor t= he Explicit Congestion Notification<br>> > = ;>> (ECN) information of L4S d= eployment and performance of traffic.<br>> &g= t; >> = <br>> > >> = <br>> > >> = <br>> > >> The IETF Secretariat<br>&= gt; > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> = <br>> > >> ___________________________________= ____________<br>> > >> OPSAWG mailing&nbs= p;list -- <a = href=3D"mailto:[email protected]">[email protected]</a><br>> >&nbs= p;>> To unsubscribe send an email to&= nbsp;<a = href=3D"mailto:[email protected]">[email protected]</a><br>>&n= bsp;> > -- = <br>> > > Sent from my Android&nbs= p;device with K-9 Mail. Please excuse my&nb= sp;brevity.<br>> > <br>> > = <br>> = <o:p></o:p></p></div></div></div></div><p><o:p> </o:p></p></div></di= v></div></body></html> ------=_NextPart_001_0100_01DC86D1.2D4389C0-- ------=_NextPart_000_00FF_01DC86D1.2D4389C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCGI8w ggU4MIIDIKADAgECAhEAlb4WoPcuRvF7OYJy+ovNljANBgkqhkiG9w0BAQUFADA3MRQwEgYDVQQK DAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0wNzEwMTgx MjAwNTBaFw0zMjEwMTgxMjAwNTBaMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU ZWxpYVNvbmVyYSBSb290IENBIHYxMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwr7r J/Aho/NpJlV+ncVVFpFc/e8hv1OAei3SkYxjMfDsJPDDpdJyfBBt9De35eZ8eeqMtYKLrki2rADc ZXXsKk1fwYf1IGUrgahHPokjlTAWkH/oVwdI5xmuv0VnsTcbBir+3vmsfYP7Xrrkj5dnvkuOjWQH VzhVaTQ2PRNI70/i02YepM8at142M9S0Br0YAf13hFAARfWMXegjvH7+NeHtUHupMI0Z0wmOaGdd vzyXGFO7KWLFyl5ywceW1NstoLQfaQPs6uJQ8Qw88KzzUy3wHPXtbDk5c4AWyFKwI83gPtzdPEeg uzWK4phoi77lv3Lu0vql7RLt/JgYqSZ23ChLECAc038Wdy3tb4D3SbtTBbtdaMfUyHUWP4lai/cX R9RM8dKJeT5NPZioYd46HtL4XgPgwckcjNONTdOVNrM3X2NjmzMU8C0ma1N8iYwywm7sPSEAOcmh aOJQgy6wOivzNqCsL+RvYcJRCTk+i1O5u2fa3FO5dlk2nUPlIOA9MmCFIlG3xzO73RUvpHimB3uB RjYEht15NceVLDuwoxc15XMftFxZ79rqEGV7etB/n7O0Kjc7cIubW7krt+yyURKXUyla1PASENxP ArsSki9i1D9pQ3wN1vxYdQGInVgWS966kP9HAYkGavZfspBqswKmAoi/s0d+KtnV+mh4NU0CAwEA AaM/MD0wDwYDVR0TAQH/BAUwAwEB/zALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFPCPWTgAs/WPmpYM 1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQC+5FxiTiT0DAj/8NMMaOSTSSI/RCdvu23eg2bO qMwN/PWaBuV3FJHrnUF7mSqE5f/8IcFd8OQfV7d1qaFfAib/18f3Tt5P+PccRsB6T0AsIjXwGbHQ a2cssKjgwEA3NfaEXFzjr0J4/qfJDVDqDYR29lHvg1PGev8OVkkuj3rWDOYnVONNCmByYs2RB9al v8iZa+3EGearTBE4xW8x4m5JyD92gCYDJingNvb2IFPjF3A0F51jaB5r7MNNhrgTMC9dRg1HQ9Ub qlkOuVyNBkitdIdfx/wxVEET4schDp7gHg3hwHtDhZDFiljGZQp4V/LGIw8B2SBL3g/7koV1Klxz jW17JZHK7kWuBksAzNOxWVDaOog7KUNGXpcrVM5Tb41K55b6v3EOQot8/Sig0EjK2sSBTLuic5Mm yOsM1iaItsAkz7u9W+t1fekIjoYzLHl3CWmlifyzcJCHdo/TIrtCzr1zCyAmKtCbPXAeJGzNh3ap F5a3zw2S+44YqZhJ0Z7+YERyIbkZ7cL1MfE5SIiQJHVUFq3O9PhpFGQ5+6O4unBAxyccv8RWU/pj ZdDzHA4W9WuGWE0Y1OQNjqWdW5HcdiRQP8Yq+9m3nLXW5tDZ6BmLFXFIrbfq2FmI1JC/FrPZ6axZ YVTIHLrKwcrhuSBMjzqTiaWgzL/T9nWkdZZtVjCCBiQwggQMoAMCAQICDwGLKTrMQKumkjA5d3U7 jDANBgkqhkiG9w0BAQsFADBKMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLRXJpY3Nzb24gQUIxJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjQwHhcNMjMxMDEzMTMzMDAxWhcNMjYx MDEzMTMzMDAwWjCBkDERMA8GA1UECgwIRXJpY3Nzb24xGjAYBgNVBGEMEU5UUlNFLTU1NjA1Ni02 MjU4MRwwGgYDVQQDDBNJbmdlbWFyIEpvaGFuc3NvbiBTMRAwDgYDVQQFEwdFUExJSk9IMS8wLQYJ KoZIhvcNAQkBFiBpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAIPQsolJYmqI5CNTFiFAxkt5A9q0vkiLOoE8jAj8vQ/dE6FouFCN iv48zAUJ4c7yFyg42SQZ7iv1GRsewEhFka+4AHnXsqi/u3TvihRQ8u0rr+TqR3gWe6hqyhbIgIBu asE/5D8plirG9rss5gHhTEpDRqDFhHV/U/ayvwhoCkl2iooOp2pnin0Fdn36VvkC/tCBVfO1f76h eIqk2nn/BNfxaYedRVqJOYCzpbuwoy9ypShJM8uVJH5TQmWU2HzxRf9SifIlQ+MSeohTV4ljORRw 6NEYXVLx8OTRJpCsHxLgEC5oRmthRKHS2bXWIDvuWDSbtcCyn3gwsS5hRbO3AvECAwEAAaOCAb4w ggG6MB8GA1UdIwQYMBaAFBnB/xAJ/P1A3TawbtmNbz+37ZwrMB0GA1UdDgQWBBSGwGoz89Rp5jKY uw1TFynSL7rzfzAOBgNVHQ8BAf8EBAMCBaAwTwYDVR0gBEgwRjA5BgwrBgEEAYIPAgMBARIwKTAn BggrBgEFBQcCARYbaHR0cHM6Ly9jcHMudHJ1c3QudGVsaWEuY29tMAkGB2eBDAEFAwEwKwYDVR0R BCQwIoEgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20wTAYDVR0fBEUwQzBBoD+gPYY7 aHR0cDovL2h0dHBjcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2NC5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GCCsGAQUFBwEBBHEwbzAoBggrBgEF BQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nw cy50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXY0LmNlcjANBgkqhkiG9w0B AQsFAAOCAgEAipQlun9jJDJuQ71u6c3kLm3aiWBcpJRPr5dZgdNH8JWWmEvzerwB3NlyQn+CeMym 9/NMhvMoCj7r4vQPEbrtuXnvveiQ9XcczDzyPpcMPIJaYWZp7V246SMLpJUBWmQT9Z/9jATn5Eyk 3dVsJxMp/eeiXKBnfzPjqqOhZ41Sxx6qVrYHVfBW6/3WrjfI2duOYLZP/8/3xqLnio1Tid8lTaBg XdljMvHOow4NDVyFvqpNLhfHenuHQoGpAfpD2WUxmFZ/UYm2kKsE412jsbBpkd4dD0TvBK55rq0O f9o9q3/PtPVBOhH6GhiXGPwUXGNuE0jZyVc+fzAtjosrs7An1JD7rTkdKCwViXWH6lSS+m+A4WEU EUR8Ju3VN1ArcS1oSStrkCfB9N+AIF33VHB8/lQr+KXqcgCFtpXMsQrs33ZfViA0yZJ52ftRNPvq Mt15WPwfd78EvAdNy2Qo41zIF6YQlMXVFYQzg9QegdRmUECvdM89/2AJFFBik8eTkwdwmu4Iqc7K w+ubFBFKzivLZfRv4DF/6GvvKPQ9aexXOlpE+qt7gZcCC6ptYtGB4zUH42zgTKXfp2/E1V0X+1AL C6vjvo0yfMPkKNTYw1hf3sHSEQF34VcePbzCZBomTuTSsY650ATmbgx/8vS1RjjOP+truZf88GWi lZF+SbrkCwAwggZrMIIEU6ADAgECAg8BZ1+CvgAX3olVqTdusfkwDQYJKoZIhvcNAQELBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcN MTgxMTI5MTI0MDEzWhcNMzIxMDE4MTIwMDUwWjBEMQswCQYDVQQGEwJGSTEaMBgGA1UECgwRVGVs aWEgRmlubGFuZCBPeWoxGTAXBgNVBAMMEFRlbGlhIFJvb3QgQ0EgdjIwggIiMA0GCSqGSIb3DQEB AQUAA4ICDwAwggIKAoICAQCy0D8HvOJ70GuZ+OJ3aefOnaQDvIJtof6BZR9MJ6yOALoWe+swagDA s3RofrKvx9Vis3o/UMqMNkQkY9I26QyF9kN21UyhYHJn4igzpcsxuDoiIzS4fb1WIkCd6vR7A61o /LKBT5jQdOqN5X3NY8Oj9t6SwlgZ4Ja7xcSpPaV0lv6v+YmqvZUXVNh4RPEMdxWS4JhCp6TWqiCS zcGgs5ayOoRCjX3VleTW2+lixFizecWM0zUzg591oVInYTjxWT2OUOC9eTznbJb+XtkCZbSOXNAR NN9dv1KngQDDf5lFmRXVF8gKU+xj85l9zGkShsIX8AGev4S80VLLG5JmzqRT5aG/xNsJ1uaJVivI 43ze4/+J5TVuKOhsCyNRqSUF60j43bHK+mwIUe+3GGxEyibhc8aJBoHliqyw4inGuSSza0QR9KVD wkxD5XA2jLYzV3qVLoKg9FwQs2GD9gIFhi58LWzcA0ZuNZPVepUv3iDYW36UkARqulk9BAV1nTei Di4968GkUoP+0GvUZo7cxukSTh0qV6oQvHxegn2mpsnyLbn1Fyet0Q6JVCuV+sCtHZgUeDNChgqp c7X7dA23GzAZxFoOHCe32hjQ/4rIBbrxqhyiN7fmSKRGLJTqqHZiR4sQUwdIV2zikk22rgXL3MFK Xo+sPRlOwu1gdSvbwcpC1QIDAQABo4IBZTCCAWEwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwHQYDVR0OBBYEFHKs5DN5qkWH9v2sHZ7Wxy+G2CQ5MA4GA1UdDwEB/wQEAwIBBjA8BgNV HSAENTAzMDEGBFUdIAAwKTAnBggrBgEFBQcCARYbaHR0cHM6Ly9jcHMudHJ1c3QudGVsaWEuY29t MA8GA1UdEwEB/wQFMAMBAf8wRwYDVR0fBEAwPjA8oDqgOIY2aHR0cDovL2h0dHBjcmwudHJ1c3Qu dGVsaWEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMHcGCCsGAQUFBwEBBGswaTA+BggrBgEF BQcwAoYyaHR0cDovL2Nwcy50cnVzdC50ZWxpYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTANBgkqhkiG9w0BAQsFAAOC AgEAh6xHD6ksuWOG01+v7C1yTSH18k4/PGwMXRi4q8Hm7MgVm/SnQnh3mRCGJ80sBUb1w6PBUdpW Rjvb4KrC/2PXBmL8OdYQUn0TNA9S0Xk5voi6vUI/ROUXpIWcz5kx8QVCteFLyeLZYLzdjYOM5MWk 0qr0eSVPlT7SsuaB+LBLNoy3IJilTT0JK/Gtpm3/CYv+i/YgdbiC2tq8zLGLoOdzgsLVCOd3HT2W A65YGPekPZ+4Vw3kNVU7EkTseXTrwI/G/dDSSnlTgBCxMOTXsuEsZQtV8/rNFOF3MJY0rG+fNuPH skqK63E4ouoDD98IEEk/z2Qi/wRsw9zSCNdLxjWe3WDEmjTEl4/wWm5Oh1b7VIAGeIQdg3LRP0LU FOxR0lrXy6Q6hHeX256+8hSvrnYlKH8ss9tvuXWaVeFDD2pWOeqoGGMqmTO9y1xCeh5p3F0wqtqR tCi9YqaDlAsbKM5GNuFpiYy/6FRxmnVxxsHFeWemSBIwT6/IzOJxvJkWdpg7BkAhcOV71Vbegdms FxetLH0at8HQjoGu7R6VJspIsvNowmR/z6CW3WYrnDQhohY+c6uvHCRTY0imWED6b7AALIAOSw2f 0am1HoomxKgrDDBPkjnC415rL3ocx/0joQAUhSXjaXiVYro1J9n8uBINoWUEhxpbkxTnddLh11ze Z3Ywgga4MIIEoKADAgECAg8Bif1TULJPL1hJviqRpMMwDQYJKoZIhvcNAQELBQAwRDELMAkGA1UE BhMCRkkxGjAYBgNVBAoMEVRlbGlhIEZpbmxhbmQgT3lqMRkwFwYDVQQDDBBUZWxpYSBSb290IENB IHYyMB4XDTIzMDgxNjA3NDc0NVoXDTQzMTEyOTA3MjI0NVowSjELMAkGA1UEBhMCU0UxFDASBgNV BAoMC0VyaWNzc29uIEFCMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHY0MIIC IjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA5QfDmBIbgy7k2r1evUPvBvGxGWkvB1PS05oY xpONCBm3i2+2qxGp4hijk9tK4Q/gShpbVpp5Hb0ByD0d7sxZmXWAIKKDqeA7w4ibnx8sz7xsgA5d daVN5zb5xIUDkUKTKAz4+hldKzd83HGN1sTzpwtdmkScPmRrLy9u3xpHTU9YRvO0gWIuTFKNpcSW goxYOQYQCg4iY//JyzGkDbkvh/OhOUIKfh1DXJk4maTqnZ6cMljonZULXXEHiRhA3XDazzGN5DQU oYrV3MCSK7lnV8z87W3CmXaLogpbm+0O23595XmLK4s0iJ48AAbX4ti9z13eoe9vPe37WnxiaOxY 5x0lNv1/JQjOcDnaDdgUm6ByiAQRi2EExadI+wJ9skoUUoYD93s3h07snlH9T3e9XnW7m1hj2ACt SDcwHY0XeNXXkPPrbpWOx7gmWgXBqLHr7NwC79AuEZG9wT4y0KywANEZarxotOkY2z9AmkMmna+O qOFEmpP9ehbA8em+7+uDNUdLLlJAghra3IKGZxosW9GdA/b0xb41xiAat5P0R8/QlqyKYMvEWyIu tK9DnhoUehcyNguX8BHjs9o+pX+qu0R8j8ndyWmjdTurxd3v9J/+bGu25v+3oasV2/zMgo6l3Euf h2y6I3YMfqKtRO6APMur/aB+bsI1KmrDRTyVhu0CAwEAAaOCAZ8wggGbMB8GA1UdIwQYMBaAFHKs 5DN5qkWH9v2sHZ7Wxy+G2CQ5MB0GA1UdDgQWBBQZwf8QCfz9QN02sG7ZjW8/t+2cKzAOBgNVHQ8B Af8EBAMCAQYwLwYDVR0gBCgwJjAOBgwrBgEEAYIPAgMBARIwCQYHZ4EMAQUBATAJBgdngQwBBQMB MBIGA1UdEwEB/wQIMAYBAf8CAQAwLwYDVR0eAQH/BCUwI6AhMA6BDGVyaWNzc29uLmNvbTAPgQ0u ZXJpY3Nzb24uY29tMEEGA1UdHwQ6MDgwNqA0oDKGMGh0dHA6Ly9odHRwY3JsLnRydXN0LnRlbGlh LmNvbS90ZWxpYXJvb3RjYXYyLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwcQYI KwYBBQUHAQEEZTBjMDgGCCsGAQUFBzAChixodHRwOi8vY3BzLnRydXN0LnRlbGlhLmNvbS90ZWxp YXJvb3RjYXYyLmNlcjAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AudHJ1c3QudGVsaWEuY29tMA0G CSqGSIb3DQEBCwUAA4ICAQCKVbn47kw/ShE7cf7Hv9GnSSHJjDhMGhVwfWuuBuQcKz1tyyVbv226 n+/UwUcYBNTLTJUMsRy9uR5MjNaN3zVrKQVMTfTun+wzyTrE7mB5VCMxnrXXQCuOSfniJPwyQBrB RHCy+U7Nou5aISJbX32tBY4cWcmA0e9IRjXUXzjx9xBEgHDtuAx1SiPX051cJLGvl59/k0HiXMbh TpkjgGpim6T/x8iRFt9OjUsPzd8rjNPPE1slJ0Qlx15HXSQNZvKCjDoSe/1Bdaxp8ve79Ow5coFZ fiq0anNHCgr/VCnSE/v4404glJVDIcNFNYMIHAv65JHQ178F6zdt7Uz6nBaMBSeLpstUgosVey7V o3Ds97/RWrzPra8XHxS0PjOGNw62OAcs1xwxVqtM+Bga+ceD6E1bxBS4JCeUZVZlRo3K6UyPzDJY 83QpzN0MBm7eRUVLeHWHQwbfUcMMHWhAe8/3ggn/P4BO/NaLbMqXOfmxAWfJPnlOHhZAmJhg5pho o0QnSLfS0LviZouOGrMhOIZuHRMhZLMGlYYs0y17fAYs331HKu3jSUS0KjLsks26UIgSYLNpulZO dap63bTCp/dWGvHirK+y1vbpgYrnoKJePjC8nOL1AdpBQmSrIHHD72chMGGV6T/+hY+Tp3fRgDdp qwGoJlh9UmJMFjmGkWF92zGCAzIwggMuAgEBMF0wSjELMAkGA1UEBhMCU0UxFDASBgNVBAoMC0Vy aWNzc29uIEFCMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHY0Ag8Biyk6zECr ppIwOXd1O4wwDQYJYIZIAWUDBAIBBQCgggGmMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTI2MDExNjA5MTYyN1owLwYJKoZIhvcNAQkEMSIEILj4rwm3VgZZdfoOqDWH 5EXUGNc5GDQm5fhp5M+A2dYNMF0GCSqGSIb3DQEJDzFQME4wCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjALBglghkgBZQMEAQIwCwYJYIZIAWUDBAIBMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIw bAYJKwYBBAGCNxAEMV8wXTBKMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLRXJpY3Nzb24gQUIxJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjQCDwGLKTrMQKumkjA5d3U7jDBuBgsq hkiG9w0BCRACCzFfoF0wSjELMAkGA1UEBhMCU0UxFDASBgNVBAoMC0VyaWNzc29uIEFCMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHY0Ag8Biyk6zECrppIwOXd1O4wwDQYJKoZI hvcNAQEBBQAEggEAGx69G9B/6+VHIdjYwn8euEHFxwxExW9GPcIg0BqODS0gn0eDj/KC2mGLvGbx LQjIZDQ/Zf6/MeHHJuItHiEPgB2V/Gg1tjZpP/i4oZQTMX8TSVd45029o3SqahU3L/B31XyaNwMk rdalBVeNwrFtiMC1NxwnmHShny+m0596IOjvNrpGhpfQw5amd+TkVU6XTAjV6hXlokuScPdDa4/J DG6RJxC82Nk1k5AMKylWb+sdkgeODIT7gxM1k1871CQTdU/gdUieN13sp5e9Og/5ZEzfNcRfugc2 cQhjr/QMWKc10xFdmG7VgwT6Bu1k31Uk4y6QAuJ66OcileOM4duNigAAAAAAAA== ------=_NextPart_000_00FF_01DC86D1.2D4389C0-- --===============5461412873427450332== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KT1BTQVdHIG1h aWxpbmcgbGlzdCAtLSBvcHNhd2dAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFp bCB0byBvcHNhd2ctbGVhdmVAaWV0Zi5vcmcK --===============5461412873427450332==--