netdev
[Top] [All Lists]

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

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Thomas Graf <tgraf@xxxxxxx>
Date: Wed, 18 May 2005 14:24:21 +0200
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, akepner@xxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20050518114030.GA16993@xxxxxxxxxxxxxxxxxxx>
References: <20050517.104947.112621738.davem@xxxxxxxxxxxxx> <E1DYAHF-0006qW-00@xxxxxxxxxxxxxxxxxxxxxxxx> <20050518004733.GG13748@xxxxxxxxxxxxxx> <20050518011632.GA27813@xxxxxxxxxxxxxxxxxxx> <20050518013712.GH13748@xxxxxxxxxxxxxx> <20050518015213.GB28070@xxxxxxxxxxxxxxxxxxx> <20050518113030.GA15391@xxxxxxxxxxxxxx> <20050518114030.GA16993@xxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
* Herbert Xu <20050518114030.GA16993@xxxxxxxxxxxxxxxxxxx> 2005-05-18 21:40
> On Wed, May 18, 2005 at 01:30:30PM +0200, Thomas Graf wrote:
> >
> > > I think it's big enough.  If it isn't it means that somebody
> > > has reordered the packets by 30000 which I find hard to
> > > believe :)
> > 
> > I was thinking about some kind of nfs server with huge recv
> > buffers and increased limits receiving at 50kpps experiencing
> > a delayed fragment once in a while. Definitely a rare case
> > but not impossible ;->
> 
> The worst that can happen if 30000 is too low is that we drop
> a packet when we shouldn't.  IMHO if a single host sends us an
> incomplete packet, followed by 30000 unrelated fragments, and
> finally a fragment of the original packet, then it is only
> fair for us to drop that packet.

Argueable but I generally agree.

> OTOH if you're arguing that 30000 is too high then you might have
> a point.  However, in that respect it cannot be any worse than
> what we have now which is essentially unlimited.

It's definitely better than what we have now, if the sender
uses a per route or even per interface counter we're on the
losing side anyway but if there are any gbit capable oses present
which do that then it's really their problem. Not sure if it
is small enough for randomly generated ids though.

Anyways, I think that the assumption that at least 50% of the
id space is actually used by the sender and seen by the receiver
is fair enough.

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