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

Sebastian Moeller moeller0 at gmx.de
Tue Dec 17 04:31:33 EST 2013


Hi Rich,

thanks for your time and input.


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

> Sebastian, List,
> 
>> 	That sounds quite promising. I would be delighted, if stability permits, if you could test the current AQM implementation and send me your feedback and or open questions. It seems I have been looking at the link layer issue for so long that I do not realize which information is required so please let me know if parts are to terse or too verbose.
> 
> Thanks for making these changes. I was able to check the appearance (but not the performance) of the new GUI. My thoughts/comments/questions inserted between the screen shots:
> 
> 
> 
> The Basic Settings tab looks good. It’s all stuff I understand. I might like a More Info: link that tells me what the parameters are, and how I should set them. This is especially important because there’s a trick you need to know - set them to 85-90% of the link’s actual bandwidth. 
> 
> The introductory text could also read, “With AQM you can enable traffic shaping and prioritisation on a *single* network interface, your uplink to the Internet. Once you set the download and upload speeds (below), most people can leave the other options set to their defaults.” (at least, if that’s true…)
> 
> 
> 
> It looks a little funny with just the bare un-checked box. But I’m not horrified: checking the box shows the screen below, which is certainly clear enough.
	
	Okay, I think I will expose the disc and script selection unconditionally and only put the ECN under the advanced configuration checkbox.

> 
> 
> 
> - I like how fq_codel is labeled “default”. Since the other two controls are labeled with “default, should we do the same with the queue setup script (“simples.qos (default)”)?

	I will have a look, de to the implementation that is not as easy as one would like (the GUI displays all scripts it finds in /usr/lib/aqm, which makes adding new scripts a breeze but puts some restrictions on what is displayed in the GUI)

> 
> - Do we include pfifo anymore? (just to see how bad things could be?)

	Dave?

> 
> - Should we tell which version of pie has been included? (I’ve heard the names piev3 and piev4)

	Since we will not have concurrent PIEversions that have the same name I vote for leaving the version information out of the GUI, otherwise we have to keep updating the GUI...

> 
> - In the Basic tab, we talk about download/upload. In the ECN settings, we talk about inbound/outbound. Should we choose one pair of terms for consistency (perhaps, “ECN on downloaded/uploaded packets”?)

	Good point. I will harmonize the nomenclature

> 
> 
> 
> This tab forces us to confront all the sticky questions. The first question immediately makes me wonder, “Do I have DSL or ATM?

	The ida was that unless you have DSL or ATM you probably do not care. In most cases DSL means ATM carrier (and it is only the last that is relevant, but also users typically do not have this information, so asking for adel is sort of a proxy)

> Or both? What’s a ‘tc_stab'? How do I know?”

	Yeah, I guess td-stab needs a better name… "Perform link layer adjustments: Yes / No"

> 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).

>  
> 
> It would be cool to set everything here automagically.

	Yes it would, and no I do not see this coming, as only the ISP has all the required information readily available, end-users typically do not. Trying to figure it out empirically takes too long, especially at higher link speeds.

> Nonetheless, this is still a research project, and we probably don’t know enough to do that. Consequently, we should strive for good defaults that people can override while making experiments or if the defaults are wrong. I don’t know any answers here, or even where I’m going with this, but I’ll observe the following:
> 
> - (I believe) The Link Layer Adaptations help the router squeeze out the maximum performance accounting for peculiar link's transmission/framing method. If this stuff isn't set optimally, things will still work, at a (small?) loss of performance.

	Okay, bear with me here; the telco's created ATM as a carrier for digital voice data, they wanted small packets to allow good multiplexing behavior (and I think france wanted 32byte payload packets to be able to avoid having to do echo cancelation in their network, while the US having to do echo cancelation due to the extent of the country wanted 64 bytes payload; hence a compromise on 48 bytes payload). ATM cells as they are called typical require a 5 bytes header for 48 bytes of payload. So far all is well and one could say just take the link rate * 48 / 53 to get the "payload rate" and set the shaper to this; problem solved. BUT alas, ATM will always put each packet into an integer number of cells, or put differently will pad the last cell. So consider a very small UDP packet that with header (and overhead) has say 48 bytes all is well that just takes one ATM cell on the wire and all is fine, but add one more byte. Now we have to send two full ATM cells taking 96 bytes. In other words the atm carrier quantization can effectively double the effective size of a packet. So either we shape down to 50% to always have enough bandwidth even for the worst encapsulation or we actually calculate the wire size of each packet to send and use this size to calculate how long the link will be "blocked" while sending this packet (and this is what the link layer adaptation actually does). 
	So in short if your traffic has lots of small packets (say VoIP) it is affected most severely by the quantization and will expose buffer bloat if cerowrt does not shape properly.

> 
> - The choices in the Protocol dropdown for the GE00 interface are:
> 
> Static address
> DHCP client
> Unmanaged
> Dual-Stack Lite (RFC6333)
> IPv6-in-IPv4 (RFC4213)
> IPv6-over-IPv4 (6to4)
> IPv6-over-IPv4 (6rd)
> DHCPv6 client
> PPP
> PPtP
> PPPoE
> PPPoATM
> UMTS/GPRS/EV-DO
> L2TP
> 
> - (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.

> 
> - For each of those link layers, what customizations are required?

	Hopefully just the overhead and the type of the link layer.

> Can we give guidance (on the wiki) for people who want to set them? (Although it would be slick if someone chose the PPPoE protocol, and this tab got set up properly, we may not know enough today to do this properly.) 

	You are right, there are four possible overhead values for PPPoE ranging from 32 to 44 bytes and two possible link layers, so that in itself is not too helpful.

> 
> Fussy GUI comments:
> 
> - Would it be correct to change the label to say, “Show Advanced Link Layer Options, (only needed if using large packets, MTU > 1500 bytes)”

	

> 
> - The “Which linklayer adaptation …” question runs outside its bounding box in the GUI. This only happens when I make the window narrow for the screen shot, so it probably isn’t worth perseverating about.
> 
> - I would be tempted make “Link Layer” two words in the GUI, unless it’s a term of art.

	I am fine with that, so unless some one objects I will switch to "link layer"

> 
> Thanks, all, for this good work!
> 
> Rich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20131217/645f5558/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.png
Type: image/png
Size: 88299 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20131217/645f5558/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-4.png
Type: image/png
Size: 75746 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20131217/645f5558/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.png
Type: image/png
Size: 128059 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20131217/645f5558/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-3.png
Type: image/png
Size: 123847 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20131217/645f5558/attachment-0007.png>


More information about the Cerowrt-devel mailing list