From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vps.slashdirt.org (vps.slashdirt.org [144.91.108.218]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 215043B29D for ; Thu, 17 Nov 2022 10:53:03 -0500 (EST) Received: from smtpclient.apple (tardis.herebedragons.eu [171.22.3.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by vps.slashdirt.org (Postfix) with ESMTPSA id BAC6E60140; Thu, 17 Nov 2022 16:53:01 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 vps.slashdirt.org BAC6E60140 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=slashdirt.org; s=mail; t=1668700381; bh=pyYPXHizoJBX7KfvP7G0Qy8/tGFZ959HdALO9VefLHo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=LIBV3BqLhlp9dplVeA3IuyynGNtT8K8MlWqGfDBbC/6GoyzKai+YrEAUXQcdNPJ1W tAnXZY3gjjwwcxXr++wHDtiU1AJx8Hzcn7abuU0wGTrSVE9YiLPqaY2/MclkEYhZqL ESEYLDKGbd2XDOwlB/resHZcIdZETUdY+lh0alcM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) From: Thibaut In-Reply-To: <94702DB0-7CD6-469D-8C13-B30831CAEB38@gmx.de> Date: Thu, 17 Nov 2022 16:53:00 +0100 Cc: openwrt-devel , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: 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> <94702DB0-7CD6-469D-8C13-B30831CAEB38@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.3696.120.41.1.1) 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:53:03 -0000 Hi Sebastian, > Le 17 nov. 2022 =C3=A0 16:19, Sebastian Moeller a = =C3=A9crit : >=20 > Hi Thibaut, [...] >>>> 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), >=20 > Well, all I can say about encapsulations and per-packet-overhead = is: it's complicated. I can see that now :) >> 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? >=20 > 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 And now I=E2=80=99m even more confused: why do we suggest an overhead of = 34/26 for VDSL or 22 for docsis cable then? I assume the respective = modems are connected via ethernet, aren=E2=80=99t they? Another confusing point in the current detailed doc (and possibly the = one that got me started): " =E2=80=A2 Link Layer Adaptation calculates the proper overheads = for WAN links such as DSL and ADSL. If you use any kind of DSL link, you = should review this section." This seems to imply LLA is only necessary for =C2=AB exotic =C2=BB links = such as ADSL/VDSL. This also brought me to the (na=C3=AFve) comment that it would be nice = if CAKE would account for local NIC L2 overhead internally (since that = info is readily available to it, is it not?), and one would only have to = configure the actual =C2=AB overhead =C2=BB of whatever is connected to = the local NIC. There would be less margin for error I believe. Then I saw this: "Please note that as of middle 2018 cake, and cake only, will try to = interpret any given overhead to be applied on top of IP packets, all = other qdiscs (and cake if configured with the =E2=80=9Craw=E2=80=9D = keyword) will add the specified overhead on top of the overhead the = kernel already accounted for. This seems confusing, because it is ;) so = if in doubt stick to cake." Well yes, it *is* very confusing :P > 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. >=20 > *) The IFG is not real bytes, but transmission silence for the time it = would take to transmit 12 octets. >=20 >>=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. >=20 > 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. >=20 >> Not to mention the kind of users who want to squeeze the maximum = performance out of their setup. >=20 > 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. Yes, I see it=E2=80=99s a bit of a headache :) >>> *) 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) :) >=20 > 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. OK but I also believe it=E2=80=99s important to clarify that the = overhead setting needs not be adjusted whether we shape the pppoe = interface or its underlying ethernet one: that certainly was = counter-intuitive for me. Thanks for bearing with my ignorance, T=