RFC 1693 An Extension to TCP : Partial Order Service

[Docs] [txt|pdf] [Tracker]

Obsoleted by: 6247 HISTORIC

Network Working Group                                       T.  Connolly
Request for Comments: 1693                                       P. Amer
Category: Experimental                                         P. Conrad
                                                  University of Delaware
                                                           November 1994


              An Extension to TCP : Partial Order Service

Status of This Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited

IESG Note:

   Note that the work contained in this memo does not describe an
   Internet standard.  The Transport AD and Transport Directorate do not
   recommend the implementation of the TCP modifications described.
   However, outside the context of TCP, we find that the memo offers a
   useful analysis of how misordered and incomplete data may be handled.
   See, for example, the discussion of Application Layer Framing by D.
   Clark and D. Tennenhouse in, "Architectural Considerations for a New
   Generation of Protocols", SIGCOM 90 Proceedings, ACM, September 1990.

Abstract

   This RFC introduces a new transport mechanism for TCP based upon
   partial ordering.  The aim is to present the concepts of partial
   ordering and promote discussions on its usefulness in network
   communications.  Distribution of this memo is unlimited.

Introduction

   A service which allows partial order delivery and partial reliability
   is one which requires some, but not all objects to be received in the
   order transmitted while also allowing objects to be transmitted
   unreliably (i.e., some may be lost).

   The realization of such a service requires, (1) communication and/or
   negotiation of what constitutes a valid ordering and/or loss-level,
   and (2) an algorithm which enables the receiver to ascertain the
   deliverability of objects as they arrive.  These issues are addressed
   here - both conceptually and formally - summarizing the results of
   research and initial implementation efforts.




Connolly, Amer & Conrad                                         [Page 1]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   The authors envision the use of a partial order service within a
   connection-oriented, transport protocol such as TCP providing a
   further level of granularity to the transport user in terms of the
   type and quality of offered service.  This RFC focuses specifically
   on extending TCP to provide partial order connections.

   The idea of a partial order service is not limited to TCP. It may be
   considered a useful option for any transport protocol and we
   encourage researchers and practitioners to investigate further the
   most effective uses for partial ordering whether in a next-generation
   TCP, or another general purpose protocol such as XTP, or perhaps
   within a "special purpose" protocol tailored to a specific
   application and network profile.

   Finally, while the crux of this RFC relates to and introduces a new
   way of considering object ordering, a number of other classic
   transport mechanisms are also seen in a new light - among these are
   reliability, window management and data acknowledgments.

   Keywords: partial order, quality of service, reliability, multimedia,
   client/server database, Windows, transport protocol

Table of Contents

   1. Introduction and motivation ..................................  3
   2. Partial Order Delivery .......................................  4
   2.1 Example 1: Remote Database ..................................  4
   2.2 Example 2: Multimedia .......................................  8
   2.3 Example 3: Windows Screen Refresh ...........................  9
   2.4 Potential Savings ........................................... 10
   3. Reliability vs. Order ........................................ 12
   3.1 Reliability Classes ......................................... 13
   4. Partial Order Connection ..................................... 15
   4.1 Connection Establishment .................................... 16
   4.2 Data Transmission ........................................... 19
   4.2.1 Sender .................................................... 22
   4.2.2 Receiver .................................................. 25
   5. Quantifying and Comparing Partial Order Services ............. 30
   6. Future Direction ............................................. 31
   7. Summary ...................................................... 32
   8. References ................................................... 34
   Security Considerations ......................................... 35
   Authors' Addresses .............................................. 36








Connolly, Amer & Conrad                                         [Page 2]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


1. Introduction and motivation

   Current applications that need to communicate objects (i.e., octets,
   packets, frames, protocol data units) usually choose between a fully
   ordered service such as that currently provided by TCP and one that
   does not guarantee any ordering such as that provided by UDP.  A
   similar "all-or-nothing" choice is made for object reliability -
   reliable connections which guarantee all objects will be delivered
   verses unreliable data transport which makes no guarantee.  What is
   more appropriate for some applications is a partial order and/or
   partial reliability service where a subset of objects being
   communicated must arrive in the order transmitted, yet some objects
   may arrive in a different order, and some (well specified subset) of
   the objects may not arrive at all.

   One motivating application for a partial order service is the
   emerging area of multimedia communications.  Multimedia traffic is
   often characterized either by periodic, synchronized parallel streams
   of information (e.g., combined audio-video), or by structured image
   streams (e.g., displays of multiple overlapping and nonoverlapping
   windows).  These applications have a high degree of tolerance for
   less-than-fully-ordered data transport as well as data loss.  Thus
   they are ideal candidates for using a partial order, partial
   reliability service.  In general, any application which communicates
   parallel and/or independent data structures may potentially be able
   to profit from a partial order service.

   A second application that could benefit from a partial order service
   involves remote or distributed databases.  Imagine the case where a
   database user transmitting queries to a remote server expects objects
   (or records) to be returned in some order, although not necessarily
   total order.  For example a user writing an SQL data query might
   specify this with the "order by" clause.  There exist today a great
   number of commercial implementations of distributed databases which
   utilize - and thus are penalized by - an ordered delivery service.

   Currently these applications must use and pay for a fully
   ordered/fully reliable service even though they do not need it.  The
   introduction of partial services allows applications to lower the
   demanded quality of service (QOS) of the communication assuming that
   such a service is more efficient and less costly.  In effect, a
   partial order extends the service level from two extremes - ordered
   and unordered - to a range of discreet values encompassing both of
   the extremes and all possible partial orderings in between.  A
   similar phenomenon is demonstrated in the area of reliability.






Connolly, Amer & Conrad                                         [Page 3]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   It is worth mentioning that a TCP implementation providing a partial
   order service, as described here, would be able to communicate with a
   non-partial order implementation simply by recognizing this fact at
   connection establishment - hence this extension is backward
   compatible with earlier versions of TCP.  Furthermore, it is
   conceivable for a host to support the sending-half (or receiving-
   half) of a partial order connection alone to reduce the size of the
   TCP as well as the effort involved in the implementation.  Similar
   "levels of conformance" have been proposed in other internet
   extensions such as [Dee89] involving IP multicasting.

   This RFC proceeds as follows.  The principles of partial order
   delivery, published in [ACCD93a], are presented in Section 2.  The
   notion of partial reliability, published in [ACCD93b], is introduced
   in Section 3 followed by an explanation of "reliability classes".
   Then, the practical issues involved with setting up and maintaining a
   Partial Order Connection (POC) within a TCP framework are addressed
   in Section 4 looking first at connection establishment, and then
   discussing the sender's role and the receiver's role.  Section 5
   provides insights into the expected performance improvements of a
   partial order service over an ordered service and Section 6 discusses
   some future directions.  Concluding remarks are given in Section 7.

2. Partial Order Delivery

   Partial order services are needed and can be employed as soon as a
   complete ordering is not mandatory.  When two objects can be
   delivered in either order, there is no need to use an ordered service
   that must delay delivery of the second one transmitted until the
   first arrives as the following examples demonstrate.

2.1 Example 1: Remote Database

   Simpson's Sporting Goods (SSG) has recently installed a state-of-
   the-art enterprise-wide network.  Their first "network application"
   is a client/server SQL database with the following four records,
   numbered {1 2 3 4} for convenience:

         SALESPERSON    LOCATION           CHARGES    DESCRIPTION
         -------------  -----------------  ---------  -----------------
      1  Anderson       Atlanta, GA        $4,200     Camping Gear
      2  Baker          Boston, MA           $849     Camping Gear
      3  Crowell        Boston, MA         $9,500     Sportswear
      4  Dykstra        Wash., DC          $1,000     Sportswear

   SSG employees running the client-side of the application can query
   the database server from any location in the enterprise net using
   standard SQL commands and the results will be displayed on their



Connolly, Amer & Conrad                                         [Page 4]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   screen.  From the employee's perspective, the network is completely
   reliable and delivers data (records) in an order that conforms to
   their SQL request.  In reality though, it is the transport layer
   protocol which provides the reliability and order on top of an
   unreliable network layer - one which introduces loss, duplication,
   and disorder.

   Consider the four cases in Figure 1 - in the first query (1.a),
   ordered by SALESPERSON, the records have only one acceptable order at
   the destination, 1,2,3,4.  This is evident due to the fact that there
   are four distinct salespersons.  If record 2 is received before
   record 1 due to a network loss during transmission, the transport
   service can not deliver it and must therefore buffer it until record
   1 arrives.  An ordered service, also referred to as a virtual circuit
   or FIFO channel, provides the desired level of service in this case.

   At the other extreme, an unordered service is motivated in Figure 1.d
   where the employee has implicitly specified that any ordering is
   valid simply by omitting the "order by" clause.  Here any of 4! = 24
   delivery orderings would satisfy the application, or from the
   transport layer's point of view, all records are immediately
   deliverable as soon as they arrive from the network.  No record needs
   to buffered should it arrive out of sequential order.  As notation, 4
   ordered objects are written 1;2;3;4 and 4 unordered objects are
   written using a parallel operator: 1||2||3||4.

   Figures 1.b and 1.c demonstrate two possible partial orders that
   permit 2 and 4 orderings respectively at the destination.  Using the
   notation just described, the valid orderings for the query in 1.b are
   specified as 1;(2||3);4, which is to say that record 1 must be
   delivered first followed by record 2 and 3 in either order followed
   by record 4.  Likewise, the ordering for 1.c is (1||2);(3||4).  In
   these two cases, an ordered service is too strict and an unordered
   service is not strict enough.

















Connolly, Amer & Conrad                                         [Page 5]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   +-----------------------------------------------------------------+
   |    SELECT SALESPERSON, LOCATION, CHARGES, DESCRIPTION           |
   |    FROM BILLING_TABLE                                           |
   |                                                                 |
   |    SALESPERSON    LOCATION           CHARGES    DESCRIPTION     |
   |    -------------  -----------------  ---------  --------------- |
   | 1  Anderson       Atlanta, GA        $4,200     Camping Gear    |
   | 2  Baker          Boston, MA           $849     Camping Gear    |
   | 3  Crowell        Boston, MA         $9,500     Sportswear      |
   | 4  Dykstra        Wash., DC          $1,000     Sportswear      |
   +=================================================================+
   |a -  ORDER BY SALESPERSON                                        |
   |                                                                 |
   |  1,2,3,4                                          1,2,3,4       |
   |                                                                 |
   | Sender ----------->   NETWORK   -------------->   Receiver      |
   |                                              (1 valid ordering) |
   +-----------------------------------------------------------------+
   |b -  ORDER BY LOCATION                                           |
   |                                                   1,2,3,4       |
   |  1,2,3,4                                          1,3,2,4       |
   |                                                                 |
   | Sender ----------->   NETWORK   -------------->   Receiver      |
   |                                             (2 valid orderings) |
   +-----------------------------------------------------------------+
   |c -  ORDER BY DESCRIPTION                                        |
   |                                                   1,2,3,4       |
   |                                                   2,1,3,4       |
   | 1,2,3,4                                           1,2,4,3       |
   |                                                   2,1,4,3       |
   |                                                                 |
   | Sender ----------->   NETWORK   -------------->   Receiver      |
   |                                             (4 valid orderings) |
   +-----------------------------------------------------------------+
   |d - (no order by clause)                                         |
   |                                                   1,2,3,4       |
   |                                                   1,2,4,3       |
   | 1,2,3,4                                             ...         |
   |                                                   4,3,2,1       |
   |                                                                 |
   | Sender ----------->   NETWORK   -------------->   Receiver      |
   |                                         (4!=24 valid orderings) |
   +-----------------------------------------------------------------+
      Figure 1: Ordered vs. Partial Ordered vs. Unordered Delivery

   It is vital for the transport layer to recognize the exact
   requirements of the application and to ensure that these are met.
   However, there is no inherent need to exceed these requirements; on



Connolly, Amer & Conrad                                         [Page 6]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   the contrary, by exceeding these requirements unecessary resources
   are consumed.  This example application requires a reliable
   connection - all records must eventually be delivered - but has some
   flexibility when it comes to record ordering.

   In this example, each query has a different partial order.  In total,
   there exist 16 different partial orders for the desired 4 records.
   For an arbitrary number of objects N, there exist many possible
   partial orders each of which accepts some number of valid orderings
   between 1 and N!  (which correspond to the ordered and unordered
   cases respectively).  For some classes of partial orders, the number
   of valid orderings can be calculated easily, for others this
   calculation is intractable.  An in-depth discussion on calculating
   and comparing the number of orderings for a given partial order can
   be found in [ACCD93a].




































Connolly, Amer & Conrad                                         [Page 7]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


2.2 Example 2: Multimedia

   A second example application that motivates a partial order service
   is a multimedia broadcast involving video, audio and text components.
   Consider an extended presentation of the evening news - extended to
   include two distinct audio channels, a text subtitle and a closed-
   captioned sign language video for the hearing impaired, in addition
   to the normal video signal, as modeled by the following diagram.

            (left audio)                     (right audio)
              +------+                         +------+
              | ++++ |                         | ++++ |
              | ++++ |                         | ++++ |
              +------+                         +------+
         ===================================================
         I                                +---------------+I
         I                                |               |I
         I                                |  (hand signs) |I
         I                                |               |I
         I                                +---------------+I
         I                                                 I
         I                                                 I
         I          (Main Video)                           I
         I                                                 I
         I                                                 I
         I                                                 I
         I                                                 I
         I  +------------------------------------------+   I
         I  |     (text subtitle)                      |   I
         I  +------------------------------------------+   I
         I                                                 I
         ===================================================
            Figure 2: Multimedia broadcast example

  The multimedia signals have differing characteristics.  The main video
  signal may consist of full image graphics at a rate of 30 images/sec
  while the video of hand signs requires a lower quality, say 10
  images/sec.  Assume the audio signals are each divided into 60 sound
  fragments/sec and the text object each second consists of either (1)
  new text, (2) a command to keep the previous second of text, or (3) a
  command for no subtitle.

  During a one-second interval of the broadcast, a sender transmits 30
  full-motion video images, 10 closed-captioned hand sign images, 60
  packets of a digitized audio signal for each of the audio streams and
  a single text packet.  The following diagram then might represent the
  characteristics of the multimedia presentation in terms of the media
  types, the number of each, and their ordering.  Objects connected by a



Connolly, Amer & Conrad                                         [Page 8]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


  horizontal line must be received in order, while those in parallel
  have no inherent ordering requirement.

+----------------------------------------------------------------------+
|                                                                      |
|  |-o-|-o-|-o-|-o-|-o-|-o-|-o-|-o-|-o-...-o-|-o-|-o-|  right audio    |
|  |   |   |   |   |   |   |   |   |         |   |   |  (60/sec)       |
|  |   |   |   |   |   |   |   |   |         |   |   |                 |
|  |-o-|-o-|-o-|-o-|-o-|-o-|-o-|-o-|-o-...-o-|-o-|-o-|  left audio     |
|  |       |       |       |       |         |       |  (60/sec)       |
|  |       |       |       |       |         |       |                 |
|  |---o---|---o---|---o---|---o---|---...---|---o---|  normal video   |
|  |                       |                         |  (30/sec)       |
|  |                       |                         |                 |
|  |-----------o-----------|--------o--...--------o--|  hand signs     |
|  |                                                 |  (10/sec)       |
|  |                                                 |                 |
|  |-----------------------------o-----...-----------|  text           |
|  |                                                 |  (1/sec)        |
|                                                                      |
+----------------------------------------------------------------------+
          Figure 3: Object ordering in multimedia application

   Of particular interest to our discussion of partial ordering is the
   fact that, while objects of a given media type generally must be
   received in order, there exists flexibility between the separate
   "streams" of multimedia data (where a "stream" represents the
   sequence of objects for a specific media type).  Another significant
   characteristic of this example is the repeating nature of the object
   orderings.  Figure 3 represents a single, one-second, partial order
   snapshot in a stream of possibly thousands of repeating sequential
   periods of communication.

   It is assumed that further synchronization concerns in presenting the
   objects are addressed by a service provided on top of the proposed
   partial order service.  Temporal ordering for synchronized playback
   is considered, for example, in [AH91, HKN91].

2.3 Example 3: Windows Screen Refresh

   A third example to motivate a partial order service involves
   refreshing a workstation screen/display containing multiple windows
   from a remote source.  In this case, objects (icons, still or video
   images) that do not overlap have a "parallel" relationship (i.e.,
   their order of refreshing is independent) while overlapping screen
   objects have a "sequential" relationship and should be delivered in
   order.  Therefore, the way in which the windows overlap induces a
   partial order.



Connolly, Amer & Conrad                                         [Page 9]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   Consider the two cases in Figure 4.  A sender wishes to refresh a
   remote display that contains four active windows (objects) named {1 2
   3 4}.  Assume the windows are transmitted in numerical order and the
   receiving application refreshes windows as soon as the transport
   service delivers them.  If the windows are configured as in Figure
   4a, then there exist two different orderings for redisplay, namely
   1,2,3,4 or 1,3,2,4.  If window 2 is received before window 1, the
   transport service cannot deliver it or an incorrect image will be
   displayed.  In Figure 4b, the structure of the windows results in six
   possible orderings - 1,2,3,4 or 1,3,2,4 or 1,3,4,2 or 3,4,1,2 or
   3,1,4,2 or 3,1,2,4.

       +================================+============================+
       |a       +-----------+           |b   +----------+            |
       |        | 1         |           |    | 1        |            |
       |        |           |           |    |     +----------+      |
       |  +---------+    +----------+   |    +-----| 2        |      |
       |  | 2       |----| 3        |   |          |          |      |
       |  |     +-----------+       |   |          +----------+      |
       |  |     | 4         |       |   |    +----------+            |
       |  +-----|           |-------+   |    | 3        |            |
       |        |           |           |    |      +----------+     |
       |        +-----------+           |    +------| 4        |     |
       |                                |           |          |     |
       |                                |           +----------+     |
       |                                |                            |
       |        1;(2||3);4              |       (1;2)||(3;4)         |
       +================================+============================+
                     Figure 4: Window screen refresh

2.4 Potential Savings

   In each of these examples, the valid orderings are strictly dependent
   upon, and must be specified by the application.  Intuitively, as the
   number of acceptable orderings increases, the amount of resources
   utilized by a partial order transport service, in terms of buffers
   and retransmissions, should decrease as compared to a fully ordered
   transport service thus also decreasing the overall cost of the
   connection.  Just how much lower will depend largely upon the
   flexibility of the application and the quality of the underlying
   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
   - 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
   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, "is this ONE OF the next
   deliverable objects?"  Hence, it is convenient to think of a
   "Deliverable Set" of objects with a partial order protocol.  To
   determine the elements of this set and answer the question of
   deliverability, the receiver relies upon the partial order matrix
   but, unlike the sender, the receiver dynamically updates the matrix
   as objects are processed thus making other objects (possibly already
   buffered objects) deliverable as well.  A check of the object type
   also must be performed since BART-NL and BART-L objects require an
   ACK to be returned to the sender but NBART-L do not.  Consider our
   example from the previous section.

                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

   When object 5 arrives, the receiver scans column 5, finds that the
   object is deliverable (since there are no 1's in the column) and
   immediately delivers the object to the user application. Then, the



Connolly, Amer & Conrad                                        [Page 25]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   matrix is updated to remove the constraint of any object whose
   delivery depends on object 5 by clearing all entries of row 5.  This
   may enable other objects to be delivered (for example, if object 2 is
   buffered then the delivery of object 1 will make object 2
   deliverable).  This leads us to the next issue - delivery of stored
   objects.

   In general, whenever an object is delivered, the buffers must be
   examined to see if any other stored object(s) becomes deliverable.
   CAC93 describes an efficient algorithm to implement this processing
   based on traversing the precedence graph.

   Consideration of object reliability is interesting.  The authors have
   taken a polling approach wherein a procedure is executed
   periodically, say once every 100 milliseconds, to evaluate the
   temporal value of outstanding objects on which the destination is
   waiting.  Those whose temporal value has expired (i.e. which are no
   longer useful as defined by the application) are "declared lost" and
   treated in much the same manner as delivered objects - the matrix is
   updated, and if the object type is BART-L, an ACK is sent.  Any
   objects from the current period which have not yet been delivered or
   declared lost are candidates for the "Terminator" as the procedure is
   called.  The Terminator's criterion is not specifically addressed in
   this RFC, but one example might be for the receiving user to
   periodically pass a list of no-longer-useful objects to TCP-B.

   Another question which arises is, "How does one calculate the send
   and receive windows?"  With a partial order service, these windows
   are no longer contiguous intervals of objects but rather sets of
   objects.  In fact, there are three sets which are of interest to the
   receiving TCP one of which has already been mentioned - the
   Deliverable Set.  Additionally, we can think of the Bufferable Set
   and the Receivable Set.  Some definitions are in order:

      Deliverable Set: objects which can be immediately passed up to
           the user.

      Buffered Set: objects stored in a buffer awaiting delivery.

      Bufferable Set: objects which can be stored but not immediately
           delivered (due to some ordering constraint).

      Receivable Set: union of the Deliverable Set and the Bufferable
           Set (which are disjoint) - intuitively, all objects which
           are "receivable" must be either "deliverable" or
           "bufferable".





Connolly, Amer & Conrad                                        [Page 26]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   The following example will help to illustrate these sets.  Consider
   our simple service profile from earlier for the case where the size
   of each object is 1 MByte and the receiver has only 2 MBytes of
   buffer space (enough for 2 objects).  Define a boolean vector of
   length N (N = number of objects in a period) called the Processed
   Vector which is used to indicate which objects from the current
   period have been delivered or declared lost.  Initially, all buffers
   are empty and the PO Matrix and Processed Vector are as shown here,

                1 2 3 4 5 6
              +-------------+
            1 | - 1 0 0 0 1 |
            2 | - - 0 0 0 1 |
            3 | - - - 1 0 1 |
            4 | - - - - 0 1 |
            5 | - - - - - 1 |      [ F F F F F F ]
            6 | - - - - - - |        1 2 3 4 5 6
              +-------------+

                 PO Matrix        Processed Vector

   From the PO Matrix, it is clear that the Deliverable Set =
   {(1,1),(1,3),(1,5)}, where (1,1) refers to object #1 from period #1,
   asssuming that the current period is period #1.

   The Bufferable Set, however, depends upon how one defines bufferable
   objects.  Several approaches are possible.  The authors' initial
   approach to determining the Bufferable Set can best be explained in
   terms of the following rules,

      Rule 1: Remaining space must be allocated for all objects from
              period i before any object from period i+1 is buffered

      Rule 2: In the event that there exists enough space to buffer
              some but not all objects from a given period, space will
              be reserved for the first objects (i.e. 1,2,3,...,k)

   With these rules, the Bufferable Set = {(1,2),(1,4)}, the Buffered
   Set is trivially equal to the empty set, { }, and the Receivable Set
   = {(1,1),(1,2),(1,3),(1,4),(1,5)}.

   Note that the current acknowledgment scheme uses the min and max
   values in the Receivable Set for its window advertisement which is
   transmitted in all ACK segments sent along the receive-side of the
   connection (from receiver to sender).  Moreover, the
   "piggyback_delay" timer is still used to couple ACKs with return data
   (as utilized in standard TCP).




Connolly, Amer & Conrad                                        [Page 27]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   Returning to our example, let us now assume that object 1 and then 3
   arrive at the receiver and object 2 is lost.  After processing both
   objects, the PO Matrix and Processed Vector will have the following
   updated structure,

                1 2 3 4 5 6
              +-------------+
            1 | - 0 0 0 0 0 |
            2 | - - 0 0 0 1 |
            3 | - - - 0 0 0 |
            4 | - - - - 0 1 |
            5 | - - - - - 1 |      [ T F T F F F ]
            6 | - - - - - - |        1 2 3 4 5 6
              +-------------+

                 PO Matrix        Processed Vector

   We can see that the Deliverable Set = {(1,2),(1,4),(1,5)}, but what
   should the Bufferable Set consist of?  Since only one buffer is
   required for the current period's objects, we have 1 Mbyte of
   additional space available for "future" objects and therefore include
   the first object from period #2 in both the Bufferable and the
   Receivable Set,

      Deliverable Set = {(1,2),(1,4),(1,5)}

      Bufferable Set =  {(1,6),(2,1)}

      Buffered Set = { }

      Receivable Set = {(1,2),(1,4),(1,5),(1,6),(2,1)}

   In general, the notion of window management takes on new meaning with
   a partial order service.  One may re-examine the classic window
   relations with a partial order service in mind and devise new, less
   restrictive relations which may shed further light on the operation
   of such a service.

   Two final details: (1) as with the sender, the receiver must
   periodically establish or modify the PO service profile and (2) upon
   processing the last object in a period, the receiver must re-set the
   PO matrix and Processed vector to their initial states.









Connolly, Amer & Conrad                                        [Page 28]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   Let us look at the state machine and pseudo-code for the receiver.

         (2)Data Segment Arrival          (5)PO Profile fragment Arrival
            +------+                          +-------+
            |      |                          |       |
            |      V    (1)First PO Profile   |       V
          +---------+     fragment arrives   +---------+(6) Data Segment
    +---->|         |----------------------->|         |<-----+ Arrival
    |     |  ESTAB  |                        |   PO    |------+
    |     |         |                        |         |
    |     |         |                        |  SETUP  |<-----+
(3) +-----|         |<-----------------------|         |------+
Terminator+---------+  (9)PO Setup complete  +---------+(7) Terminator
            ^      |                          |      ^
            |      |                          |      |
            +------+                          +------+
          (4)Piggyback Timeout             (8)Piggyback Timeout


   Event 1 - First PO Service Profile fragment arrives at network
   =======   interface
      Transition to the PO SETUP state
      Store the PO service profile (fragment)
      Send an Acknowledgement of the PO service profile (fragment)

   Event 2 - Data Segment Arrival
   =======
      If object is in Deliverable Set then
           Deliver the object
           Update PO Matrix and Processed Vector
           Check buffers for newly deliverable objects
           If all objects from current period have been processed then
                Start the next period (re-initialize data structures)
           Start piggyback_delay timer to send an ACK
      Else if object is in Bufferable Set then
           Store the object
      Else
           Discard object
           Start piggyback_delay timer to send an ACK

   Event 3 - Periodic call of the Terminator
   =======
      For all unprocessed objects in the current period do
           If object is "no longer useful" then
                Update PO Matrix and Processed Vector
                If object is in a buffer then
                     Release the buffer
                Check buffers for newly deliverable objects



Connolly, Amer & Conrad                                        [Page 29]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


                If all objects from current period have been processed
                then Start the next period (re-initialize data
                structures)

   Event 4 - Piggyback_delay Timer Expires
   =======
      Send an ACK
      Disable piggyback_delay timer

   Event 5 - PO Service Profile fragment arrives at network interface
   =======
      Store the PO service profile (fragment)
      Send an Acknowledgement of the PO service profile (fragment)
      If entire PO Service profile has been received then enable Event
      (9)

   Event 6 - Data Segment arrival
   =======
      (See event 2)

   Event 7 - Periodic call of the terminator
   =======
      (See Event 3)

   Event 8 - Piggyback_delay Timer Expires
   =======
      (See Event 4)

   Event 9 - PO Setup Complete
   =======
      Transition to the ESTAB state

   Note that, for reasons of clarity, we have used a transitively closed
   matrix representation of the partial order.  A more efficient
   implementation based on an adjacency list representation of a
   transitively reduced precedence graph results in a more efficient
   running time [CAC93].

5. Quantifying and Comparing Partial Order Services

   While ordered, reliable delivery is ideal, the existence of less-
   than-ideal underlying networks can cause delays for applications that
   need only partial order or partial reliability.  By introducing a
   partial order service, one may in effect relax the requirements on
   order and reliability and presumably expect some savings in terms of
   buffer utilization and bandwidth (due to fewer retransmissions) and
   shorter overall delays.  A practical question to be addressed is,
   "what are the expected savings likely to be?"



Connolly, Amer & Conrad                                        [Page 30]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   As mentioned in Section 2, the extent of such savings will depend
   largely on the quality of the underlying network - bandwidth, delay,
   amount and distribution of loss/duplication/disorder - as well as the
   flexibility of the partial order itself - specified by the PO matrix
   and reliability vector.  If the underlying network has no loss, a
   partial order service essentially becomes an ordered service.
   Collecting experimental data to ascertain realistic network
   conditions is a straightforward task and will help to quantify in
   general the value of a partial order service [Bol93].  But how can
   one quantify and compare the cost of providing specific levels of
   service?

   Preliminary research indicates that the number of linear extensions
   (orderings) of a partial order in the presence of loss effectively
   measures the complexity of that order.  The authors have derived
   formulae for calculating the number of extensions when a partial
   order is series-parallel and have proposed a metric for comparing
   partial orders based on this number [ACCD93b].  This metric could be
   used as a means for charging for the service, for example. What also
   may be interesting is a specific head-to-head comparison between
   different partial orders with varying degrees of flexibility.  Work
   is currently underway on a simulation model aimed at providing this
   information.  And finally, work is underway on an implementation of
   TCP which includes partial order service.

6. Future Direction

   In addition to the simulation and implementation work the authors are
   pursuing several problems related to partial ordering which will be
   mentioned briefly.

   An interesting question arises when discussing the acknowledgment
   strategy for a partial order service.  For classic protocols, a
   cumulative ACK of object i confirms all objects "up to and including"
   i.  But the meaning of "up to and including" with a partial order
   service has different implications than with an ordered service.

   Consider our example partial order, ((1;2)||(3;4)||5);6).  What
   should a cumulative ACK of object 4 confirm?  The most logical
   definition would say it confirms receipt of object 4 and all objects
   that precede 4 in the partial order, in this case, object 3.  Nothing
   is said about the arrival of objects 1 or 2.  With this alternative
   interpretation where cumulative ACKs depend on the partial order, the
   sender must examine the partial order matrix to determine which
   buffers can be released.  In this example, scanning column 4 of the
   matrix reveals that object 3 must come before object 4 and therefore
   both object buffers (and any buffers from a previous period) can be
   released.



Connolly, Amer & Conrad                                        [Page 31]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   Other partial order acknowledgment policies are possible for a
   protocol providing a partial order service including the use of
   selective ACKs (which has been proposed in [JB88] and implemented in
   the Cray TCP [Chang93]) as well as the current TCP strategy where an
   ACK of i also ACKs everything <= i (in a cyclical sequence number
   space).  The authors are investigating an ACK policy which utilizes a
   combination of selective and "partial-order-cumulative"
   acknowledgments.  This is accomplished by replacing the current TCP
   cumulative ACK with one which has the partial order meaning as
   described above and augmenting this with intermittent selective ACKs
   when needed.

   In another area, the notion of fragmented delivery, mentioned in the
   beginning of Section 4, looks like a promising technique for certain
   classes of applications which may offer a substantial improvement in
   memory utilization.  Briefly, the term fragmented delivery refers to
   the ability to transfer less-than-complete objects between the
   transport layer and the user application (or session layer as the
   case may be).  For example, a 1Mbyte object could potentially be
   delivered in multiple "chunks" as segments arrive thus freeing up
   valuable memory and reducing the delay on those pieces of data.  The
   scenario becomes somewhat more complex when multiple "parallel
   streams" are considered where the application could now receive
   pieces of multiple objects associated with different streams.

   Additional work in the area of implementing a working partial order
   protocol is being performed both at the University of Delaware and at
   the LAAS du CNRS laboratory in Toulouse, France - particularly in
   support of distributed, high-speed, multimedia communication. It will
   be interesting to examine the processing requirements for an
   implementation of a partial order protocol at key events (such as
   object arrival) compared with a non-partial order implementation.

   Finally, the authors are interested in the realization of a network
   application utilizing a partial order service.  The aim of such work
   is threefold: (1) provide further insight into the expected
   performance gains, (2) identify new issues unique to partial order
   transport and, (3) build a road-map for application designers
   interested in using a partial order service.

7. Summary

   This RFC introduces the concepts of a partial order service and
   discusses the practical issues involved with including partial
   ordering in a transport protocol.  The need for such a service is
   motivated by several applications including the vast fields of
   distributed databases, and multimedia.  The service has been
   presented as a backward-compatible extension to TCP to adapt to



Connolly, Amer & Conrad                                        [Page 32]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   applications with different needs specified in terms of QOS
   parameters.

   The notion of a partial ordering extends QOS flexibility to include
   object delivery, reliability, and temporal value thus allowing the
   transport layer to effectively handle a wider range of applications
   (i.e., any which might benefit from such mechanisms).  The service
   profile described in Section 4 accurately characterizes the QOS for a
   partial order service (which encompasses the two extremes of total
   ordered and unordered transport as well).

   Several significant modifications have been proposed and are
   summarized here:

       (1) Replacing the requirement for ordered delivery with one for
           application-dependent partial ordering

       (2) Allowing unreliable and partially reliable data transport

       (3) Conducting a non-symmetrical connection (not entirely foreign
           to TCP, the use of different MSS values for the two sides
           of a connection is an example)

       (4) Management of "objects" rather than octets

       (5) Modified acknowledgment strategy

       (6) New definition for the send and receive "windows"

       (7) Extension of the User/TCP interface to include certain
           QOS parameters

       (8) Use of new TCP options

   As evidenced by this list, a partial order and partial reliability
   service proposes to re-examine several fundamental transport
   mechanisms and, in so doing, offers the opportunity for substantial
   improvement in the support of existing and new application areas.













Connolly, Amer & Conrad                                        [Page 33]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


8. References

   [ACCD93a]  Amer, P., Chassot, C., Connolly, T., and M. Diaz,
              "Partial Order Transport Service for Multimedia
              Applications: Reliable Service", Second International
              Symposium on High Performance Distributed Computing
              (HPDC-2), Spokane, Washington, July 1993.

   [ACCD93b]  Amer, P., Chassot, C., Connolly, T., and M. Diaz,
              "Partial Order Transport Service for Multimedia
              Applications: Unreliable Service", Proc. INET '93, San
              Francisco, August 1993.

   [AH91]     Anderson, D., and G. Homsy, "A Continuous Media I/O
              Server and its Synchronization Mechanism", IEEE
              Computer, 24(10), 51-57, October 1991.

   [AS93]     Agrawala, A., and D. Sanghi, "Experimental Assessment
              of End-to-End Behavior on Internet," Proc. IEEE INFOCOM
              '93, San Francisco, CA, March 1993.

   [BCP93]    Claffy, K., Polyzos, G., and H.-W. Braun, "Traffic
              Characteristics of the T1 NSFNET", Proc. IEEE INFOCOM
              '93, San Francisco, CA, March 1993.

   [Bol93]    Bolot, J., "End-to-End Packet Delay and Loss Behavior
              in the Internet", SIGCOMM '93, Ithaca, NY, September
              1993.

   [CAC93]    Conrad, P., Amer, P., and T. Connolly, "Improving
              Performance in Transport-Layer Communications Protocols
              by using Partial Orders and Partial Reliability",
              Work in Progress, December 1993.

   [Chang93]  Chang, Y., "High-Speed Transport Protocol Evaluation --
              the Final Report", MCNC Center for Communications
              Technical Document, February 1993.

   [Dee89]    Deering, S., "Host Extensions for IP Multicasting," STD
              5, RFC 1112 Stanford University, August 1989.

   [DS93]     Diaz, M., and P. Senac, "Time Stream Petri Nets: A
              Model for Multimedia Synchronization", Proceedings of
              Multimedia Modeling '93, Singapore, 1993.







Connolly, Amer & Conrad                                        [Page 34]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


   [HKN91]    Hardt-Kornacki, S., and L. Ness, "Optimization Model
              for the Delivery of Interactive Multimedia Documents",
              In Proc.  Globecom '91, 669-673, Phoenix, Arizona,
              December 1991.

   [JB88]     Jacobson, V., and R. Braden, "TCP Extensions for
              Long-Delay Paths", RFC 1072, LBL, USC/Information
              Sciences Institute, October 1988.

   [JBB92]    Jacobson, V., Braden, R., and D. Borman, "TCP
              Extensions for High Performance", RFC 1323, LBL, Cray
              Research, USC/Information Sciences Institute, May 1992.

   [LMKQ89]   Leffler, S., McKusick, M., Karels, M., and J.
              Quarterman, "4.3 BSD UNIX Operating System",
              Addison-Wesley Publishing Company, Reading, MA, 1989.

   [OP91]     O'Malley, S., and L. Peterson, "TCP Extensions
              Considered Harmful", RFC 1263, University of Arizona,
              October 1991.

   [Pos81]    Postel, J., "Transmission Control Protocol - DARPA
              Internet Program Protocol Specification," STD 7,
              RFC 793, DARPA, September 1981.

Security Considerations

   Security issues are not discussed in this memo.























Connolly, Amer & Conrad                                        [Page 35]


RFC 1693       An Extension to TCP: Partial Order Service  November 1994


Authors' Addresses

   Tom Connolly
   101C Smith Hall
   Department of Computer & Information Sciences
   University of Delaware
   Newark, DE 19716 - 2586

   EMail: connolly@udel.edu


   Paul D. Amer
   101C Smith Hall
   Department of Computer & Information Sciences
   University of Delaware
   Newark, DE 19716 - 2586

   EMail: amer@udel.edu


   Phill Conrad
   101C Smith Hall
   Department of Computer & Information Sciences
   University of Delaware
   Newark, DE 19716 - 2586

   EMail: pconrad@udel.edu
























Connolly, Amer & Conrad                                        [Page 36]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/