From owner-freebsd-net Sat May 18 15:29:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 6432837B40E; Sat, 18 May 2002 15:29:14 -0700 (PDT) Received: from pool0271.cvx22-bradley.dialup.earthlink.net ([209.179.199.16] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 179ChE-0004Gt-00; Sat, 18 May 2002 15:29:04 -0700 Message-ID: <3CE6D592.DCF73743@mindspring.com> Date: Sat, 18 May 2002 15:28:34 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Reilly Cc: Attila Nagy , freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: HEADS UP: ALTQ integration developer preview References: <3CE55A9B.73EA3DE4@mindspring.com> <3CE61675.BCE2A9E1@mindspring.com> <1021717195.1466.4.camel@gurney.reilly.home> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Andrew Reilly wrote: > On Sat, 2002-05-18 at 18:53, Terry Lambert wrote: > > Sending datagrams bigger than the MTU is a bad idea. > > > > I would be real tempted to drop the packets and send "don't fragment" > > ICMP responses to beat up anyone who abused UDP by sending larger > > than the MTU. > > > > I guess this is about Linux UDP NFS clients, in particular. > > Eh? Isn't the original, traditional and best NFS configuration 8k UDP > packets? > > Sure worked fine that way on SunOS-4 those many years ago. (On LANs, of > course. No one does NFS over the internet. I hope.) No. TCP. RPC over UDP is really a silly idea. If you need reliable delivery, then don't use a protocol with "unreliable" as the first word of it's name. 8-). In any case, the best UDP packet size is always "The largest possible amount of data which fits in the MTU". There's no retransmit timeout to deal with incomplete fragment sets pending reassembly. If you want to get technical, TCP also has a bug; in the move from FIN-WAIT-1 to FIN-WAIT-2, there's an assumption of two responses for a single request. That's just intrinsically bad protocol design. The workaround is to pretend you didn't get the first FIN, resend, and then either get re-ACK'ed, or get an RST. NT does this. So did Paul Vixie's "Interceptor" product (transparent proxy cache appliance using NetBSD). Putting yourself in a situation where protocol bugs result in effective attacks is, well, "a bad idea". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message