Re: [tcpm] poll for adoption of draft-ananth-persist-02

Murali Bashyam <MBashyam@OcarinaNetworks.com> Mon, 22 March 2010 19:21 UTC

Return-Path: <MBashyam@OcarinaNetworks.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B20F3A6950 for <tcpm@core3.amsl.com>; Mon, 22 Mar 2010 12:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.724
X-Spam-Level:
X-Spam-Status: No, score=0.724 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaRb8RpTlu2d for <tcpm@core3.amsl.com>; Mon, 22 Mar 2010 12:21:24 -0700 (PDT)
Received: from mail.ocarinanetworks.com (mail.ocarinanetworks.com [69.3.29.22]) by core3.amsl.com (Postfix) with ESMTP id F36C93A69EA for <tcpm@ietf.org>; Mon, 22 Mar 2010 12:21:05 -0700 (PDT)
Received: from exchsvr01.ocarina.local ([10.250.1.7]) by exchsvr01.ocarina.local ([10.250.1.7]) with mapi; Mon, 22 Mar 2010 12:23:08 -0700
From: Murali Bashyam <MBashyam@OcarinaNetworks.com>
To: "mallman@icir.org" <mallman@icir.org>, "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <wesley.m.eddy@nasa.gov>
Date: Mon, 22 Mar 2010 12:23:03 -0700
Thread-Topic: [tcpm] poll for adoption of draft-ananth-persist-02
Thread-Index: AcrJ88Uwmslo20H3QTGFuADyfcAK/gAAG34Q
Message-ID: <EC7B72027914A242B991C029F5F213CF3EBF26780A@exchsvr01.ocarina.local>
References: <C304DB494AC0C04C87C6A6E2FF5603DB47DF997794@NDJSSCC01.ndc.nasa.gov> <20100322191118.1F267B91393@lawyers.icir.org>
In-Reply-To: <20100322191118.1F267B91393@lawyers.icir.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Mar 2010 19:21:25 -0000

As an FYI, I wanted to point out the purpose of this document at a high level. It is to clarify that it is OK for connections to be aborted in the ZWP state (which entity is not the subject here), currently the language of RFC 1122 has caused confusion about this and has been interpreted by implementers to mean an "indefinite wait" and is amply substantiated by the fact that none of the widely deployed implementations (BSD, linux and windows) have got this aspect right, i.e they exhibit marked differences in their handling of this condition. 

-----Original Message-----
From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Mark Allman
Sent: Monday, March 22, 2010 12:11 PM
To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
Cc: tcpm@ietf.org
Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02

> http://www.ietf.org/id/draft-ananth-tcpm-persist-02.txt
> 
> Please respond if you either:
> 
> (1) Support making this document a WG document with the
>     target for Informational.
> 
> (2) Oppose making this document a WG document.
> 
> Of course, other comments are also welcome :).

I think (1) is fine.  I don't really think this document is needed, but I also don't think it hurts anything as a clarification.  It could also be a bit more clear and succinct.  A few comments below, but in general "eh, whatever".

allman


Section 1:

  - I find this ...

      It is important to remember that ACK (acknowledgement) segments
      that contain no data are not reliably transmitted by TCP.
      Therefore zero window probing SHOULD be supported to prevent a
      connection from hanging forever if ACK segments that re-opens the
      window is lost.

    confusing.  I understand the first sentence, but I cannot parse the
    second.  I can guess what it is trying to say, but it needs fixed.

Section 3:

  - The sender does not necessarily dump "all" data into the send
    queue.  It depends on how big the send buffer is and how much data
    needs to be sent.

Section 5:

  - This:

      It also suggests that TCP MUST not abort any connection until
      either explicitly requested by the application to do so.
      
    makes no sense.  

    Is that "MUST not" or "MUST NOT".

    Usually there are two options after an "either", but I see only
    one.  I would normally think this is a spurious "either", but here
    am somehow thinking there is an option that was forgotten.

Meta:

  - Isn't the overall point of this document to clarify things to say
    that (1) a TCP cannot tear down a connection itself, (2) the
    application can abort a connection and (3) the OS can abort a
    connection?  If I am remembering this right then this could and
    should be called out **much** better in the document.