Date: Tue, 04 Nov 2025 07:48:10 +0100
From: Sebastian Moeller <moeller0@gmx.de>
To: tsvwg@ietf.org, Chris Box <chris.box.ietf@gmail.com>,
 "Mohit P. Tahiliani" <tahiliani@nitk.edu.in>
User-Agent: K-9 Mail for Android
In-Reply-To: 
 <CACJ6M14vcjDF4ScTAOeH9ocPxY9obQ73j_CSr-UXPB=GbuFxHQ@mail.gmail.com>
References: 
 <175613588142.385624.6850148653392553559@dt-datatracker-67876766b7-bkzgr>
 <FD1F6ABC-B0C7-4F22-ACF7-1475A5FB1AF5@gmx.de>
 <CAM4esxS8+2f-fPT98GKDTq3BgOrrcpV62x3uWEZQ8gxQHM_SeA@mail.gmail.com>
 <CACJ6M14vcjDF4ScTAOeH9ocPxY9obQ73j_CSr-UXPB=GbuFxHQ@mail.gmail.com>
Message-ID: <9342E9A6-E020-408F-9BDF-10CB892DBB3E@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:24r6LFjVFvw=;clbUjHGZa40agnuwku7e59gq+Zp
 05CKqjFpM/4g5VeAGqa0LYFLZBuGu7SwT4TRuvbfMcRAZoyn7DF2q27yOj8O+LLZU1KNNljyE
 yr9AxI/xyZIrCD9G5y7nxd+Rh3R4oNU7g8tsHyQ0c9jGUXbFhVOXf998+PK+JucGeiuoSemFj
 Fm2KAznKOrTwiSX+pGU9gT4NHX3namwDFTlUYCOLHWgG6aAjQfRknk52QPkDRyNqD/TQFZLpK
 VSHIiEVBBmaMnhKr6CBglkkCetZyDy8lX7hOUjj/5WBDuNZm0D8kurklIi/9v6Wxq4yquy2fr
 zb0Br/ozwbsGp5MD/axyDqle0jPewAFPbChIUoB6Y6R9n1G2x8LpuoSBn03NDtaN/NjxdlTAs
 YGhmxdg029sWSBeUuNkAwH6fLuJZxuwDvF+GdmGmquxw3Yj1ZHPLSPfoZnTokJixg5X7LQYvs
 RmSGDR/tKC8Efey663otktD4EjOudkJpQfWG+EaM+KKnIdx1F/8FLS1bj4eJ4We47NDTRIZ+b
 ALixwQtprCZsIcnfBCd3ofj5qnmISciuy7FDVI049/mEhuDFCxocdPO9TX1ZImJSC+SEEBigt
 ZU8acQK6mwYMAf7tVRRvXlzNP6WKiXH0zLwazGGHxhthp2MsyLaaEarJKRcWuejqxiw9KvY7S
 zKGd0+XMb7SMomj2KbAGFSkyn+a2CkejcCvLe2ZZGjfENJW8g5hukKG1xJL/qsv6WKTi7aQyh
 DSX62MymQxlmO3eMu7FJCX+iZ9IF8geN6InhwqgHVMQrqj0BBuNdgzkxUA/b2OE1gp726RKLk
 Nnp2wJZ03/THIsVscLU3GlqdkOLzxikckwpDuq/eBj9+jU29sb0A9u+1u4MIotA66kbFxgUA/
 bOo26wV8V64FWcy0zQzMOdSMdg+ENLkkETTp5/N1tS5XbzPY+IZ2oqc2USjgwvCD+29mJ4lYP
 cx//ZrYca33HS0S8x2ON+uOz9jVwQHhjAT/CKplN9YMvqI5Q2jeKHDU7WuaDulEiDUiUs8jze
 LFPaiRFmjtmIB3Y7qNOvK6DtFR+GmM97Tw1VNsBkEVI2uIPyLBZ6nu1hM2jTDj8CLEY29J6i0
 rPnoxKPKtRiuVzxwKtmZPg1AyVAvk5LQnNjhU4mmvPvVKfsimx8ltXomFqf7+iSAW2XvzrOCf
 iOwP43RfUa2StKKUY6r0yhaKo+elcy8wRSyWIqPyFBwAzHUDngPfbSYw6Sp8EjCLS7LRRkQVz
 bomZxL71dHfnnYHvWTBpflkuk7DX3+tVhFgyXjkILwX0r3BpvNG6Sv6HZCKhVhw+e9MgNXVVj
 OmR+C9SzVtCCGTxSFBdHQDhJGl6+ejItsXOPwNrLa2tW/BE1bsWtAQMGDHKZO2tXMG/itcL6V
 PferGF41SeV2jHokycH9Vv+/z4JRjy2+oL0q1KywAoDG897FRaQfuF/N14ogTDjoj7xwsRcaF
 B46J8aQZoPvMo0V5uyIsDknlmnphd186KgjcS7eU2iLaB3RF/PRhIuZ53hwNHW9KpUY8a0T/O
 E6tzwZrc9LJQDsp5GyyfW4mYTWAk5AKzXtraF2mU2UlAoYvi2+HmXT3eqlTB6tJ1+6PpUUNdd
 i+OjTZUeWPrBfP7uSodTD2ac9zq3o2lLMd4+g1ZUEyurWrT94UrFz27BvKMoe5DHHZY9aV6Qe
 sEW8A060pER49JBn/90cKFUyYWpT5kkF/IflH60FQnXuf0S4uRQVtE03UZQxdQow3WyN+wXU2
 Zc3GM42OEJzh3dwKFkzBh9gwcjj9H/6rAR25LV3V1/sHuuGEAQu7Ah3JyHgqinNcw/L2KVmcQ
 mVuxhFcgMsfuOdoa+wx+v8CDcoMzCeSxCwc1V2nMVd1r0qQD7R8HLd+FrPITGKutkOYrhFbo9
 zLYtnJJF+ZZiyi8Ck+WgKJBY8ZOODyZ9Ml5InzWyKXumOF8Uk3kkOqt1xvll62X5je/ciD/z9
 E4lm++/Y77wGQHBAMT3qxfKtv4atnpU5y/mvjJJUrrbjcN6ClyH9/W/S6nkvEAIKz+jfFY56g
 xNnulUizoucvVe4+v/PcJvPPg/ZtNYRX0kcVBtOzCWHDsI/qvHhopK6CQd1kbF/TV+g4axdAm
 IDbK3KePwWW/mUjjVGTPGJAzm53s3zWcotlcrNCpVLY4X/oYjUPtbc1Lt3EfrQz0CIvZLjPSp
 2NsON7baGbjLioVJCmVwrcIFhMIFJGLry4NyC1RHR811MZn5Q+WLxNmRi1bJTVOwCTlk16W0u
 f3Xy19GepffZyzSQA/ZNEeYyfzLrNySTnj0T/Ufart0lNkaccjDdeh7tTk3BX2jvuXX6w80PC
 jI0rkMsuSs6Z2xjf0S3bS02D/7/kQsJgH0hd/K/mw2qgdjCu4t3ucZOCAJVyUr8Vfcci5qoAv
 NWtsElyXrMg4m51wu92O91ObLFF2jXwPPeqOp++GuLj1a9L1bilwXEu+s8L23Kz8GtLxbmaux
 73l6V/MeQ7jbFvDf4LQMCyA7c2bMiJYAV186veBAmBxYu124V6TDpVqnpZfD7VQ5ncsKgkNci
 iYdompRREjtSMbaBCYK2JWDF4R28ZrilW2twKNewgJg0YPWHGG7WExeVM1SbL05h2mQ4/TDZL
 g2ufB2nf86Y+Q/PeLY1FNXdp96nFh6lsHTWU3cVvhL4YVEmnY0lpbzDihlBGgFSHw8mOdQ2ZT
 nO41pgxg9n/UfHaOoop4wgyWrLPqQggS/WJ32YkmNI1l6vl4Q8RDdUer9ar1NWdK1YPz6UDbE
 NmnjRMrTPbEAPzZC8YF+aDT/BWBKzTcqejl+0fvKhtOyb6W4EtDNPzfxdZcItA2JMpFMEWYZm
 s9BpubQ76qO8asctiiIXdcH04u8LF1faEIbWHWeG8nwrhq7ZhIhZKbLV6OvMDtE7YFKKGybQ3
 5To6K0cYAuSIsz7zXAGwgzDtOH7Sgwiu2H5hsx60K3iy1rMrfVga9KAioZtGxsfEb3/LLZ7bA
 6VvU+KnB2MIXuFhqe2DQqisP3U13uWFlMBcjgEn9fzFRQ0QtUdcRk2Zbu/r+0f6tLoWRnzQpH
 ytYZi4/8lIN5LPdBjq2hhqfp8kHcq9JoVPZnHyCJNsUnj4ppwNetptmYWv4HedmFGLTnN+Ba7
 7/68gzDRbAY23cYoZb8qIRmYZE4bJgfOdk4qySVmF+fKzD4Qge/bRL8tSnecLP3lidEMWlVVg
 xR5ilc5GFnPT1fDWW3t2dfRNg3nQz2P1xPNlWvQQiBRDvHgQ+QIggvLXXccPptgqrtS9pfKiO
 F7OQxZdFdJXITtIPrYyXcJxe5B6LUq6BJ0GD3dKzBRXwBl5FMdXcJcO5oUPbrivdDVJ5L3rwJ
 Ts96Et/usthUH/YNqolREN6wi1CkLMYhZgUCOu4jbb5GAU/pLRVT/JXEYn9dntMXtpRo/oqXf
 TxvShjnP1SGwItNyRd8m23ANdkSQyS8R+lNbXMjtkxrrufP7glidIyQFL2cjfcrwmxSJvtHX/
 uDTo8gPNRAHM3farquL7EyUY0ju63UAqtIh1lNj3g5waCRUnkS0alBr5JHMViGmsiv/HHfieh
 9bAjYdBcivr1h4viPvL1gXpfpGMUG/shNYCPTZcPglvDY6JUvFrn9Nyu198k7WSdhztTNNljZ
 Jx61EyKAadFrXIvA27urbvL61/I2ZY9/Z/HiZcsdDpWDrMuBtLLFN6fzNRf2bml0OANdVwLc2
 qA3vVfkbTQnvsgiyI9LgcfvixeSH+q7XH6+7uj6QwP81XhUh7yV3L9Xbj0YIvDG5R/ExE91wY
 pCBfdi5aE1Bg6lGN4R70u8EBPpKT7KlVUvHaqN9FVf36sYNRWxSKMxmX3+RvaUDNq2ZlgO/lI
 +1aUubYGG+nY9Jw/nUExTdl0W+vjMvt4k0FHIOCYqJ+oK+7AcCpVRdY4pYkFjS9yYdkoqVEsw
 O8XT/2ocXbRk0d2P3qxtSSeyFZJuExLPKmDbm5vPD0pVmiHxPpo4B/ojL/4B3NlqEFo/MT51+
 QpgueXLqOwO38Dx5xRLTRzVK5wziOJcXmIgGzn6e+EEP288kaMSirLep5oQzAoprp1JhGP26x
 mEC+JsF9NFKHs1EC7RQgCZ2qU1zaD9KPh05MmdfQjhZpoO6Yn/lz0H8dAD1k5NILgKNomUgKg
 VUJWuvYstuJKKDHCYYZdf6cc76MdCxgqvCNL44i7FHJ9RvW40MYula569jyNqlL+ZgYJUTTsP
 B9TfCusuxxU4ZdBy1M+aQSrsVGNLS0f0Gb3UBJwRtXksW2rUSt5t130b41Hp1xFeocED+BAPV
 swZshGal1uGXldQcpCT+rkngYVOeq3RI2UXwmellNmu6bEOcBCVeueoZmYgB3r/GKsa5ZULfi
 id7LykUDxr3O0I3Ig/9poo7qHHDE9VGUT1YEM8DiGaWZd2vUoHSjB5Ba04Lj9NOLvFmHdvZOu
 vouN1tVq8BPlgBR0/aLTitYTb4fMqUDELKECZwSY3TD5/0HWQDE6rhPsb/+tt402D2BOJhwVB
 8kldPiEwQEmxglc8V4OdA9rYM9p+D62ZvGoaEQ4K7VKsC61o+yIAaEPy2ykYa63XtU/JJR1PD
 d770Aff3ckJdhz4vreVVpk4DCbnOLFVH5YNpuQtHn8GQM3YOknpaCsu04iDY360HZ9mHF8T2F
 tTzzKVGV8a7H/kCaqwO9G/1jc1gJT1XYtSjp7kTuxdENJNX8pDVT4S8xE+XY+KypCgwwFtvHX
 zC/MWK8S5OruAtyZ1I1KSKC8Q9lAyNIaFPZ5QhlfiumkUqjSKLMarQzw19MCNQK9MaIO1z5Vt
 1qsfvgzkvQcU3T14FRHen+hF0qhHWwp2TsJC7BxyCj1C/5XYrY+VC5HYLR5vJ9XVQN237o+FC
 ZHnzGTE/xoeNgsYnTW1UVvlrkmqWNPTPq/XPOIg4NIIbElrwWx8Balr9Acu1NIJ/zmwrWkZVY
 xo3+xVjiDfzR/bPHK0RF/pZitK5pjuZOxCX8aFYWRihRB220nHV98E41+j/JIk5mMRd0NX7iA
 vA8f9ZVS7mGpH7KF0ytJtXh0LDGFHGeBwnJY69Cm4MTS5AHhsvU9MN/IQpHeOJR2MD3O6Thbs
 1vdDw==
Message-ID-Hash: RIZLG5ROFVF6OWSY7L6OMRAZZQI45UR6
Precedence: list
Subject: =?utf-8?q?=5Btsvwg=5D_Re=3A_Thoughts_on_FQ-PIE?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tsvwg/q5Fi-VDusfjbgb0Qud5CKqdnhrk>

Hi Chris,

See below [SM]=2E

On 4 November 2025 02:22:56 CET, Chris Box <chris=2Ebox=2Eietf@gmail=2Ecom=
> wrote:
>On Mon, 3 Nov 2025 at 15:35, Martin Duke <martin=2Eh=2Eduke@gmail=2Ecom> =
wrote:
>
>> belatedly, this draft is adopted=2E Mohit, please submit an -ietf- vers=
ion
>> of the draft as soon as possible=2E
>>
>
>Hi everyone=2E I wasn't following this list so missed the adoption call, =
but
>for the record I fully support adoption=2E We should definitely describe =
this
>form of modern AQM so the wider world is aware=2E
>
>I'd like to share my thoughts on how to evolve the document=2E
>
>Section 4
>I would prefer that RFC8033 (PIE) did not say the latency target "SHOULD =
be
>15ms",

[SM] Fully agree, especially since rfc8033 lacks any justification/rationa=
le why, but I note the WG dropped the ball on that years ago and we are not=
 talking rfc8033-bis here=2E I do note that these 15 ms seem to be aligned =
with what cable labs used for the PIE component for DOCSIS, but that still =
does not answer why=2E

> as the optimum queue size depends very much on the variability of
>the bottleneck bandwidth=2E Constant bandwidth can handle a shorter stand=
ing
>queue=2E=20
>Wireless links often require a longer queue unless they are to
>sacrifice a lot of throughput=2E=20

Well, for WiFi IMHP the state of the art is to put an fq scheduler and AQM=
 into the wifi stack where more information about imjediate rate can be gle=
aned=2E But that is orthogonal to this ID's goal=2E

>So for this draft I'd prefer that we didn't
>reinforce the problem=2E Instead of "(recommended as 15ms in RFC8033)" we
>could say "(such as the 15ms default in RFC8033)"=2E


[SM] Mmmh, if 8033 is faulty, we should fix this at the source as well, no=
=2E=20


>
>Section 4=2E1 Enqueue
>This says "*It is important to note that the timestamping approach provid=
es
>a "per-packet queue delay," while the drop probability is calculated
>periodically (every 15 ms, as specified in [RFC8033])=2E Therefore, the
>FQ-PIE algorithm MAY use the queue delay value from the most recently
>dequeued packet when calculating the drop probability=2E*"
>This feels like a big choice being offered to the implementer=2E Either w=
e
>change the drop probability every packet, or we change it every 15ms=2E=
=20


[SM] I have not looked into the imoolementation, but I read this as, at th=
e time we re-evaluate the drop probability (so every 15ms) we might use the=
 most recent sojourn time as input or the total queue size / egress rate=2E


>As
>all three current implementations take the per-packet approach, should we
>instead make this the default in the document? Are there some circumstanc=
es
>in which every 15ms is better?=20


[SM] IIRC pie really needs the drop probability to stay constantish for so=
me time to achieve some modicum of fairness, but that indeed might not matt=
er for fq-pie=2E


>If yes, let's describe that=2E If not, get rid
>of it entirely=2E
>
>"*FQ-PIE does not adopt this approach for the reasons explained below=2E*=
"
>I think the document would be easier to read if we move the reasons
>paragraph to an appendix=2E


[SM] Rrespectfully disagree, the ID is not very long, so what is gained fr=
om moving this out of line?


>
>Section 4=2E3 ECN Support
>As L4S was published as RFC9330 nearly three years ago, any mention of EC=
N
>in this document shouldn't ignore its presence=2E These days ECT(1) does =
not
>generally imply classic 3168 marking=2E


[SM] Does it? Like in real world measurements? I note that to this day nei=
ther tcp prague nor the dualqueue AQM are in upstream Linux=2E=2E=2E and L4=
S is just another experiment, not a standard=2E=2E=2E (in fairness so are m=
ost AQM rfcs)=2E


>
>RFC9330 section 4=2E2b actually mentions FQ-PIE!


[SM] Does it? Seems more of a theoretical shout out, given that fq-pie doe=
s not implement special treatment for ECT(1)=2E



>"*Per-Flow Queues and AQMs: A scheduler with per-flow queues, such as
>FQ-CoDel or FQ-PIE, can be used for L4S=2E For instance, within each queu=
e of
>an FQ-CoDel system, as well as a CoDel AQM, there is typically also the
>option=20


[SM] Engineering by wishful thinking=2E=2E=2E unless somebody implements s=
uch a conditional treatment this option does not exist for the user=2E


>of ECN marking at an immediate (unsmoothed) shallow threshold to
>support use in data centres (see Section 5=2E2=2E7 of the FQ-CoDel spec
>[RFC8290])=2E In Linux, this has been modified so that the shallow thresh=
old
>can be solely applied to ECT(1) packets [FQ_CoDel_Thresh]=2E=20


[SM] Not false, but misleading, in current Linux that treatment can be app=
lied to any (masked) value of the old TOS/TCLASS bitfield=2E=2E=2E


>Then, if there
>is a flow of Not-ECT or ECT(0) packets in the per-flow queue, the Classic
>AQM (e=2Eg=2E, CoDel) is applied; whereas, if there is a flow of ECT(1) p=
ackets
>in the queue, the shallower (typically sub-millisecond) threshold is


[SM] Unsure where that sub-millisecond claim is comming from=2E=2E=2E and =
whether that has been actually tested over the internet (this is a recurrin=
g figure in the L4S rfcs, that claims are made but not substantiated, quite=
 puzzling given that these drafts are quite long)=2E


>applied=2E In addition, ECT(0) and Not-ECT packets could potentially be
>classified into a separate flow queue from ECT(1) and CE packets to avoid
>them mixing if they share a common flow identifier (e=2Eg=2E, in a VPN)=
=2E*"


[SM] Yeah, this lacks a discussion of the effects of the to be expected pa=
cket reordering on the VPN performance and seems, again, untested hypothesi=
s=2E


>
>I think we should refer to the above, and add relevant commentary=2E I'm
>happy to write a PR to do this=2E=20


[SM] Why? Unless these theories and ideas are substantiated first, I do no=
t think we should treat them as more than vague proposals of what might be =
fresearched,


>We also have the interesting design choice
>about having separate FQs for ECT(1)=2E The aforementioned VPNs are one
>reason to do this=2E The other (possibly more common) reason is for hash
>collisions=2E


[SM] The more flows you have the likelier are hash collisions, so potentia=
lly doubling all flows with mixed ECT is IMHO not guaranteed to be an advan=
tage=2E=2E=2E heck I question whether the idea of mixed markings inside a s=
ingle flow is not too cute for its own sake, until somebody presents actual=
 empirical evidence that this solves real issues=2E
(A VPN should not leak internal state like whether a given packet uses ECT=
1 or 0 and arguably not even where the  real packet boundaries are)=2E


>
>Section 5 Experiments
>
>If we're going to list suggestions for experimentation, we could add:
>* Assessment of performance differences of handling mixed L4S/Classic
>traffic through FQ-PIE vs DualPI2=2E


[SM] Aling which performance axis? And how to test this given, that upstre=
am Linux still has neither tcp prague nor dualqueue if I understand correct=
ly, nor accurate ECN=2E=2E=2E


>* Assessment of performance differences of FQ-PIE vs FQ-Codel, using and
>extending the hackathon work=2E
>
>Interested to hear working group thoughts on the above ideas=2E

>
>Chris

--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E