|
|
Erik Anderson <erikba@xxxxxxxxxxxxxxxxx> said: > This --mtu-test option sounds extremely useful, unfortunately I haven't > had a chance to try it out (versioning issues). > > Is there any focus on speeding up mtu-test, so that it could theoretically > be used to dynamically discover and use the best MTU in both directions, > outside of a test/diag/install environment? Right now I'm leaving it as a diag option because (1) I want to gather more data from actual real-world usage to see if it really works, i.e. produces a working tunnel when the mtu-test result is used as the mssfix parameter. (2) Making it run fast would be more complicated to implement because you would need to manage congestion control. Part of the inefficiency comes from the fact that large packets need to be sent back and forth and they need to be sent several times to make sure that lack of reception is due to an MTU problem and not just a regular network hiccup. There is definitely room for improvement though -- such as using a binary rather than a linear search, and making the mtu load-test protocol smarter. (3) Since it only works between 2 recent versions of OpenVPN I think that it would be more difficult to support right now, because a lot of people would try to use a new openvpn with an old version and of course the old version would not recognize the new mtu load-test packets. James ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |