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

David Borman <david.borman@windriver.com> Wed, 28 November 2007 00:16 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 1IxAbb-0005T0-A1; Tue, 27 Nov 2007 19:16:43 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxAba-0005M2-Dt for tcpm-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 19:16:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxAbZ-0005Lf-W9 for tcpm@ietf.org; Tue, 27 Nov 2007 19:16:42 -0500
Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxAbY-0002Gy-D2 for tcpm@ietf.org; Tue, 27 Nov 2007 19:16:41 -0500
Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id lAS0GVHq024457; Tue, 27 Nov 2007 16:16:31 -0800 (PST)
Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 16:16:31 -0800
Received: from [172.25.34.21] ([172.25.34.21]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 16:16:31 -0800
Message-Id: <3EE5954A-5E50-4B1E-82BC-7A5FD55AEF1F@windriver.com>
From: David Borman <david.borman@windriver.com>
To: Mahesh Jethanandani <mahesh@cisco.com>
In-Reply-To: <474CA683.2030600@cisco.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
Date: Tue, 27 Nov 2007 18:16:29 -0600
References: <20071126193803.585E12FC5BE@lawyers.icir.org> <61806008-0CBC-417D-B5EB-46A7EE18446F@windriver.com> <474CA683.2030600@cisco.com>
X-Mailer: Apple Mail (2.915)
X-OriginalArrivalTime: 28 Nov 2007 00:16:31.0515 (UTC) FILETIME=[ED686EB0:01C83153]
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
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

On Nov 27, 2007, at 5:21 PM, Mahesh Jethanandani wrote:

> My understanding of rfc 1122 is and I quote from the rfc itself:
>
>> 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.
>>
>>             DISCUSSION:
>>                  It is extremely important to remember that ACK
>>                  (acknowledgment) segments that contain no data are  
>> not
>>                  reliably transmitted by TCP.  If zero window  
>> probing is
>>                  not supported, a connection may hang forever when an
>>                  ACK segment that re-opens the window is lost.
>>
> This tells me that the concern was with ACK's getting lost in the  
> network and that is why the need to keep the connection open. The  
> point we bring up in the draft is in the case the ACK's are being  
> received reliably then the need to keep the connection open just to  
> make sure the ACK has made it to the other end goes away. That is  
> why the request to change the language to say that in case of  
> reliable ACK, TCP MAY tear the connection down if it is not able to  
> service existing or new connections.

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.

			-David Borman


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