Date: Fri, 05 Apr 2002 16:12:12 -0800 From: bmah@FreeBSD.ORG (Bruce A. Mah) To: Bill Fenner <fenner@research.att.com> Cc: bmah@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: IP fragmentation (was Re: Fatal trap 12: page fault while in kernel mode) Message-ID: <200204060012.g360CC99056167@intruder.bmah.org> In-Reply-To: <200204052345.PAA21989@windsor.research.att.com> References: <20020403181854.I42720-100000@angui.sh> <15532.29114.310072.957330@grasshopper.cs.duke.edu> <200204050504.g355493C001200@intruder.bmah.org> <15533.46222.49598.958821@grasshopper.cs.duke.edu> <3CADE0E7.ED472650@mindspring.com> <15533.57961.725030.692387@grasshopper.cs.duke.edu> <200204052120.g35LKW00034174@intruder.bmah.org> <200204052345.PAA21989@windsor.research.att.com>
next in thread | previous in thread | raw e-mail | index | archive | help
If memory serves me right, Bill Fenner wrote: > The problem with the ip_nfragments code is that if space becomes > available in the middle of reception of an entire packet, a queue > will be created to reassemble a packet that will never completely > arrive (since we dropped some of the beginning of it due to no space). > I guess the nipq code has a similar problem: it will gladly free > a queue that contains fragments that go with the next fragment that > arrives. ...but of course the "obvious" solution of only creating the queue when we see a fragment with offset 0 doesn't work, because of the potential of out-of-order delivery. Sigh. > In fact, if datagrams that hash to the same bucket arrive with > interleaved fragments, the nipq code could thrash between the two > packets, creating and deleting a frag queue for each fragment arrival, > dropping both datagrams. Bleah. This is an acid flashback to grad school, when I was measuring TCP performance over ATM switches with too-small drop-tail cell buffers. :-( > To address this kind of problem, it might be worth creating a "drop" > frag queue entry, which is a way to remember that we dropped fragments > from a given datagram so we should drop all the other fragments too. Sounds reasonable, I think. > (I'd also go for modifying the data structures to make it easy to drop > the oldest frag queue.) That's a *lot* harder. We're at least dumping the oldest queue in the hash bucket now (64 buckets, fragment queues in the hundreds). Bruce. 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?200204060012.g360CC99056167>