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

Mark Allman <mallman@icir.org> Mon, 22 March 2010 19:11 UTC

Return-Path: <mallman@icir.org>
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 661953A6B61 for <tcpm@core3.amsl.com>; Mon, 22 Mar 2010 12:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.679
X-Spam-Level:
X-Spam-Status: No, score=-5.679 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
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 YkqnDKW2NsrY for <tcpm@core3.amsl.com>; Mon, 22 Mar 2010 12:11:20 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 941D43A69EB for <tcpm@ietf.org>; Mon, 22 Mar 2010 12:11:01 -0700 (PDT)
Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2MJBIuw017232; Mon, 22 Mar 2010 12:11:18 -0700 (PDT)
Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1F267B91393; Mon, 22 Mar 2010 15:11:18 -0400 (EDT)
To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <wesley.m.eddy@nasa.gov>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB47DF997794@NDJSSCC01.ndc.nasa.gov>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Glory Days
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma49365-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 22 Mar 2010 15:11:18 -0400
Sender: mallman@icir.org
Message-Id: <20100322191118.1F267B91393@lawyers.icir.org>
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
Reply-To: mallman@icir.org
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:11:27 -0000

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