Date: Sat, 18 May 2002 15:28:34 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Andrew Reilly <areilly@bigpond.net.au> Cc: Attila Nagy <bra@fsn.hu>, freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: HEADS UP: ALTQ integration developer preview Message-ID: <3CE6D592.DCF73743@mindspring.com> References: <Pine.BSF.4.10.10205170216500.29826-100000@ady.warpnet.ro> <Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu> <3CE55A9B.73EA3DE4@mindspring.com> <Pine.LNX.4.44.0205181018300.10011-100000@scribble.fsn.hu> <3CE61675.BCE2A9E1@mindspring.com> <1021717195.1466.4.camel@gurney.reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CE6D592.DCF73743>