Date: Thu, 3 Jun 2010 05:22:45 -0700 From: Srinivas Neginhal <sneginha@vmware.com> To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Question on ACKs on out-of-window packets Message-ID: <D70647EE96810D4D9A9DF11A49204E74041F99F860@EXCH-MBX-2.vmware.com>
next in thread | raw e-mail | index | archive | help
Hi,
I had a question on how the current tcp_input()/tcp_do_segment() code =
handles ACKs on out-of-window packets.
Specifically, The code to handle packets which fall entirely to the le=
ft of the window.
Here is the scenario I am analyzing right now.
1. Client has sent out a window worth of data to the server and is waiting =
for acks, it can't send any more data.
2. The server is also sending data to the client.
3. The client has received everything the server had to send and has sent s=
ent an ack for the last byte.
4. Further, for what ever reason the ACK the client sent to the server take=
s longer than usual time to get to the server.
5. The server decides to retransmit earlier packets. And it starts way back=
.
6. It retransmits an old packet but now piggybacks an ACK for all the data =
the client sent the server.
Now, say, this old packet has the following attributes
Sequence number: 100000=20
Acknowledgement number : 300000
Packet Len: 1448 bytes.
Say the client has the following=20
rcv_nxt: 105000.
wl1: 104000.
This entire packet falls to the left of the receive window. The ack on this=
packet would be processed but the window update won't happen.
Now at the same time if the server receives and processes the latest ACK th=
e client sent in step 3 above (for 105000), it would stop all retransmissio=
n.
The server has no more data to send to the client.=20
Also, since the server has already sent an ACK for all the data the client =
sent it, it won't send a pure ACK either.
The client would be stuck with a snd_wnd of 0.
At the least, wouldn't this trigger unnecessary window probes?
In my particular case, the persist timer has not been triggered either sinc=
e tcp_output() never got called.
Solaris seems to have changed their window update code=20
http://blogs.sun.com/kcpoon/entry/solaris_tcp_window_update
This is not really as per the RFC but would fix the problem I am dealing wi=
th.
Any thoughts?
Regards,
Srinivas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D70647EE96810D4D9A9DF11A49204E74041F99F860>