<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 5, 2018 at 8:32 AM, Kalin KOZHUHAROV <span dir="ltr"><<a href="mailto:me.kalin@gmail.com" target="_blank">me.kalin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
On Thu, Apr 5, 2018 at 5:22 AM, Ximin Luo <<a href="mailto:ximin@dfinity.org">ximin@dfinity.org</a>> wrote:<br>
> Our network churn is not expected to be very heavy, perhaps on the order of<br>
> ~30 new connections per node per week or so. So any extra latency in the initial<br>
> connection caused by this separation of layers, should not be significant.<br>
> However this churn is probably higher than what current typical WG usages<br>
> get exposed to.<br>
><br>
</span>Few times a day, I would even say few times per hour is a very normal use and<br>
should not be strange, AFAIK.<span class="gmail-"><br></span></blockquote><div><br></div><div>OK great, thanks for clarifying.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> I'm also wondering how easy this would be to program. It would clearly be<br>
> much more heavyweight than simply opening a socket, but I guess it can be done<br>
> via invocations of the `wg` or `wg-quick` tools. Has anyone had any experience<br>
> with this level of WG automation, could you share your thoughts?<br>
><br>
</span>Definitely not "hard", it will depend more on what you are trying to<br>
achieve exactly.<br>
<span class="gmail-"><br>
> Would the program need any extra system-level privileges?<br>
><br>
</span>Yes for sure ;-D Adding interfaces is a admin task, using sudo or<br>
similar should be trivial.<br>
<span class="gmail-"><br>
> Ideally we wouldn't need root, of course - does that mean we're forced to wait for a userspace WG library such<br>
> as wireguard-rs? I understand there is a performance penalty here, but I'd have<br>
> to run benchmarks to know if this affects our use-case significantly.<br>
><br>
</span>I don't think performance matters in your case, as it will be only<br>
during setup; once setup,<br>
all data goes to a socket/kernel and it doesn't matter how it was set up.<span class="gmail-"><br></span></blockquote><div><br></div><div>Application-level data goes to a socket, but AIUI adding/removing WG protocol wrapping is done either in the kernel (as in the main implementation) or in userspace (as in wireguard-rs). In the latter case there is apparently a performance penalty in terms of throughput (i.e. not only for the setup phase), judging by Jason's comments in various places. Did I understand wrong / could you explain in more detail if so?<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> Once the network is live, we'd need the transport protocol to be relatively<br>
> stable, or at least be easily upgradeable - perhaps using the noise<br>
> negotiation subprotocol to support two protocols during network upgrade times. This is<br>
> an extra requirement that seems beyond WG's current main use-case so I was also<br>
> wondering if that is something that you guys plan to cover.<br>
><br>
</span>Making it "support 2 protocols" in the design phase is a good practice<br>
for availability.<br>
It will introduce complexity, maintainability issues and thus possible<br>
security issues.<br>
Working out a "maintenance mode" might be easier.<br></blockquote><div><br></div><div>Could you elaborate what is meant by "maintenance mode"?<br><br>I suppose in the worst case we could do something like: add logic "change from protocol X to protocol Y at future round N" to software version V and expect that everyone upgrades to software version V before round N. That should hopefully work even if protocol X doesn't explicitly define a smooth upgrade path to protocol Y (e.g. X = WG version 3, Y = WG version 4).<br><br></div><div>X<br></div></div></div></div>