netdev
[Top] [All Lists]

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

To: Andi Kleen <ak@xxxxxx>
Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly
From: John Heffner <jheffner@xxxxxxx>
Date: Tue, 17 May 2005 14:57:38 -0400
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, akepner@xxxxxxx
In-reply-to: <m1zmut7l5q.fsf@xxxxxx>
Organization: PSC
References: <Pine.LNX.4.61.0505170914130.29021@xxxxxxxxxx> <20050517.104947.112621738.davem@xxxxxxxxxxxxx> <m1zmut7l5q.fsf@xxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: KMail/1.8
On Tuesday 17 May 2005 02:38 pm, Andi Kleen wrote:
> "David S. Miller" <davem@xxxxxxxxxxxxx> writes:
> > From: Arthur Kepner <akepner@xxxxxxx>
> > Date: Tue, 17 May 2005 09:18:26 -0700 (PDT)
> >
> >>   1) Fragments must arrive in order (or in reverse order) -
> >>      out of order fragments are dropped.
> >
> > Even the most simplistic flow over the real internet
> > can get slight packet reordering.
> >
> > Heck, reordering happens on SMP on any network.
> >
> > IP is supposed to be resilient to side effects of network
> > topology, and one such common side effect is packet reordering.
> > It's common, it's fine, and the networking stack deals with it
> > gracefully.  Strict reassembly does not.
>
> If anything it would be better as a per route flag.
> Then you could set it only for your local network
> where you know Gigabit happens and reordering might
> be avoidable in some cases.

It would be better still to have a per-route packet reassembly timeout in 
milliseconds.  Expecting perfect ordering seems very fragile even for a LAN.

  -John

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