[Top] [All Lists]

Re: [RFC/PATCH] "strict" ipv4 reassembly

To: netdev@xxxxxxxxxxx
Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Rick Jones <rick.jones2@xxxxxx>
Date: Tue, 17 May 2005 15:18:23 -0700
Cc: netdev-bounce@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.61.0505171501510.3184@xxxxxxxxxx>
References: <m1k6lx7gkf.fsf@xxxxxx> <20050517.132202.59028935.davem@xxxxxxxxxxxxx> <20050517202730.GA79960@xxxxxx> <20050517.140245.71090021.davem@xxxxxxxxxxxxx> <428A613F.1020303@xxxxxx> <Pine.LNX.4.61.0505171501510.3184@xxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304
Arthur Kepner wrote:
On Tue, 17 May 2005, Rick Jones wrote:

or an added heuristic of "if have reassembled N datagrams for the same
source/dest/protocol tuple with ID's "larger" than 'this one' since it has
arrived, we are probably going to wrap so might as well drop 'this one'"  for
some judicious and magical selection of N that may be a decent predictor of
wrap on top of some existing reassembly timout.

How do you define "larger" in this case? A sender is free to choose any ID - they can't be assumed to be montonic, for sure.

Actually, I was ass-u-me-ing they would be monotonic, but thinking about it more, that doesn't really matter. If N datagrams from that source/dest/prot tuple have been reassembled since the first/current frag of this datagam has arrived, chances are still good that the rest of the fragments of this datagram are toast and any subsequent fragments with a matching src/dst/prot/id would likely create a frankengram.

in broad handwaving terms, those N other datagrams (non-fragmented or fragmented and successfully reassembled or not I suspect) are a measure of just how far "out of order" the rest of the fragments of this datagram happen to be. for some degree of "out of orderness" we can ass-u-me the datagram is toast.

chosing a strawman, if we've received 24000 datagrams from that source/dest/prot (perhaps even just that source) since we've started reassembling this datagram from that source/dest/prot, chances seem pretty good indeed that this datagram is toast. a value of N even smaller than 24000 might suffice.

the devil seems to be in the accounting.

rick jones

<Prev in Thread] Current Thread [Next in Thread>