In article <local.mail.freebsd-hackers/[EMAIL PROTECTED]> you write:
>Quoting Sergey Babkin ([EMAIL PROTECTED]):
>> John Capo wrote:
>> > 21:41:49.001039 client.4427 > server.22: P 144:192(48) ack 12937 win
>17376 <nop,nop,timestamp 53827954 105528895> (DF) [tos 0x10]
>> > 21:41:49.001073 server.22 > client.4427: . 28049:29497(1448) ack 192
>win 17328 <nop,nop,timestamp 105529049 53827954> (DF) [tos 0x10]
>> > 21:41:49.001085 server.22 > client.4427: P 29497:30313(816) ack 192
>win 17328 <nop,nop,timestamp 105529049 53827954> (DF) [tos 0x10]
>> > 21:41:49.109131 client.4427 > server.22: . ack 12937 win 17376
><nop,nop,timestamp 53827967 105528895> (DF) [tos 0x10]
>>
>> And here a _very_ pathological thing has happened: the server
>> just forgot to send the data between sequence numbers 12937
>> and 28049. Since the dump was done on the server side, this suggests
>> that something very bad has happened with the TCP state on
>> the server side. Possibly the value of the current sequence number
>> in the protocol control block got overwritten by something.
I don't believe this is happening. It looks like the server blasts
everything over the the client, and the client drops a whole bunch of
segments. When the server gets the dupack, it correctly performs a
fast retransmit and continues transmitting where it left off.
server side:
21:41:46.396051 client.4427 > server.22: . ack 11489 win 17376
21:41:46.418208 client.4427 > server.22: . ack 11489 win 17376
21:41:47.460903 server.22 > client.4427: . 11489:12937(1448) ack 144 win 17376
client side:
21:41:46.712307 server.22 > client.4427: P 11441:11489(48) ack 144 win 17376
21:41:46.763034 server.22 > client.4427: . 25937:27385(1448) ack 144 win 17376
21:41:46.763106 client.4427 > server.22: . ack 11489 win 17376
21:41:46.785324 server.22 > client.4427: P 27385:28049(664) ack 144 win 17376
21:41:46.785370 client.4427 > server.22: . ack 11489 win 17376
21:41:47.936278 server.22 > client.4427: . 11489:12937(1448) ack 144 win 17376
However, at this point, the client no further packets, so the server
really needs to enter slow start and retransmit everything starting at 12937.
Instead, it seems that the server remains in congestion avoidance, and
keeps sending at leading edge of the window, performing fast retransmits.
John, please try tweaking this sysctl:
sysctl -w net.inet.tcp.local_slowstart_flightsize=1
which should force the server to start out doing slow start. This isn't
exactly a fix for the above problem, but may heip avoid getting into the
situation in the first place.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
