From 107e3e41065a816354c3f383736c5abbb156b0d3 Mon Sep 17 00:00:00 2001 From: Adam Ierymenko Date: Thu, 4 May 2017 17:12:02 -0700 Subject: First pass of configurable MTU and max MTU increase. --- include/ZeroTierOne.h | 22 +--------------------- 1 file changed, 1 insertion(+), 21 deletions(-) (limited to 'include') diff --git a/include/ZeroTierOne.h b/include/ZeroTierOne.h index 20707a1d..21adbe02 100644 --- a/include/ZeroTierOne.h +++ b/include/ZeroTierOne.h @@ -61,28 +61,8 @@ extern "C" { /** * Maximum MTU for ZeroTier virtual networks - * - * This is pretty much an unchangeable global constant. To make it change - * across nodes would require logic to send ICMP packet too big messages, - * which would complicate things. 1500 has been good enough on most LANs - * for ages, so a larger MTU should be fine for the forseeable future. This - * typically results in two UDP packets per single large frame. Experimental - * results seem to show that this is good. Larger MTUs resulting in more - * fragments seemed too brittle on slow/crummy links for no benefit. - * - * If this does change, also change it in tap.h in the tuntaposx code under - * mac-tap. - * - * Overhead for a normal frame split into two packets: - * - * 1414 = 1444 (typical UDP MTU) - 28 (packet header) - 2 (ethertype) - * 1428 = 1444 (typical UDP MTU) - 16 (fragment header) - * SUM: 2842 - * - * We use 2800, which leaves some room for other payload in other types of - * messages such as multicast propagation or future support for bridging. */ -#define ZT_MAX_MTU 2800 +#define ZT_MAX_MTU 10000 /** * Maximum length of network short name -- cgit v1.2.3