3.5.  Closing a Connection

  CLOSE is an operation meaning "I have no more data to send."  The
  notion of closing a full-duplex connection is subject to ambiguous
  interpretation, of course, since it may not be obvious how to treat
  the receiving side of the connection.  We have chosen to treat CLOSE
  in a simplex fashion.  The user who CLOSEs may continue to RECEIVE
  until he is told that the other side has CLOSED also.  Thus, a program
  could initiate several SENDs followed by a CLOSE, and then continue to
  RECEIVE until signaled that a RECEIVE failed because the other side
  has CLOSED.  We assume that the TCP will signal a user, even if no
  RECEIVEs are outstanding, that the other side has closed, so the user
  can terminate his side gracefully.  A TCP will reliably deliver all
  buffers SENT before the connection was CLOSED so a user who expects no
  data in return need only wait to hear the connection was CLOSED
  successfully to know that all his data was received at the destination
  TCP.  Users must keep reading connections they close for sending until
  the TCP says no more data.

  There are essentially three cases:

    1) The user initiates by telling the TCP to CLOSE the connection

    2) The remote TCP initiates by sending a FIN control signal

    3) Both users CLOSE simultaneously

  Case 1:  Local user initiates the close

    In this case, a FIN segment can be constructed and placed on the
    outgoing segment queue.  No further SENDs from the user will be
    accepted by the TCP, and it enters the FIN-WAIT-1 state.  RECEIVEs
    are allowed in this state.  All segments preceding and including FIN
    will be retransmitted until acknowledged.  When the other TCP has
    both acknowledged the FIN and sent a FIN of its own, the first TCP
    can ACK this FIN.  Note that a TCP receiving a FIN will ACK but not
    send its own FIN until its user has CLOSED the connection also.

  Case 2:  TCP receives a FIN from the network

    If an unsolicited FIN arrives from the network, the receiving TCP
    can ACK it and tell the user that the connection is closing.  The
    user will respond with a CLOSE, upon which the TCP can send a FIN to
    the other TCP after sending any remaining data.  The TCP then waits
    until its own FIN is acknowledged whereupon it deletes the
    connection.  If an ACK is not forthcoming, after the user timeout
    the connection is aborted and the user is told.

  Case 3:  both users close simultaneously

    A simultaneous CLOSE by users at both ends of a connection causes
    FIN segments to be exchanged.  When all segments preceding the FINs
    have been processed and acknowledged, each TCP can ACK the FIN it
    has received.  Both will, upon receiving these ACKs, delete the
    connection.

  

      TCP A                                                TCP B

  1.  ESTABLISHED                                          ESTABLISHED

  2.  (Close)
      FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  --> CLOSE-WAIT

  3.  FIN-WAIT-2  <-- <SEQ=300><ACK=101><CTL=ACK>      <-- CLOSE-WAIT

  4.                                                       (Close)
      TIME-WAIT   <-- <SEQ=300><ACK=101><CTL=FIN,ACK>  <-- LAST-ACK

  5.  TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>      --> CLOSED

  6.  (2 MSL)
      CLOSED                                                      

                         Normal Close Sequence

                               Figure 13.

  

      TCP A                                                TCP B

  1.  ESTABLISHED                                          ESTABLISHED

  2.  (Close)                                              (Close)
      FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  ... FIN-WAIT-1
                  <-- <SEQ=300><ACK=100><CTL=FIN,ACK>  <--
                  ... <SEQ=100><ACK=300><CTL=FIN,ACK>  -->

  3.  CLOSING     --> <SEQ=101><ACK=301><CTL=ACK>      ... CLOSING
                  <-- <SEQ=301><ACK=101><CTL=ACK>      <--
                  ... <SEQ=101><ACK=301><CTL=ACK>      -->

  4.  TIME-WAIT                                            TIME-WAIT
      (2 MSL)                                              (2 MSL)
      CLOSED                                               CLOSED

                      Simultaneous Close Sequence

                               Figure 14.

3.6.  Precedence and Security

  The intent is that connection be allowed only between ports operating
  with exactly the same security and compartment values and at the
  higher of the precedence level requested by the two ports.

  The precedence and security parameters used in TCP are exactly those
  defined in the Internet Protocol (IP) [2].  Throughout this TCP
  specification the term "security/compartment" is intended to indicate
  the security parameters used in IP including security, compartment,
  user group, and handling restriction.

  A connection attempt with mismatched security/compartment values or a
  lower precedence value must be rejected by sending a reset.  Rejecting
  a connection due to too low a precedence only occurs after an
  acknowledgment of the SYN has been received.

  Note that TCP modules which operate only at the default value of
  precedence will still have to check the precedence of incoming
  segments and possibly raise the precedence level they use on the
  connection.

  The security paramaters may be used even in a non-secure environment
  (the values would indicate unclassified data), thus hosts in
  non-secure environments must be prepared to receive the security
  parameters, though they need not send them.

3.7.  Data Communication

  Once the connection is established data is communicated by the
  exchange of segments.  Because segments may be lost due to errors
  (checksum test failure), or network congestion, TCP uses
  retransmission (after a timeout) to ensure delivery of every segment.
  Duplicate segments may arrive due to network or TCP retransmission.
  As discussed in the section on sequence numbers the TCP performs
  certain tests on the sequence and acknowledgment numbers in the
  segments to verify their acceptability.

  The sender of data keeps track of the next sequence number to use in
  the variable SND.NXT.  The receiver of data keeps track of the next
  sequence number to expect in the variable RCV.NXT.  The sender of data
  keeps track of the oldest unacknowledged sequence number in the
  variable SND.UNA.  If the data flow is momentarily idle and all data
  sent has been acknowledged then the three variables will be equal.

  When the sender creates a segment and transmits it the sender advances
  SND.NXT.  When the receiver accepts a segment it advances RCV.NXT and
  sends an acknowledgment.  When the data sender receives an

  acknowledgment it advances SND.UNA.  The extent to which the values of
  these variables differ is a measure of the delay in the communication.
  The amount by which the variables are advanced is the length of the
  data in the segment.  Note that once in the ESTABLISHED state all
  segments must carry current acknowledgment information.

  The CLOSE user call implies a push function, as does the FIN control
  flag in an incoming segment.

  Retransmission Timeout

  Because of the variability of the networks that compose an
  internetwork system and the wide range of uses of TCP connections the
  retransmission timeout must be dynamically determined.  One procedure
  for determining a retransmission time out is given here as an
  illustration.

    An Example Retransmission Timeout Procedure

      Measure the elapsed time between sending a data octet with a
      particular sequence number and receiving an acknowledgment that
      covers that sequence number (segments sent do not have to match
      segments received).  This measured elapsed time is the Round Trip
      Time (RTT).  Next compute a Smoothed Round Trip Time (SRTT) as:

        SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT)

      and based on this, compute the retransmission timeout (RTO) as:

        RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]]

      where UBOUND is an upper bound on the timeout (e.g., 1 minute),
      LBOUND is a lower bound on the timeout (e.g., 1 second), ALPHA is
      a smoothing factor (e.g., .8 to .9), and BETA is a delay variance
      factor (e.g., 1.3 to 2.0).

  The Communication of Urgent Information

  The objective of the TCP urgent mechanism is to allow the sending user
  to stimulate the receiving user to accept some urgent data and to
  permit the receiving TCP to indicate to the receiving user when all
  the currently known urgent data has been received by the user.

  This mechanism permits a point in the data stream to be designated as
  the end of urgent information.  Whenever this point is in advance of
  the receive sequence number (RCV.NXT) at the receiving TCP, that TCP
  must tell the user to go into "urgent mode"; when the receive sequence
  number catches up to the urgent pointer, the TCP must tell user to go

  into "normal mode".  If the urgent pointer is updated while the user
  is in "urgent mode", the update will be invisible to the user.

  The method employs a urgent field which is carried in all segments
  transmitted.  The URG control flag indicates that the urgent field is
  meaningful and must be added to the segment sequence number to yield
  the urgent pointer.  The absence of this flag indicates that there is
  no urgent data outstanding.

  To send an urgent indication the user must also send at least one data
  octet.  If the sending user also indicates a push, timely delivery of
  the urgent information to the destination process is enhanced.

  Managing the Window

  The window sent in each segment indicates the range of sequence
  numbers the sender of the window (the data receiver) is currently
  prepared to accept.  There is an assumption that this is related to
  the currently available data buffer space available for this
  connection.

  Indicating a large window encourages transmissions.  If more data
  arrives than can be accepted, it will be discarded.  This will result
  in excessive retransmissions, adding unnecessarily to the load on the
  network and the TCPs.  Indicating a small window may restrict the
  transmission of data to the point of introducing a round trip delay
  between each new segment transmitted.

  The mechanisms provided allow a TCP to advertise a large window and to
  subsequently advertise a much smaller window without having accepted
  that much data.  This, so called "shrinking the window," is strongly
  discouraged.  The robustness principle dictates that TCPs will not
  shrink the window themselves, but will be prepared for such behavior
  on the part of other TCPs.

  The sending TCP must be prepared to accept from the user and send at
  least one octet of new data even if the send window is zero.  The
  sending TCP must regularly retransmit to the receiving TCP even when
  the window is zero.  Two minutes is recommended for the retransmission
  interval when the window is zero.  This retransmission is essential to
  guarantee that when either TCP has a zero window the re-opening of the
  window will be reliably reported to the other.

  When the receiving TCP has a zero window and a segment arrives it must
  still send an acknowledgment showing its next expected sequence number
  and current window (zero).

  The sending TCP packages the data to be transmitted into segments

  which fit the current window, and may repackage segments on the
  retransmission queue.  Such repackaging is not required, but may be
  helpful.

  In a connection with a one-way data flow, the window information will
  be carried in acknowledgment segments that all have the same sequence
  number so there will be no way to reorder them if they arrive out of
  order.  This is not a serious problem, but it will allow the window
  information to be on occasion temporarily based on old reports from
  the data receiver.  A refinement to avoid this problem is to act on
  the window information from segments that carry the highest
  acknowledgment number (that is segments with acknowledgment number
  equal or greater than the highest previously received).

  The window management procedure has significant influence on the
  communication performance.  The following comments are suggestions to
  implementers.

    Window Management Suggestions

      Allocating a very small window causes data to be transmitted in
      many small segments when better performance is achieved using
      fewer large segments.

      One suggestion for avoiding small windows is for the receiver to
      defer updating a window until the additional allocation is at
      least X percent of the maximum allocation possible for the
      connection (where X might be 20 to 40).

      Another suggestion is for the sender to avoid sending small
      segments by waiting until the window is large enough before
      sending data.  If the the user signals a push function then the
      data must be sent even if it is a small segment.

      Note that the acknowledgments should not be delayed or unnecessary
      retransmissions will result.  One strategy would be to send an
      acknowledgment when a small segment arrives (with out updating the
      window information), and then to send another acknowledgment with
      new window information when the window is larger.

      The segment sent to probe a zero window may also begin a break up
      of transmitted data into smaller and smaller segments.  If a
      segment containing a single data octet sent to probe a zero window
      is accepted, it consumes one octet of the window now available.
      If the sending TCP simply sends as much as it can whenever the
      window is non zero, the transmitted data will be broken into
      alternating big and small segments.  As time goes on, occasional
      pauses in the receiver making window allocation available will

      result in breaking the big segments into a small and not quite so
      big pair. And after a while the data transmission will be in
      mostly small segments.

      The suggestion here is that the TCP implementations need to
      actively attempt to combine small window allocations into larger
      windows, since the mechanisms for managing the window tend to lead
      to many small windows in the simplest minded implementations.

3.8.  Interfaces

  There are of course two interfaces of concern:  the user/TCP interface
  and the TCP/lower-level interface.  We have a fairly elaborate model
  of the user/TCP interface, but the interface to the lower level
  protocol module is left unspecified here, since it will be specified
  in detail by the specification of the lowel level protocol.  For the
  case that the lower level is IP we note some of the parameter values
  that TCPs might use.

  User/TCP Interface

    The following functional description of user commands to the TCP is,
    at best, fictional, since every operating system will have different
    facilities.  Consequently, we must warn readers that different TCP
    implementations may have different user interfaces.  However, all
    TCPs must provide a certain minimum set of services to guarantee
    that all TCP implementations can support the same protocol
    hierarchy.  This section specifies the functional interfaces
    required of all TCP implementations.

    TCP User Commands

      The following sections functionally characterize a USER/TCP
      interface.  The notation used is similar to most procedure or
      function calls in high level languages, but this usage is not
      meant to rule out trap type service calls (e.g., SVCs, UUOs,
      EMTs).

      The user commands described below specify the basic functions the
      TCP must perform to support interprocess communication.
      Individual implementations must define their own exact format, and
      may provide combinations or subsets of the basic functions in
      single calls.  In particular, some implementations may wish to
      automatically OPEN a connection on the first SEND or RECEIVE
      issued by the user for a given connection.

      In providing interprocess communication facilities, the TCP must
      not only accept commands, but must also return information to the
      processes it serves.  The latter consists of:

        (a) general information about a connection (e.g., interrupts,
        remote close, binding of unspecified foreign socket).

        (b) replies to specific user commands indicating success or
        various types of failure.

      Open

        Format:  OPEN (local port, foreign socket, active/passive
        [, timeout] [, precedence] [, security/compartment] [, options])
        -> local connection name

        We assume that the local TCP is aware of the identity of the
        processes it serves and will check the authority of the process
        to use the connection specified.  Depending upon the
        implementation of the TCP, the local network and TCP identifiers
        for the source address will either be supplied by the TCP or the
        lower level protocol (e.g., IP).  These considerations are the
        result of concern about security, to the extent that no TCP be
        able to masquerade as another one, and so on.  Similarly, no
        process can masquerade as another without the collusion of the
        TCP.

        If the active/passive flag is set to passive, then this is a
        call to LISTEN for an incoming connection.  A passive open may
        have either a fully specified foreign socket to wait for a
        particular connection or an unspecified foreign socket to wait
        for any call.  A fully specified passive call can be made active
        by the subsequent execution of a SEND.

        A transmission control block (TCB) is created and partially
        filled in with data from the OPEN command parameters.

        On an active OPEN command, the TCP will begin the procedure to
        synchronize (i.e., establish) the connection at once.

        The timeout, if present, permits the caller to set up a timeout
        for all data submitted to TCP.  If data is not successfully
        delivered to the destination within the timeout period, the TCP
        will abort the connection.  The present global default is five
        minutes.

        The TCP or some component of the operating system will verify
        the users authority to open a connection with the specified

        precedence or security/compartment.  The absence of precedence
        or security/compartment specification in the OPEN call indicates
        the default values must be used.

        TCP will accept incoming requests as matching only if the
        security/compartment information is exactly the same and only if
        the precedence is equal to or higher than the precedence
        requested in the OPEN call.

        The precedence for the connection is the higher of the values
        requested in the OPEN call and received from the incoming
        request, and fixed at that value for the life of the
        connection.Implementers may want to give the user control of
        this precedence negotiation.  For example, the user might be
        allowed to specify that the precedence must be exactly matched,
        or that any attempt to raise the precedence be confirmed by the
        user.

        A local connection name will be returned to the user by the TCP.
        The local connection name can then be used as a short hand term
        for the connection defined by the <local socket, foreign socket>
        pair.

      Send

        Format:  SEND (local connection name, buffer address, byte
        count, PUSH flag, URGENT flag [,timeout])

        This call causes the data contained in the indicated user buffer
        to be sent on the indicated connection.  If the connection has
        not been opened, the SEND is considered an error.  Some
        implementations may allow users to SEND first; in which case, an
        automatic OPEN would be done.  If the calling process is not
        authorized to use this connection, an error is returned.

        If the PUSH flag is set, the data must be transmitted promptly
        to the receiver, and the PUSH bit will be set in the last TCP
        segment created from the buffer.  If the PUSH flag is not set,
        the data may be combined with data from subsequent SENDs for
        transmission efficiency.

        If the URGENT flag is set, segments sent to the destination TCP
        will have the urgent pointer set.  The receiving TCP will signal
        the urgent condition to the receiving process if the urgent
        pointer indicates that data preceding the urgent pointer has not
        been consumed by the receiving process.  The purpose of urgent
        is to stimulate the receiver to process the urgent data and to
        indicate to the receiver when all the currently known urgent

        data has been received.  The number of times the sending user's
        TCP signals urgent will not necessarily be equal to the number
        of times the receiving user will be notified of the presence of
        urgent data.

        If no foreign socket was specified in the OPEN, but the
        connection is established (e.g., because a LISTENing connection
        has become specific due to a foreign segment arriving for the
        local socket), then the designated buffer is sent to the implied
        foreign socket.  Users who make use of OPEN with an unspecified
        foreign socket can make use of SEND without ever explicitly
        knowing the foreign socket address.

        However, if a SEND is attempted before the foreign socket
        becomes specified, an error will be returned.  Users can use the
        STATUS call to determine the status of the connection.  In some
        implementations the TCP may notify the user when an unspecified
        socket is bound.

        If a timeout is specified, the current user timeout for this
        connection is changed to the new one.

        In the simplest implementation, SEND would not return control to
        the sending process until either the transmission was complete
        or the timeout had been exceeded.  However, this simple method
        is both subject to deadlocks (for example, both sides of the
        connection might try to do SENDs before doing any RECEIVEs) and
        offers poor performance, so it is not recommended.  A more
        sophisticated implementation would return immediately to allow
        the process to run concurrently with network I/O, and,
        furthermore, to allow multiple SENDs to be in progress.
        Multiple SENDs are served in first come, first served order, so
        the TCP will queue those it cannot service immediately.

        We have implicitly assumed an asynchronous user interface in
        which a SEND later elicits some kind of SIGNAL or
        pseudo-interrupt from the serving TCP.  An alternative is to
        return a response immediately.  For instance, SENDs might return
        immediate local acknowledgment, even if the segment sent had not
        been acknowledged by the distant TCP.  We could optimistically
        assume eventual success.  If we are wrong, the connection will
        close anyway due to the timeout.  In implementations of this
        kind (synchronous), there will still be some asynchronous
        signals, but these will deal with the connection itself, and not
        with specific segments or buffers.

        In order for the process to distinguish among error or success
        indications for different SENDs, it might be appropriate for the

        buffer address to be returned along with the coded response to
        the SEND request.  TCP-to-user signals are discussed below,
        indicating the information which should be returned to the
        calling process.

      Receive

        Format:  RECEIVE (local connection name, buffer address, byte
        count) -> byte count, urgent flag, push flag

        This command allocates a receiving buffer associated with the
        specified connection.  If no OPEN precedes this command or the
        calling process is not authorized to use this connection, an
        error is returned.

        In the simplest implementation, control would not return to the
        calling program until either the buffer was filled, or some
        error occurred, but this scheme is highly subject to deadlocks.
        A more sophisticated implementation would permit several
        RECEIVEs to be outstanding at once.  These would be filled as
        segments arrive.  This strategy permits increased throughput at
        the cost of a more elaborate scheme (possibly asynchronous) to
        notify the calling program that a PUSH has been seen or a buffer
        filled.

        If enough data arrive to fill the buffer before a PUSH is seen,
        the PUSH flag will not be set in the response to the RECEIVE.
        The buffer will be filled with as much data as it can hold.  If
        a PUSH is seen before the buffer is filled the buffer will be
        returned partially filled and PUSH indicated.

        If there is urgent data the user will have been informed as soon
        as it arrived via a TCP-to-user signal.  The receiving user
        should thus be in "urgent mode".  If the URGENT flag is on,
        additional urgent data remains.  If the URGENT flag is off, this
        call to RECEIVE has returned all the urgent data, and the user
        may now leave "urgent mode".  Note that data following the
        urgent pointer (non-urgent data) cannot be delivered to the user
        in the same buffer with preceeding urgent data unless the
        boundary is clearly marked for the user.

        To distinguish among several outstanding RECEIVEs and to take
        care of the case that a buffer is not completely filled, the
        return code is accompanied by both a buffer pointer and a byte
        count indicating the actual length of the data received.

        Alternative implementations of RECEIVE might have the TCP

        allocate buffer storage, or the TCP might share a ring buffer
        with the user.

      Close

        Format:  CLOSE (local connection name)

        This command causes the connection specified to be closed.  If
        the connection is not open or the calling process is not
        authorized to use this connection, an error is returned.
        Closing connections is intended to be a graceful operation in
        the sense that outstanding SENDs will be transmitted (and
        retransmitted), as flow control permits, until all have been
        serviced.  Thus, it should be acceptable to make several SEND
        calls, followed by a CLOSE, and expect all the data to be sent
        to the destination.  It should also be clear that users should
        continue to RECEIVE on CLOSING connections, since the other side
        may be trying to transmit the last of its data.  Thus, CLOSE
        means "I have no more to send" but does not mean "I will not
        receive any more."  It may happen (if the user level protocol is
        not well thought out) that the closing side is unable to get rid
        of all its data before timing out.  In this event, CLOSE turns
        into ABORT, and the closing TCP gives up.

        The user may CLOSE the connection at any time on his own
        initiative, or in response to various prompts from the TCP
        (e.g., remote close executed, transmission timeout exceeded,
        destination inaccessible).

        Because closing a connection requires communication with the
        foreign TCP, connections may remain in the closing state for a
        short time.  Attempts to reopen the connection before the TCP
        replies to the CLOSE command will result in error responses.

        Close also implies push function.

      Status

        Format:  STATUS (local connection name) -> status data

        This is an implementation dependent user command and could be
        excluded without adverse effect.  Information returned would
        typically come from the TCB associated with the connection.

        This command returns a data block containing the following
        information:

          local socket,

          foreign socket,
          local connection name,
          receive window,
          send window,
          connection state,
          number of buffers awaiting acknowledgment,
          number of buffers pending receipt,
          urgent state,
          precedence,
          security/compartment,
          and transmission timeout.

        Depending on the state of the connection, or on the
        implementation itself, some of this information may not be
        available or meaningful.  If the calling process is not
        authorized to use this connection, an error is returned.  This
        prevents unauthorized processes from gaining information about a
        connection.

      Abort

        Format:  ABORT (local connection name)

        This command causes all pending SENDs and RECEIVES to be
        aborted, the TCB to be removed, and a special RESET message to
        be sent to the TCP on the other side of the connection.
        Depending on the implementation, users may receive abort
        indications for each outstanding SEND or RECEIVE, or may simply
        receive an ABORT-acknowledgment.

    TCP-to-User Messages

      It is assumed that the operating system environment provides a
      means for the TCP to asynchronously signal the user program.  When
      the TCP does signal a user program, certain information is passed
      to the user.  Often in the specification the information will be
      an error message.  In other cases there will be information
      relating to the completion of processing a SEND or RECEIVE or
      other user call.

      The following information is provided:

        Local Connection Name                    Always
        Response String                          Always
        Buffer Address                           Send & Receive
        Byte count (counts bytes received)       Receive
        Push flag                                Receive
        Urgent flag                              Receive

  TCP/Lower-Level Interface

    The TCP calls on a lower level protocol module to actually send and
    receive information over a network.  One case is that of the ARPA
    internetwork system where the lower level module is the Internet
    Protocol (IP) [2].

    If the lower level protocol is IP it provides arguments for a type
    of service and for a time to live.  TCP uses the following settings
    for these parameters:

      Type of Service = Precedence: routine, Delay: normal, Throughput:
      normal, Reliability: normal; or 00000000.

      Time to Live    = one minute, or 00111100.

        Note that the assumed maximum segment lifetime is two minutes.
        Here we explicitly ask that a segment be destroyed if it cannot
        be delivered by the internet system within one minute.

    If the lower level is IP (or other protocol that provides this
    feature) and source routing is used, the interface must allow the
    route information to be communicated.  This is especially important
    so that the source and destination addresses used in the TCP
    checksum be the originating source and ultimate destination. It is
    also important to preserve the return route to answer connection
    requests.

    Any lower level protocol will have to provide the source address,
    destination address, and protocol fields, and some way to determine
    the "TCP length", both to provide the functional equivlent service
    of IP and to be used in the TCP checksum.

3.9.  Event Processing

  The processing depicted in this section is an example of one possible
  implementation.  Other implementations may have slightly different
  processing sequences, but they should differ from those in this
  section only in detail, not in substance.

  The activity of the TCP can be characterized as responding to events.
  The events that occur can be cast into three categories:  user calls,
  arriving segments, and timeouts.  This section describes the
  processing the TCP does in response to each of the events.  In many
  cases the processing required depends on the state of the connection.

    Events that occur:

      User Calls

        OPEN
        SEND
        RECEIVE
        CLOSE
        ABORT
        STATUS

      Arriving Segments

        SEGMENT ARRIVES

      Timeouts

        USER TIMEOUT
        RETRANSMISSION TIMEOUT
        TIME-WAIT TIMEOUT

  The model of the TCP/user interface is that user commands receive an
  immediate return and possibly a delayed response via an event or
  pseudo interrupt.  In the following descriptions, the term "signal"
  means cause a delayed response.

  Error responses are given as character strings.  For example, user
  commands referencing connections that do not exist receive "error:
  connection not open".

  Please note in the following that all arithmetic on sequence numbers,
  acknowledgment numbers, windows, et cetera, is modulo 2**32 the size
  of the sequence number space.  Also note that "=<" means less than or
  equal to (modulo 2**32).

  A natural way to think about processing incoming segments is to
  imagine that they are first tested for proper sequence number (i.e.,
  that their contents lie in the range of the expected "receive window"
  in the sequence number space) and then that they are generally queued
  and processed in sequence number order.

  When a segment overlaps other already received segments we reconstruct
  the segment to contain just the new data, and adjust the header fields
  to be consistent.

  Note that if no state change is mentioned the TCP stays in the same
  state.