draft-ietf-avtcore-mprtp-00.txt   draft-ietf-avtcore-mprtp-01.txt 
AVT Core Working Group V. Singh AVT Core Working Group V. Singh
Internet-Draft T. Karkkainen Internet-Draft T. Karkkainen
Intended status: Experimental J. Ott Intended status: Experimental J. Ott
Expires: June 23, 2015 S. Ahsan Expires: January 7, 2016 S. Ahsan
Aalto University Aalto University
L. Eggert L. Eggert
NetApp NetApp
December 20, 2014 July 6, 2015
Multipath RTP (MPRTP) Multipath RTP (MPRTP)
draft-ietf-avtcore-mprtp-00 draft-ietf-avtcore-mprtp-01
Abstract Abstract
The Real-time Transport Protocol (RTP) is used to deliver real-time The Real-time Transport Protocol (RTP) is used to deliver real-time
content and, along with the RTP Control Protocol (RTCP), forms the content and, along with the RTP Control Protocol (RTCP), forms the
control channel between the sender and receiver. However, RTP and control channel between the sender and receiver. However, RTP and
RTCP assume a single delivery path between the sender and receiver RTCP assume a single delivery path between the sender and receiver
and make decisions based on the measured characteristics of this and make decisions based on the measured characteristics of this
single path. Increasingly, endpoints are becoming multi-homed, which single path. Increasingly, endpoints are becoming multi-homed, which
means that they are connected via multiple Internet paths. Network means that they are connected via multiple Internet paths. Network
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 23, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 30 skipping to change at page 3, line 30
11.5. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 31 11.5. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 31
11.5.1. In-band Signaling Example . . . . . . . . . . . . . 31 11.5.1. In-band Signaling Example . . . . . . . . . . . . . 31
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
12.1. MPRTP Header Extension . . . . . . . . . . . . . . . . . 32 12.1. MPRTP Header Extension . . . . . . . . . . . . . . . . . 32
12.2. MPRTCP Packet Type . . . . . . . . . . . . . . . . . . . 32 12.2. MPRTCP Packet Type . . . . . . . . . . . . . . . . . . . 32
12.3. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 33 12.3. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 33
12.3.1. "mprtp" attribute . . . . . . . . . . . . . . . . . 33 12.3.1. "mprtp" attribute . . . . . . . . . . . . . . . . . 33
13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 13. Security Considerations . . . . . . . . . . . . . . . . . . . 34
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
15.1. Normative References . . . . . . . . . . . . . . . . . . 34 15.1. Normative References . . . . . . . . . . . . . . . . . . 35
15.2. Informative References . . . . . . . . . . . . . . . . . 35 15.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Interoperating with Legacy Applications . . . . . . 37 Appendix A. Interoperating with Legacy Applications . . . . . . 37
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 37 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 37
B.1. Changes in draft-ietf-avtcore-mprtp-00 . . . . . . . . . 37 B.1. Changes in draft-ietf-avtcore-mprtp-00 . . . . . . . . . 37
B.2. Changes in draft-singh-avtcore-mprtp-10 . . . . . . . . . 37 B.2. Changes in draft-singh-avtcore-mprtp-10 . . . . . . . . . 37
B.3. Changes in draft-singh-avtcore-mprtp-09 . . . . . . . . . 37 B.3. Changes in draft-singh-avtcore-mprtp-09 . . . . . . . . . 38
B.4. Changes in draft-singh-avtcore-mprtp-08 . . . . . . . . . 37 B.4. Changes in draft-singh-avtcore-mprtp-08 . . . . . . . . . 38
B.5. Changes in draft-singh-avtcore-mprtp-06 and -07 . . . . . 38 B.5. Changes in draft-singh-avtcore-mprtp-06 and -07 . . . . . 38
B.6. Changes in draft-singh-avtcore-mprtp-05 . . . . . . . . . 38 B.6. Changes in draft-singh-avtcore-mprtp-05 . . . . . . . . . 38
B.7. Changes in draft-singh-avtcore-mprtp-04 . . . . . . . . . 38 B.7. Changes in draft-singh-avtcore-mprtp-04 . . . . . . . . . 38
B.8. Changes in draft-singh-avtcore-mprtp-03 . . . . . . . . . 38 B.8. Changes in draft-singh-avtcore-mprtp-03 . . . . . . . . . 38
B.9. Changes in draft-singh-avtcore-mprtp-02 . . . . . . . . . 39 B.9. Changes in draft-singh-avtcore-mprtp-02 . . . . . . . . . 39
B.10. Changes in draft-singh-avtcore-mprtp-01 . . . . . . . . . 39 B.10. Changes in draft-singh-avtcore-mprtp-01 . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Multi-homed endpoints are becoming common in today's Internet, e.g., Multi-homed endpoints are becoming common in today's Internet, e.g.,
devices that support multiple wireless access technologies such as 3G devices that support multiple wireless access technologies such as 3G
and Wireless LAN. This means that there is often more than one and Wireless LAN. This means that there is often more than one
network path available between two endpoints. Transport protocols, network path available between two endpoints. Transport protocols,
such as RTP, have not been designed to take advantage of the such as RTP, have not been designed to take advantage of the
availability of multiple concurrent paths and therefore cannot availability of multiple concurrent paths and therefore cannot
benefit from the increased capacity and reliability that can be benefit from the increased capacity and reliability that can be
skipping to change at page 8, line 25 skipping to change at page 8, line 25
case. case.
5.1. Streaming use-case 5.1. Streaming use-case
In the unidirectional scenario, the receiver (client) initiates a In the unidirectional scenario, the receiver (client) initiates a
multimedia session with the sender (server). The receiver or the multimedia session with the sender (server). The receiver or the
sender may have multiple interfaces and both endpoints are MPRTP- sender may have multiple interfaces and both endpoints are MPRTP-
capable. Figure 3 shows this scenario. In this case, host A has capable. Figure 3 shows this scenario. In this case, host A has
multiple interfaces. Host B performs connectivity checks on host A's multiple interfaces. Host B performs connectivity checks on host A's
multiple interfaces. If the interfaces are reachable, then host B multiple interfaces. If the interfaces are reachable, then host B
streams multimedia data along multiple paths to host A. Moreover, streams multimedia data along multiple paths to host A. Moreover,
host B also sends RTCP Sender Reports (SR) for each subflow and host host B also sends RTCP Sender Reports (SR) for each subflow and host
A responds with a normal RTCP Receiver Report (RR) for the overall A responds with a normal RTCP Receiver Report (RR) for the overall
session as well as the receiver statistics for each subflow. Host B session as well as the receiver statistics for each subflow. Host B
distributes the packets across the subflows based on the individually distributes the packets across the subflows based on the individually
measured path characteristics. measured path characteristics.
Alternatively, to reduce media startup time, host B may start Alternatively, to reduce media startup time, host B may start
streaming multimedia data to host A's initiating interface and then streaming multimedia data to host A's initiating interface and then
perform connectivity checks for the other interfaces. This method of perform connectivity checks for the other interfaces. This method of
updating a single path session to a multipath session is called updating a single path session to a multipath session is called
skipping to change at page 10, line 45 skipping to change at page 10, line 45
of individual RTP sessions. A multipath session may be upgraded of individual RTP sessions. A multipath session may be upgraded
from a typical single path session, as and when new interfaces from a typical single path session, as and when new interfaces
appear or disappear. However, it is also possible to setup a appear or disappear. However, it is also possible to setup a
multipath session from the beginning, if the interfaces are multipath session from the beginning, if the interfaces are
available at the start of the multimedia session. available at the start of the multimedia session.
2. Expanding RTP: For a multipath session, each subflow MUST look 2. Expanding RTP: For a multipath session, each subflow MUST look
like an independent RTP flow, so that individual RTCP messages like an independent RTP flow, so that individual RTCP messages
can be generated per subflow. Furthermore, MPRTP splits the can be generated per subflow. Furthermore, MPRTP splits the
single multimedia stream into multiple subflows based on path single multimedia stream into multiple subflows based on path
characteristics (e.g. RTT, loss-rate, receiver rate, bandwidth- characteristics (e.g. RTT, loss-rate, receiver rate, bandwidth-
delay product etc.) and dynamically adjusts the load on each delay product etc.) and dynamically adjusts the load on each
link. link.
3. Adding Interfaces: Interfaces on the host need to be regularly 3. Adding Interfaces: Interfaces on the host need to be regularly
discovered and advertised. This can be done at session setup and discovered and advertised. This can be done at session setup
/or during the session. Discovering interfaces is outside the and/or during the session. Discovering interfaces is outside the
scope of this document. scope of this document.
4. Expanding RTCP: MPRTP MUST provide per path RTCP reports for 4. Expanding RTCP: MPRTP MUST provide per path RTCP reports for
monitoring the quality of the path, for load balancing, or for monitoring the quality of the path, for load balancing, or for
congestion control, etc. To maintain backward compatibility with congestion control, etc. To maintain backward compatibility with
legacy applications, the receiver MUST also send aggregate RTCP legacy applications, the receiver MUST also send aggregate RTCP
reports along with the per-path reports. reports along with the per-path reports.
5. Maintenance and Failure Handling: In a multi-homed endpoint 5. Maintenance and Failure Handling: In a multi-homed endpoint
interfaces may appear and disappear. If this occurs at the interfaces may appear and disappear. If this occurs at the
skipping to change at page 29, line 10 skipping to change at page 29, line 10
the RTCP reports for the active subflows based on the share of the the RTCP reports for the active subflows based on the share of the
transmitted or received bit rate to the average media bit rate, this transmitted or received bit rate to the average media bit rate, this
method ensures fair sharing of the RTCP bandwidth. Alternatively, method ensures fair sharing of the RTCP bandwidth. Alternatively,
the endpoint MAY schedule the reports in round-robin. the endpoint MAY schedule the reports in round-robin.
11. SDP Considerations 11. SDP Considerations
11.1. Signaling MPRTP Header Extension in SDP 11.1. Signaling MPRTP Header Extension in SDP
To indicate the use of the MPRTP header extensions (see Section 9) in To indicate the use of the MPRTP header extensions (see Section 9) in
SDP, the sender MUST use the following URI in extmap: urn:ietf:params SDP, the sender MUST use the following URI in extmap:
:rtp-hdrext:mprtp. This is a media level parameter. Legacy RTP urn:ietf:params:rtp-hdrext:mprtp. This is a media level parameter.
(non-MPRTP) clients will ignore this header extension, but can Legacy RTP (non-MPRTP) clients will ignore this header extension, but
continue to parse and decode the packet (see Appendix A). can continue to parse and decode the packet (see Appendix A).
Example: Example:
v=0 v=0
o=alice 2890844526 2890844527 IN IP4 192.0.2.1 o=alice 2890844526 2890844527 IN IP4 192.0.2.1
s= s=
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
t=0 0 t=0 0
m=video 49170 RTP/AVP 98 m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000 a=rtpmap:98 H264/90000
skipping to change at page 34, line 26 skipping to change at page 34, line 26
13. Security Considerations 13. Security Considerations
TBD TBD
All drafts are required to have a security considerations section. All drafts are required to have a security considerations section.
See RFC 3552 [RFC3552] for a guide. See RFC 3552 [RFC3552] for a guide.
14. Acknowledgements 14. Acknowledgements
Varun Singh, Saba Ahsan, and Teemu Karkkainen are supported by Varun Singh, Saba Ahsan, and Teemu Karkkainen are supported by
Trilogy (http://www.trilogy-project.org), a research project Trilogy (http://www.trilogy-project.org), a research project (ICT-
(ICT-216372) partially funded by the European Community under its 216372) partially funded by the European Community under its Seventh
Seventh Framework Program. The views expressed here are those of the Framework Program. The views expressed here are those of the
author(s) only. The European Commission is not liable for any use author(s) only. The European Commission is not liable for any use
that may be made of the information in this document. that may be made of the information in this document.
The work of Varun Singh and Joerg Ott from Aalto University has been The work of Varun Singh and Joerg Ott from Aalto University has been
partially supported by the European Institute of Innovation and partially supported by the European Institute of Innovation and
Technology (EIT) ICT Labs activity RCLD 11882. Technology (EIT) ICT Labs activity RCLD 11882.
Thanks to Roni Even , Miguel A. Garcia , Ralf Globisch , Christer Lars Eggert has received funding from the European Union's Horizon
2020 research and innovation program 2014-2018 under grant agreement
No. 644866. This document reflects only the authors' views and the
European Commission is not responsible for any use that may be made
of the information it contains.
Thanks to Roni Even , Miguel A. Garcia , Ralf Globisch , Christer
Holmberg , and Frederic Maze for providing valuable feedback on Holmberg , and Frederic Maze for providing valuable feedback on
earlier versions of this draft. earlier versions of this draft.
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
skipping to change at page 36, line 31 skipping to change at page 36, line 37
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, June 2011. Control Protocol (RTCP) Flows", RFC 6263, June 2011.
[I-D.singh-mmusic-mprtp-sdp-extension] [I-D.singh-mmusic-mprtp-sdp-extension]
Singh, V., Ott, J., Karkkainen, T., Globisch, R., and T. Singh, V., Ott, J., Karkkainen, T., Globisch, R., and T.
Schierl, "Multipath RTP (MPRTP) attribute in Session Schierl, "Multipath RTP (MPRTP) attribute in Session
Description Protocol", draft-singh-mmusic-mprtp-sdp- Description Protocol", draft-singh-mmusic-mprtp-sdp-
extension-03 (work in progress), January 2014. extension-04 (work in progress), September 2014.
[I-D.reddy-mmusic-ice-best-interface-pcp] [I-D.reddy-mmusic-ice-best-interface-pcp]
Reddy, T., Wing, D., Steeg, B., Penno, R., and V. Varun, Reddy, T., Wing, D., Steeg, B., Penno, R., and V. Varun,
"Improving ICE Interface Selection Using Port Control "Improving ICE Interface Selection Using Port Control
Protocol (PCP) Flow Extension", draft-reddy-mmusic-ice- Protocol (PCP) Flow Extension", draft-reddy-mmusic-ice-
best-interface-pcp-00 (work in progress), October 2013. best-interface-pcp-00 (work in progress), October 2013.
[I-D.wing-mmusic-ice-mobility] [I-D.wing-mmusic-ice-mobility]
Wing, D., Reddy, T., Patil, P., and P. Martinsen, Wing, D., Reddy, T., Patil, P., and P. Martinsen,
"Mobility with ICE (MICE)", draft-wing-mmusic-ice- "Mobility with ICE (MICE)", draft-wing-mmusic-ice-
mobility-06 (work in progress), February 2014. mobility-07 (work in progress), June 2014.
[I-D.ietf-rmcat-eval-criteria] [I-D.ietf-rmcat-eval-criteria]
Singh, V. and J. Ott, "Evaluating Congestion Control for Singh, V. and J. Ott, "Evaluating Congestion Control for
Interactive Real-time Media", draft-ietf-rmcat-eval- Interactive Real-time Media", draft-ietf-rmcat-eval-
criteria-00 (work in progress), January 2014. criteria-02 (work in progress), July 2014.
[ACM-MPRTP] [ACM-MPRTP]
Singh, V., Ahsan, S., and J. Ott, "MPRTP: multipath Singh, V., Ahsan, S., and J. Ott, "MPRTP: multipath
considerations for real-time media", in Proc. of ACM considerations for real-time media", in Proc. of ACM
Multimedia Systems, MMSys, 2013. Multimedia Systems, MMSys, 2013.
Appendix A. Interoperating with Legacy Applications Appendix A. Interoperating with Legacy Applications
Some legacy endpoints may abort processing incoming packets, if they Some legacy endpoints may abort processing incoming packets, if they
are received from different source address. This may occur due to are received from different source address. This may occur due to
skipping to change at page 39, line 49 skipping to change at page 40, line 14
Authors' Addresses Authors' Addresses
Varun Singh Varun Singh
Aalto University Aalto University
School of Electrical Engineering School of Electrical Engineering
Otakaari 5 A Otakaari 5 A
Espoo, FIN 02150 Espoo, FIN 02150
Finland Finland
Email: varun@comnet.tkk.fi Email: varun.singh@iki.fi
URI: http://www.netlab.tkk.fi/~varun/ URI: http://www.netlab.tkk.fi/~varun/
Teemu Karkkainen Teemu Karkkainen
Aalto University Aalto University
School of Electrical Engineering School of Electrical Engineering
Otakaari 5 A Otakaari 5 A
Espoo, FIN 02150 Espoo, FIN 02150
Finland Finland
Email: teemuk@comnet.tkk.fi Email: teemuk@comnet.tkk.fi
Joerg Ott Joerg Ott
 End of changes. 20 change blocks. 
26 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/