From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 21:03:18 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 720EC16A403 for ; Wed, 18 Jul 2007 21:03:18 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp813.mail.ird.yahoo.com (smtp813.mail.ird.yahoo.com [217.146.188.73]) by mx1.freebsd.org (Postfix) with SMTP id 94DA413C48D for ; Wed, 18 Jul 2007 21:03:17 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 57888 invoked from network); 18 Jul 2007 21:03:15 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.140.28.215 with plain) by smtp813.mail.ird.yahoo.com with SMTP; 18 Jul 2007 21:03:15 -0000 X-YMail-OSG: QOsJfKcVM1nL2gb58Aa6zIjd3Gwwn8F6hmaC8XhHsPuZe_hq Message-ID: <469E8E5F.9000707@tomjudge.com> Date: Wed, 18 Jul 2007 23:04:15 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Stephen.Clark@seclark.us References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> In-Reply-To: <469E0FFF.8070802@seclark.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bill Moran , freebsd-net@FreeBSD.org, karels@karels.net, Robert Watson , Julian Elischer , Sten Daniel Soersdal Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 21:03:18 -0000 Stephen Clark wrote: > Mike Karels wrote: > >>> A related change that should probably be discussed if we want to >>> think more about asymmetry in maximum transmission unit is this one: >>> >> >> >> >>> ---------------------------- >>> revision 1.98 >>> date: 2006/06/26 17:54:53; author: andre; state: Exp; lines: +2 -0 >>> In syncache_respond() do not reply with a MSS that is larger than what >>> the peer announced to us but make it at least tcp_minmss in size. >>> >> >> >> >>> Sponsored by: TCP/IP Optimization Fundraise 2005 >>> ---------------------------- >>> >> >> >> >>> In this change, we cap the advertised MSS in SYN/ACK to the received >>> advertised MSS, which presumably avoids an extra PMTU round trip if >>> jumbograms are enabled on the receiving endpoint. However, it also >>> prevents use of larger packet sizes if asymmetric MTU is supported. >>> I think I suggested after this was committed that we at least add an >>> administrative twiddle to enable/disable this mode of operation, but >>> don't see one in there currently. Does the Secure Computing scenario >>> use TCP in this way, and is the potential win in avoiding a PMTU >>> round-trip worth disallowing asymmetric MSS at the TCP layer? >>> >> >> In our case, TCP isn't aware of the MRU, and bases its MSS on the MTU >> values. >> However, I don't see any reason for TCP to cap the MSS at the received >> MSS. >> If the other end doesn't want to receive more than 1024 bytes, that's no >> reason to refuse to accept more. >> >> Mike >> >> >> > So was any decision reached on this issue - will FreeBSD changed to > accept a packet on an > interface that is larger than the mtu on that interface? > > Steve > There are also things to consider such as if a GigE card is connected to a GigE device (switch/card etc) and the card supports jumbo frames should the MRU be set to the max jumbo receive size for the card? This could cause confusion when people plug jumbo capable devices in with hardware limitations making the MRU lower than other devices on the network. Just some thoughts. Tom