Increase control channel packet size for faster handshakes

Instead of limiting the control channel TCP/UDP packet payload size at '100 bytes + real control channel overhead' (~140 bytes ethernet payload), increase the max TCP/UDP payload size to '1250 bytes - calculated overhead' (~1210 bytes ethernet payload). This decreases the number of packets required to establish a connection by a factor 10, but still has a comfortable enough margin to succeed for lower-MTU connections.

This should especially help out for complex configs (trac #545), but also for high-latency connections (trac #543).

Note that this patch does *not* yield an optimal solution, but it is a simple and rather safe change that will improve connection setup times significantly.

---
 src/openvpn/ssl.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

index bc17fd0..cde820d 100644
@@ -299,8 +299,9 @@ tls_init_control_channel_frame_parameters(const struct frame *data_channel_frame
   reliable_ack_adjust_frame_parameters (frame, CONTROL_SEND_ACK_MAX);
   frame_add_to_extra_frame (frame, SID_SIZE + sizeof (packet_id_type));
 
-  /* set dynamic link MTU to minimum value */
-  frame_set_mtu_dynamic (frame, 0, SET_MTU_TUN);
+  /* set dynamic link MTU to cap control channel packets at 1250 bytes */
+  ASSERT(TUN_LINK_DELTA(frame) < 1250);
+  frame->link_mtu_dynamic = 1250 - TUN_LINK_DELTA(frame);
 }
 
 void

2.1.4

Am 29.06.15 um 22:59 schrieb Steffan Karger:

I have no experience with the code and what happens on a small MTU connection. Are there still very strange small MTU connections (like 56k dialup modems) around? On the other hand the OpenVPN 3.0 also uses 1200ish packet.

Arne

Hi,

A 56k dialup doesn't *need* to have a strange small MTU - at least not unless someone followed the "speed optimization tricks" common at that time and messed up their windows 3.1 TCP/IP settings... :-)

But anyway. If somone's line has a MTU below 1300 bytes, the control packets will end up being fragmented - which is not necessarily a killer, but in combination with NAT routers might indeed be a problem.

Now, *if* someone has such a line, and non-working fragmentation, their data packets will also run into this. So I wonder if we can (ab-)use one of the existing mtu-capping command line arguments, like --link-mtu, to set a configurable upper bound for control packets as well (and default to 1250 otherwise).

The option is there, the manpage description of the option "fits", we just need to make it visible inside ssl.c... :-) - Steffan?

Indeed... but then, in a household with 56k Internet, you just do not want to use any modern iOS or Android gear anyway... ("upgrade Angry Birds?" - "yes!" - "ok, ready in 36 hours!")

gert

USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...

Hi,

... and while I have the magic wand, another wish .-) - please log a message what MTU we've decided to use. We *will* see "it does not work!" log files and that might help...

gert

USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...

Sure! I just compiled it into your local binary. Just use --verb 4 and a line like

Control Channel MTU parms [ L:1541 D:1184 EF:66 EB:0 ET:0 EL:3 ]

will be appear to report the calculated MTU ;)

-Steffan

Spoiler: frame_print() is already called from do_init_finalize_tls_frame().