DragonFly kernel List (threaded) for 2005-07
Re: MAXSAVEDBLOCKS in netinet/tcp_sack.c
Thanks for your reply.
> But I will note that the saved blocks are in fact the number of
> discontiguous segment ranges, not single segments. That should make it
> fairly independant of the bandwidth delay product on a real network.
> If you use dummynet to inject random errors... well, that isn't really
> a characteristic of a real network.
I agree that my network environment is unusual. :-) I just thought
that saying "I want xxx because..." is better than saying "I think
some people might need xxx because..."
BTW, I use dummynet to set delays and router queue length. I do not
use it to inject random losses. Even in such case, if both send and
receive buffers are large enough, packets are lost when the queue on
my router becomes full. In that case, my TCP receiver receives tens
of discontiguous data ranges. In my environment, the number of
discontiguous data ranges depends on the value of HZ on the router.
The larger the value of HZ, the bigger the number of discontiguous
ranges. Currently, I'm using HZ=10000 on my router.
> I still believe that there are
> certain situations where one might need to bump the number up, which
> is why I like the sysctl idea. I'm not sure the default needs to be
> increased, though.
I guess the reason of having MAXSAVEDBLOCKS is to protect from some
attack that injects many small SACK blocks. If so, I do not think
there would be a problem if the value is increased to, say, 64.