DECADE                                                            H. Liu
Internet-Draft                                           Yale University
Intended status: Informational                              Mar 12, 2012
Expires: September 13, 2012


                 Data Streaming Subscription in DECADE
                    draft-liu-decade-subscription-01

Abstract

   This document describes a potential performance issue in DECADE to
   support real-time applications.  It shows the current content hashing
   based naming scheme might harm the performance when the content data
   is generated in real time and low propagation latency of the data is
   required.  This draft propose a new naming scheme and protocol,
   subscribe/unsubscribe, for real-time applications to address the
   problem caused by content hashing.  DECADE clients use subscribe/
   unsubscribe to express their interests to receive data streaming.
   DECADE servers pro-actively push stream data to eligible clients,
   which saves the time consumed on exchanging the hashing of new
   generated data.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 13, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Liu                    Expires September 13, 2012               [Page 1]


Internet-Draft             DECADE Subscription                  Mar 2012


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Problems of Content Hash Only Naming for Real-time
       Applications  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Subscribe/Unsubscribe . . . . . . . . . . . . . . . . . . . . . 5
     3.1.  Work Flow of Stream Subscription  . . . . . . . . . . . . . 5
     3.2.  Stream ID . . . . . . . . . . . . . . . . . . . . . . . . . 6
     3.3.  Stream Token  . . . . . . . . . . . . . . . . . . . . . . . 6
     3.4.  Stream Forwarding Table . . . . . . . . . . . . . . . . . . 6
   4.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8

























Liu                    Expires September 13, 2012               [Page 2]


Internet-Draft             DECADE Subscription                  Mar 2012


1.  Introduction

   Existing DECADE protocol identifies all the objects by their content
   hashes.  A client cannot fetch an object from DECADE servers until it
   learns the hash of this object.  This property introduces additional
   delays in "real-time applications", e.g. live streaming, video
   conference, etc., in which data is generated on the fly and short
   latency is required to distribute data to clients.

   This draft discusses about the performance loss of real-time
   applications with existing DECADE protocol.  Moreover it presents a
   new mechanism "subscribe/unsubscribe" in DECADE framework to better
   support real-time applications.

1.1.  Concepts

1.1.1.  Real-time Applications

   The applications that have a source generating live data and deliver
   the data to the receivers with latency as short as possible.

1.1.2.  DECADE Sender

   An end host which uploads data to a DECADE server and leverages
   DECADE framework to deliver the data to one or multiple DECADE
   receivers.

1.1.3.  DECADE Receiver

   An end host which downloads data from DECADE servers.


2.  Problems of Content Hash Only Naming for Real-time Applications

   In naming schemes only based on content hashing, an object is
   identified uniquely by its hash of its content.  In other words, if a
   client wants to download an object, it should firstly learn the
   object's hash value and send a request to DECADE servers with this
   hash.  This works well in "offline" applications, such as file
   sharing and video on demand, in which the objects and their hashes
   already exist, and the object delivery performance is not delay
   sensitive.  However, it will introduces significant additional delays
   which harms "real-time" application performance.








Liu                    Expires September 13, 2012               [Page 3]


Internet-Draft             DECADE Subscription                  Mar 2012


                                .---------.<--------.
                    .---------> |    S    |          \
      1. Upload    /            `---------'--------.  \  3.Request
         Object   /                     4. Download \  \   Object
                 /                         Object    \  \
                /                                     v  \
       .---------------.     2. Token of Object      .-----------------.
       | DECADE Sender |---------------------------->| DECADE Receiver |
       |   (Speaker)   |                             |    (Listener)   |
       `---------------'                             `-----------------'

      Figure 1: Real-time Object Distribution with Traditional DECADE

   Figure 1 illustrates a simple case of voice over IP (VoIP) using
   content hash only naming.  When the client on the left is a speaker.
   It wants to upload only one copy of its voice data to DECADE server S
   and asks S to upload the data to multiple listeners.  The work flow
   is as the following: (1) The speaker buffers its voice data until its
   size meets the minimum object size requirement in DECADE (or in the
   application).  Denote D_buffer as the delay caused by the buffering;
   (2) The speaker uploads the object to S (with delay D_up) and in the
   meanwhile sends the token to the receiver (with delay D_token); (3)
   With the token, the listener requests and downloads the object from S
   (with delay D_down which is the RTT between S and the listener).  In
   summary, the total latency from the moment a piece of voice is
   generated to the moment this piece reaches the listener side is D_1 =
   D_buffer + max(D_up, D_token) + D_down.

                                 .---------.
                     .---------> |    S    |--------.
       1. Up-Stream /            `---------'         \  2.Down-Stream
                   /                                  \
                  /                                    \
                 /                                      v
        .---------------.                            .-----------------.
        | DECADE Sender |                            | DECADE Receiver |
        |   (Speaker)   |                            |    (Listener)   |
        `---------------'                            `-----------------'

       Figure 2: Real-time Streaming with A Simple Forwarding Server

   Compare with an alternative design shown in Figure 2.  If the speaker
   just pushes data to S and S pushes data to listenrs, the total
   latency is only D_2 = D_up + D_down/2.  D1 - D2 >= D_buffer +
   D_down/2.  In reality, D1 can be much larger than D2.  In paricular,
   D1 can be larger than typical delay threshold (say 200 ms) for VoIP's
   continulity, while D2 is not.




Liu                    Expires September 13, 2012               [Page 4]


Internet-Draft             DECADE Subscription                  Mar 2012


   Therefore, to better support real-time applications in DECADE, we
   propose a new protocol flow to achieve the ideal case in Figure 2
   compatibly with existing DECADE framework and with scalability and
   manageability.


3.  Subscribe/Unsubscribe

   A stream is a special object whose length we do not know and whose
   hash does not exist.  This is the fundamental reason that content-
   hash only naming cannot support live streaming well.  In this section
   we propose a new type of protocol subscribe/unsubscribe to support
   streams in DECADE.  There are two key ideas in this new protocol: (1)
   DECADE servers push stream data to the subscribers; (2) Tokens are
   used to authorize the eligibility of stream subscriptions.

3.1.  Work Flow of Stream Subscription

   Figure 3 illustrates an example of how subscribe/unsubscribe works.
   At the beginning, the speaker on the left sends a stream creating
   message to its DECADE server S1 and S1 will allocate a stream ID for
   the speaker.  Then, the speaker uses this stream ID to construct
   tokens and upload stream data to S1.  After the listener gets the
   stream token, it presents the token in its subscription of the
   stream.  Its DECADE server S2, if S2 is not S1, will recursively
   subscribe the stream from S1 with the token.  Finally if the
   subscription is authorized, S1 will forward the stream to S2 and S2
   in turn push the stream to the listener.  For scalability and
   robustness, a stream token might only valid for a duration.  The
   listener should update the stream token periodically from the
   speaker.  When the listener does not want to receive the stream any
   more, it unsubscribes the stream from S2.  When S2 finds there is no
   subscribers for the stream, it will unsubscribe the stream from S1.


                2. Up-Stream  .----.       .----.   4.Down-Stream
                     .======> | S1 | ====> | S2 | ============.
                    //  .---> `----` <---- `----` <--------.  \\
                   //  /                                    \  \\
                  //  / 1. Create              3. Subscribe  \  \\
                 //  v     Stream                 (Token)     v  v
        .---------------.                            .-----------------.
        | DECADE Sender | <------------------------> | DECADE Receiver |
        |   (Speaker)   |     Stream Token Update    |    (Listener)   |
        `---------------'                            `-----------------'

                Figure 3: Work Flow of Stream Subscription




Liu                    Expires September 13, 2012               [Page 5]


Internet-Draft             DECADE Subscription                  Mar 2012


3.2.  Stream ID

   Each stream must has a unique ID.  One possible solution is that each
   DECADE provider owns a unique prefix for the streams created on its
   DECADE servers.  And the DECADE provider guarantees the uniqueness of
   streams inside its DECADE network itself.

   The requirement for the length of stream ID is the same with the
   object ID defined in [I-D.ietf-decade-arch]

3.3.  Stream Token

   Stream Tokens have the same format of DECADE token defined in
   [I-D.ietf-decade-arch].  In streaming tokens, the "object ID" part is
   actually stream ID.  DECADE servers use stream token to figure out
   when a subscriber's account is eligible to receive the stream.

3.4.  Stream Forwarding Table

   The DECADE server creates a streaming forwarding table to manage and
   forward streams.  When a DECADE client creates a stream in its DECADE
   server, it actually sets up an item in the server's stream forwarding
   table.  As shown in Figure 4, the key of each item in the table is
   stream ID.  With a stream ID, the server can obtain the owner of the
   stream which is used to authorize tokens in subscriptions and account
   resource usage.  The server can also learn the current subscribers of
   the stream and decide where to forward a stream or when to
   unsubscribe a stream (after the subscriber list becomes empty.)

           .=============.=================================.
           |     Key     |            Values               |
           .-------------.---------------------------------.
           | Stream ID 1 | Owner Account | Subscriber List |
           .-------------.---------------------------------.
           | Stream ID 2 | Owner Account | Subscriber List |
           .=============.=================================.

            Figure 4: Stream Forwarding Table in DECADE Servers

   Note that only the DECADE server or DECADE provider (e.g.  S1 in
   Figure 3) on which a stream is created has the stream owner account
   information.  For other DECADE servers or providers (e.g.  S2 in
   Figure 3), they only maintain subscribers who subscribe the stream
   via themselves.







Liu                    Expires September 13, 2012               [Page 6]


Internet-Draft             DECADE Subscription                  Mar 2012


4.  Protocol

   This section shows an example of DECADE subscription protocol on
   HTTP.

   As shown in Figure 5, in the subscription request, the client puts
   the stream ID into the URL.  The "Connection" header should be "Keep-
   Alive" to establish a persistent with the DECADE server.  There are
   two new HTTP headers for DECADE: (1) "Decade-Origin" which indicates
   the backup location where the stream can be fetched, and (2) "Decade-
   Token" which presents the token for access the stream to the DECADE
   server.

   The server status uses code 200 (OK), 404 (Not Found) or 401
   (Unauthorized) to tell the clients the result of the subscription.
   If the subscription is accepted, the server will push streaming data
   to the client.  Otherwise, the server closes the connection.

           GET /StreamID HTTP/1.1
           Connection: Keep-Alive
           Host: server1.decade.net
           Decade-Origin: http://server2.decade.net
           Decade-Token: TWFuIGlzIGRpc3Rpbmd


       Figure 5: A Message of DECADE Streaming Subscription Request


           HTTP/1.1 200 OK
           Connection: Keep-Alive
           Content-Type: application/octet-stream

           streaming data


       Figure 6: A Message of DECADE Streaming Subscription Response


5.  Security Considerations

   This document does not contain any security considerations.


6.  IANA Considerations

   This document does not have any IANA considerations.





Liu                    Expires September 13, 2012               [Page 7]


Internet-Draft             DECADE Subscription                  Mar 2012


7.  References

7.1.  Normative References

7.2.  Informative References

   [I-D.ietf-decade-problem-statement]
              Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
              Application Data Enroute (DECADE) Problem Statement",
              draft-ietf-decade-problem-statement-05 (work in progress),
              February 2012.

   [I-D.ietf-decade-survey]
              Alimi, R., Rahman, A., and Y. Yang, "A Survey of In-
              network Storage Systems", draft-ietf-decade-survey-06
              (work in progress), August 2011.

   [I-D.ietf-decade-arch]
              Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and H. Liu,
              "DECADE Architecture", draft-ietf-decade-arch-04 (work in
              progress), October 2011.

   [I-D.gu-decade-reqs]
              Yingjie, G., Bryan, D., Yang, Y., and R. Alimi, "DECADE
              Requirements", draft-gu-decade-reqs-05 (work in progress),
              July 2010.


Author's Address

   Hongqiang Liu
   Yale University

   Email: hongqiang.liu@yale.edu

















Liu                    Expires September 13, 2012               [Page 8]