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

Joe Touch <touch@ISI.EDU> Thu, 22 November 2007 19:24 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 1IvHfP-0005JR-E0; Thu, 22 Nov 2007 14:24:51 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IvHfO-0005Ie-L5 for tcpm-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 14:24:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvHfN-0005IW-Vb for tcpm@ietf.org; Thu, 22 Nov 2007 14:24:49 -0500
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvHfJ-0003fT-Sv for tcpm@ietf.org; Thu, 22 Nov 2007 14:24:49 -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 lAMJOTRZ021723; Thu, 22 Nov 2007 11:24:29 -0800 (PST)
Message-ID: <4745D765.2090706@isi.edu>
Date: Thu, 22 Nov 2007 11:24:21 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]
References: <0C53DCFB700D144284A584F54711EC580452BBAB@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC580452BBAB@xmb-sjc-21c.amer.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: c1c65599517f9ac32519d043c37c5336
Cc: tcpm@ietf.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>
Content-Type: multipart/mixed; boundary="===============0837970782=="
Errors-To: tcpm-bounces@ietf.org


Anantha Ramaiah (ananth) wrote:
...
> Yes, needless to say the timer would be initialised to infinity OR the
> timer would never be started unless it is programmed to do so.
> 
> So, I think we are in agreement here that it doesn't matter from which
> context you are aborting the TCP connection which is hanging in the
> persist state. Any abort is compliant with the RFC. 

Any abort under application control is compliant with 1122.

At which point, putting it inside the TCP code vs. elsewhere in the OS,
vs. in the application are all implementation decisions. That would not
be a change to TCP, and would not include a recommendation to implement
it inside TCP.

If you're asking to extend the TCP API to include access to a TCP timer
for this purpose - and thus to make that standard (which is what an API
extension would require), I think the consensus has been that lazy
application design is not a motivation for unnecessarily
overcomplicating the TCP API.

Joe

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