Re: [tcpm] TCP zero window timeout?

Mahesh Jethanandani <mahesh@cisco.com> Sat, 26 August 2006 00:02 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGldS-0004CG-D2; Fri, 25 Aug 2006 20:02:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGldR-0004BG-17 for tcpm@ietf.org; Fri, 25 Aug 2006 20:02:49 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGlaw-0002vT-TL for tcpm@ietf.org; Fri, 25 Aug 2006 20:00:17 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 25 Aug 2006 17:00:14 -0700
X-IronPort-AV: i="4.08,170,1154934000"; d="vcf'?scan'208,217"; a="338266106:sNHT66461154"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7Q00EUP021536; Fri, 25 Aug 2006 17:00:14 -0700
Received: from [171.69.142.71] (dhcp-171-69-142-71.cisco.com [171.69.142.71]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7Q00D1E028742; Fri, 25 Aug 2006 17:00:13 -0700 (PDT)
Message-ID: <44EF8F0D.7030803@cisco.com>
Date: Fri, 25 Aug 2006 17:00:13 -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: "Mahdavi, Jamshid" <jamshid.mahdavi@bluecoat.com>
Subject: Re: [tcpm] TCP zero window timeout?
References: <D87D0DFD1BEB364D8E528F28527DD6130240571D@bcs-mail2.internal.cacheflow.com> <7.0.1.0.0.20060722170818.05a59eb8@gont.com.ar>
In-Reply-To: <7.0.1.0.0.20060722170818.05a59eb8@gont.com.ar>
Content-Type: multipart/mixed; boundary="------------090600050709000903020704"
DKIM-Signature: a=rsa-sha1; q=dns; l=6443; t=1156550414; x=1157414414; 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:Re=3A=20[tcpm]=20TCP=20zero=20window=20timeout?; X=v=3Dcisco.com=3B=20h=3DRQcAyez2TCOgZUlmMmi1jXlyvq0=3D; b=ayF5iCbucG0E8Br38uN5RqeyTVm7D33Gehuaj1ScWCrOBkb44rH4FGlcyOytsxlyByJPG7Jv wehh9jGjCs8ahFKlFPthSWQ71Xnc0Bl3ebdaiu2dhszxtIrn8dYFXTxv;
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.1 (/)
X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7
Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, Fernando Gont <fernando@gont.com.ar>
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

Jamshid,

Looking at draft-ietf-tcpm-tcp-uto it appears that the draft is 
specifically looking at the question of disconnection in the network. It 
also applies to retransmission timer.

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.

We are suggesting a solution that allows the server to get out of this 
situation by applying a upper bound on the duration of the persist 
state. Note, it is not the default behavior for TCP. The default 
behavior is still the same. The user/administrator has to explicitly 
turn it on for the server to close the connection and free the resources 
in case it is believed that it is under attack.

Fernando Gont wrote:

> At 13:24 21/07/2006, Mahdavi, Jamshid wrote:
>
>> What is the status of draft-eggert-tcpm-tcp-abort-timeout-option-01?  It
>> may be of some use in situations like this.  I've recently seen another
>> scenario where this would be useful, so I'd be interested in seeing that
>> draft reposted...
>
>
> It was merged with draft-gont-tcpm-tcp-auto-option into 
> draft-ietf-tcpm-tcp-uto.
>
> The latest revision is draft-ietf-tcpm-tcp-uto-03.txt, available at 
> the usual places (e.g., 
> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-03.txt).
>
> Feedback is more than welcome. ;-)
>
> 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

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