From nobody Tue Apr 05 14:43:54 2022 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 36C371A90B31 for ; Tue, 5 Apr 2022 14:44:06 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 4KXr4j3Q2jz4dg4 for ; Tue, 5 Apr 2022 14:44:05 +0000 (UTC) (envelope-from brett@lariat.net) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id IAA22257; Tue, 5 Apr 2022 08:43:57 -0600 (MDT) Message-Id: <202204051443.IAA22257@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 05 Apr 2022 08:43:54 -0600 To: "Patrick M. Hausen" , freebsd-net@brettglass.com From: freebsd-net@brettglass.com Subject: Re: Wireguard, MTUs, and jumbo packets Cc: "freebsd-net@freebsd.org" List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rspamd-Queue-Id: 4KXr4j3Q2jz4dg4 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brett@lariat.net designates 66.62.230.51 as permitted sender) smtp.mailfrom=brett@lariat.net X-Spamd-Result: default: False [-1.40 / 15.00]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[brettglass.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-net]; FORGED_SENDER(0.30)[freebsd-net@brettglass.com,brett@lariat.net]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:19092, ipnet:66.62.228.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[freebsd-net@brettglass.com,brett@lariat.net]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Interesting. That 60 byte overhead (which I understand is intended to make the protocol connectionless) is concerning, because to send a 1500 byte packet one needs to have enabled jumbo packets along the entire path. Otherwise, there will be a lot of fragmentation... which in turn will create yet more overhead. It also means that - at the other end of the packet size range - protocols that send many small packets (e.g. VOIP) could have tremendous overhead - 100% or more. Even TCP ACKs become substantial. This is a big disadvantage compared to protocols such as L2TP and PPTP. Is there any provision in Wireguard for packet aggregation? If not, there likely should be. --Brett Glass At 01:27 AM 4/4/2022, Patrick M. Hausen wrote: >Hi all, >as far as I know WireGuard does not care about interface or PMTU >nor perform PMTUd. You can set the WG interface MTU in the configuration, e.g. > > [Interface] > PrivateKey = ************** > Address = [...] > DNS = [...] > MTU = 1280 > >Wether your path will be capable of transporting packets with a tunnel MTU >of 1500 is left for you to take care of - outside of WG. > >WireGuard overhead is 60 bytes for IPv4 transport and 80 bytes for IPv6.