On 26/02/09 07:16 PM, [email protected] wrote:
On (02/26/09 14:16), Darren Reed wrote:
The other relevant RFC here is 1122, see section 3.2.2.
We currently appear to default to 64, which is pretty good.
That's going to cover 99% of packets IP+TCP header data.
The real benefit in ensuring that all the IP+TCP/UDP/ICMP
header data is included. There's not a lot of benefit in sending
back 400 bytes of HTTP headers because the receiving stack
just won't use it.
If the concern is that we will be wastefully copying data,
then perhaps the stack should build in some logic to send more
data from the offending packet when tunnels are involved, but
use other heuristics in other cases. I still think that this
does not classify as a "tunable", but something that should
be self-tuned in the stack.
I think Jim was on the money - given that others tend to be including
as much as we can, upto the prescribed limit, so should we. But that
would entail just changing the default, not removing the knob.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
