[Cerowrt-devel] Update to "Setting up SQM for CeroWrt 3.10" web page. Comments needed.

[Sebastian Moeller]

Hi Rich,


On Dec 28, 2013, at 15:27 , Rich Brown <richb.hanover at gmail.com> wrote:

> Hi Sebastian,
> 
>> I would love to comment further, but after reloading http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 just returns a blank page and I can not get back to the page as of yesterday evening… I will have a look later to see whether the page resurfaces…
> 
> I’m not sure what happened to this page for you. It’s available now (at least to me) at that URL…

	Well, it is back for me as well,


> 
> Rich

	So without much further ado...

> Queueing Discipline - the details...
> 
> CeroWrt is the proof-of-concept for the CoDel and fq_codel algorithms that prevent large flows of data (downloads, videos, etc.) from affecting applications that use a small number of small packets. The default of fq_codel and the simple.qos script work very well for most people.
> 
> [What are the major features of the simple.qos, simplest.qos, and drr.qos scripts?]
	simple.qos, has a shaper and three classes with different priorities
	simplest.qos has a shaper and just one class for all traffic
	drr.qos, no idea yet, I have not tested it nor looked at it closely

> 
> Explicit Congestion Notification (ECN) is a mechanism for notifying a sender that its packets are encountering congestion and that the sender should slow its packet delivery rate. We recommend that you turn ECN off for the Upload (outbound, egress) direction, because fq_codel handles and drops packets before the bottleneck, providing the congestion signal to local senders.

	Well, we recommend to disable egress ECN as marked packets still need to go over the slow bottleneck link. Dropping these instead frees up the egress queue and will allow faster reactivity on the slow uplink. With a slow enough uplink, every packet counts...

> For the Download (inbound, ingress) link, we recommend you turn ECN on so that CeroWrt can inform the remote sender that it has detected congestion.

	The same signaling is achieved by dropping the packet and not sending an ACK packet for that data, but this takes a bit longer as it relays on some timer in the sender.

>  [Is this still relevant? Arriving packets have already cleared the bottleneck, and hence dropping has no bandwidth advantage anymore. ]

	I think it still is relevant.

> 
> If you make your own queue setup script, you can pass parameters to them using the "Dangerous Configuration" strings. The name forewarns you.

	Well the dangerous string is just appended to the tc command that sets up the queuing disciplines, so you can use this to modify the existing invocation, say by changing values away from implicit defaults. Like in Fred's case where he added "target 25ms" in the egress string to change the target from the 5ms default.


> 3. Link Layer Adaptation
> 
> You must set the Link Layer Adaptation options correctly so that CeroWrt can perform its best with VoIP, gaming, and other protocols that rely on short packets. The general rule for selecting the Link Layer Adaption is:
> 
> 	• If you use any kind of DSL/ADSL connection to the Internet (that is, if you get your internet service through the telephone line), you should choose the "ATM" item.

	ADSL is the keyword here, people on VDSL most likely will not need to set ATM, but ethernet.

> Leave the Per-packet Overhead set to zero.

	I know I am quite wobbly on this topic, but we should recommend to use 40 as default here if ATM was selected.

> 	• [What is the proper description here?] If you use PPPoE (but not over ADSL/DSL link)

	You will have at least 8 byte overhead, probably more. Unfortunatelly I have no idea how to measure the overhead on non-ATM  links.

> , PPPoATM, or bridging that isn’t Ethernet, you should choose [what?] and set the Per-packet Overhead to [what?]

	I have to pass, maybe someone with such a link can chime in here? Then again these setups should be rare enough to just punt (we could let the users know they are on their own and ask for the conclusion they reached to incorporate into the wiki).

> 	• If you use Ethernet, Cable modem, Fiber, or other kind of connection to the Internet, you should choose “none (default)”.

	The decision tree should be, you have no ATM carrier and you do not know of any per packet overhead you should select none.

> If you cannot tell what kind of link you have, first try the ATM choice and run the Quick Test for Bufferbloat. If the results are good, you’re done.

	This will not really work, on non-ATM links selecting ATM will overestimate the wire size of packets thereby retaining excellent latency even at high nominal shaped ratios (should even work well at 105% of link capacity). To really test for this we need a test that measures the link capacity for different packet sizes, but I digress.

> You can also try the other link layer adaptations to see which performs better. 

	So for a real ATM link selecting link layer ATM should allow to specify higher shaping percentage than 90% for large and 85% for small packets.

> 
> 
> Link Layer Adaptation - the details…
> 
> It is especially important to set this on links that use ATM framing (almost all DSL/ADSL links do), because ATM adds five additional bytes of overhead to a 48-byte frame. Unless you tell CeroWrt to account for the ATM framing bytes, short packets will appear to take longer to send than expected, and CeroWrt will penalize that traffic. 
> 
> CeroWrt can also account for the overhead imposed by PPPoE, PPPoATM and other links when you select that option.

	Besides the nasty 48 in 53 issue, each packet also carries some ATM header overhead, just exactly how much depends on the actual encapsulation used (Fred send a useful short list of the different encapsulations). 	

> 
> Ethernet, Cable Modems, Fiber generally do not need any kind of link layer adaptation.
> 
> The "Advanced Link Layer" choices are relevant if you are sending packets larger than 1500 bytes (this is unusual for most home setups.)

	Actually the defaults will be good up to 2048 byte packets (including overhead) so even baby jumbo frames are covered :)

> 
> [What to say about the options on the maximal size, number of entries, and minimal packet size?]

	I would give a link to the tc stab man page, we just expose the values to be passed to stab here. I really assume there is nothing that needs changing in here unless the user knows exactly why he wants a change.

> 
> [What to say about tc_stab vs htb_private?]

	Basically, unless you know better, stick to tc_stab.

Best Regards
	Sebastian