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 23:54 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 1IuzOO-0007h6-O4; Wed, 21 Nov 2007 18:54:04 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuzON-0007fi-5u for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 18:54:03 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuzOM-0007fZ-RF for tcpm@ietf.org; Wed, 21 Nov 2007 18:54:02 -0500
Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuzOM-0000f1-AJ for tcpm@ietf.org; Wed, 21 Nov 2007 18:54:02 -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 lALNrj9u011336; Wed, 21 Nov 2007 15:53:46 -0800 (PST)
Message-ID: <4744C501.4090801@isi.edu>
Date: Wed, 21 Nov 2007 15:53:37 -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: <0C53DCFB700D144284A584F54711EC58044CE135@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC58044CE135@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: 31247fb3be228bb596db9127becad0bc
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="===============0962375473=="
Errors-To: tcpm-bounces@ietf.org


Anantha Ramaiah (ananth) wrote:
>  
> 
>> RFC1122 allows you to abort a connection explicitly. It 
>> allows you to have an user application timer to abort a 
>> connection explicitly. It allows you to have an OS timer that 
>> aborts a connection explicitly. To TCP, the OS and/or user 
>> application are not distinguishable.
>>
>> Now if you "set a local timer that initiates an explicit 
>> call" and want to call that "implicit", that's fine. It's 
>> still explicit ultimately (i.e., a real abort call is 
>> issued), and still supported by RFC793 and RFC1122.
> 
> Ok, I am not sure if the rest of the WG feels the same way you do. If
> what you say is true, implicit abort isn't an issue, so in theory I CAN
> have a timer inside my embedded system (it can running anywhere inhe
> system), and it can abort the connection through some interface.
> Actually no-one would even notice this behaviour since one really can't
> determine from "outside"" whether the connection was aborted implicitly
> or explicitly.

That's right.

> So I gather that there is no need to have a standards change, since you
> seem to say that RFC allows you to abort a connection which everyone is
> aware of. But it is the same RFC that says you MUST persist a connection
> indefinetly as long as you receive ACKS, so you are now providing an
> external override for this MUST behaviour. 

I think the relevant text is:

         4.2.2.17  Probing Zero Windows: RFC-793 Section 3.7, page 42

            Probing of zero (offered) windows MUST be supported.

            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.

TCP. Not the user. Users get to abort connections.

        4.2.2.13  Closing a Connection: RFC-793 Section 3.5

            A TCP connection may terminate in two ways: (1) the normal
            TCP close sequence using a FIN handshake, and (2) an "abort"
            in which one or more RST segments are sent and the
            connection state is immediately discarded.

FWIW.

Joe

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