rfc1693.txt

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

   - passing arbitrarily large data structures to IP for transmission.
   At the sending side of the connection this would actually work since
   IP is prepared to perform source fragmentation, however, there is no
   guarantee that the receiving IP will be able to reassemble the
   fragments!  IP relies on the TCP max segment size to prevent this
   situation from occurring[LMKQ89].

   A more realistic approach given the existing IP constraints might be
   to maintain the current notion of a TCP max segment size for the
   lower-layer interface with IP while allowing a much larger object
   size at the upper-layer interface.  Of course this presents some
   additional complexities.  First of all, the transport layer will now
   have to be concerned with fragmentation/reassembly of objects larger



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


   than the max segment size and secondly, the increased object sizes
   will require significantly more buffer space at the receiver if we
   want to buffer the object until it arrives in entirety.
   Alternatively, one may consider delivering "fragments" of an object
   as they arrive as long as the ordering of the fragments is correct
   and the application is able to process the fragments (this notion of
   fragmented delivery is discussed further in Section 6).

4.1 Connection Establishment

   By extending the transport paradigm to allow partial ordering and
   reliability classes, a user application may be able to take advantage
   of a more efficient data transport facility by negotiating the
   optimal service level which is required - no more, no less.  This is
   accomplished by specifying these variables as QOS parameters or, in
   TCP terminology, as options to be included in the TCP header [Pos81].

   A TCP implementation that provides a partial order service requires
   the use of two new TCP options.  The first is an enabling option
   "POC-permitted" (Partial Order Connection Permitted) that may be used
   in a SYN segment to request a partial order service.  The other is
   the "POC-service-profile" option which is used periodically to
   communicate the service characteristics.  This second option may be
   sent only after successful transmission and acknowledgment of the
   POC-permitted option.

   A user process issuing either an active or passive OPEN may choose to
   include the POC-permitted option if the application can benefit from
   the use of a partial order service and in fact, in cases where the
   viability of such service is unknown, it is suggested that the option
   be used and that the decision be left to the user's peer.

   For example, a multimedia server might issue a passive <SYN> with the
   POC-permitted option in preparation for the connection by a remote
   user.

   Upon reception of a <SYN> segment with the POC-permitted option, the
   receiving user has the option to respond with a similar POC-permitted
   indication or may reject a partial order connection if the
   application does not warrant the service or the receiving user is
   simply unable to provide such a service (e.g., does not recognize the
   POC-permitted option).

   In the event that simultaneous initial <SYN> segments are exchanged,
   the TCP will initiate a partial order connection only if both sides
   include the POC-permitted option.





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


   A brief example should help to demonstrate this procedure.  The
   following notation (a slight simplification on that employed in RFC
   793) will be used.  Each line is numbered for reference purposes.
   TCP-A (on the left) will play the role of the receiver and TCP-B will
   be the sender.  Right arrows  (-->) indicate departure of a TCP
   segment from TCP-A to TCP-B, or arrival of a segment at B from A.
   Left arrows indicate the reverse.  TCP states represent the state
   AFTER the departure or arrival of the segment (whose contents are
   shown in the center of the line).  Liberties are taken with the
   contents of the segments where only the fields of interest are shown.

         TCP-A                                              TCP-B

      1. CLOSED                                             LISTEN

      2. SYN-SENT    --> <CTL=SYN><POC-perm>            --> SYN-RECEIVED

      3. ESTABLISHED <-- <CTL=SYN,ACK><POC-perm>        <-- SYN-RECEIVED

      4. ESTABLISHED --> <CTL=ACK>                      --> ESTABLISHED

        Figure 7. Basic 3-Way handshake for a partial order connection

   In line 1 of Figure 7, the sending user has already issued a passive
   OPEN with the POC-permitted option and is waiting for a connection.
   In line 2, the receiving user issues an active OPEN with the same
   option which in turn prompts TCP-A to send a SYN segment with the
   POC-permitted option and enter the SYN-SENT state.  TCP-B is able to
   confirm the use of a PO connection and does so in line 3, after which
   TCP-A enters the established state and completes the connection with
   an ACK segment in line 4.

   In the event that either side is unable to provide partial order
   service, the POC-permitted option will be omitted and normal TCP
   processing will ensue.

   For completeness, the authors include the following specification for
   both the POC-permitted option and the POC-service-profile option in a
   format consistent with the TCP specification document [Pos81].

      TCP POC-permitted Option:

         Kind: 9  Length: - 2 bytes

             +-----------+-------------+
             |  Kind=9   |  Length=2   |
             +-----------+-------------+




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


      TCP POC-service-profile Option:

         Kind: 10  Length: 3 bytes

                                       1 bit        1 bit    6 bits
             +----------+----------+------------+----------+--------+
             |  Kind=10 | Length=3 | Start_flag | End_flag | Filler |
             +----------+----------+------------+----------+--------+

   The first option represents a simple indicator communicated between
   the two peer transport entities and needs no further explanation.
   The second option serves to communicate the information necessary to
   carry out the job of the protocol - the type of information which is
   typically found in the header of a TCP segment - and raises some
   interesting questions.

   Standard TCP maintains a 60-byte maximum header size on all segments.
   The obvious intuition behind this rule is that one would like to
   minimize the amount of overhead information present in each packet
   while simultaneously increasing the payload, or data, section.  While
   this is acceptable for most TCP connections today, a partial-order
   service would necessarily require that significantly more control
   information be passed between transport entities at certain points
   during a connection.  Maintaining the strict interpretation of this
   rule would prove to be inefficient.  If, for example, the service
   profile occupied a total of 400 bytes (a modest amount as will be
   confirmed in the next section), then one would have to fragment this
   information across at least 10 segments, allocating 20 bytes per
   segment for the normal TCP header.

   Instead, the authors propose that the service profile be carried in
   the data section of the segment and that the 3-byte POC-service-
   profile option described above be placed in the header to indicate
   the presence of this information.  Upon reception of such a segment,
   the TCP extracts the service profile and uses it appropriately as
   will be discussed in the following sections.

   The option itself, as shown here, contains two 1-bit flags necessary
   to handle the case where the service profile does not fit in a single
   TCP segment.  The "Start_flag" indicates that the information in the
   data section represents the beginning of the service profile and the
   "End_flag" represents the converse.  For service profiles which fit
   completely in a single segment, both flags will be set to 1.
   Otherwise, the Start_flag is set in the initial segment and the
   End_flag in the final segment allowing the peer entity to reconstrcut
   the entire service profile (using the normal sequence numbers in the
   segment header).  The "Filler" field serves merely to complete the
   third byte of the option.



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


   Note that the length of the service profile may vary during the
   connection as the order or reliability requirements of the user
   change but this length must not exceed the buffering ability of the
   peer TCP entity since the entire profile must be stored.  The exact
   makeup of this data structure is presented in Section 4.2.

4.2 Data Transmission

   Examining the characteristics of a partial order TCP in chronological
   fashion, one would start off with the establishment of a connection
   as described in Section 4.1.  After which, although both ends have
   acknowledged the acceptability of partial order transport, neither
   has actually begun a partial order transmission - in other words,
   both the sending-side and the receiving-side are operating in a
   normal, ordered-reliable mode.  For the subsequent discussion, an
   important distinction is made in the terms sending-side and
   receiving-side which refer to the data flow from the sender and that
   from the receiver, respectively.

   For the partial ordering to commence, the TCP must be made aware of
   the acceptable object orderings and reliability for both the send-
   side and receive-side of the connection for a given set of objects
   (hereafter referred to as a "period").  This information is contained
   in the service profile and it is the responsibility of the user
   application to define this profile.  Unlike standard TCP where
   applications implicitly define a reliable, ordered profile; with
   partial order TCP, the application must explicity define a profile.

   The representation of the service profile is one of the concerns for
   the transport protocol.  It would be useful if the TCP could encode a
   partial ordering in as few bits as possible since these bits will be
   transmitted to the destination each time the partial order changes.
   A matrix representation appears to be well-suited to encoding the
   partial order and a vector has been proposed to communicate and
   manage the reliability aspects of the service.  Temporal values may
   be included within the objects themselves or may be defined as a
   function of the state of the connection [DS93].  Using these data
   structures, the complete service profile would include (1) a partial
   order matrix, (2) a reliability vector and (3) an object_sizes vector
   which represents the size of the objects in octets (see
   [ACCD93a,CAC93] for a discussion on alternative structures for these
   variables).

   Throughout this section, we use the following service profile as a
   running example.  Shown here is a partial order matrix and graphical
   representation for a simple partial order with 6 objects -
   ((1;2)||(3;4)||5);6.  In the graphical diagram, arrows (-->) denote
   sequential order and objects in parallel can be delivered in either



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


   order.  So in this example, object 2 must be delivered after object
   1, object 4 must be delivered after object 3, and object 6 must be
   delivered after objects 1 through 5 have all been delivered.  Among
   the 6 objects, there are 30 valid orderings for this partial order
   (each valid ordering is known as a linear extension of the partial
   order).

                1 2 3 4 5 6
              +-------------+
            1 | - 1 0 0 0 1 |         |               |       |
            2 | - - 0 0 0 1 |         |-->1-->|-->2-->|       |
            3 | - - - 1 0 1 |         |               |       |
            4 | - - - - 0 1 |         |-->3-->|-->4-->|-->6-->|
            5 | - - - - - 1 |         |               |       |
            6 | - - - - - - |         |------>5------>|       |
              +-------------+         |               |       |

                 PO Matrix                 PO Graph


   In the matrix, a 1 in row i of column j denotes that object i must be
   delivered before object j.  Note that if objects are numbered in any
   way such that 1,2,3,...,N is a valid ordering, only the upper right
   triangle of the transitively closed matrix is needed [ACCD93a].
   Thus, for N objects, the partial order can be encoded in (N*(N-1)/2)
   bits.

   The reliability vector for the case where reliability classes are
   enumerated types such as {BART-NL=1, BART-L=2, NBART-L = 3} and all
   objects are BART-NL would simply be, <1, 1, 1, 1, 1, 1>.  Together