From owner-freebsd-net@FreeBSD.ORG Thu Jun 3 12:42:20 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF0F41065672 for ; Thu, 3 Jun 2010 12:42:20 +0000 (UTC) (envelope-from sneginha@vmware.com) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [65.115.85.73]) by mx1.freebsd.org (Postfix) with ESMTP id 9309B8FC0A for ; Thu, 3 Jun 2010 12:42:20 +0000 (UTC) Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 10C055A002 for ; Thu, 3 Jun 2010 05:22:47 -0700 (PDT) Received: from pa-excaht04.vmware.com (pa-excaht04.vmware.com [10.113.81.155]) by mailhost3.vmware.com (Postfix) with ESMTP id 074C1CD94C for ; Thu, 3 Jun 2010 05:22:47 -0700 (PDT) Received: from EXCH-MBX-2.vmware.com ([10.113.81.224]) by pa-excaht04.vmware.com ([10.113.81.155]) with mapi; Thu, 3 Jun 2010 05:22:47 -0700 From: Srinivas Neginhal To: "freebsd-net@freebsd.org" Date: Thu, 3 Jun 2010 05:22:45 -0700 Thread-Topic: Question on ACKs on out-of-window packets Thread-Index: AQHLAxd4oJyqXEltG0m8g+eI0DpQJQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Question on ACKs on out-of-window packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 12:42:20 -0000 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