[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   AVT
   Internet Draft                                 S. Narayanan (Editor)
   draft-narayanan-mrtp-motivation-00.txt                  D. Bushmitch
   Expires: April 14, 2005                                    Panasonic
                                                                 S. Mao
                                                          Virginia Tech
                                                              S. Panwar
                                                       Polytechnic Univ
                                                       October 14, 2004


         Motivation for a Multi-Flow Real-time Transport Protocol


Status of this Memo
   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 9, 2005

Copyright Notice


   Copyright (C) The Internet Society (2004).  All Rights Reserved.



Narayanan et. al.      Expires - April 17, 2005               [Page 1]


Internet-draft         Motivation for MRTP                October 2004



Abstract

   We proposed a new multi-flow real time protocol (MRTP) in our earlier
   internet-draft [1] for carrying real-time data through multiple paths
   between the source and the destination. There are a various
   advantages in multipath data transport as demonstrated by [2][3]
   [5][8]. MRTP would provide an end-to-end transport services over
   multiple flows and paths to real time data. In this draft we discuss
   the motivation for needing such a standardized protocol to encourage
   further discussion on the requirement for a multi-path transport
   protocol.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [4].































Narayanan, et al.          Expires - April                   [Page 2]


Internet-draft         Motivation for MRTP                October 2004




Table of Contents

   1. Introduction...................................................4
   2. Terminology....................................................4
   3. Motivation.....................................................4
   4. Advantages of using multi-path transport.......................5
   5. Reasons for a new protocol.....................................6
   6. Usage scenarios................................................6
      6.1 Unicast Video Streaming....................................6
      6.2 P2P Video Downloading......................................7
      6.3 Realtime Multicasting......................................8
   7. Security Considerations........................................8
   Acknowledgments...................................................9
   Author's Addresses................................................9
































Narayanan, et al.          Expires - April                   [Page 3]


Internet-draft         Motivation for MRTP                October 2004




1. Introduction
   In [1] we proposed a new protocol, the Multi-flow Real-time Transport
   Protocol (MRTP), for real-time transport over networks using multiple
   paths (e.g., P2P, wireless networks, ad hoc networks). MRTP is a
   transport protocol that could be implemented in the user space of the
   hosts operating system. Given multiple paths maintained by an
   underlying multipath routing protocol, MRTP and its companion control
   protocol, the Multi-flow Real-time Transport Control Protocol
   (MRTCP), provide essential support for multiple path real-time
   transport. This includes session and flow management, data
   partitioning, traffic dispersion, timestamping, sequence numbering,
   and Quality of Service (QoS) reporting. In this draft we provide the
   background and motivation that lead us to the conclusion that we need
   new standardized protocol to support the above listed features.

2. Terminology
   This document does not introduce any new terminology.

3. Motivation
   Various research activities have repeatedly demonstrated multiple
   benefits in partitioning real time data and transmitting each
   partition through a different path between the source and the
   destination (see section 4). With the advent of P2P networks,
   wireless ad hoc networks and multipath routing protocols (e.g.,
   MDSR), using multiple paths to deliver a single real-time stream is
   becoming more possible.

   None of the existing transport protocols provide the required multi-
   path service in a transparent manner (see section 6). Applications
   used in such research projects are forced to develop their own
   proprietary protocols (e.g., Meta-RTP [5])to implement and study
   multi-path real-time transport. As progress is made in this area,
   different groups will develop independent and redundant protocol
   specifications that will not interoperate. In order to avoid such a
   scenario, we propose that a standard multi-path protocol should be
   developed by IETF, published as an experimental RFC to be used in the
   research and development efforts in this area. We believe
   availability of such a standard protocol will play a crucial role in
   accelerating research in multi-path transport applications. Section 6
   presents some such example applications.





Narayanan, et al.          Expires - April                   [Page 4]


Internet-draft         Motivation for MRTP                October 2004


4. Advantages of using multi-path transport
   This section presents a subset of the advantages in using multi-path
   transport:
     . Improves reliability of the end-to-end channel. Transmission
        errors in one path can be independent from other paths, allowing
        the use of forward error-correction schemes.

     . Some Redundancy in traffic dispersion  / coding can allow
        message reconstruction only from a subset of paths.

     . Increases fault-tolerance of the real-time networks. When
        multiple connections share the same path, the level of
        redundancy needs to be increased.

     . Improves throughput or the overall bandwidth availability to
        transmitting / receiving nodes. Provides for load balancing
        without additional delays typically introduced by traffic
        shaping. Can lead to energy conservation for wireless devices.

     . Improves queuing delays and delay variation experienced by
        transmitted traffic as shown by a number of experimental studies
        and theoretical models.

     . Improves resilience to attacks in security applications

     . Shown to reduce the information leakage probability when traffic
        is dispersed over N path and K routers are attacked.

     . Greatly enhances multiple description coded (MDC) content
        transport. Multiple paths carry multiple descriptions,
        presentation is possible only with a subset of successfully
        received descriptions. Provides for graceful presentation
        quality adaptation upon path degradation/failure.

     . Also shown to improve the quality in rendering when applied to
        layered coding (e.g., MPEG) transport. Packet-based dispersion,
        Frame-based dispersion, GOP-based dispersion, priority-based
        dispersion.

     . Improved traffic characteristics (correlations within critical
        time scale (CTS) of a system). Traffic partitioning is shown to
        decrease SRD within CTS of the queue. As a result, shown to
        significantly improve Queueing performance (BOP) of the
        underlying queues.






Narayanan, et al.          Expires - April                   [Page 5]


Internet-draft         Motivation for MRTP                October 2004


5. Reasons for a new protocol
   One natural question arises is that can any of the existing protocols
   provides the same support, i.e., do we really need such a new
   protocol? There are two existing protocols that are closely related
   to our proposal. One is the Realtime Transport Protocol (RTP) [10].
   RTP is a multicast-oriented protocol for Internet realtime
   applications. RTP is not suitable for the purpose of enabling
   interoperable applications for the following reasons:
     . RTP itself does not support the use of multiple flows.
     . An application could implement multipath real-time transport
        using RTP, but it would have to perform all the overhead
        processing of managing multiple individual flows, partitioning
        traffic, determining the quality of the overall session based on
        individual flow statistics, etc. An signaling mechanism used by
        such an application to exchange the Session-Flow-Substreams
        mapping will make it non-interoperable with applications
        developed by other groups.

   The other closely related protocol is the Stream Control Transport
   Protocol (SCTP) [6]. SCTP is a message-based transport layer protocol
   initially designed for reliable signaling in the Internet ( e.g.,
   out-of-band control messages for Voice over IP (VoIP) call setup or
   teardown). One attractive feature of SCTP is that it supports multi-
   homing and multi-streaming, where multiple network interfaces or
   multiple streams can be used for a single SCTP session. SCTP can not
   be directly used for multi-path real-time transport for the following
   reasons:
     . With SCTP, generally one primary path is used and other paths
        are used as backups or retransmission channels.
     . Even though there are several recent papers proposing to adapt
        SCTP to use multiple paths simultaneously for data transport
        [7]. SCTP cannot be applied directly for multimedia data because
        there is no real-time features like timestamping and QoS
        feedback services. With MRTP, the design is focused on
        supporting real-time applications, with timestamping and QoS
        feedback as its essential modes of operation.
     . Moreover, since SCTP is a transport layer protocol and is
        implemented in the system kernel, it is hard, if not impossible,
        to make changes to it. A new multimedia application, with a new
        coding format, a new transport requirement, etc., could only
        with difficulty be supported by SCTP.

6. Usage scenarios
6.1 Unicast Video Streaming
   This is a point-to-point scenario, where a wireless sensor network is
   deployed to monitor,  e.g., wild life, in a remote region. Some



Narayanan, et al.          Expires - April                   [Page 6]


Internet-draft         Motivation for MRTP                October 2004


   sensors carry a video camera, and others are simple relays that relay
   the captured video to the base. Source routing, or some other simple
   routing protocols can be used.

   A camera sensor initiates an MRTP session to the base. The captured
   video is transmitted using multiple flows going through different
   relays. In this way, a relative high rate video can be scattered to
   multiple paths each is bandwidth-limited. Redundancy can also be
   added by transmitting a more important sub-stream using multiple
   flows.

   Some sensors may be damaged or may run out of power. In this case,
   the underlying multipath routing protocol informs MRTP about the path
   changes. Either the sender or the receiver can delete a failed flow,
   or add a new flow to the session. The server at the base maintains a
   resequencing buffer for each flow, as well as enforcing a deadline
   for each packet expected to arrive.

6.2 P2P Video Downloading
   This is a many-to-one scenario. In a P2P network where each node
   maintains a cache for recently downloaded files. When a node A wants
   to download a movie, it would be more efficient to search the caches
   of other nearby nodes first than going directly to the Internet. If
   the movie is found in the caches of nodes B, C, and D, A can initiate
   an MRTP session to these nodes, downloading a piece of the movie
   simultaneously (or sequentially, depending on the coding scheme used)
   from each of them. A pair of pointers is used for each flow
   indicating the segment of the video assigned to that flow. There are
   three flows, each with a unique flow ID, in this MRTP session.
   However, the flows have the same session ID since they belong to the
   same MRTP session. Resequencing buffers are used in A to reorder the
   packets, using the sequence numbers and the timestamps in their
   headers. A similar application of video streaming in Content Delivery
   Networks (CDN) using multiple servers is presented in [8].

   During the transmission, Node D moves out of the network. Node A
   would delete the flow from D and adjust the file pointers in the
   other two flows. Now the part of the video initially chosen from D
   will be downloaded from B and C instead, by sending Add Flow packets
   to B and C with updated pointers. On the other hand, node A may
   broadcast probes periodically to find new neighbors with the movie
   and replace the stale flows in the session. Note that MRTP provides
   the flexibility for applications to implement these schemes.






Narayanan, et al.          Expires - April                   [Page 7]


Internet-draft         Motivation for MRTP                October 2004


6.3 Realtime Multicasting
   This is a multicast application similar to a video teleconferencing
   using RTP. Unlike RTP, MRTP uses multiple multicast trees. In [9],
   algorithms are given for computing two maximally disjoint multicast
   trees, where one is used for multicasting and the other is maintained
   as backup. This algorithm can be adapted to support multiple
   multicast trees in an MRTP session.

   For the example, if there are two multicast trees used, where each
   multicast tree is a flow and both flows belong to the same MRTP
   session. Since there may be a large number of participants in the
   session, QoS feedback should be suppressed, as in RTP, to avoid
   feedback explosion. The RTCP transmission interval computing
   algorithm [10] can be used to dynamical compute the interval between
   two back-to-back QoS reports according to the current number of
   participants and the available bandwidth. Since a flow may have more
   than one receiver, the sender ID field in a RR packet is used to
   identify its sender. The QoS metrics for a flow are computed over all
   the receivers of this flow.

7. Security Considerations
   This draft just presents the motivation for an earlier internet-
   draft. As such, there are no security issues that needs to addressed
   by this draft.

References

     1. S. Narayanan, D. Bushmitch, S. Mao, S. Panwar, ôMRTP: A Multi-
        flow Real Time Transport Protocolö, draft-narayanan-mrtp-00.txt,
        July 2004.
     2. Shiwen Mao, Shunan Lin, Shivendra S. Panwar, Yao Wang, and Emre
        Celebi, "Video transport over ad hoc networks: Multistream
        coding with multipath transport," IEEE Journal on Selected Areas
        in Communications, Special Issue on Recent Advances in Wireless
        Multimedia, vol. 21, no. 10,
        pp.1721-1737, December 2003.
     3. D. Bushmitch, R. Izmailov, S. Panwar, A. Pal, ``Thinning,
        Striping and Shuffling: Traffic Shaping and Transport Techniques
        for Variable Bit Rate Video,'' in Proc. IEEE GLOBECOM'02,
        Taipei, 2002.
     4. S. Bradner, ``Key words for use in RFCs to indicate requirement
        levelö, RFC 2119.
     5. N. Gogate, D. Chung, S.~S. Panwar, Y. Wang,``Supporting
        image/video applications in a multihop radio environment using
        route diversity and multiple description coding,''  IEEE Trans.



Narayanan, et al.          Expires - April                   [Page 8]


Internet-draft         Motivation for MRTP                October 2004



        Circuit Syst. Video Technol., vol.12, no.9, pp.777-792, Sept.
        2002.
     6. R.~R. Stewart and Q. Xie,  Stream Control Transmission Protocol:
        A Reference Guide. Reading, MA: Addison-Wesley, 2001.
     7. D.~S. Phatak and T. Goff, ``A novel mechanism for data streaming
        across multiple IP links for improving throughput and reliabilit
        in mobile environments,'' in  Proc. IEEE INFOCOM, pp.773-782,
        June 2002.
     8. J.~G. Apostolopoulos, T. Wong, W. Tan, and S. Wee, ``On Multiple
        Description Streaming in Content Delivery Networks,'' in  Proc.
        IEEE INFOCOM, pp.1736-1745, June 2002.
     9. S. Sajama and Z. J. Haas, ``Independent-tree ad hoc multicast
        routing (ITAMAR),'' in  Proc. IEEE Fall VTC'01, October 2001.
     10. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson,
        ``RTP: A transport protocol for realtime applications,'' IETF
        Request For Comments 3550. [Online]. Available at:
        http://www.ietf.org.

Acknowledgments
   < TBD>

Author's Addresses

   Sathya Narayanan
   Panasonic Digital Networking Lab,
   2 Research Way, Princeton, NJ 08540
   Phone: (609) 734 7599
   Email: sathya@Research.Panasonic.COM

   Dennis Bushmitch
   Panasonic Digital Networking Lab,
   2 Research Way, Princeton, NJ 08540
   Phone: (609) 734
   Email: db@Research.Panasonic.COM

   Shiwen Mao
   Virginia Polytechnic Institute and State University
   340 Whittemore Hall (0111), Blacksburg, VA 24061
   Email: smao@vt.edu

   Shivendra Panwar
   Polytechnic University
   Brooklyn, NY
   Phone: (618) 260 3740
   Email: panwar@catt.poly.edu


Narayanan, et al.          Expires - April                   [Page 9]


Internet-draft         Motivation for MRTP                October 2004



Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.




Narayanan, et al.          Expires - April                  [Page 10]


Internet-draft         Motivation for MRTP                October 2004




Acknowledgment
   Funding for the RFC Editor function is currently provided by the
   Internet Society.












































Narayanan, et al.          Expires - April                  [Page 11]


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