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.....
--fragment is/was very useful on a system where you do not / cannot change the tun MTU size. Up to Windows XP, this was not
possible without rebooting the OS. Since Vista, it *is* possible to change the MTU of an adapter on the fly (as explained in my
trusty old cookbook, of course ;))
--fragment is also quite useful in combination with compression, to ensure that the payload never exceeded a particular size
*after* compression+encryption+encapsulation.
Now that Windows XP and below are gone, and now that compression+encryption is considered evil (voracle) it might be possible to
better calculate/predict the maximum encrypted payload size. With that, it would be possible to fix the link-mtu to 1500 (or
whatever is set on the outbound interface) and then subtract the header size to get a meaningful tun-mtu size.
As for mtu=1500 being the best possible choice: that depends if you are doing routing on your VPN or not. 95+ % of all Ethernet
LANs have the MTU set to 1500 - increasing the tun MTU to 9000 does not increase performance, as forwarded packets are coming in
from the LAN at 1500 bytes. If we can come up with an efficient method to gather a bunch of packets before processing them
inside OpenVPN then I am all for increasing the MTU to something higher (why not go for 65000?). However, until we can do that
increasing the tun mtu size will do little to improve (routing/forwarding) performance.
Having said all that, I do have one gripe with the way the link or tun mtu is
calculated in the current codebase:
In the 2.3 code base, the server tun mtu size was equal to the client tun-mtu
size.
In the 2.4+ code base, the server-side tun mtu size is set to some ridiculous low level (with link-mtu 1500 set) in order to
accomocate all possible encryption ciphers - *even if I add ncp-disable* . To me, that does not make a whole lot of sense. If I
add '--ncp-disable' I'd expect the client and the server to behave pretty much like an OpenVPN 2.3 client (with a possible 3
bytes difference to accomodate for the peer id).
JM2CW,
JJK
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
