Re: RFC: fragmentation code experiment

Dancer (dancer@zeor.simegen.com)
Mon, 25 Oct 1999 07:56:54 +0000

Todd wrote:
> i am working on a project related to the linux networking code and wanted
> comments both on the project, in general, and on methodology.
>
> here is the general set of premises:
>
> 1) the code related to fragmentation and (especially) reassembly and
> (especially) out-of-order reassembly is some of the more complicated and
> difficult-to-get-right code ...
> 2) modern networks almost never produce out-of-order fragments for packets
> that are eventually accepted ...
> 3) workstations and server that do no fragment reassembly ... would have simpler (and
> better-performing) network code.
>
> 4) if fragment reassembly (out-of-order or not) needs to be done, it
> should be done by border routers (where people are increasingly willing to
> do computationally intensive stuff like filter and reassemble fragments).

1 Agree. 2 Can't say. 3 more than likely. 4 heaps of routers are already
doing this, for masquerading due to the v4 address shortage.

> .. stuff...

If it led to cleaner, faster, sexier-in-evening-wear networking for
hosts, I'd be more than happy to see the burden for fragmentation
shifted to a router or gateway (I still stubbornly persist in drawing a
big black line between the those two - forgive).

I'm not totally sure how this would work in practical situations..I keep
my MTU/MRU pretty damn small on most of my data-links, ethernet
excepted. Just thinking about the possibilities of fragging in places
that there might not be a compliant reassembler between two arbitrary
parties. Scary thought. Guess that comes down to PMTU discovery
(something which, I might add doesn't run through certain NAT solutions
from our solar friends, due to the mangling of icmp...that's OT, though)

I think this wants some good hard thinking through if nobody can see a
good reason against it....because if there isn't a good obvious reason
against it there may well be a good _non_ obvious reason lurking in
there somewhere that won't turn up until later...and it's so
_depressing_ to scrap something after you've invested a lot of time on
it.

D

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/