rfc1693.txt

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

   network.

   As an indication of the potential for improved service, let us
   briefly look at the case where a database has the following 14
   records.






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


          SALESPERSON    LOCATION           CHARGES    DESCRIPTION
          -------------  -----------------  ---------  ---------------
       1  Anderson       Washington          $4,200    Camping Gear
       2  Anderson       Philadelphia        $2,000    Golf Equipment
       3  Anderson       Boston                $450    Bowling shoes
       4  Baker          Boston                $849    Sportswear
       5  Baker          Washington          $3,100    Weights
       6  Baker          Washington           $2000    Camping Gear
       7  Baker          Atlanta               $290    Baseball Gloves
       8  Baker          Boston              $1,500    Sportswear
       9  Crowell        Boston              $9,500    Camping Gear
      10  Crowell        Philadelphia        $6,000    Exercise Bikes
      11  Crowell        New York            $1,500    Sportswear
      12  Dykstra        Atlanta             $1,000    Sportswear
      13  Dykstra        Dallas             $15,000    Rodeo Gear
      14  Dykstra        Miami               $3,200    Golf Equipment

   Using formulas derived in [ACCD93a] one may calculate the total
   number of valid orderings for any partial order that can be
   represented in the notation mentioned previously.  For the case where
   a user specifies "ORDER BY SALESPERSON", the partial order above can
   be expressed as,

          (1||2||3);(4||5||6||7||8);(9||10||11);(12||13||14)

   Of the 14!=87,178,291,200 total possible combinations, there exist
   25,920 valid orderings at the destination.  A service that may
   deliver the records in any of these 25,920 orderings has a great deal
   more flexibility than in the ordered case where there is only 1 valid
   order for 14 objects.  It is interesting to consider the real
   possibility of hundreds or even thousands of objects and the
   potential savings in communication costs.

   In all cases, the underlying network is assumed to be unreliable and
   may thus introduce loss, duplication, and disorder.  It makes no
   sense to put a partial order service on top of a reliable network.
   While the exact amount of unreliability in a network may vary and is
   not always well understood, initial experimental research indicates
   that real world networks, for example the service provided by the
   Internet's IP level, "yield high losses, duplicates and reorderings
   of packets" [AS93,BCP93].  The authors plan to conduct further
   experimentation into measuring Internet network unreliability.  This
   information would say a great deal about the practical merit of a
   partial order service.







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


3. Reliability vs. Order

   While TCP avoids the loss of even a single object, in fact for many
   applications, there exists a genuine ability to tolerate loss.
   Losing one frame per second in a 30 frame per second video or losing
   a segment of its accompanying audio channel is usually not a problem.
   Bearing this in mind, it is of value to consider a quality of service
   that combines a partial order with a level of tolerated loss (partial
   reliability).  Traditionally there exist 4 services: reliable-
   ordered, reliable-unordered, unreliable-ordered, and unreliable-
   unordered. See Figure 5.  Reliable-ordered service (denoted by a
   single point) represents the case where all objects are delivered in
   the order transmitted.  File transfer is an example application
   requiring such a service.

                   reliable-ordered                  reliable-unordered
                      |                                 |
                      |                                 |
                      v                                 v
          zero loss-->*---------------------------------*
           min loss-->|<--                              |<--
                .     |                                 |
                .     |<--                              |<--
                      |                                 |
                      |<-- unreliable-                  |<-- unreliable-
     RELIABILITY      |      ordered                    |     unordered
                      |<--                              |<--
                      |                                 |
                      |<--                              |<--
           max loss-->|                                 |
                      +-+--+--+--+--+--+--+--+--+--+--+-+
                   ordered       partial ordered     unordered

                                   ORDER

         Figure 5: Quality Of Service: Reliability vs. Order -
                   Traditional Service Types

   In a reliable-unordered service (also a single point), all objects
   must be delivered, but not necessarily according to the order
   transmitted; in fact, any order will suffice.  Some transaction
   processing applications such as credit card verification require such
   a service.

   Unreliable-ordered service allows some objects to be lost.  Those
   that are delivered, however, must arrive in relative order (An
   "unreliable" service does not necessarily lose objects; rather, it
   may do so without failing to provide its advertised quality of



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


   service; e.g., the postal system provides an unreliable service).
   Since there are varying degrees of unreliability, this service is
   represented by a set of points in Figure 5.  An unreliable-ordered
   service is applicable to packet-voice or teleconferencing
   applications.

   Finally unreliable-unordered service allows objects to be lost and
   delivered in any order.  This is the kind of service used for normal
   e-mail (without acknowledgment receipts) and electronic announcements
   or junk e-mail.

   As mentioned previously, the concept of a partial order expands the
   order dimension from the two extremes of ordered and unordered to a
   range of discrete possibilities as depicted in Figure 6.
   Additionally, as will be discussed presently, the notion of
   reliability is extended to allow for varying degrees of reliability
   on a per-object basis providing even greater flexibility and improved
   resource utilization.

                                reliable-PO

                      |  |  |  |  |  |  |  |  |  |  |   |
                      |  |  |  |  |  |  |  |  |  |  |   |
                      v  v  v  v  v  v  v  v  v  v  v   v
          zero loss-->*---------------------------------*
           min loss-->| .  .  .  .  .  .  .  .  .  .  . |
                .     | .  .  .  .  .  .  .  .  .  .  . |
                .     | .  .  .  .  .  .  .  .  .  .  . |
                      | .  .  .                 .  .  . |
     RELIABILITY      | .  .  .  unreliable-PO  .  .  . |
                      | .  .  .  .  .  .  .  .  .  .  . |
                      | .  .  .  .  .  .  .  .  .  .  . |
                      | .  .  .  .  .  .  .  .  .  .  . |
                      | .  .  .  .  .  .  .  .  .  .  . |
           max loss-->| .  .  .  .  .  .  .  .  .  .  . |
                      +-+--+--+--+--+--+--+--+--+--+--+-+
                   ordered       partial ordered     unordered

                                   ORDER

         Figure 6: Quality Of Service: Reliability vs. Order - Partial
                   Order Service

3.1 Reliability Classes

   When considering unreliable service, one cannot assume that all
   objects are equal with regards to their reliability.  This
   classification is reasonable if all objects are identical (e.g.,



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


   video frames in a 30 frame/second film).  Many applications, such as
   multimedia systems, however, often contain a variety of object types.
   Thus three object reliability classes are proposed: BART-NL, BART-L,
   and NBART-L.  Objects are assigned to one of these classes depending
   on their temporal value as will be show presently.

   BART-NL objects must be delivered to the destination.  These objects
   have temporal value that lasts for an entire established connection
   and require reliable delivery (NL =  No Loss allowed).  An example of
   BART-NL objects would be the database records in Example 2.1 or the
   windows in the screen refresh in Example 2.3.  If all objects are of
   type BART-NL, the service is reliable.  One possible way to assure
   eventual delivery of a BART-NL object in a protocol is for the sender
   to buffer it, start a timeout timer, and retransmit it if no ACK
   arrives before the timeout.  The receiver in turn returns an ACK when
   the object has safely arrived and been delivered (BART = Buffers,
   ACKs, Retransmissions, Timers).

   BART-L objects are those that have temporal value over some
   intermediate amount of time - enough to permit timeout and
   retransmission, but not everlasting.  Once the temporal value of
   these objects has expired, it is better to presume them lost than to
   delay further the delivery pipeline of information.  One possibility
   for deciding when an object's usefulness has expired is to require
   each object to contain information defining its precise temporal
   value [DS93].  An example of a BART-L object would be a movie
   subtitle, sent in parallel with associated film images, which is
   valuable any time during a twenty second film sequence.  If not
   delivered sometime during the first ten seconds, the subtitle loses
   its value and can be presumed lost.  These objects are buffered-
   ACKed-retransmitted up to a certain point in time and then presumed
   lost.

   NBART-L objects are those with temporal values too short to bother
   timing out and retransmitting.  An example of a NBART-L object would
   be a single packet of speech in a packetized phone conversation or
   one image in a 30 image/sec film.  A sender transmits these objects
   once and the service makes a best effort to deliver them.  If the one
   attempt is unsuccessful, no further attempts are made.

   An obvious question comes to mind - what about NBART-NL objects?  Do
   such objects exist?  The authors have considered the notion of
   communicating an object without the use of BART and still being able
   to provide a service without loss.  Perhaps with the use of forward
   error correction this may become a viable alternative and could
   certainly be included in the protocol.  However, for our purposes in
   this document, only the first three classifications will be
   considered.



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


   While classic transport protocols generally treat all objects
   equally, the sending and receiving functions of a protocol providing
   partial order/partial reliability service will behave differently for
   each class of object.  For example, a sender buffers and, if
   necessary, retransmits any BART-NL or BART-L objects that are not
   acknowledged within a predefined timeout period.  On the contrary,
   NBART-L objects are forgotten as soon as they are transmitted.

4. Partial Order Connection

   The implementation of a protocol that provides partial order service
   requires, at a minimum, (1) communication of the partial ordering
   between the two endpoints, and (2) dynamic evaluation of the
   deliverability of objects as they arrive at the receiver.  In
   addition, this RFC describes the mechanisms needed to (3) initiate a
   connection, (4) provide varying degrees of reliability for the
   objects being transmitted, and (5) improve buffer utilization at the
   sender based on object reliability.

   Throughout the discussion of these issues, the authors use the
   generic notion of "objects" in describing the service details.  Thus,
   one of the underlying requirements of a partial order service is the
   ability to handle such an abstraction (e.g., recognize object
   boundaries).  The details of object management are implementation
   dependent and thus are not specified in this RFC.  However, as this
   represents a potential fundamental change to the TCP protocol, some
   discussion is in order.

   At one extreme, it is possible to consider octets as objects and
   require that the application specify the partial order accordingly
   (octet by octet).  This likely would entail an inordinate amount of
   overhead, processing each octet on an individual basis (literally
   breaking up contiguous segments to determine which, if any, octets
   are deliverable and which are not).  At the other extreme, the
   transport protocol could maintain object atomicity regardless of size