rfc1693.txt

中、英文RFC文档大全打包下载完全版 .

   with the object_sizes vector, the complete service profile is
   described.

   This information must be packaged and communicated to the sending TCP
   before the first object is transmitted using a TCP service primitive
   or comparable means depending upon the User/TCP interface.  Once the
   service profile has been specified to the TCP, it remains in effect
   until the connection is closed or the sending user specifies a new
   service profile.  In the event that the largest object size can not
   be processed by the receiving TCP, the user application is informed
   that the connection cannot be maintained and the normal connection
   close procedure is followed.

   Typically, as has been described here, the service profile definition
   and specification is handled at the sending end of the connection,
   but there could be applications (such as the screen refresh) where
   the receiving user has this knowledge.  Under these circumstances the
   receiving user is obliged to transmit the object ordering on the



Connolly, Amer & Conrad                                        [Page 20]

RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   return side of the connection (e.g., when making the request for a
   screen refresh) and have the sender interpret this data to be used on
   the send side of the connection.

   Requiring that the sending application specify the service profile is
   not an arbitrary choice.  To ensure proper object identification, the
   receiving application must transmit the new object numbering to the
   sending application (not the sending transport layer).  Since the
   sending application must receive this information in any case, it
   simplifies matters greatly to require that the sending application be
   the only side that may specify the service profile to the transport
   layer.

   Consider now the layered architecture diagram in Figure 8 and assume
   that a connection already is established.  Let us now say that UserA
   specifies the service profile for the sending-side of the connection
   via its interface with TCP-A. TCP-A places the profile in the header
   of one or more data packets (depending upon the size of the service
   profile, the profile may require several packets), sets the POC-
   service-profile option and passes it to IP for transmission over the
   network.  This packet must be transmitted reliably, therefore TCP-A
   buffers it and starts a normal retransmit timer.  Subsequently, the
   service profile arrives at the destination node and is handed to
   TCP-B (as indicated by the arrows in Figure 8).  TCP-B returns an
   acknowledgment and immediately adopts the service profile for one
   direction of data flow over the connection.  When the acknowledgment
   arrives back at TCP-A, the cycle is complete and both sides are now
   able to use the partial order service.

                 +--------+                +----------+
        Service  | UserA  |                | UserB    |
        Profile  +--------+                +----------+
          |          |                           |
          |          |                           |
          v          |                           |
          |      +---------+               +-----------+    Service
          |      |  TCP-A  |               |  TCP-B    |    Profile
          |      +---------+               +-----------+       ^
          |          |                           |             |
          |          |                           |             |
          |          |                           |             |
          |      +---------------------------------------+     |
          v      |                                       |     |
          ------>| ---- Service Profile ------------->   |----->
                 +---------------------------------------+

          Figure 8. Layered Communication Architecture




Connolly, Amer & Conrad                                        [Page 21]

RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   Note that one of the TCP entities learns of the profile via its user
   interface, while the other TCP entity is informed via its network
   interface.

   For the remaining discussions, we will assume that a partial order
   profile has been successfully negotiated for a single direction of
   the connection (as depicted in Figure 8) and that we may now speak of
   a "sending TCP" (TCP-A) and a "receiving TCP" (TCP-B).  As such,
   TCP-A refers to the partial order data stream as the "send-side" of
   the connection, while TCP-B refers to the same data stream as the
   "receive-side".

   Having established a partial order connection, the communicating TCPs
   each have their respective jobs to perform to ensure proper data
   delivery.  The sending TCP ascertains the object ordering and
   reliability from the service profile and uses this information in its
   buffering/retransmission policy.  The receiver modifications are more
   significant, particularly the issues of object deliverability and
   reliability.  And both sides will need to redefine the notion of
   window management.  Let us look specifically at how each side of the
   TCP connection is managed under this new paradigm.

4.2.1 Sender

   The sender's concerns are still essentially four-fold - transmitting
   data, managing buffer space, processing acknowledgments and
   retransmitting after a time-out - however, each takes on a new
   meaning in a partial order service.  Additionally, the management of
   the service profile represents a fifth duty not previously needed.

   Taking a rather simplistic view, normal TCP output processing
   involves (1) setting up the header, (2) copying user data into the
   outgoing segment, (3) sending the segment, (4) making a copy in a
   send buffer for retransmission and (5) starting a retransmission
   timer.  The only difference with a partial order service is that the
   reliability vector must be examined to determine whether or not to
   buffer the object and start a timer - if the object is classified as
   NBART-L, then steps 4 and 5 are omitted.

   Buffer management at the sending end of a partial order connection is
   dependent upon the object reliability class and the object size.
   When transmitting NBART-L objects the sender need not store the data
   for later possible retransmission since NBART-L objects are never
   retransmitted.  The details of buffer management - such as whether to
   allocate fixed-size pools of memory, or perhaps utilize a dynamic
   heap allocation strategy - are left to the particular system
   implementer.




Connolly, Amer & Conrad                                        [Page 22]

RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   Acknowledgment processing remains essentially intact -
   acknowledgments are cumulative and specify the peer TCP's window
   advertisement.  However, determination of this advertisement is no
   longer a trivial process dependent only upon the available buffer
   space (this is discussed further in Section 4.2.2).  Moreover, it
   should be noted that the introduction of partial ordering and partial
   reliability presents several new and interesting alternatives for the
   acknowledgment policy.  The authors are investigating several of
   these strategies through a simulation model and have included a brief
   discussion of these issues in Section 6.

   The retransmit function of the TCP is entirely unchanged and is
   therefore not discussed further.

   For some applications, it may be possible to maintain the same
   partial order for multiple periods (e.g., the application repeats the
   same partial order).  In the general case, however, the protocol must
   be able to change the service profile during an existing connection.
   When a change in the service profile is requested, the sending TCP is
   obliged to complete the processing of the current partial order
   before commencing with a new one.  This ensures consistency between
   the user applications in the event of a connection failure and
   simplifies the protocol (future study is planned to investigate the
   performance improvement gained by allowing concurrent different
   partial orders).  The current partial order is complete when all
   sending buffers are free.  Then negotiation  of the new service
   profile is performed in the same manner as with the initial profile.

   Combining these issues, we propose the following simplified state
   machine for the protocol (connection establishment and tear down
   remains the same and is not show here).

               (1)Send Request                            (5)Ack Arrival
                  +------+                                +-----------+
                  |      |                                |           |
                  |      V                                |           |
                +----------+  (4) New PO Profile    +----------+      |
          +---->|          |----------------------->|   PO     |<-----+
          |     |  ESTAB   |                        |          |
      (2) |     |          |                        |  SETUP   |
      Ack +-----|          |<-----------------------|          |<-----+
      Arrival   +----------+  (7)PO Setup Complete  +----------+      |
                  ^      |                                  |         |
                  |      |                                  |         |
                  +------+                                  +---------+
                (3)Timeout                                  (6)Timeout





Connolly, Amer & Conrad                                        [Page 23]

RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   Event (1) - User Makes a Data Send Request
   =========
      If Piggyback Timer is set then
           cancel piggyback timer
      Package and send the object (with ACK for receive-side)
      If object type = (BART-L,BART-NL) then
           Store the object and start a retransmit timer
      If sending window is full then
           Block Event (1) - allow no further send requests from user

   Event (2) - ACK Arrives
   =========
      If ACKed object(s) is buffered then
           Release the buffer(s) and stop the retransmit timer(s)
      Extract the peer TCP's window advertisement
      If remote TCP's window advertisement > sending window then
           Enable Event (1)
      If remote TCP's window advertisement <= sending window then
           Block Event (1) - allow no further send requests from user
      Adjust sending window based on received window advertisement

   Event (3) - Retransmit Timer Expires
   =========
      If Piggyback Timer is set then
           cancel piggyback timer
      Re-transmit the segment (with ACK for receive-side)
      Restart the timer

   Event (4) - PO Service Profile Arrives at the User Interface
   =========
      Transition to the PO SETUP state
      Store the Send-side PO service profile
      Package the profile into 1 or more segments, setting the
           POC-Service-Profile option on each
      If Piggyback Timer is set then
           cancel piggyback timer
      Send the segment(s) (with ACK for receive-side)
      Store the segment(s) and start a retransmit timer

   Event (5) - ACK Arrival
   =========
      If ACKed object(s) is buffered then
           Release the buffer(s) and stop the retransmit timer(s)
      Extract the peer TCP's window advertisement
      If all objects from previous service profile have been ACKed and
      the new service profile has been ACKed then enable Event (7)





Connolly, Amer & Conrad                                        [Page 24]

RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   Event (6) - Retransmit Timer Expires
   =========
      If Piggyback Timer is set then
           cancel piggyback timer
      Re-transmit the segment (with ACK for receive-side)
      Restart the timer

   Event (7) - PO Setup Completed
   =========
      Transition to the ESTAB state and begin processing new service
      profile

4.2.2 Receiver

   The receiving TCP has additional decisions to make involving object
   deliverability, reliability and window management.  Additionally, the
   service profile must be established (and re-established) periodically
   and some special processing must be performed at the end of each
   period.

   When an object arrives, the question is no longer, "is this the next
   deliverable object?", but rather, "