Discussion:
babeld patch enabling ecn
(too old to reply)
Dave Taht
2018-08-28 16:45:43 UTC
Permalink
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
Toke Høiland-Jørgensen
2018-08-28 19:05:05 UTC
Permalink
Post by Dave Taht
as the multicast queue is infinite and not fq_codeled.
No it isn't. Multicast has its own fully fq-codel'ed queue...

-Toke
Dave Taht
2018-08-28 19:12:42 UTC
Permalink
Post by Toke Høiland-Jørgensen
Post by Dave Taht
as the multicast queue is infinite and not fq_codeled.
No it isn't. Multicast has its own fully fq-codel'ed queue...
Used to be infinite. Does it adjust the target?
Post by Toke Høiland-Jørgensen
-Toke
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
Toke Høiland-Jørgensen
2018-08-28 20:32:11 UTC
Permalink
Post by Dave Taht
Post by Toke Høiland-Jørgensen
Post by Dave Taht
as the multicast queue is infinite and not fq_codeled.
No it isn't. Multicast has its own fully fq-codel'ed queue...
Used to be infinite.
Not since we enabled fq-codel'ed queues.
Post by Dave Taht
Does it adjust the target?
Don't think so...

-Toke
Dave Taht
2018-08-28 20:37:30 UTC
Permalink
Post by Toke Høiland-Jørgensen
Post by Dave Taht
Post by Toke Høiland-Jørgensen
Post by Dave Taht
as the multicast queue is infinite and not fq_codeled.
No it isn't. Multicast has its own fully fq-codel'ed queue...
Used to be infinite.
Not since we enabled fq-codel'ed queues.
Bulk dropper is also still just the qdisc.
Post by Toke Høiland-Jørgensen
Post by Dave Taht
Does it adjust the target?
Don't think so...
Might explain how disastrous my test was.
Post by Toke Høiland-Jørgensen
-Toke
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
Continue reading on narkive:
Loading...