Re: [tcpm] TCP zero window timeout?

Mahesh Jethanandani <mahesh@cisco.com> Tue, 29 August 2006 21:29 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIB8s-00040F-1j; Tue, 29 Aug 2006 17:29:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIB8q-000402-E4 for tcpm@ietf.org; Tue, 29 Aug 2006 17:29:04 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIB8n-0001i8-Rw for tcpm@ietf.org; Tue, 29 Aug 2006 17:29:04 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 29 Aug 2006 14:29:02 -0700
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 k7TLT1YB018683; Tue, 29 Aug 2006 14:29:01 -0700
Received: from [10.34.37.171] ([10.34.37.171]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7TLT01E008775; Tue, 29 Aug 2006 14:29:00 -0700 (PDT)
Message-ID: <44F4B19C.5050001@cisco.com>
Date: Tue, 29 Aug 2006 14:29:00 -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: Caitlin Bestler <caitlinb@broadcom.com>
Subject: Re: [tcpm] TCP zero window timeout?
References: <54AD0F12E08D1541B826BE97C98F99F189EDD1@NT-SJCA-0751.brcm.ad.broadcom.com>
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F189EDD1@NT-SJCA-0751.brcm.ad.broadcom.com>
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; 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=3D9Dr6uzpTon5iKrVxEhPCDHqT2s4=3D; b=atBUeduotxhKA5yfroPNRERRY5NAU/7T0DQEBEegimAM9w3DvpjbHzez8CeS8Lm2XNC3Z1EP 7BJNEnkUT/Tlh8VhV3y9mYC+DtvYdn0LGy6w1qF/dh9Ji7iqP42TZ6Gf;
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: 68ba2b07ef271dba6ee42a93832cfa4c
Cc: tcpm@ietf.org, Ted Faber <faber@ISI.EDU>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, "Mahdavi, Jamshid" <jamshid.mahdavi@bluecoat.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

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
>consider?
>  
>
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 
situation.

>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
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm