[tcpm] TCP zero window timeout?

Mahesh Jethanandani <mahesh@cisco.com> Thu, 20 July 2006 20:39 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fIr-00070G-3F; Thu, 20 Jul 2006 16:39:25 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fIq-0006zc-3j for tcpm@ietf.org; Thu, 20 Jul 2006 16:39:24 -0400
Received: from sj-iport-1-in.cisco.com ([] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3fGH-0006rT-Eh for tcpm@ietf.org; Thu, 20 Jul 2006 16:36:46 -0400
Received: from sj-dkim-2.cisco.com ([]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2006 13:36:45 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com []) by sj-dkim-2.cisco.com ( with ESMTP id k6KKaiKV012656 for <tcpm@ietf.org>; Thu, 20 Jul 2006 13:36:44 -0700
Received: from [] ([]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6KKaiiB028060 for <tcpm@ietf.org>; Thu, 20 Jul 2006 13:36:44 -0700 (PDT)
Message-ID: <44BFE95C.4070001@cisco.com>
Date: Thu, 20 Jul 2006 13:36:44 -0700
From: Mahesh Jethanandani <mahesh@cisco.com>
Organization: Cisco Systems Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: tcpm@ietf.org
Content-Type: multipart/mixed; boundary="------------000305060203090201000403"
DKIM-Signature: a=rsa-sha1; q=dns; l=1862; t=1153427804; x=1154291804; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:Mahesh=20Jethanandani=20<mahesh@cisco.com> |Subject:TCP=20zero=20window=20timeout?; X=v=3Dcisco.com=3B=20h=3DqwKLOoM9ZzqT/XvePVQWCYS22Vg=3D; b=k7kI1DxO/O3IOL7LnsDsAV+01Suad06Vh3A2lPiNwWYD3GkZlHp9eOPFIHd/rACjWMOezzCA I/rsfR1qubUW4fv8byGUC/Lon7PvcjRzA97IIhmMmipbzLTReIitreG7;
Authentication-Results: sj-dkim-2.cisco.com; header.From=mahesh@cisco.com; dkim=pass ( 44 extraneous bytes; sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Subject: [tcpm] TCP zero window timeout?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

We recently ran into a customer case where the client was advertising a 
zero window towards our TCP stack in the middle of a stream. Subsequent 
probes were also resulting in a zero window advertisement.

While it was clear that the client application was where the problem 
was, our TCP implementation was left holding a lot of client data (we 
are a proxy). The result was that we ultimately ran out of buffers and 
stopped processing new connections.

This was a problem for our customer also and they were looking for a 
solution. So we decided to offer a fix in the form of TCP option that 
the customer could configure. The fix entailed using the idle timeout 
period and the normal persist backoff mechanism to determine if the 
client had made any progress (towards opening up the window), and if it 
had not, we would time out the connection with a RST, and reclaim all 
the buffers.

Would this be considered reasonable to make the server robust? Is there 
a RFC that talks about it? If not, would it be of interest to this group 
for me to write a draft, describing the changes we made?

tcpm mailing list