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]