Loading ...
Sorry, an error occurred while loading the content.

internet draft on suggested mod to the Nagle algorithm

Expand Messages
  • Greg Minshall
    Tcp-impl people, Just in case you didn t see the following, i m forwarding the announcement along. I d love to hear any thoughts people might have, both on
    Message 1 of 135 , Feb 1, 1999
      Tcp-impl people,

      Just in case you didn't see the following, i'm forwarding the announcement
      along. I'd love to hear any thoughts people might have, both on the concept
      and on how to implement it. (I need to do at least one modification to add in
      how Sam Manthorpe/SGI has addressed this issue.)

      Thanks, Greg Minshall
      ------- Forwarded Message

      Message-Id: <199902011653.LAA23867@...>
      Mime-Version: 1.0
      Content-Type: Multipart/Mixed; Boundary="NextPart"
      To: IETF-Announce: ;
      From: Internet-Drafts@...
      Reply-to: Internet-Drafts@...
      Subject: I-D ACTION:draft-minshall-nagle-00.txt
      Date: Mon, 01 Feb 1999 11:53:39 -0500
      Sender: cclark@...
      X-UIDL: 2d7829f9365bbfc5454f7c0d6a61f975

      - --NextPart

      A New Internet-Draft is available from the on-line Internet-Drafts directories.

      Title : A Suggested Modification to Nagle's Algorithm
      Author(s) : G. Minshall
      Filename : draft-minshall-nagle-00.txt
      Pages : 4
      Date : 29-Jan-99

      The Nagle algorithm is one of the primary mechanisms which protects
      the internet from poorly designed and/or implemented applications.
      However, for a certain class of applications (notably,
      request-response protocols) the Nagle algorithm interacts poorly
      with delayed acknowledgements to give these applications poorer

      This draft is NOT suggesting that these applications should disable
      the Nagle algorithm.

      This draft suggests a fairly small and simple modification to the
      Nagle algorithm to preserve Nagle as a means of protecting the
      internet while at the same time giving better performance to a
      wider class of applications.

      A URL for this Internet-Draft is:

      Internet-Drafts are also available by anonymous FTP. Login with the username
      "anonymous" and a password of your e-mail address. After logging in,
      type "cd internet-drafts" and then
      "get draft-minshall-nagle-00.txt".

      A list of Internet-Drafts directories can be found in
      or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

      Internet-Drafts can also be obtained by e-mail.

      Send a message to:
      In the body type:
      "FILE /internet-drafts/draft-minshall-nagle-00.txt".

      NOTE: The mail server at ietf.org can return the document in
      MIME-encoded form by using the "mpack" utility. To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command. To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader. Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e. documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

      Below is the data which will enable a MIME compliant mail reader
      implementation to automatically retrieve the ASCII version of the

      - --NextPart
      Content-Type: Multipart/Alternative; Boundary="OtherAccess"

      - --OtherAccess
      Content-Type: Message/External-body;

      Content-Type: text/plain
      Content-ID: <19990129145320.I-D@...>

      ENCODING mime
      FILE /internet-drafts/draft-minshall-nagle-00.txt

      - --OtherAccess
      Content-Type: Message/External-body;

      Content-Type: text/plain
      Content-ID: <19990129145320.I-D@...>

      - --OtherAccess--

      - --NextPart--

      ------- End of Forwarded Message
    • der Mouse
      ... None that I can see. ... That s not how I read it. Suppose there is no send window available, MSS 1500, 500 bytes buffered waiting for window, and then,
      Message 135 of 135 , Feb 17, 1999
        >> What's the difference [on the wire] between a flush bit in the
        >> send() system call, and explicit setsockopt()'s turning off
        >> TCP_NODELAY off before a send() and on afterwards?

        None that I can see.

        > The problem is that there isn't really a required correlation between
        > send() calls and segments, regardless of NODELAY (or anything else I
        > can find, excepting _only_ the proposed flush bit, which might be
        > defined as guaranteeing that the last byte of the write is the last
        > byte of a segment).

        That's not how I read it. Suppose there is no send window available,
        MSS 1500, 500 bytes buffered waiting for window, and then, without any
        network traffic occurring during it, the application does
        write-with-flush 10 bytes then ordinary write 10 bytes more. I don't
        think any of the flush-bit proposals would require the next segment to
        hold 510 bytes rather than 520 (assuming that when the window opens, it
        opens at least 520 bytes' worth).

        der Mouse

        7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
      Your message has been successfully submitted and would be delivered to recipients shortly.