rfc938.txt

RFC 相关的技术文档

   4.5 Receiving Data

      When an IRTP module in data_transfer state receives a DATA packet,
      its behavior depends on the port number, sequence number and
      implementation dependent space considerations.

      DATA ACK and PORT NAK packets are used to acknowledge the receipt
      of DATA packets.  Both of these acknowledgment packets acknowledge
      the receipt of all sequence numbers up to, but not including, the
      sequence number in their headers.  Note that this value is denoted
      "rcv_nxt" in the figures below.  This number is the value of
      rcv_nxt at the source of the acknowledgment packet when the
      acknowledgment was generated.


Miller                                                         [Page 10]



RFC 938                                                    February 1985
Internet Reliable Transaction Protocol


         0      7 8     15 16             31
         +--------+--------+--------+--------+
         |00000011|port num|     rcv_nxt     |
         +--------+--------+--------+--------+
         |        8        |    checksum     |
         +-----------------+-----------------+

         Figure 4-4.  DATA ACK Packet Format

         0      7 8     15 16             31
         +--------+--------+--------+--------+
         |00000100|port num|     rcv_nxt     |
         +--------+--------+--------+--------+
         |        8        |    checksum     |
         +-----------------+-----------------+

         Figure 4-5.  PORT NAK Packet Format

      It is not required that a receiving IRTP implementation return an
      acknowledgment packet for every incoming DATA packet, nor is it
      required that the acknowledged sequence number be that in the most
      recently received packet.  The exact circumstances under which
      DATA ACK and PORT NAK packets are sent are detailed below.  The
      net effect is that every sequence number is acknowledged, a sender
      can force reacknowledgment if an ACK is lost, all acknowledgments
      are cumulative, and no out of order acknowledgments are permitted.

      4.5.1 Receive and Acknowledgment Windows -

         Each IRTP module has two windows associated with the receive
         side of a connection.  For convenience in the following
         discussion these are given names.  The sequence number window

         rcv_nxt-MAXPACK =< sequence number < rcv_nxt

         is called the acknowledge window.  All sequence numbers within
         this window represent packets which have previously been acked
         or nacked, however, the ack or nack may have been lost in the
         network.

         The sequence number window

         rcv_nxt =< sequence number < rcv_nxt+MYRCV =< rcv_nxt+MAXPACK

         is called the receive window.  All sequence numbers within this
         window represent legal packets which may be in transit,
         assuming that the remote host has received acks for all packets


Miller                                                         [Page 11]



RFC 938                                                    February 1985
Internet Reliable Transaction Protocol


         in the acknowledge window.  The value of MYRCV depends on the
         implementation of the IRTP.  In the simplest case this number
         will be one, effectively meaning that the IRTP will ignore any
         incoming packets not in the acknowledge window or not equal to
         rcv_nxt.  If the IRTP has enough memory to buffer some incoming
         out-of-order packets, MYRCV can be set to some number =<
         MAXPACK and a more complex algorithm can be used to compute
         rcv_nxt, thereby achieving potentially greater efficiency.
         Note that in the latter case, these packets are not
         acknowledged until their sequence number is less than rcv_nxt,
         thereby insuring that acknowledgments are always cumulative.
         (See 4.5.4 below.)

      4.5.2 Invalid Packets -

         When an IRTP receives a DATA packet, it first checks the
         sequence number in the received packet.  If the sequence number
         is not within the acknowledge or receive window, the packet is
         discarded.  Similarly, if the computed checksum does not match
         that in the header, the packet is discarded.  No further action
         is taken.

      4.5.3 Sequence Numbers Within Acknowledge Window -

         When an IRTP receives an incoming DATA packet whose sequence
         number is within the acknowledge window, if the port specified
         in the incoming DATA packet is known to this IRTP, a DATA ACK
         packet is returned.  Otherwise, a PORT NAK is returned.

         In both cases, the value put in the sequence number field of
         the acknowlegement packet is the current value of rcv_nxt at
         the IRTP module which is acknowledging the DATA packet.  The
         DATA packet itself is discarded.

         (Note that the PORT NAK acknowledges reception of all packet
         numbers up to rcv_nxt.  It NAKs the port number, not the
         sequence number.)

      4.5.4 Sequence Numbers Within the Receive Window -

         If the received sequence number is within the receive window,
         rcv_nxt is recomputed.  How this is done is implementation
         dependent.  If MYRCV is one, then rcv_nxt is simply
         incremented.  Otherwise, rcv_nxt is set to the lowest sequence
         number such that all data packets with sequence numbers less




Miller                                                         [Page 12]



RFC 938                                                    February 1985
Internet Reliable Transaction Protocol


         than this number have been received and are buffered at the
         receiving IRTP, or have been delivered to their destination
         port.

         Once rcv_nxt has been recomputed, a DATA ACK or PORT NAK is
         returned, depending on whether the port number is known or not
         known.  The value placed in the sequence number field is the
         newly computed value for rcv_nxt.

      4.5.5 Forwarding Data to Using Processes -

         Whenever an incoming DATA packet has been acknowledged (either
         implicitly or explicitly) its header can be stripped off and it
         can be queued for delivery to the user process which has
         claimed its port number.  If the IRTP implementation allows
         MYRCV to be greater than one, care must be taken that data
         which was originally received out of order is forwarded to its
         intended recipient in order of original sequence number.































Miller                                                         [Page 13]



RFC 938                                                    February 1985
Internet Reliable Transaction Protocol


CHAPTER 5 - IMPLEMENTATION ISSUES

   The preceding chapter was left intentionally vague in certain ways.
   In particular, no explicit description of the use of a timer or
   timers within an IRTP module was given, nor was there a description
   of how timer events should relate to "retransmission events".  This
   was done to separate the syntactic and operational requirements of
   the protocol from the performance characteristics of its
   implementation.

   It is believed that the protocol is robust.  That is, any
   implementation which strictly conforms to Chapter 4 should provide
   reliable synchronization of two hosts and reliable sequenced transfer
   of transaction data between them.  However, different ways of
   defining the notion of a retransmission event can have potentially
   significant impact on the performance of the protocol in terms of
   throughput and in terms of the load it places on the network.  It is
   up to the implementor to take into account overall requirements of
   the network environment and the intended use of the protocol, if
   possible, to optimize overall characteristics of the implementation.
   Several such issues will be discussed in this chapter.

   5.1 Retransmission Strategies

      The IRTP requires that a timer mechanism exists to somehow trigger
      retransmissions and requires that the packet with sequence number
      snd_una be the one retransmitted.  It is not required that
      retransmission be performed on every timer event, though this is
      one "retransmission strategy".  A possible alternative strategy is
      to perform a retransmission on a timer event only if no ACKs have
      been received since the last event.

      Additionally, the interval of the timer can affect the performance
      of the strategies, as can the value of MYRCV and the lossiness of
      the network environment.

      It is not within the scope of this document to recommend a
      retransmission strategy, only to point out that different
      strategies have different consequences.  It might be desirable to
      allow using processes to "specify" a strategy when a port is
      claimed in order to tailor the service of the protocol to the
      needs of a particular application.

   5.2 Pinging

      It is important to make explicit that IRTP modules ping by
      definition.  That is, as long as a remote internet address is


Miller                                                         [Page 14]



RFC 938                                                    February 1985
Internet Reliable Transaction Protocol


      known, and is in use (that is, either synchronization or data
      transfer is being attempted), the protocol requires "periodic
      retransmission" of packets.  Note that this is true even if the
      IRTP module has determined that the remote address is currently
      unreachable.

      It is suggested that this situation can be made more sensible by
      adding two fields to the connection table.  These are:

      num_retries  (number of times current packet has been sent)
      time_out     (current retransmission timeout)

      These fields are to be used as follows.  It is assumed that there
      is some default initial value for time_out called DEFTIME, some
      (relatively long) value for time_out called PINGTIME and some
      value MAX_TRIES.  The exact values of these constants are
      implementation dependent.  The value of DEFTIME may also be
      retransmission strategy dependent.

      At the time that a connection table is initialized, num_retries is
      set to zero, and time_out is set to DEFTIME.  Whenever a
      retransmission event occurs (this will either be a retransmission
      of a SYNCH packet or of the packet with sequence number snd_una),
      num_retries is incremented by one unless it is equal to MAX_TRIES.
      If a destination is determined to be unreachable, either via an
      ICMP message or a Destination Host Dead message, num_retries is
      set to MAX_TRIES.  Whenever num_retries transitions to MAX_TRIES,
      either by being incremented or as above, the destination is is
      presumed unreachable and user processes are notified. At this
      point, time_out is set to PINGTIME, the state of the connection
      does not change and retransmissions occur at PINGTIME intervals
      until the destination becomes reachable.

      Conversely, whenever a SYNCH_ACK is received (in synch_wait
      state), or an (implicit or explicit) acknowledgment of sequence
      number snd_una is received (in data transfer state), time_out is
      set to DEFTIME and num_retries is reset to zero.  If time_out was
      already set to PINGTIME, user processes are notified that the
      destination is now reachable.

      The effect of this system is obvious.  The implementation still
      pings as required, but at presumably very infrequent intervals.
      Alternative solutions, which might place the decision to ping on
      using processes, are considered undesirable because

         o  IRTP itself becomes more complicated in terms of states of
            the connection table


Miller                                                         [Page 15]



RFC 938                                                    February 1985
Internet Reliable Transaction Protocol


         o  the user interface becomes both more complicated and more
            rigid

         o  such solutions might be deadlock prone in some instances

         o  it seems appropriate that the host to host protocol should
            be the place to determine destination reachability, if the
            overall application requires that such information be known
            (as it does in the environments intended for IRTP.)

   5.3 Deleting Connection Tables

      The protocol as defined does not allow connection tables to be
      deleted (or for a connection state to transition to out_of_synch
      from any other state).  It might be appropriate to delete a
      connection table if it is known that the destination internet
      address is no longer one which this host wants to communicate
      with.  (The only danger there is that if the destination does not
      know this, it could ping this host forever.)  It is dangerous to
      delete a connection table or to go into out_of_synch state to
      avoid pinging when a destination does not appear to be there.  Two
      hosts with the same such strategy could potentially deadlock and
      fail to resynchronize.

AUTHOR'S ADDRESS

   Trudy Miller
   Advanced Computer Communications
   720 Santa Barbara Street
   Santa Barbara, CA  93101
   [phone]


















Miller                                                         [Page 16]