Hello!
> Or are you trying to say something else here? I really don't agree
> with this part of the change.
It was "brain fart". Do I correctly pronounce this new phrase? 8)8)
About another two chunks: I forgot to emphasize that they are unlikely
to be appropriate to apply to the kernel.
They cure the problem, but I think true fix is different.
F.e. "when" argument in tcp_reset_timer apparently must
be not "unsigned long", but something signed to work with
small negative offsets.
Also, did you look at the tcpdump output? It shows WEIRD thing!
snd_cwnd inflates very fastly after tcp_simple_retransmit()
and host floods network with new and new segments until it fills
all the receiver window inside one (or a few) rtt.
Apparently, setting correct retransmit timer stops the inflation
after it expires, but it is enough disasterous even inside one rtt.
I saw values of snd_cwnd about 100. F.e. if you have snd_cwnd=20
at pmtu discovery moment and loose a single fragmented segment,
it will be snd_cwnd+snd_cwnd*(old_mtu/new_mtu)=80 inside one rtt.
At least my router which stupidly sent to alisa pmtu disc. icmp
overruns immediately 8)
Probably, the situation after tcp_simple_retransmit()
is different of normal fast retr. and we should not
inflate snd_cwnd each new dup ack? Well, I do not know,
but it is clear, that some clamp should exist: if mtu would
fall not to 536 but to 256, alisa would loose half of segments
in her output queue. 8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
