Re: [tcpm] New I-D

Mahesh Jethanandani <mahesh@cisco.com> Fri, 29 June 2007 20:47 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4NN5-00062i-9u; Fri, 29 Jun 2007 16:47:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4NN4-000618-MF for tcpm@ietf.org; Fri, 29 Jun 2007 16:47:14 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4NMq-0001Pq-91 for tcpm@ietf.org; Fri, 29 Jun 2007 16:47:14 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Jun 2007 13:46:59 -0700
X-IronPort-AV: i="4.16,476,1175497200"; d="scan'208"; a="174574733:sNHT97449066"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5TKkxd9014208; Fri, 29 Jun 2007 13:46:59 -0700
Received: from [171.69.75.156] (dhcp-171-69-75-156.cisco.com [171.69.75.156]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5TKkwXH017708; Fri, 29 Jun 2007 20:46:58 GMT
Message-ID: <46856FC2.90309@cisco.com>
Date: Fri, 29 Jun 2007 13:46:58 -0700
From: Mahesh Jethanandani <mahesh@cisco.com>
Organization: Cisco Systems Inc.
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: John Heffner <jheffner@psc.edu>
Subject: Re: [tcpm] New I-D
References: <20070221144454.3D3E01827FD@lawyers.icir.org> <45DCC9BB.4010302@psc.edu>
In-Reply-To: <45DCC9BB.4010302@psc.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1014; t=1183150019; x=1184014019; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20<mahesh@cisco.com> |Subject:=20Re=3A=20[tcpm]=20New=20I-D |Sender:=20; bh=Ydu5QqQ6SicWEqMegLjxMCt4pjw9/nheew6toA58fTw=; b=VUi7MCxTHz8+FLPwufI9je4q4TUMKDFQ5gE/3tkdbVkH0MxzeTKv0EC9bhfxVeI4X0VU3P0/ 3QUp9WYmIHKtaZkAd3mBrbWc1dt+Rm0+qvo83CUTJoBBmiEj3/mxQtgO;
Authentication-Results: sj-dkim-2; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: tcpm@ietf.org, weddy@grc.nasa.gov, mallman@icir.org
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

Context is the draft - 
http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt

John Heffner wrote:
> As proof of concept, I wrote up a simple script (I think only about 30 
> lines of python) that used the TCP ESTATS MIB to monitor connections, 
> and kill off ones making no progress while consuming the most memory. 
> This proved an effective defense against netkill, and I think would 
> solve the problem described in the draft as well.  It would be easy 
> enough to write a kernel thread to do the same if the system doesn't 
> do ESTATS.
>
>   -John
John,

The issue with Netkill or any other application trying to kill 
connections is that they cannot distinguish between connections that are 
held up because of network issues where packets are getting dropped and 
connections that are in persist state because the client refuses to open 
the zero window. TCP can distinguish between the connections and 
determine which ones need to go. Wouldn't you agree?

m/

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