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

Mahesh Jethanandani <mahesh@cisco.com> Wed, 28 November 2007 06:51 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 1IxGm6-00073r-K3; Wed, 28 Nov 2007 01:51:58 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxGm4-00073l-O4 for tcpm-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 01:51:56 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGm4-00073d-BA for tcpm@ietf.org; Wed, 28 Nov 2007 01:51:56 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxGm3-0004RD-Ub for tcpm@ietf.org; Wed, 28 Nov 2007 01:51:56 -0500
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Nov 2007 22:51:55 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAS6ptYt005791; Tue, 27 Nov 2007 22:51:55 -0800
Received: from [10.21.104.26] (sjc-vpnasa1-26.cisco.com [10.21.104.26]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAS6pm1f022654; Wed, 28 Nov 2007 06:51:48 GMT
Message-ID: <474D1004.9030100@cisco.com>
Date: Tue, 27 Nov 2007 22:51:48 -0800
From: Mahesh Jethanandani <mahesh@cisco.com>
Organization: Cisco Systems Inc.
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
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> <474CA683.2030600@cisco.com> <3EE5954A-5E50-4B1E-82BC-7A5FD55AEF1F@windriver.com>
In-Reply-To: <3EE5954A-5E50-4B1E-82BC-7A5FD55AEF1F@windriver.com>
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=1552; t=1196232715; x=1197096715; c=relaxed/simple; s=sjdkim4002; 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=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward[WasRe=3A=0A=20[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=h+CZOfgSlkZ63PFRKAejZE1hkEN3oT2bXJPwC3btpbU=; b=nwu3zmQRkVQTxSDHTNWhoBO2ESImqbpw7Il1C6kHEq80j+PTNogwV2zO1+8t2jKQwClF6BrR r8+neQvCeRikSE2VtNUgJjEOaCzD+vsTBuydOSZOUSOvapJrSCg/VJoY;
Authentication-Results: sj-dkim-4; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: tcpm@ietf.org, 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:
>>
>>> A TCP MAY keep its offered receive window closed
>>>             indefinitely.  As long as the receiving TCP continues to
>>>             send acknowledgments in response to the probe segments, the
>>>             sending TCP MUST allow the connection to stay open.
>>>
>
> You are misreading this.  This section (4.2.2.1) has two requirements: 
> 1) Zero Window Probing must be supported (to guard against lost window 
> updates), and 2) as long as you get responses to the ZWP, you must 
> keep the connection open.  That's it.  You aren't keeping it open to 
> get lost ACKs, you're keeping it open because the other side of the 
> connection is still there and responding.
You are right. Thanks for correcting that perception.

What I should have said is that the fact that the above statement in RFC 
1122 that "TCP MUST allow the connection to stay open" in response to 
probes has caused a lot of confusion. We have opinions all the way from 
it is ok for TCP to terminate the connection "in times of trouble" to it 
is not for TCP to terminate any connection. We have had mails that have 
said that it is ok for application/OS/socket layer to terminate the 
connection but it is not ok for TCP to terminate the connection. Does it 
mean that if socket interface makes a call to tcp_abort() to abort a 
connection, that it is not TCP that is aborting the connection, but it 
is socket interface that is, and therefore it is fine?

Would it not help to clarify the statement in the rfc?
-- 


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