Consider design/protocol changes to make the platform more mobile friendly

[liilac]

Adding this largely to track verbal discussions. I'll make a point of editing this later to include more specific details.

Consider the use case of energy sensitive mobile devices with a lot of background network activity, where radio and processor wakes are a big deal.

Consider both use cases where lokinet is used for system-wide anonymity, with associated challenges in making it efficient enough for real-world use, and where it is used per-app, in which case it is important to not make the impact of lokinet disproportionate with e.g. background network traffic independent of the actual tunnelled application.

[neuroscr]

I'm hoping we can intro a set of timing parameters for a mobile mode that would allow for long delays before timeouts.

[liilac]

I'll need to go into more detail and properly document the requirements for mobile/embedded use cases, but some thoughts that come to mind include:

• cellular MTU vs packet size, especially where there might be easy paths to optimisation (see below)
• extended radio and processor wake times due to larger and more packets as a product of current data encoding scheme and structures used to represent some information such as bools
• consideration of most appropriate cryptographic function variants such as blake2 variant (blake2b, blake2s, etc) with the characteristics of embedded processors (e.g. 32 bit ones, which is not an issue for modern mobile but is for embedded)
• possible present lack of thought/effort put into protocol optimisation for non-x86 architectures (arm64, MIPS, armv7, etc) of relevance to mobile and embedded use cases
  ** crypto instructions, and IP cores/blocks, in some cases coprocessors
  ** similar for network acceleration (e.g. as seen in octeon processors)

I'll make an effort to update this and expand on and formalise on these.

[majestrate]

On Fri, Dec 21, 2018 at 11:15:32AM -0800, Lilac wrote: I'll need to go into more detail and properly document the requirements for mobile/embedded use cases, but some thoughts that come to mind include: * cellular MTU vs packet size, especially where there might be easy paths to optimisation (see below)

if the mtu is any smaller than 1280 then it's not technically a network on the internet as it's below the required minimum mtu for ipv6

* extended radio and processor wake times due to larger and more packets as a product of current data encoding scheme and structures used to represent some information such as bools

you'll get more perf if you can align data not pack it

* possible present lack of thought/effort put into protocol optimisation for non-x86 architectures (arm64, MIPS, armv7, etc) of relevance to mobile and embedded use cases

that's solvable for arm by including NEON implementations, the biggest gotcha is for sntrup that would need to be created. for MIPS it's really low powered and probably doesn't have anything we can use. for POWER (specifically POWER9) they probably have some instructions we can use, again more code to write.

** crypto instructions, and IP cores/blocks, in some cases coprocessors

probably a premature optimization right now but not totally out of the question in the future, also more code to write.

** similar for network acceleration (e.g. as seen in octeon processors)

related thought i had, RoCE or infiniband transport for big clusters on the same layer 2 network i.e. for direct inter ISP peering. a way far off dream but it'd be cool, probably overkill tho.

…

I'll make an effort to update this and expand on and formalise on these. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #112 (comment)