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 [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
