[Babel-users] 64k routes, bird, babel rfc, rtod, etc

[Dave Taht]

On Thu, Nov 8, 2018 at 1:40 PM Dave Taht <dave.taht at gmail.com> wrote:
>
> On Thu, Nov 8, 2018 at 1:21 PM Juliusz Chroboczek <jch at irif.fr> wrote:
> >
> > > things fall apart at about 32k in this case.
> >
> > That's pretty good.  We'll reach your 64k target when we get around to
>
> It's a worthy goal, but really excessive. :) I basically wanted to
> know the limits
> of the lowest end hw I had, for real, before daring to try and deploy
> ipv6 willy nilly again.
>
> > fixing the resend data structure
>
> Got any ideas? I enjoyed poking into the latest trie research (source
> specific routing is a new area!) and I really enjoyed learning about
> skiplists last week, am liking the uthash potential long term...
>
> > and implement pacing in the buffer
> > flushing code.
>
> Pacing can be done at the socket layer now and it's been working for
> udp and QUIC since, oh, about 4.12? 4.9? can't
> remember. I tried this at one point. Easy patch to fiddle with to
> "just turn it on"
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=62748f32d501f5d3712a7c372bbb92abc7c62bc7

This no longer requires the fq scheduler, btw. Problem is (as the quic
folk are experiencing) is that the kernel doesn't know
(at least not with public patches) that you can send udp at one rate
one way, and another at another. tcp can do it per connection.

still, adding some pacing would mitigate the bursts somewhat. rate
limiting it to, I don't know, 10Mbit/sec? and recognising
the pushback might help...

> >
> > What happens if you disable all forms of AQM on the outgoing interface?
>
> This is on a gigE and bridged to wifi network primarily.
>
> Sorry, dude, ain't my fault here for a change. :) We're not even
> driving the interface hard enough for much
> fq to kick in.
>
> tc -s qdisc show dev enp7s0
> qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514
> target 5.0ms interval 100.0ms memory_limit 32Mb ecn
>  Sent 3757104160 bytes 2768425 pkt (dropped 0, overlimits 0 requeues 704)
>  backlog 0b 0p requeues 704
>   maxpacket 68130 drop_overlimit 0 new_flow_count 695 ecn_mark 0
>   new_flows_len 0 old_flows_len 0
>
> I don't see any drops on the outbound interface. I do see babel
> perhaps bottlenecking on the send buf a bit.
>
> It's on recv that's the issue here, more, I think. Need to do less
> work per recv.
>
> I can of course throw aqm at it, as normally I do run a box with sqm
> on it at 20Mbits, (where certainly drops become a huge issue) and am
> looking at wifi and get stats on that, but for a change, it's the
> code, not the network. I'm of course very interested in someday
> returning to the short-rtt-metric and ecn work, but what
> I wanted mostly to be done was to be able to deploy rfc-bis with
> confidence. I have a heck of a lot more confidence now...
>
> (how's the hmac branch? :)
>
> I'd like to get back on my atomic attempt also as the big reason
> networkmanager/odhcpd/dnsmasq go nuts is sending a lot of ip del/adds
> that could be modifies...
>
> > I.e. use large FIFO queues both at the interface layer and in the wifi
> > driver?
>
> I'll take a harder look at that later. I think increasing (sigh) the
> sndbuf and rcvbuf might "help"... but that way lies madness.
>
> babel recognizing there's congestion in the sndbuf and
> rescheduling/dropping that packet in order to get to the important
> ones (hellos) would be better.
>
> Not really testing wifi, I'd started with the intent to blow up bird.
> And I did. And then I got some lithium to throw in the pond....
> >
> > -- Juliusz
>
>
>
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740