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 <[email protected]> wrote: > >> why are the vdsl options suffixed with _ptm, but the atm options are not? > > Because the “vcmux” and “llc” suffixes are sufficient to imply ATM cell > framing. The operational word here is “imply”, in a user interface unlike poetry explicit beats implicit any day in my opinion. And whether we want or not tc’s command line arguments are cake’s 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’s should not be forced to guess or rely on intuition, at least as far as I can see it. But the missing “_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: “pppoe-vcmuc noatm” results in a different cake state than “noatm pppoe-vcmux” 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’s 48/53 encoding, but pppoe-ptm will NOT account for PTM’s 64/65 encoding… 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… (heck I believe this is too subtle for you ;) ) > >> is the currently selected set of keywords minimal and complete? > > 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. > > I haven’t 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… 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 “overhead NN” is not a solution, because with that argument you could get rid of the whole bunch (with the possible exemption of “conservative_atm” as that really is a nice gesture to offer novice users, that at least know they have an adsl link…). > 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 “bullying". 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… After all, as it looks I will be babysitting people in e.g. the openwrt forum that actually try to use cake. > > That, by the way, is *me* being blunt to the point of rudeness. Fine, the “gloves are off”, no issue from my side, even though I prefer strong arguments to strong words; to each his own, I guess. > >> why name something conservative that will for all peop;e not using an ATM >> link cost between 9 to 40% of goodput? > > The use-case for the “conservative” keyword is essentially: “I know what the > raw bitrate of the link is, but I have no sodding clue what overhead it has”. > The goal is to prevent the dumb buffers elsewhere from filling up and > undoing our good work. > > Yes, it will overcompensate, leading to reduced throughput. That’s > recognised and accepted as far as I’m 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) = 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) = 1382400 bps add the framing 1382400/0.9 = 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’t 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 “spoil" your beautiful system while adding no useful information to our users, some of which (on openwrt/lede) will only ever see the output of “tc qdisc add cake help” 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… ;) Best Regards Sebastian P.S.: Oh and by the way the comment in q_cake.c: /* Typical VDSL2 framing schemes */ /* NB: PTM includes HDLC’s 0x7D/7E expansion, adds extra 1/128 */ still is wrong for VDSL2’s data bearers, they do not use HDLC, and even VDSL1 uses byte mode so 1/128 is just an approximation… I believe I have pointed that out some months ago already. > > - Jonathan Morton > _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
