On 29/11/2018 10:49, Jan Just Keijser wrote: > Hi, > > On 29/11/18 09:03, Samuli Seppänen wrote: >> [...] > >> Had a discussion about --fragment. Agreed that if we can fix internal >> fragmentation without needing a change in frame format then we can >> definitely deprecate --fragment in the long-term. Also noted that lack >> of tun-mtu support on Windows might be for historic reasons and might >> not apply to tap-windows6. Also questioned whether the default MTU of >> 1500 is the best possible choice. >> > I wish I'd known about this discussion - I saw the topic list and figured I > wouldn't be able to contribute much to the discussion. > Regarding MTU/fragment however.....
Hi Jan, First of all, I'm terribly sorry I didn't get a chance to update the topics page in a timely manner. That should have been done, but we have been discussing this internally for a little while and I thought it was about time to get a bigger audience included in this discussion too. I brought up this discussion now because we do need to find a better way to handle --fragment. I had no goal of ending up with a complete solution in this meeting, and we didn't really conclude either how to resolve this issue. But I felt it was important to at least start this discussion so we can find a better solution for the future, with the community more involved in this discussion too. We (OpenVPN Inc) fully understand the usefulness of --fragment, but this is a very intrusive feature - from a code perspective. We also want to reduce the number of options which is needed to manually tweak a setup into a functional or better performing state. We believe a modern VPN solution should figure this out automatically and it should just work. But at the same time, automation in this area is tricky and hard - after all, how do you know if a packet was lost and why? Sometimes the packet drop is expected while other times it should not have happened. There is no quick-fix for this. So part of what we want (from a high level perspective) is to push lots of this "tackle fragmentation logic" to be handled by the kernel primarily. The kernel network stack (on all platforms) have logic to reassemble fragmented packets. But we need to find ways to better facilitate this behaviour in the kernel scope from OpenVPN. Which is why we started looking into --mssfix and --tun-mtu. Combine these areas with the ultimate goal of automation ... If the OpenVPN stack can somehow figure out that "something broke the connection to the remote side now" and then start trying resolving this automatically can provide a much better end-user experience. If that is by dynamically tweaking the --tun-mtu, --mssfix or whatever else ... that would be good. But we generally want to avoid implementing code which needs to keep track of packet reassembly due to needed fragmentation. If we really end up needing it, well, then we have at least tried resolving it in a simpler way. Kind of like trying to make it as simple as possible but no simpler. At the same time we also don't want to provide a worse end-user experience by today's standards for the vast majority of users by having the wrong default values. To exemplify this quite a bit (disregarding other comments related to --tun-mtu, this is just a stupid and simple example): It is better to start with --tun-mtu 1500 which works for 90% of our users and breaks 10% of configs which will then be automatically resolved after a shorter time (20-60 seconds?), rather than starting with --tun-mtu 1280 which works for 99.9% of users out-of-the box. We don't want to punish 90% of the users because 9.9% of the users would need a lower --tun-mtu to get things working instantly. It is better then to have code which then saves the solution or provides options for the 9.9% of users to more quickly recover - if the default resolving method can't be done faster without a pre-save state. But in the end, it might not be the --tun-mtu option we end up with modifying, it could be something different - or it could be combination of things. Right now, we just need start on a path figuring out the alternatives to reduce the need of fragmentation processing inside OpenVPN. This is basically the more detailed background of why this discussion was opened. If we can make OpenVPN even better with lesser configuration complexity we believe we're providing a better end-user experience. But neither I nor OpenVPN Inc says this will be an easy or quick path. In addition, we need to keep whatever changes compatible between OpenVPN 2 and OpenVPN 3, so we're sure there is a reasonable migration path in the future - so clients and servers can be upgraded independently without really breaking anything. With all that said: Thank you for valuable feedback regardless. And your feedback on changing the "change of MTU" on Windows prior to Vista was gold! For the rest of your points, I believe Lev has followed well up on those. -- kind regards, David Sommerseth OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
