Re: [tcpm] TCP zero window timeout?

Fernando Gont <fernando@gont.com.ar> Sat, 26 August 2006 11:25 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGwIB-0001ve-D8; Sat, 26 Aug 2006 07:25:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGwIA-0001vZ-Bh for tcpm@ietf.org; Sat, 26 Aug 2006 07:25:34 -0400
Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGwI8-00087F-Gu for tcpm@ietf.org; Sat, 26 Aug 2006 07:25:34 -0400
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 2D4CBF0C66D; Sat, 26 Aug 2006 08:25:42 -0300 (ART)
Received: from fgont.gont.com.ar ([200.70.146.80]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k7QBOssi012924; Sat, 26 Aug 2006 08:25:12 -0300
Message-Id: <7.0.1.0.0.20060826070050.062ba618@gont.com.ar>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Sat, 26 Aug 2006 07:13:56 -0300
To: Mahesh Jethanandani <mahesh@cisco.com>, "Mahdavi, Jamshid" <jamshid.mahdavi@bluecoat.com>
From: Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] TCP zero window timeout?
In-Reply-To: <44EF8F0D.7030803@cisco.com>
References: <D87D0DFD1BEB364D8E528F28527DD6130240571D@bcs-mail2.internal.cacheflow.com> <7.0.1.0.0.20060722170818.05a59eb8@gont.com.ar> <44EF8F0D.7030803@cisco.com>
Mime-Version: 1.0
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>
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>
Content-Type: multipart/mixed; boundary="===============0038452873=="
Errors-To: tcpm-bounces@ietf.org

At 21:00 25/08/2006, Mahesh Jethanandani wrote:

>The situation I was referring to is a little different and applies 
>to persist timer. In our situation the client stops reading data. 
>These clients are machines out in the Internet and as such the 
>server has no control over their behavior. So while there is 
>unacknowledged data, it is not that the client is not acking any 
>data. It is responding to the probe but that it continuously 
>advertises a window of zero.  There is currently to my knowledge no 
>timeout for this state for the server. This can manifest itself as a 
>DOS situation if there are several such connections where the server 
>is forced to hold data.

I'd argue that this should be handled by an application-level timer.

The problem with the scenario you point out is that there will always 
be one more way to do the same thing.

If we're talking about connections wasting resources, there are many 
protocols (POP3, SMTP) in which after the initial greeting by the 
server, the client is supposed to go ahead. In all those cases, the 
client could just sit there. And only an application-layer timeout 
would help you.

I'm not sure how many servers implement this type of 
application-layer timer. But there are some (Apache) that I have 
checked, and do.

Nevertheless, I'm interested in the behaviour you described. Is it 
supposed to be malicious activity?

Kindest regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm