From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D24FA3B29D for ; Thu, 17 Nov 2022 10:19:19 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1668698358; bh=X/2HHnasHu/RnKyp+YfmDoFXB37ntAH3rinOkNeYDVw=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=gruqcNn4OsqSFpNemzCM/XugfuiNwr5Sy8pl9gfvlYSOpjaJe4PfEY2Zv3P2hmQFP o6A19VuYfiL7RbS70paf81wocuGusBMY66D7FEQBqSzg+jMBFU5WfeH1+njxaF2/0T bUe8kr9BAdW4B+uHPPBQP6DnV80RWa/oYyrE2wgsw0bjQ6xkYkJB0LJIS9RdleG+ZH H1QR2wqcGv4cTE41QErVjKrLssUJWcagrKKVTsvmvx98LW0VXu8GAhLS7ySGF63qjA JkVtxPe65hdcY86tU0jmlpP+QiL212ZRkryCdJJRSDXCtU+3kk4+MqT43H0YI7YJEn wRkR7+MlUf3Lw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MgvrB-1pRzgG3tr3-00hPov; Thu, 17 Nov 2022 16:19:17 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) From: Sebastian Moeller In-Reply-To: <3550010F-3EB3-4CF3-B107-367802DF39A1@slashdirt.org> Date: Thu, 17 Nov 2022 16:19:17 +0100 Cc: openwrt-devel , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: <94702DB0-7CD6-469D-8C13-B30831CAEB38@gmx.de> References: <386F2ED9-3D39-4A42-8982-742B5D4B417F@slashdirt.org> <4CF53FE3-D26A-4E32-8378-3B27BBB70AEF@slashdirt.org> <4D5AA477-1547-441F-900C-6DC70C824960@slashdirt.org> <3550010F-3EB3-4CF3-B107-367802DF39A1@slashdirt.org> To: Thibaut X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Provags-ID: V03:K1:U95BJqR41pcxXksZfBZIInkS6pJ74GyO0lJpKoHGmDKfNc+rWTO XMkmST0ZxC8jviWMUne5B55rwpdRJg7bHj94KJGMpBwIurWZ0Fs/XFbeAn3QjetdYPRmjSS 1I/h9zNURVxD09RHs/YLcOLhbkItONhPDIbQwsqq8FDXthYMqJDXbX6/mGKHrRQ8FzZrZAM 8Ekh16ROT0Q/T7X/gEMHA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:fZLcEGZYkzg=;DhqaCG7+h854e0AsI8Z8pSOKKDN oGunmywy+gyq9GmyM87vhsm5+e/O0/XL0H8b6UJaS2owkYmcfOzOhH8fjPOYURJ2n8dC28J6U benfJfSHUaV2T6HomLJhk9V+Oj86pZIp7er6Y+sif9hYwS0Rzvo0guRCapFjigCCM/LyyNVNj c9ff9FvBrKaJMxWcXV2BxNbwL/qY89SxdU/ChBRUP9x6KNW5ej0+D0iPy0i3E/uuq5n+icsUu E2gkVDj/++LBT/yawQfhwLbApVTjqziXkIdOaMn6ZQVus9btUm3DYM4QcPu6o+z0piNHPnNnS UNpC2lpyfUSOg1yz7b+8XbKobQNdt4n8OEYkhlFcPhKjqfukzaJ3adCE6LbiRKQhp0xuMQKCX Mz5kEydSIuehOIiu76JEOe39fOg8B+zTGPXDNhCYoKfO/SN2huCl2y1UxoMBPp7zbwgxH257U jDYPe45UttG8arvms+1vJM3QJPo0QaaTnPcIdNY8jHE7i7FJeBufGnfTDwDc9ULcI83smY9Vi E65CEKajT0uLzIFCgT7yOpcEFLcPehHtSBwgs7rgdH4fEOaDAyvKQflSMb/0sUZHa2HqMWb/o Joi+WYLF7DK5xSqKtjzBkKcmADo/VX64lYJxurYcsRaFGXqIzg0aIqDQoDc8Pqb9Kig506XYY INkwPYwxCNnMGQbcS6LDuf/0tF+2KQi3yH610upUnxruIva8uquLpPFOnRcIVSusUZZf7lrEa ORLeXtRpvLU5lXbQZlblqEYouHjqS113zl6KCdvOPgSS8yAq7tVFkvVQk6K1UAiHAJK2VxRz2 jLkVUXAcuXZhJh1YYfmpRQdXW+xxzxHhO3+Kb5klwypfalf0NNwW8jD1l9fXA59tKoDxRxFa7 cO8vc+6p1y+rdcDx5hRJPe3KjmEV+2WO2ODZHEcn+gcCFE71uKlJLWwKBKYUAjyQUX8JHF0+8 u3fM9qni49xB0wSasLgSFsS5dW8= Subject: Re: [Cake] Help untangling CAKE settings for FTTH X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2022 15:19:20 -0000 Hi Thibaut, > On Nov 17, 2022, at 16:00, Thibaut wrote: >=20 >=20 >=20 >> Le 17 nov. 2022 =C3=A0 15:42, Sebastian Moeller a = =C3=A9crit : >>=20 >> Hi Thibaut, >>=20 >>> On Nov 17, 2022, at 15:22, Thibaut wrote: >>>=20 >>> Hi Sebastian, >>>=20 >>>> Le 17 nov. 2022 =C3=A0 10:50, Sebastian Moeller a = =C3=A9crit : >>>>=20 >>>> Hi T. >>>>=20 >>>>=20 >>>> so taking your proposa under consideration I canged the section = that threw you off course to read: >>>>=20 >>>>=20 >>>> =E2=80=A2 Ethernet with Overhead: SQM can also account for the = overhead imposed by VDSL2 links - add 22 bytes of overhead (mpu 68). = Cable Modems (DOCSIS) set both up- and downstream overhead to 18 bytes = (6 bytes source MAC, 6 bytes destination MAC, 2 bytes ether-type, 4 = bytes FCS), to allow for a possible 4 byte VLAN tag it is recommended to = set the overhead to 18 + 4 =3D 22 (mpu 64). For FTTH the answer is less = clear cut, since different underlaying technologies have different = relevant per-packet-overheads; however underestimating the = per-packet-overhead is considerably worse for responsiveness than = (gently) overestimating it, so for FTTH set the overhead to 44 (mpu 84) = unless there is more detailed information about the true overhead on a = link available. >>>> =E2=80=A2 None: All shaping below the physical gross-rate of a = link requires correct per-packet overhead accounting to be precise, so = None is only useful if approximate shaping is sufficient, say if you = want to clamp a guest network to at best ~50% of the available capacity = or similar tasks, but even then configuring an approximate correct = per-packet-overhead is recommended (overhead 44 (mpu 84) is a decent = default to pick). >>>>=20 >>>>=20 >>>> I hope this is explicit enough. >>>=20 >>> Yes this looks a lot better, thank you. >>>=20 >>> Although I must confess that it certainly feels counter-intuitive = that for ethernet (and FTTH) we suggest a higher overhead than e.g. = VDSL2/cable (which themselves run off an ethernet interface). >>=20 >> That is simply because for (ADSL) DOCSIS VDSL2 we have a much = clear picture about what we need to account for. And AON can be = essentially using true ethernet encapsulation so we can expect an = unspecified "FTTH" class to encompass a broad set of different = encapsulations, if we want to recommend a single number that should also = cover AON (the PONs are much less clear*). Why do you assume that FTTH = necessarily would have a smaller per-packet-overhead than other link = technologies?=20 >=20 > I=E2=80=99m not (necessarily) making that assumption for FTTH = (although I would expect it to be the case, from my limited = understanding of FTTH technologies), Well, all I can say about encapsulations and per-packet-overhead = is: it's complicated. > I am however certainly making that assumption for plain ethernet, = which is included in the 44-byte documentation case. I think it=E2=80=99s = a reasonable one? Yes, the goal is to give one number that works everywhere so 44 = is what we recommend. As I said overestimating the overhead is benign, = underestimating it is not. True ethernet has an effective* = per-packet-overhead of: 7 Byte Preamble + 1 Byte start of frame delimiter (SFD) + 12 Byte inter = frame gap (IFG) + 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 = (src MAC) + 2 (ethertype) 7 + 1 + 12 + 4 + 6 + 6 + 2 =3D 38 bytes Now if a VLAN tag is added you end up with 38+4 =3D 42 so both pure = ethernet and ethernet+VLAN have a er-packet-overhead close to 44 bytes. *) The IFG is not real bytes, but transmission silence for the time it = would take to transmit 12 octets. >=20 >> Now, if you have reliable information for say GPON-overhead, by = all means add it (but to be useful this also should contain an easy = identifier for other users to figure out whether they use GPON in the = first place). >>=20 >> The bigger point however is IMHO, from the perspective of = minimizing bufferbloat/latency-under-load-increase using a slightly too = large per-packet-overhead is fully benign, while specifying to small an = overhead can easily result in measurable bufferbloat increase. So IMHO = it is fine to err on the side of too large when estimating the = per-packet-overhead. >=20 > OK. Although I would think people reading the detailed explanation are = looking for precise info and explanations, not one-stop-shop = approximations. Sure, but the problem is we can not give them that "precise = information" them, you , me would like to have, so we do the best we = can. > Not to mention the kind of users who want to squeeze the maximum = performance out of their setup. Just read the section where I explain how per-packet-overhead = and shaper-rate are not orthogonal variables to understand how = problematic the whoe thing is, add to it that ISPs often employ traffic = shapers with potentially independent overhead-assumptions making the = whole problem even harder. >=20 >> *) The core problem is that we have no straight forward way to = empirically deduce the effective per-packet-overhead over an arbitrary = network path, so if a link technology defines/documents the overhead = well and conclusively (like docsis) we are in luck, but if the details a = vague or leave many options to the ISP we have to make an educated = guess. >>=20 >>=20 >>> I would also like to see some info about ppp vs ethernet interface = in there (matching your previous email): unless you beat me to it I will = add it. >>=20 >> I will not beat you to it, because for users of cake it does not = matter >=20 > You said the exact opposite in your previous email (persistence of = statistics) :) I misunderstood your argument here and thought you wanted a = section explaining the issues with getting the overhead numbers for = pppoe** and ethernet interfaces set for HTB+fq_codel, sorry. If you want = to explain differences between cake on pppoe or on ethN go for it. **) ppp or pppoe somewhat matters, PPPoE has 6 Bytes of overhead on top = of PPP's 2 byte resulting in a total of=20 PPPoE: 2 Byte PPP + 6 Byte (PPP)oE =3D 8 Byte >=20 >> and we do recommend to use cake in the first place... heck even for = folks wanting to use HTB+fq_codel I would recommend to start with cake = and then look at the output of `tc -s qdisc` to figure out the overhead = that is already accounted for on an interface. >>=20 >>> I also think the =C2=AB details =C2=BB page needs to be reformatted = a bit, it=E2=80=99s very dense and relevant info is all over the place = and not very well organized. >>=20 >> Might well be true (the page evolved over time and might need a = full editorial pass), but it covers quite some territory and hence = always will be a bit unwieldy. >>=20 >>=20 >>> I=E2=80=99ll try to get around improving that. >>=20 >> Please try to keep all correct information around in the = document. >=20 > Sure. >=20 > Cheers Regards