Hi Lev, Simon,
On 30/11/18 07:10, Simon Matter wrote:
Hi Jan Just,
(forgot to add openvpn-devel in previous mail)
Some background information.
In openvpn3 we decided not to implement fragments, because:
- this is quite a big feature which has to be supported through the whole
stack (client, server, kernel module)
- we assume that it is not used by most of users
However, for those who needs --fragment, we'll implement:
- mssfix support, this should solve problems with tcp-based protocols
- sending icmp "packet too big" for other protocols, we assume that
they'll respect icmp response
--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 ;))
As James wrote a while ago (13 years ago :)
https://openvpn.net/archive/openvpn-users/2005-10/msg00354.html
A lot of experience gained during the OpenVPN 1.x releases showed that
it's best to fix the tunnel MTU at
1500 and vary the other parameters (and use --mssfix to prevent
fragmentation rather than a lower tunnel MTU).
Don't know if still holds. Assuming that we can change tun-mtu on any
supported platforms, do you think that it is better
to do _that_, rather than have mssfix/icmp ptb workaround?
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.
Do you think 1500 is a safe value? Arne just mentioned today that his
network interface MTU is 1500 and router's MTU is 1492 due to
PPPoE, and openvpn2 works because it assumes that mtu is 1450.
I also think 1500 isn't safe because different types ob internet
connections may reduce it, like the mentioned PPPoE.
this is why the --fragment feature is so handy - no need to change the
mtu values on either end, yet you can fiddle with the fragmentation size
to tune performance.
I agree that in most home environments the MTU size should be lower - if
you look at e.g. IPsec you will find that it sets the tunnel MTU size to
1360 to ensure that it will "almost always" work.
Having said that, I'd like see a solution that will work in 99% of the
cases *AND* that will give most users close-to-optimal performance. If
"fragment" is not implemented in OpenVPN 3 then what happens if the tun
MTU is too high? where does fragmentation occur? at the OS level? at
the UDP level? I'd prefer to leave any fragmenting to the underlying OS
as much as possible - hence if I want to send packets of 4000 bytes than
either they are fragmented at the tun level (i.e. before they are
processed by OpenVPN) or at the transport level (i.e. OpenVPN spits out
a 4000 byte packet over the UDP/TCP connection, which the OS then
fragements). The problem with fragmenting at the UDP level is that you
need to keep track of the fragments in order to reassemble them - TCP
does this for you.
cheers,
JJK
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
