In cleaning up the lab and some long out of tree patches, I guess I should make a push for the the following patch to be more thoroughly tested in openwrt. For review here first before running that gauntlet.... [PATCH] Disable CS6 and enable ECN in Babeld This one line patch disables CS6 marking and enables ECN in babeld. ECN decouples "packet loss from congestion" from "loss due to bad connectivity". It also moves unicast babel packets into the best effort queue. The good: * OpenWrt is fully fq_codeled and doesn't pay much attention to diffserv * ECN'd Routes stay up even under extreme congestion * ECN'd Packet loss returns to a measure of connectivity only * Killing CS6 saves bandwidth - The 802.11n VO queue (where CS6 falls normally) cannot aggregate. I would support a default qos-map for Openwrt 802.11n devices essentially disabling the VO queue, as better aggregation works so much better, (In fact I'd disable VI and BK universally also), post fq_codel for wifi on ath*, and poorly in general on all devices - and then keep CS6 + ECN. The bad: * Babel does not do anything to reduce its rate on receipt of CE or modify its metrics Given a choice between losing core connectivity under congestion or not... * a babeld instance using ECN over a fq_codel'd link will always be more reachable than a non-ecn'd one you can argue that a fq_codel'd link is generically faster than one that is not. * CS6 does help somewhat on ethernet switches but it's largely been immeasurable * Lacking an effective response to ECN large babel networks can fill it's FQ'd queue with undroppable packets. This problem is generic, actually, ECN or no, as the multicast queue is infinite and not fq_codeled. babel protocol packets however are light, a single flow, and babel flooding will be unnoticible except to itself, and if it gets truly out of hand the bulk dropper should kick in. * Babeld should also independently schedule hellos from route announcements and manage the route announcement queue better After 5 years in my deployment of babel + fq_codel running this patch IMHO this is the best of multiple bad alternatives, and dramatically improves network reliability. It is the rough equivalent of adding a minimal "control plane" for critical packets. -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619