> 2) modern networks almost never produce out-of-order fragments for packets
> that are eventually accepted (this is a premise--needs to be tested).
It is correct in 99% of cases, provided you do not call backward order
"out-of-order". 8) And it is wrong in the rest 1%.
> 3) workstations and server that do no fragment reassembly
But how will they work then???
> or at least no out-of-order fragment reassembly would have simpler
If it will work, it will not be simpler even a bit.
> (and better-performing) network code.
Alas, it is not true. See below.
> 4) if fragment reassembly (out-of-order or not) needs to be done, it
Fragmented packets almost never intersect borders, so that you will
have no performance implications.
> where people are increasingly willing to
> do computationally intensive stuff like filter and reassemble fragments).
People, attached to internet by single slow serial link, do want
it sometimes. But it is made not because of performance, but because
they want to masquearade or because of wrongly understood security.
People, attached via fast links, cannot use it not because of defragmentation
costs (though it is high in theory, but fragmented packets rarely intersect
borders), but because it creates single failure point, which is very easy
to beat from any point of the globe.
Alexey Kuznetsov
-
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/