netdev
[Top] [All Lists]

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

To: "David S. Miller" <davem@xxxxxxxxxxxxx>
Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Thomas Graf <tgraf@xxxxxxx>
Date: Tue, 17 May 2005 22:48:06 +0200
Cc: jheffner@xxxxxxx, ak@xxxxxx, netdev@xxxxxxxxxxx, akepner@xxxxxxx
In-reply-to: <20050517.120950.74749758.davem@xxxxxxxxxxxxx>
References: <20050517.104947.112621738.davem@xxxxxxxxxxxxx> <m1zmut7l5q.fsf@xxxxxx> <200505171457.38719.jheffner@xxxxxxx> <20050517.120950.74749758.davem@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
* David S. Miller <20050517.120950.74749758.davem@xxxxxxxxxxxxx> 2005-05-17 
12:09
> From: John Heffner <jheffner@xxxxxxx>
> Date: Tue, 17 May 2005 14:57:38 -0400
> 
> > It would be better still to have a per-route packet reassembly timeout in 
> > milliseconds.
> 
> I agree.  And if we can setup the infrastructure such that the
> drivers can indicate the speed of the link they are communicating
> on, then we can set sane default values on the automatically
> created subnet routes.

I think we have two separate issues to resolve, first we need
to figure out a way to state the probability of a id wrap, this
can be a very simple pps rate estimator on the driver statistics
for hardware interfaces and something more tricky for virtual
interfaces such as found in xen. I think the link speed is not
reliable enough for this.

The second issue covers the actual defeat of the wraps, we have
to differ between the rare but possible case for long delayed
fragments and short delayed reorderings as caused by SMP. A
combination of both short and long delayed reorderings rarely
happens in practice and if so that's the bigger problem anyway.
The above probability can be used to distinguish these cases
and be more specific. SMP caused fragments have a very local
distribution and thus the window for accepted ids can be smaller
than the one for a long delayed fragment session. So maybe we
can use the above probability as a factor to calculate a window
of accepted ids.

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