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

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Thu, 22 November 2007 00:10 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 1Iuzei-000788-FG; Wed, 21 Nov 2007 19:10:56 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iuzeg-00077k-Ti for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 19:10:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuzeg-00076k-8m for tcpm@ietf.org; Wed, 21 Nov 2007 19:10:54 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuzeb-000529-Ax for tcpm@ietf.org; Wed, 21 Nov 2007 19:10:54 -0500
Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 21 Nov 2007 16:10:48 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id lAM0AmdT026605; Wed, 21 Nov 2007 16:10:48 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAM0AmAx020253; Thu, 22 Nov 2007 00:10:48 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 16:10:48 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]
Date: Wed, 21 Nov 2007 16:10:49 -0800
Message-ID: <0C53DCFB700D144284A584F54711EC580452BB46@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <4744C501.4090801@isi.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]
Thread-Index: Acgsmcs9rxAPDSYlShuFi8ARR4u+vQAAMPxA
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: Joe Touch <touch@ISI.EDU>
X-OriginalArrivalTime: 22 Nov 2007 00:10:48.0735 (UTC) FILETIME=[229DDAF0:01C82C9C]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2099; t=1195690248; x=1196554248; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco.com> |Subject:=20RE=3A=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward=20[Was=20Re=3A=09[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=tLcx546y30aeOKBTSD0bJmpr+Ez6QTivu7S//lyHcRU=; b=I1MdN0JLGaouKdAWTFESOQoBxHo9SgUXNZHZonX8yQQqCs3iYOz1no8F674L8aClOJSJrRQa k6/RJSMDIp+GkM2ih0F+vZc7npAeava87w1SL1W7eSBLl0YqF6o2FThx;
Authentication-Results: sj-dkim-8; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
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>
Errors-To: tcpm-bounces@ietf.org

 
> 
> > 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.

I know I have read the above text many times, but there is an
inconsitency here. While it says that TCP MUST keep the persist
connection open, in the other hand it also says users can abort the
connection no matter what state it is in. So implementations can chose
to have some optimal schemes built inside TCP module on behalf of the
applications ( it is just a matter of programming/implementation) and
have an implicit timer inside TCP which kills the TCP connection when
timer expires and can inform the application about the connection death.

[All the above actions are compliant to the RFC since RFC doesn't talk
about how to implement TCP and it just gives a guidance, the term
user/application and TCP are just used to illustrate the concept.]

-Anantha
> 
> Joe
> 
> 


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