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

David Borman <david.borman@windriver.com> Fri, 30 November 2007 17: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 1Iy9zC-0004Na-7H; Fri, 30 Nov 2007 12:49:10 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iy9zA-0004N1-Qn for tcpm-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 12:49:08 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9zA-0004Mh-EA for tcpm@ietf.org; Fri, 30 Nov 2007 12:49:08 -0500
Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy9z9-0004MO-Qb for tcpm@ietf.org; Fri, 30 Nov 2007 12:49:08 -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 lAUHn6DP017784; Fri, 30 Nov 2007 09:49:06 -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); Fri, 30 Nov 2007 09:49:06 -0800
Received: from dab-restive.wrs.com ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 09:49:05 -0800
Message-Id: <132F65F6-0F5B-4025-87C0-64556FD984C3@windriver.com>
From: David Borman <david.borman@windriver.com>
To: Anantha Ramaiah (ananth) <ananth@cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC5804597A88@xmb-sjc-21c.amer.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: Fri, 30 Nov 2007 11:49:04 -0600
References: <0C53DCFB700D144284A584F54711EC5804597A88@xmb-sjc-21c.amer.cisco.com>
X-Mailer: Apple Mail (2.915)
X-OriginalArrivalTime: 30 Nov 2007 17:49:05.0479 (UTC) FILETIME=[4CEE1570:01C83379]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: TCP Maintenance and Minor Extensions WG <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>
Errors-To: tcpm-bounces@ietf.org

Anantha,

You're still hung up on the differentiation between the protocol  
design and the implementation.  You have to make a choice.  Something  
is either specified within the TCP protocol, and hence is on the  
standards track, or it is outside the scope of the TCP protocol and  
would only be an informational RFC; there may be things in both areas.  
But if you can't cleanly separate the protocol design from the  
implementation, then you will not be able to make progress in either  
area.

The issue is not about where the functionality is implemented, but how  
it is documented and whether or not it changes the design of the TCP  
protocol.  My guess is that the best you can hope for in modifying TCP  
is to add a User/TCP interface that allows the application to set a  
new timer to abort the connection if it remains too long in persist  
state (and you'll probably still have resistance).  The interface has  
to be clearly defined, as well as the semantics on when the timer gets  
started, restarted and disabled, and what happens when the timer goes  
off.  Think of it this way: what would you add to RFC 793?  A separate  
description would describe how an application/OS might make use of  
this, but that would be informational only.

			-David Borman

On Nov 29, 2007, at 9:21 PM, Anantha Ramaiah (ananth) wrote:

> Hi David,
>
> Firstly, I appreciate your explanations on TCP design and the
> differences between standard and implementation, those are all good.
>
> That said, it appears that this is what is being said (at least that  
> is
> what is being inferred in the email exchanges) :-
>
> Case 1:
> Abort by the application and OS
> ==================================
>
> "The application OR any entity (like OS) which is instructed by the
> application to abort the TCP connection when deemed necessary". "The  
> OS
> can abort the TCP connection when deemed necessary". These actions  
> seems
> to enjoy full compliance of RFC 793/1122.
>
> Also an example : if there are 270 connections hanging out in persist
> state for 110 days, the system administrator chooses to clear some of
> these connections, now system administrator is acting on behalf of the
> system and may not be the application, this is not a violation of the
> RFC, it appears.
>
> WHEREAS
>
> Case 2:
> Aborts done inside TCP layer
> ============================
>
> Assuming that one implementation chooses to have a design like :
> instructs each individual components in the system like transports  
> layer
> to abort some connections and thereby relinquish system resources when
> deemed necessary using an explicit or implicit feedback from the OS.  
> Now
> this action seems to be violating the RFC since it was done inside the
> jurisdiction of TCP code. I am having hard time understanding this. To
> me, it is pure implementation thingy.
>
> To me all the above actions (case 1 and 2), either are all compliant  
> to
> RFC OR all of them aren't. May be it is just me.
...



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