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

[Murali Bashyam <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Mark Allman
Sent: Monday, March 22, 2010 12:11 PM
To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
Cc: [e-mail]
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.