search for: meshy

I have long included tinc in the cerowrt project as a lighter weight, meshy alternative to conventional vpns. I sat down a few days ago to think about how to make vpn connections work better through fq_codel, and decided I should maybe hack on a vpn to do the job. So I picked up tinc's source code for the first time, got it working on IPv6 as a switch in a matter of m...

...was that we were bottlenecking on the tinc output stage, and dropping at the input stage, with about 30ms latency on the hardware I was trying - where I said AHA! fq_codel in vpnspace might be useful, might scale better to multiple cores, even... and then there was another AHA! when I realized the meshy bits of tinc could be mapped over a received /64 without exposing all that much over a single flow tinc.... making the vpn bits incur nearly zero delay for everything but big flows, and holding the delay down... And after the aha moments, other work took over... getting a generic userspace fq_code...

Hello, Dave Taht, on Wed 02 Dec 2015 13:21:56 +0100, wrote: > I'd made a start on the send direction here: > https://github.com/dtaht/tinc/commits/master > > Perhaps that will help. Well, converting a sendto call into a sendmsg call is not really "hard" :) What will be really hard is getting multiple packet receive/send over the tap/tun device, because support for it

...t. While I have a better codel (gets below > 20ms latency, not deployed), *fq*_codel by identifying individual > flows gets the induced delay on those flows down below 5ms. But that should improve with ECN if fq_codel is configured to use that, right? > At one level, tinc being so nicely meshy means that the "fq" part of > fq_codel on the gateway will have more chance to work against the > multiple vpn flows it generates for all the potential vpn endpoints... > > but at another... lookie here! ipv6! 2^64 addresses or more to use! > and port space to burn! What i...

...wifi aps tend to do it a lot, so do route flaps, and linux tcp, at least, is now VERY resistant to reordering problems, handling megabytes of out of order delivery problems with aplomb. windows on the other hand, sucks in this department, still) > >> At one level, tinc being so nicely meshy means that the "fq" part of >> fq_codel on the gateway will have more chance to work against the >> multiple vpn flows it generates for all the potential vpn endpoints... >> >> but at another... lookie here! ipv6! 2^64 addresses or more to use! >> and port sp...

...y, not deployed), *fq*_codel by identifying individual >>> flows gets the induced delay on those flows down below 5ms. >> >> >> But that should improve with ECN if fq_codel is configured to use that, >> right? >> >>> At one level, tinc being so nicely meshy means that the "fq" part of >>> fq_codel on the gateway will have more chance to work against the >>> multiple vpn flows it generates for all the potential vpn endpoints... >>> >>> but at another... lookie here! ipv6! 2^64 addresses or more to use! >...