Re: [tcpm] TCP zero window timeout?

Mahesh Jethanandani <> Tue, 29 August 2006 21:29 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GIB8s-00040F-1j; Tue, 29 Aug 2006 17:29:06 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GIB8q-000402-E4 for; Tue, 29 Aug 2006 17:29:04 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1GIB8n-0001i8-Rw for; Tue, 29 Aug 2006 17:29:04 -0400
Received: from ([]) by with ESMTP; 29 Aug 2006 14:29:02 -0700
Received: from ( []) by ( with ESMTP id k7TLT1YB018683; Tue, 29 Aug 2006 14:29:01 -0700
Received: from [] ([]) by (8.12.10/8.12.6) with ESMTP id k7TLT01E008775; Tue, 29 Aug 2006 14:29:00 -0700 (PDT)
Message-ID: <>
Date: Tue, 29 Aug 2006 14:29:00 -0700
From: Mahesh Jethanandani <>
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: Caitlin Bestler <>
Subject: Re: [tcpm] TCP zero window timeout?
References: <>
In-Reply-To: <>
Content-Type: multipart/mixed; boundary="------------070203020001030101070202"
DKIM-Signature: a=rsa-sha1; q=dns; l=4837; t=1156886941; x=1157750941; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:Mahesh=20Jethanandani=20<> |Subject:Re=3A=20[tcpm]=20TCP=20zero=20window=20timeout?;; b=atBUeduotxhKA5yfroPNRERRY5NAU/7T0DQEBEegimAM9w3DvpjbHzez8CeS8Lm2XNC3Z1EP 7BJNEnkUT/Tlh8VhV3y9mYC+DtvYdn0LGy6w1qF/dh9Ji7iqP42TZ6Gf;
Authentication-Results:;; dkim=pass ( 44 extraneous bytes; sig from verified; );
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c
Cc:, Ted Faber <faber@ISI.EDU>, "Anantha Ramaiah (ananth)" <>, "Mahdavi, Jamshid" <>, Fernando Gont <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Caitlin Bestler wrote:

>>Are u suggesting that the application query TCP to determine
>>that the connection is stuck in persist state and how much of
>>the data has been sent or not and so on? That sounds a little
>>roundabout and complicated...
>And/or the application convey an application specific tolerance
>for such a state through a local interface.
We agree that application can help TCP by suggesting how tolerant  it 
wants to be.

>If the behavior can be corrected through a local interface,
>and there is no IETF language barring or discouraging such
>an interface, then why is this something that TCPM should
Information of how long the connection has been stuck in persist state, 
how many retry probes have been made and whether each of them has 
resulted in a zero window is all in TCP. So TCP(m) has to be involved. 
Who actually issues the reset on the connection is a implementation 
level detail which we can get into once we agree that we have a DOS 

>The nature of the Denial of Service attack presented does
>not seem to require real-time defenses and definitely does
>not present a strong case for any network element modifying
>their "fast path" handling of packets.
If we accept that it is a DOS attack, then the problem needs to be 
addressed. Our suggestion only says that today's behavior of infinite 
TCP probes in persist state lends itself open to a DOS and so the probes 
should have the option to be capped with a timeout.
tcpm mailing list