From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E46C33B25E for ; Fri, 10 Jun 2016 04:19:47 -0400 (EDT) Received: from [172.17.3.79] ([134.76.241.253]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LtIZH-1bZElP0gcF-012njl; Fri, 10 Jun 2016 10:19:44 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <74C47155-52F4-4F20-9C55-BFC0AD817555@gmail.com> Date: Fri, 10 Jun 2016 10:19:43 +0200 Cc: Kevin Darbyshire-Bryant , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <1795A564-7211-4224-BD1C-733DC0C2828B@gmx.de> References: <7409a52d-8c81-25f0-e070-c7638fdf9d83@gmail.com> <5759E14D.1050806@darbyshire-bryant.me.uk> <65184CD2-7205-4D93-9AD3-20F68C461E0E@gmx.de> <74C47155-52F4-4F20-9C55-BFC0AD817555@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:1uUMOlWYJ166M3GMFSmFMFGgEihsIahzQG10DE83VWyZNxzpabD 5OO38OPYNtfhpefWEoJP1Mv7h5xeOZxuqgjy5PPaBxXRWXwP3NwZj6MwolZR2UU8yuOnR7a K1zQ2+ctuib7P7fEDvWpiursak9Ku5Hrn6KJphZ74p+JpmkxA7IwlE053kf5IGC/l7Fubmr NE3bzqlbSWRtf0FYHXGpw== X-UI-Out-Filterresults: notjunk:1;V01:K0:mccVOz3rhgY=:1/6RVFiqEP52hSDv8SGhpW BSvg2q2W7V619Ls7sJQCRiZ7WRfESGcW/BcHrSvann4d2EIzs4VhQeUGZ1aSrcYnd0zqNWzws /qXaDuRJlEG686KXXX+04WonHupPSNl1TXRtyoKBCY0998ULjBSAAZUB0CYu/igUp4Lkn0ANU jie/vpHaXFeHBH0BI/8X2IdPcmrgwhtPsD2KnmL2yv+OtaWueTU+eb/gO9Y5Jbbd3i9E1DMi5 yxUdFc/eG7skPNDlqqcNgrkopwabj33enBpB/Wry9RQa/mYn6Znkgr8K8smE3bTjRrfPfE5qS geV4Kn312YBa5xSkzgH1Uxal9aP0hWSgmB79ItLmsUDGF69NDkqTTerm3Hb28PZKUeYCBHYbu dpxBnh/D14K47IZPsuT7r/rZGohKzwk2PB02K9gKpt1+42EG3ZROBUcLQBVUkHvBIiYiZGZir Hra9Jd+kG2lsH1mhLUXtwEqcATersTbS4+gDyiJ4ohrerBy1CaqNivUKMhXkKNwABoiwsK1OK uGRZXWCDeAK2NaPQpOUzj/UIxJNZzM9yTrxRyfnlWpin5d+ReI5TjM7N2f7qGPR9ybOvBVNbN gGJdjO2yDgkNNwllANb2HDIgHqKhT8Yyz97WO2bTN2qE3qqN9B2l77UvBOppVcmBM7/4lbed0 6nY0+94eR6hStwAGDkWPwJi3EvpQjBhvXJxnc1w79oqKmWjcQfouUF8dBnzvRo6vjAsoyR/1k 8WzJZ+NbXR5L6m3FqSJ6jXY3B+Q3qMv16Nb6Mxuuo1jANHlDjnPhulBX0JGyQVPAGWVlBRSB9 q0FmRMP Subject: Re: [Cake] New to cake. Some questions 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: Fri, 10 Jun 2016 08:19:48 -0000 Hi Jonathan, I assume you will the other points I proposed for discussion also in = dedicated emails, correct? > On Jun 10, 2016, at 01:27 , Jonathan Morton = wrote: >=20 >> why are the vdsl options suffixed with _ptm, but the atm options are = not? >=20 > Because the =E2=80=9Cvcmux=E2=80=9D and =E2=80=9Cllc=E2=80=9D suffixes = are sufficient to imply ATM cell framing. The operational word here is =E2=80=9Cimply=E2=80=9D, in a user = interface unlike poetry explicit beats implicit any day in my opinion. = And whether we want or not tc=E2=80=99s command line arguments are = cake=E2=80=99s user interface. We are talking about exposing this to = people who have done probably next to zero research on the matter. I = would propose to you that you poll actual novice users whether they = easily recognize that vcmux and llc should imply ATM-based carriers = instead of repesating this like a mantra to me. If you follow the = wikipedia entry for llc (something an interested novice might actually = do) you end up with https://en.wikipedia.org/wiki/Logical_link_control = which states a number of different systems that can use LLC, same for = SNAP with no mentioning of ATM exclusively, only the wikipedia page for = vcmux has strong indicators for ATM. But honestly in user interface = design user=E2=80=99s should not be forced to guess or rely on = intuition, at least as far as I can see it. But the missing =E2=80=9C_ATM" suffix is especially annoying as = these compound keywords do not only set a specific overhead value, but = also set the atm variable to one. So I repeat something most users will = find puzzling: =E2=80=9Cpppoe-vcmuc noatm=E2=80=9D results in a different cake state = than =E2=80=9Cnoatm pppoe-vcmux=E2=80=9D that at least requires an = explanation in on-line help and man-page. My beef here is that your = compounds comingle two different things, the atm cell accounting and the = pure overheads without reflecting this in the keyword names. Speaking of = inconsistencies, pppoe-vcmux will silently account for ATM=E2=80=99s = 48/53 encoding, but pppoe-ptm will NOT account for PTM=E2=80=99s 64/65 = encoding=E2=80=A6 I am not sure what the best solution is for that, but = at least I want to point out that this is too subtle for naive users=E2=80= =A6 (heck I believe this is too subtle for you ;) ) >=20 >> is the currently selected set of keywords minimal and complete? >=20 > I did some careful research back when I added that feature, including = taking some suggestions from you, I want reject responsibility for the current inconsistency, but = I am thankful that you added the numeric overhead option/keyword. > and according to that: yes, it is correct and complete, and every = keyword is related to a real protocol. Though some are not widely used = in practice, they *are* widely supported in ubiquitous consumer-grade = equipment. >=20 > I haven=E2=80=99t seen any evidence to the contrary; if you have any, That just shows that your research can be improved upon ;) . At = least in my eyes, annoy Sebastian enough to report more real-world = encapsulation examples does NOT count as original research=E2=80=A6 But here you go: Deutsche Telekom, DTAG for short, uses PPPoE = encapsulation on its FTTH-GPON links, so at least pure pppoe seems to be = missing from the set of keywords. And that in a nut shell is a problem with only giving compound = keywords, they do not easily allow users to assemble their own known = encapsulation from atomic base elements, so you should make sure your = set covers all bases. Saying there is always =E2=80=9Coverhead NN=E2=80=9D= is not a solution, because with that argument you could get rid of the = whole bunch (with the possible exemption of =E2=80=9Cconservative_atm=E2=80= =9D as that really is a nice gesture to offer novice users, that at = least know they have an adsl link=E2=80=A6). > please show it, if not, PLEASE SHUT UP about it. To me this does not sound like you are honestly discussion the = design of the keywords with me, but that you are deep in the trenches = and are not willing to change anything at all. But as I happen to know a = thing or two about this specific topic I will not let you end the = discussion by essentially =E2=80=9Cbullying". Eviscerate my arguments = dissect my logic, fine, but expect me to shut up just because you repeat = your same incomplete/inconsistent arguments over and over again? That = will just result in my repeating my questions/challenges over and over = again=E2=80=A6 After all, as it looks I will be babysitting people in = e.g. the openwrt forum that actually try to use cake. >=20 > That, by the way, is *me* being blunt to the point of rudeness. Fine, the =E2=80=9Cgloves are off=E2=80=9D, no issue from my = side, even though I prefer strong arguments to strong words; to each his = own, I guess. >=20 >> why name something conservative that will for all peop;e not using an = ATM link cost between 9 to 40% of goodput? >=20 > The use-case for the =E2=80=9Cconservative=E2=80=9D keyword is = essentially: =E2=80=9CI know what the raw bitrate of the link is, but I = have no sodding clue what overhead it has=E2=80=9D. The goal is to = prevent the dumb buffers elsewhere from filling up and undoing our good = work. >=20 > Yes, it will overcompensate, leading to reduced throughput. That=E2=80=99= s recognised and accepted as far as I=E2=80=99m concerned; the worst = corner cases are with very small packets, which frankly matter less. Now this is a good example why I think you stopped discussing = with me long ago and simply automatically defend past decisions, there = is a typical use case that creates a meaningful number of small packets, = the ACK traffic of large downloads. Depending on the acking strategy we = might see one ACK per downloaded packet, at a 16/1 VDSL link with = conservative we get 16Mbps: 16000000bps * 0.9(atm 48/53 encapsulation = factor) / (1500*8) =3D 1200 packets per second On the uplink we see the = need for 1200packets per second * 3*48*8 (assuming one ACK requires 3 = cells say due to TCP timestamps) =3D 1382400 bps add the framing = 1382400/0.9 =3D 1536000 so we would need more than the 1000000 we have = and hence the download will suffer due to ACK clocking. Now you say = nobody still uses one ACK per packet, but the fact remains that the = upload link will not be used efficiently as there will be lot of dead = time when the shaper thinks overhead is transported. Really, tell me why = I am wrong and you are right. > If you don=E2=80=99t want overcompensation, figure out what the real = overhead is and set that. It does not work that way, words have meaning you know. If you = name a thing conservative and recommend to use it as a default, as you = have done in the past, the onus is on you to make sure it does not do = (too much) harm. I really wonder why you believe even the even simple = act of renaming conservative to conservative_atm or conservative_adsl = will =E2=80=9Cspoil" your beautiful system while adding no useful = information to our users, some of which (on openwrt/lede) will only ever = see the output of =E2=80=9Ctc qdisc add cake help=E2=80=9D and no = man-page (not that there is a man page yet describing all of your = rationale and reasoning). The recent discussion of the overhead topic leave me believing = that the Dunning Kruger paper has some merits, it is up to the peanut = gallery to decide which of us is deeper in that trap=E2=80=A6 ;) Best Regards Sebastian P.S.: Oh and by the way the comment in q_cake.c: =20 /* Typical VDSL2 framing schemes */ /* NB: PTM includes HDLC=E2=80=99s 0x7D/7E expansion, = adds extra 1/128 */ still is wrong for VDSL2=E2=80=99s data bearers, they do not use HDLC, = and even VDSL1 uses byte mode so 1/128 is just an approximation=E2=80=A6 = I believe I have pointed that out some months ago already. >=20 > - Jonathan Morton >=20