Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]

Erik Nordmark <erik.nordmark@sun.com> Tue, 04 December 2007 22:10 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 1Izfy0-0000pD-VE; Tue, 04 Dec 2007 17:10:12 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Izfxz-0000mo-Tp for tcpm-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:10:11 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfxz-0000mV-Ib for tcpm@ietf.org; Tue, 04 Dec 2007 17:10:11 -0500
Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izfxz-0003Pj-4T for tcpm@ietf.org; Tue, 04 Dec 2007 17:10:11 -0500
Received: from jurassic.eng.sun.com ([129.146.56.36]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB4MA3MD011783; Tue, 4 Dec 2007 22:10:03 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB4MA2OV625236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 14:10:02 -0800 (PST)
Message-ID: <4755D039.9000203@sun.com>
Date: Tue, 04 Dec 2007 14:10:01 -0800
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070723)
MIME-Version: 1.0
To: David Borman <david.borman@windriver.com>
Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
References: <20071126193803.585E12FC5BE@lawyers.icir.org> <61806008-0CBC-417D-B5EB-46A7EE18446F@windriver.com>
In-Reply-To: <61806008-0CBC-417D-B5EB-46A7EE18446F@windriver.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>, Joe Touch <touch@isi.edu>, Mark Allman <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

David Borman wrote:

> While I agree with the document on the identification of the problem, I 
> disagree with the proposed solution (changing TCP to time out 
> connections in persist state).  Having a connection stay in persist 
> state for long periods of time (i.e., zero window probes continue to be 
> ACKed) by itself is not a bad thing.  That is how TCP was designed to 
> work.  Connections can survive through lots of adversity.  If a 
> connection is stuck because it is waiting for user action and the user 
> walked away and went home for the day, he should be able to come back 
> the next morning and do what needs to be done, and then the connection 
> will continue.

I'm of the same opinion.

As far as it comes to recommending a mitigation technique when TCP and 
the OS runs out of memory resources I think we can do better than merely 
looking at connections in persist state. As others have pointed out 
there is also the case of a connection which makes very slow progress 
(and uses up a fair bit of send buffer space). Ideally one don't want to 
penalize connections that happen to be over slow links, so some care 
would be needed.

    Erik



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