[Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Sebastian Moeller]

Hi Rich,


On Dec 18, 2013, at 04:06 , Rich Brown <richb.hanover at gmail.com> wrote:

> Hi Sebastian,
> 
>>> And while trying to make an intelligent guess, I wonder how to map none/tc_stab into DSL and/or ATM; if adsl is the same as DSL;
>> 
>> 	No ADLS is one out of a family of xDSLs (digital subscriber lines). As far as I know SDSL does not use ATM, VDSL1 might use ATM and all ADSL variants use ATM.
>> 
>>> and where ethernet fits into the scheme of things.
>> 
>> 	Ethernet is also a link layer, one that does typically not show quantization as ATM does, selecting the ethernet link layer allows to still specify an overhead, and that is somewhat useful for VDSL (since VDSL often still uses PPPoE).
> 
> ... and ...
> 
>>> - (I believe) Only two “protocols” (above) require “link layer adaptation": PPPoE (DSL/ADSL) and PPPoATM (PPP over ATM). All the others seem to be some variation on Ethernet. (Please correct me if I’m wrong.) 
>> 
>> 	Well for PPPoATM I agree, but PPPoE is also used with VDSL which uses PTM in stead of ATM and has no quantization issues, but still profits from setting the overhead correctly so needs the link layer adaptation as well. Now, as far as I know PPPoATM is quite rare so I have no idea of how to deal with the common case automagically.
> 
> So basically, if I understand what you’re saying, it’s a big mess. :-)

	At least as far as I understand it; there might be simple and elegant solution to this, I just do not see it...

> 
> Even though my desires conflict, I still hold out for the two goals of "working well enough for random people” and “providing a platform for research”. 
> 
> I hunger for the first, because we want people to be able to use CeroWrt right away and not be scared off. (Rich’s Rule of Trial Software: Each hurdle that you place in someone’s way reduces the potential audience by half. :-) I am hopeful that we can find default settings that are “good enough” for all link layers so that new people can see an improvement with CeroWrt. I am also mindful that the features will likely wind up in OpenWrt unchanged; it’s worth struggling a bit with the GUI so that we minimize the folklore and misinformation surrounding its use.
> 
> The tester in me also is rooting for the second goal. We need to be able to test and tweak the entire queueing system. Making some of it accessible via the GUI will make it easier to experiment, but of course, limits the kinds of changes that could be made. (The lua scripts, though, do give a lot of flexibility.)

	Well the biggest problem I see is that people on an ATM link really really need the link layer adaptation so that the shaper actually can work properly at all (otherwise they need to shape down a lot from the nominal link speed to reduce the probability of filling the modems buffers by underestimating the wire size/transfer time of packets). All other people would rather not do this as the 48 in 53 encapsulation reduces the rate to ~90% of the link speed and this is without thinking about the last cell padding. In short there is not one link layer setting that will be satisfactory for all users. (One could argue that to give the ATM users a good out of box experience the default should be link layer ADSL, and everyone else (vdsl2, cable, fiber) just sacrifices some bandwidth; compared to everyone being happy out of the box except the ADSL users…). I guess, this is something that the user will need to configure… (Also the overhead can not be really predicted so either we take the maximum possible, 44 bytes, or risk bad out-of-box experience for some users…)
	Automatic detection of the link layer as  implemented it takes a link time (several hours) during which the internet connection must not be loaded, so seems infeasible to run from the GUI for technically naive users; think "a modal box saying: please wait 3 hours until the link layer detection has finished". (The trick is to repeatedly measure the RTT at 3 different packet sizes, N, N + 24, N+ 48, so that two of these are guaranteed to have the same atm cell count, while the third is either once atm cell shorter or longer. Then statistically test for significance of differences and declare it ATM based if really two measurement sizes are significantly different from the third. The catch is that at the higher end of DSL say 16Mbit/s down (2097152 byte/s),  2.8Mbit/s up (367001.6)) the amount of RTT added by a single atm cell is quite small (around 0.15ms) compared to the RTT variance you typically get with say ping so it takes a lot of measurements to get the significance high...


> 
> On to more concrete ideas:
> 
> - From what you’ve said, I don’t have much hope for doing it automagically.

	I concur ...

> But maybe we can provide clues to help the customer do to the right thing.

	We can and should try. Since the whole issue is a mess any recommendations will not be terrible concise though.

> Perhaps the first dropdown could be “Link Layer Adjustments (used on DSL or ATM)” 

	Technically the ATM part is the relevant part, the ADSL name is only in there as too few people know about the actually carrier (and they should not need to, ATM on ADSL links should just be phased out and forgotten, but I digress)

> with options for “None/ADSL/SDSL/VDSL over PTM/VDSL over ATM/PPPoATM” and maybe others
> . CeroWrt could automatically set the proper link layer adaptations for each. \

	Would be nice, but people typically do not know the link layer their internet connection uses as ISPs do not mention this as far as I know. But as a first approximation we could say: ADSL users need to set the link layer, cable, fiber, vdsl2 users do not. But once people have too look up the relevant overhead it gets complicated no matter what...

> We could also include a link to the wiki for a flow chart for setting each of these cases, especially the questions they should ask their ISP.
> 
> - Would it be possible to keep from mentioning tc_stab in the GUI? 

	Well, I am going to hide the selection between tc_stab and htb_private behind and "advanced details" checkbox, sounds okay?

> 
> Thanks!
> 
> Rich
> 
> PS That was a nice discussion of the (wackiness of) ATM framing.