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

Joe Touch <touch@ISI.EDU> Wed, 21 November 2007 22:49 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 1IuyNS-0006zJ-Fg; Wed, 21 Nov 2007 17:49:02 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuyNR-0006yt-GB for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:49:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyNR-0006yf-4c for tcpm@ietf.org; Wed, 21 Nov 2007 17:49:01 -0500
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuyNN-0000mR-LG for tcpm@ietf.org; Wed, 21 Nov 2007 17:49:01 -0500
Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lALMmexW024145; Wed, 21 Nov 2007 14:48:41 -0800 (PST)
Message-ID: <4744B5C0.2050102@isi.edu>
Date: Wed, 21 Nov 2007 14:48:32 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Mahesh Jethanandani <mahesh@cisco.com>
Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]
References: <0C53DCFB700D144284A584F54711EC58044CDF71@xmb-sjc-21c.amer.cisco.com> <4744A639.2080404@cisco.com>
In-Reply-To: <4744A639.2080404@cisco.com>
X-Enigmail-Version: 0.95.5
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: tcpm@ietf.org, "Anantha Ramaiah (ananth)" <ananth@cisco.com>
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>
Content-Type: multipart/mixed; boundary="===============1012308602=="
Errors-To: tcpm-bounces@ietf.org


Mahesh Jethanandani wrote:
> Anantha Ramaiah (ananth) wrote:
>> 1) It is asking to correct/clarify the verbiage of RFC 1122. ie., RFC
>> 1122 tells the connections MUST persist forever as long as ACK's are
>> received. Now, clearly as demonstrated in the draft, there needs to be
>> some ammount of robustness that can be built into the TCP layer, which
>> can allow the connection to be aborted after some stipulated time. Is
>> this considered a change in the standards
> I want to try to bring some focus back on the above point that the draft
> is trying to make.
> 
> If we agree that there is a problem and the solution lies in aborting
> the connection, however it is done, i.e. by application or by some TCP
> implementation, then at the minimum we believe that a change is required
> in the verbiage of RFC 1122. The change is to say that in case of
> reliable ACK's coming back from the receiver, it is NOT a requirement
> for the sender to keep the connection open indefinitely.
> 
> Can we agree on this?

RFC1122 says that the connection MUST persist as long as ACKs are
received. That means that TCP must not abort it. There is no restriction
that the user (application) must not abort it.

Joe

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