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

Toke Høiland-Jørgensen toke at toke.dk
Thu Nov 8 21:51:15 GMT 2018


Dave Taht <dave.taht at gmail.com> writes:

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

There is also a socket option that allows you to set an "earliest send
time" on each packet... Can't remember what it's called, but it ties
into Van's timer wheel idea...

-Toke



More information about the Babel-users mailing list