draft-ietf-avtcore-mprtp-02.txt   draft-ietf-avtcore-mprtp-03.txt 
AVT Core Working Group V. Singh AVT Core Working Group V. Singh
Internet-Draft callstats.io Internet-Draft callstats.io
Intended status: Experimental T. Karkkainen Intended status: Experimental T. Karkkainen
Expires: September 22, 2016 J. Ott Expires: January 9, 2017 J. Ott
Technical University of Munich Technical University of Munich
S. Ahsan S. Ahsan
Aalto University Aalto University
L. Eggert L. Eggert
NetApp NetApp
March 21, 2016 July 8, 2016
Multipath RTP (MPRTP) Multipath RTP (MPRTP)
draft-ietf-avtcore-mprtp-02 draft-ietf-avtcore-mprtp-03
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 48 skipping to change at page 1, line 48
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 September 22, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 40
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Functional goals . . . . . . . . . . . . . . . . . . . . 5 2.1. Functional goals . . . . . . . . . . . . . . . . . . . . 6
2.2. Compatibility goals . . . . . . . . . . . . . . . . . . . 6 2.2. Compatibility goals . . . . . . . . . . . . . . . . . . . 6
3. RTP Topologies . . . . . . . . . . . . . . . . . . . . . . . 6 3. RTP Topologies . . . . . . . . . . . . . . . . . . . . . . . 7
4. MPRTP Architecture . . . . . . . . . . . . . . . . . . . . . 6 4. MPRTP Architecture . . . . . . . . . . . . . . . . . . . . . 7
5. Example Media Flow Diagrams . . . . . . . . . . . . . . . . . 8 5. Example Media Flow Diagrams . . . . . . . . . . . . . . . . . 8
5.1. Streaming use-case . . . . . . . . . . . . . . . . . . . 8 5.1. Streaming use-case . . . . . . . . . . . . . . . . . . . 8
5.2. Conversational use-case . . . . . . . . . . . . . . . . . 9 5.2. Conversational use-case . . . . . . . . . . . . . . . . . 9
6. MPRTP Functional Blocks . . . . . . . . . . . . . . . . . . . 10 6. MPRTP Functional Blocks . . . . . . . . . . . . . . . . . . . 10
7. Available Mechanisms within the Functional Blocks . . . . . . 11 7. Available Mechanisms within the Functional Blocks . . . . . . 11
7.1. Session Setup . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Session Setup . . . . . . . . . . . . . . . . . . . . . . 11
7.1.1. Connectivity Checks . . . . . . . . . . . . . . . . . 11 7.1.1. Connectivity Checks . . . . . . . . . . . . . . . . . 11
7.1.2. Adding New or Updating Interfaces . . . . . . . . . . 11 7.1.2. Adding New or Updating Interfaces . . . . . . . . . . 12
7.1.3. In-band vs. Out-of-band Signaling . . . . . . . . . . 12 7.1.3. In-band vs. Out-of-band Signaling . . . . . . . . . . 12
7.2. Expanding RTP . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Expanding RTP . . . . . . . . . . . . . . . . . . . . . . 13
7.3. Expanding RTCP . . . . . . . . . . . . . . . . . . . . . 13 7.3. Expanding RTCP . . . . . . . . . . . . . . . . . . . . . 13
7.4. Failure Handling and Teardown . . . . . . . . . . . . . . 14 7.4. Failure Handling and Teardown . . . . . . . . . . . . . . 14
8. MPRTP Protocol . . . . . . . . . . . . . . . . . . . . . . . 14 8. MPRTP Protocol . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1.1. Gather or Discovering Candidates . . . . . . . . . . 15 8.1.1. Gather or Discovering Candidates . . . . . . . . . . 15
8.1.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . 15 8.1.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . 15
8.1.3. Choosing between In-band (in RTCP) and Out-of-band 8.1.3. Choosing between In-band (in RTCP) and Out-of-band
(in SDP) Interface Advertisement . . . . . . . . . . 16 (in SDP) Interface Advertisement . . . . . . . . . . 16
8.1.4. In-band Interface Advertisement . . . . . . . . . . . 16 8.1.4. In-band Interface Advertisement . . . . . . . . . . . 16
8.1.5. Subflow ID Assignment . . . . . . . . . . . . . . . . 17 8.1.5. Subflow ID Assignment . . . . . . . . . . . . . . . . 17
8.1.6. Active and Passive Subflows . . . . . . . . . . . . . 17 8.1.6. Active and Passive Subflows . . . . . . . . . . . . . 17
8.2. RTP Transmission . . . . . . . . . . . . . . . . . . . . 17 8.2. RTP Transmission . . . . . . . . . . . . . . . . . . . . 18
8.3. Playout Considerations at the Receiver . . . . . . . . . 18 8.3. Playout Considerations at the Receiver . . . . . . . . . 18
8.4. Subflow-specific RTCP Statistics and RTCP Aggregation . . 18 8.4. Subflow-specific RTCP Statistics and RTCP Aggregation . . 18
8.5. RTCP Transmission . . . . . . . . . . . . . . . . . . . . 19 8.5. RTCP Transmission . . . . . . . . . . . . . . . . . . . . 19
9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 19 9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. RTP Header Extension for MPRTP . . . . . . . . . . . . . 19 9.1. RTP Header Extension for MPRTP . . . . . . . . . . . . . 19
9.1.1. MPRTP RTP Extension for a Subflow . . . . . . . . . . 20 9.1.1. MPRTP RTP Extension for a Subflow . . . . . . . . . . 21
9.2. RTCP Extension for MPRTP (MPRTCP) . . . . . . . . . . . . 21 9.2. RTCP Extension for MPRTP (MPRTCP) . . . . . . . . . . . . 21
9.2.1. MPRTCP Extension for Subflow Reporting . . . . . . . 23 9.2.1. MPRTCP Extension for Subflow Reporting . . . . . . . 23
9.2.1.1. MPRTCP for Subflow-specific SR, RR and XR . . . . 25 9.2.1.1. MPRTCP for Subflow-specific SR, RR and XR . . . . 25
9.3. MPRTCP Extension for Interface advertisement . . . . . . 27 9.3. MPRTCP Extension for Interface advertisement . . . . . . 27
10. RTCP Timing reconsiderations for MPRTCP . . . . . . . . . . . 28 10. RTCP Timing reconsiderations for MPRTCP . . . . . . . . . . . 28
11. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 29
11.1. Signaling MPRTP Header Extension in SDP . . . . . . . . 29 11.1. Signaling MPRTP Header Extension in SDP . . . . . . . . 29
11.2. Signaling MPRTP capability in SDP . . . . . . . . . . . 29 11.2. Signaling MPRTP capability in SDP . . . . . . . . . . . 29
11.3. MPRTP with ICE . . . . . . . . . . . . . . . . . . . . . 30 11.3. MPRTP with ICE . . . . . . . . . . . . . . . . . . . . . 30
11.4. Increased Throughput . . . . . . . . . . . . . . . . . . 30 11.4. Increased Throughput . . . . . . . . . . . . . . . . . . 30
skipping to change at page 3, line 34 skipping to change at page 3, line 34
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 . . . . . . . . . . . . . . . . . . 35 15.1. Normative References . . . . . . . . . . . . . . . . . . 35
15.2. Informative References . . . . . . . . . . . . . . . . . 36 15.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Interoperating with Legacy Applications . . . . . . 37 Appendix A. Interoperating with Legacy Applications . . . . . . 37
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 38 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 38
B.1. Changes in draft-ietf-avtcore-mprtp-01, and -02 . . . . . 38 B.1. Changes in draft-ietf-avtcore-mprtp-03 . . . . . . . . . 38
B.2. Changes in draft-ietf-avtcore-mprtp-00 . . . . . . . . . 38 B.2. Changes in draft-ietf-avtcore-mprtp-01, and -02 . . . . . 38
B.3. Changes in draft-singh-avtcore-mprtp-10 . . . . . . . . . 38 B.3. Changes in draft-ietf-avtcore-mprtp-00 . . . . . . . . . 38
B.4. Changes in draft-singh-avtcore-mprtp-09 . . . . . . . . . 38 B.4. Changes in draft-singh-avtcore-mprtp-10 . . . . . . . . . 38
B.5. Changes in draft-singh-avtcore-mprtp-08 . . . . . . . . . 38 B.5. Changes in draft-singh-avtcore-mprtp-09 . . . . . . . . . 38
B.6. Changes in draft-singh-avtcore-mprtp-06 and -07 . . . . . 38 B.6. Changes in draft-singh-avtcore-mprtp-08 . . . . . . . . . 38
B.7. Changes in draft-singh-avtcore-mprtp-05 . . . . . . . . . 38 B.7. Changes in draft-singh-avtcore-mprtp-06 and -07 . . . . . 39
B.8. Changes in draft-singh-avtcore-mprtp-04 . . . . . . . . . 39 B.8. Changes in draft-singh-avtcore-mprtp-05 . . . . . . . . . 39
B.9. Changes in draft-singh-avtcore-mprtp-03 . . . . . . . . . 39 B.9. Changes in draft-singh-avtcore-mprtp-04 . . . . . . . . . 39
B.10. Changes in draft-singh-avtcore-mprtp-02 . . . . . . . . . 39 B.10. Changes in draft-singh-avtcore-mprtp-03 . . . . . . . . . 39
B.11. Changes in draft-singh-avtcore-mprtp-01 . . . . . . . . . 40 B.11. Changes in draft-singh-avtcore-mprtp-02 . . . . . . . . . 40
B.12. Changes in draft-singh-avtcore-mprtp-01 . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 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
achieved by pooling their respective capacities. achieved by pooling their respective capacities.
Multipath RTP (MPRTP) is an OPTIONAL extension to RTP [RFC3550] that Multipath RTP (MPRTP) is an extension to RTP [RFC3550] which splits a
allows splitting a single RTP stream into multiple subflows that are single RTP Stream [RFC7656] (At any given point in time, an RTP
transmitted over different paths. In effect, this pools the resource stream can have one and only one SSRC) into multiple subflows that
are transmitted over different network interfaces paths (i.e., 2- out
of the 5-tuples are different). In effect, this pools the resource
capacity of multiple paths. Multipath RTCP (MPRTCP) is an extension capacity of multiple paths. Multipath RTCP (MPRTCP) is an extension
to RTCP, it is used along with MPRTP to report per-path sender and to RTCP, it is used along with MPRTP to report sender and receiver
receiver characteristics. characteristics for each subflow.
Other IETF transport protocols that are capable of using multiple Other IETF transport protocols that are capable of using multiple
paths include SCTP [RFC4960], MPTCP [RFC6182] and SHIM6 [RFC5533]. paths include SCTP [RFC4960], MPTCP [RFC6182] and SHIM6 [RFC5533].
However, these protocols are not suitable for real-time However, these protocols are not suitable for real-time
communications. communications.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
o Endpoint: host either initiating or terminating an RTP flow. o Endpoint: corresponds to a single host either initiating or
terminating a communication session [RFC7656].
o Interface: logical or physical component that is capable of o Interface: logical or physical component that is capable of
acquiring a unique IP address. acquiring a unique IP address.
o Path: sequence of links between a sender and a receiver. o Path: sequence of links between a sender and a receiver.
Typically, defined by a set of source and destination addresses. Typically, defined by a set of source and destination addresses.
In the context of RTP taxonomy [RFC7656] it best matches a media
transports.
o Subflow: flow of RTP packets along a specific path, i.e., a subset o Multipath RTP Stream: An RTP Stream that makes use of one or more
of the packets belonging to an RTP stream. The combination of all paths, i.e., simultaneously makes use of multiple media transports
RTP subflows forms the complete RTP stream. Typically, a subflow to send and receive from a particular RTP Stream. In cases, where
would map to a unique path, i.e., each combination of IP addresses a single path is available, an MPRTP Stream will appear to be an
and port pairs (5-tuple, including protocol) is a unique subflow. RTP Stream.
o MPRTP Subflow: The RTP packets from a single RTP Stream that are
sent or received over a particular media transport are identified
as a subflow. Therefore, an MPRTP Stream has several subflows,
each subflow is associated to a particular media transport.
o Subflow Identifier: within a communication session, the subflow
identifier denotes the RTP packets belonging to a RTP Stream sent
over a particular media transport. There are two design choices:
* Each media transport at an endpoint chooses a unique identifier
for itself, and the Subflow RTP Streams use the chosen
identifier.
* The RTP Stream chooses distinct identifiers for each Subflow
RTP stream
1.3. Use-cases 1.3. Use-cases
The primary use-case for MPRTP is transporting high bit-rate The primary use-case for MPRTP is transporting high bit-rate
streaming multimedia content between endpoints, where at least one is streaming multimedia content between endpoints, where at least one is
multi-homed. Such endpoints could be residential IPTV devices that multi-homed. Such endpoints could be residential IPTV devices that
connect to the Internet through two different Internet service connect to the Internet through two different Internet service
providers (ISPs), or mobile devices that connect to the Internet providers (ISPs), or mobile devices that connect to the Internet
through 3G and WLAN interfaces. By allowing RTP to use multiple through 3G and WLAN interfaces. By allowing a single RTP Stream to
paths for transmission, the following gains can be achieved: use multiple paths for transmission, the following gains can be
achieved:
o Higher quality: Pooling the resource capacity of multiple Internet o Higher quality: Pooling the resource capacity of multiple Internet
paths allows higher bit-rate and higher quality codecs to be used. paths allows higher bit-rate and higher quality codecs to be used.
From the application perspective, the available bandwidth between From the application perspective, the available bandwidth between
the two endpoints increases. the two endpoints increases.
o Load balancing: Transmitting an RTP stream over multiple paths o Load balancing: Transmitting a single RTP stream (or several RTP
reduces the bandwidth usage on a single path, which in turn streams) over multiple paths reduces the bandwidth usage on each
reduces the impact of the media stream on other traffic on that path, which in turn reduces the impact of the media stream(s) on
path. other traffic on those paths.
o Fault tolerance: When multiple paths are used in conjunction with o Fault tolerance: When multiple paths are used in conjunction with
redundancy mechanisms (FEC, re-transmissions, etc.), outages on redundancy mechanisms (FEC, re-transmissions, etc.), outages on
one path have less impact on the overall perceived quality of the one path have less impact on the overall perceived quality of the
stream. media stream.
A secondary use-case for MPRTP is transporting Voice over IP (VoIP) A secondary use-case for MPRTP is transporting Voice over IP (VoIP)
calls to a device with multiple interfaces. Again, such an endpoint calls to a device with multiple interfaces. Again, such an endpoint
could be a mobile device with multiple wireless interfaces. In this could be a mobile device with multiple wireless interfaces. In this
case, little is to be gained from resource pooling, i.e., higher case, little is to be gained from resource pooling, i.e., higher
capacity or load balancing, because a single path should be easily capacity or load balancing, because a single path should be easily
capable of handling the required load. However, using multiple capable of handling the required load. However, using multiple
concurrent subflows can improve fault tolerance, because traffic can concurrent subflows can improve fault tolerance, because traffic can
shift between the subflows when path outages occur. This results in shift between the subflows when path outages occur. This results in
very fast transport-layer handovers that do not require support from very fast transport-layer handovers that do not require support from
signaling. signaling.
2. Goals 2. Goals
This section outlines the basic goals that multipath RTP aims to This section outlines the basic goals that multipath RTP aims to
meet. These are broadly classified as Functional goals and meet. These are broadly classified as Functional goals and
Compatibility goals. Compatibility goals.
2.1. Functional goals 2.1. Functional goals
Allow unicast RTP session to be split into multiple subflows in order Allow an unicast RTP Stream to be split into multiple subflows in
to be carried over multiple paths. This may prove beneficial in case order to be carried over multiple paths. This may prove beneficial
of video streaming. in case of video streaming.
o Increased Throughput: Cumulative capacity of the two paths may o Increased Throughput: Cumulative capacity of the two paths may
meet the requirements of the multimedia session. Therefore, MPRTP meet the requirements of the multimedia session. Therefore, MPRTP
MUST support concurrent use of the multiple paths. MUST support concurrent use of the multiple paths.
o Improved Reliability: MPRTP SHOULD be able to send redundant o Improved Reliability: MPRTP SHOULD be able to send redundant
packets or re-transmit packets along any available path to packets or re-transmit packets along any available path to
increase reliability. increase reliability.
The protocol SHOULD be able to open new subflows for an existing The protocol SHOULD be able to open new subflows for an existing
session when new paths appear and MUST be able to close subflows when multimedia session when new paths appear and MUST be able to close
paths disappear. subflows when paths disappear.
2.2. Compatibility goals 2.2. Compatibility goals
MPRTP MUST be backwards compatible; an MPRTP stream needs to fall Multipath RTP (MPRTP) MUST be backwards compatible; an MPRTP Stream
back to be compatible with legacy RTP stacks if MPRTP support is not needs to fall back to be compatible with legacy RTP stacks if MPRTP
successfully negotiated. support is not successfully negotiated.
o Application Compatibility: MPRTP service model MUST be backwards o Application Compatibility: MPRTP service model MUST be backwards
compatible with existing RTP applications, i.e., an MPRTP stack compatible with existing RTP applications, i.e., an MPRTP stack
MUST be able to work with legacy RTP applications and not require MUST be able to work with legacy RTP applications and not require
changes to them. Therefore, the basic RTP APIs MUST remain changes to them. Therefore, the basic RTP APIs MUST remain
unchanged, but an MPRTP stack MAY provide extended APIs so that unchanged, but an MPRTP stack MAY provide extended APIs so that
the application can configure any additional features provided by the application can configure any additional features provided by
the MPRTP stack. the MPRTP stack.
o Network Compatibility: individual RTP subflows MUST themselves be o Network Compatibility: individual MPRTP subflows MUST themselves
well-formed RTP flows, so that they are able to traverse NATs and be flows of well-formed RTP packets, so that they are able to
firewalls. This MUST be the case even when interfaces appear traverse NATs and firewalls. This MUST be the case even when
after session initiation. Interactive Connectivity Establishment interfaces appear after session initiation. Interactive
(ICE) [RFC5245] MAY be used for discovering new interfaces or Connectivity Establishment (ICE) [RFC5245] MAY be used for
performing connectivity checks. discovering new interfaces or performing connectivity checks.
3. RTP Topologies 3. RTP Topologies
RFC 5117 [RFC5117] describes a number of scenarios using mixers and RFC 5117 [RFC5117] describes a number of scenarios using mixers and
translators in single-party (point-to-point), and multi-party (point- translators in single-party (point-to-point), and multi-party (point-
to-multipoint) scenarios. RFC 3550 [RFC3550] (Section 2.3 and 7.x) to-multipoint) scenarios. RFC 3550 [RFC3550] (Section 2.3 and 7.x)
discuss in detail the impact of mixers and translators on RTP and discuss in detail the impact of mixers and translators on RTP and
RTCP packets. MPRTP assumes that if a mixer or translator exists in RTCP packets. MPRTP assumes that if a mixer or translator exists in
the network, then either all of the multiple paths or none of the the network, then either all of the multiple paths or none of the
multiple paths go via this component. multiple paths go via this component.
4. MPRTP Architecture 4. MPRTP Architecture
In a typical scenario, an RTP session uses a single path. In an In a typical scenario, an RTP Stream uses a single path. In an MPRTP
MPRTP scenario, an RTP session uses multiple subflows that each use a scenario, an RTP Stream uses multiple subflows, those subflows may
different path. Figure 1 shows the difference. each use a different path. Figure 1 shows the difference.
+--------------+ Signaling +--------------+ +--------------+ Signaling +--------------+
| |------------------------------------>| | | |------------------------------------>| |
| Client |<------------------------------------| Server | | Client |<------------------------------------| Server |
| | Single RTP flow | | | | Single RTP Stream | |
+--------------+ +--------------+ +--------------+ +--------------+
+--------------+ Signaling +--------------+ +--------------+ Signaling +--------------+
| |------------------------------------>| | | |------------------------------------>| |
| Client |<------------------------------------| Server | | Client |<------------------------------------| Server |
| |<------------------------------------| | | |<------------------------------------| |
+--------------+ MPRTP subflows +--------------+ +--------------+ MPRTP subflows +--------------+
Figure 1: Comparison between traditional RTP streaming and MPRTP Figure 1: Comparison between traditional RTP streaming and MPRTP
+-----------------------+ +-------------------------------+ +-----------------------+ +-------------------------------+
| Application | | Application | | Application | | Application |
+-----------------------+ +-------------------------------+ +-----------------------+ +-------------------------------+
| | | MPRTP | | | | RTP |
+ RTP + +- - - - - - - -+- - - - - - - -+ + RTP + +- - - - - - - -+- - - - - - - -+
| | | RTP subflow | RTP subflow | | | | MPRTP subflow | MPRTP subflow |
+-----------------------+ +---------------+---------------+ +-----------------------+ +---------------+---------------+
| UDP | | UDP | UDP | | UDP | | UDP | UDP |
+-----------------------+ +---------------+---------------+ +-----------------------+ +---------------+---------------+
| IP | | IP | IP | | IP | | IP | IP |
+-----------------------+ +---------------+---------------+ +-----------------------+ +---------------+---------------+
Figure 2: MPRTP Architecture Figure 2: MPRTP Architecture
Figure 2 illustrates the differences between the standard RTP stack Figure 2 illustrates the differences between the standard RTP stack
and the MPRTP stack. MPRTP receives a normal RTP session from the and the MPRTP stack. MPRTP receives a normal RTP Stream from the
application and splits it into multiple RTP subflows. Each subflow application and splits it into multiple RTP subflows. Each subflow
is then sent along a different path to the receiver. To the network, is then sent along a different path to the receiver. To the network,
each subflow appears as an independent, well-formed RTP flow. At the each subflow appears as an independent flow of well-formed RTP
receiver, the subflows are combined to recreate the original RTP packets. At the receiver, the subflows are combined to recreate the
session. The MPRTP layer performs the following functions: original RTP Stream. The MPRTP layer performs the following
functions:
o Path Management: The layer is aware of alternate paths to the o Path Management: The layer is aware of alternate paths to the
other host, which may, for example, be the peer's multiple other host, which may, for example, be the peer's multiple
interfaces. This enables the endpoint to transmit differently interfaces. This enables the endpoint to transmit differently
marked packets along separate paths. MPRTP also selects marked packets along separate paths. MPRTP also selects
interfaces to send and receive data. Furthermore, it manages the interfaces to send and receive data. Furthermore, it manages the
port and IP address pair bindings for each subflow. port and IP address pair bindings for each subflow.
o Packet Scheduling: the layer splits a single RTP flow into o Packet Scheduling: the layer splits a single RTP Stream into
multiple subflows and sends them across multiple interfaces multiple subflows and sends them across multiple interfaces
(paths). The splitting MAY BE done using different path (paths). The splitting MAY BE done using different path
characteristics. characteristics.
o Subflow recombination: the layer creates the original stream by o Subflow recombination: the layer creates the original RTP stream
recombining the independent subflows. Therefore, the multipath by recombining the independent subflows associated with the RTP
subflows appear as a single RTP stream to applications. Stream. Therefore, the subflows are eventually presented as a
single RTP stream to the applications.
5. Example Media Flow Diagrams 5. Example Media Flow Diagrams
There may be many complex technical scenarios for MPRTP, however, There may be many complex technical scenarios for MPRTP, however,
this memo only considers the following two scenarios: 1) a this memo only considers the following two scenarios: 1) a
unidirectional media flow that represents the streaming use-case, and unidirectional media stream that represents the streaming use-case,
2) a bidirectional media flow that represents a conversational use- and 2) a bidirectional media stream that represents a conversational
case. use-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 the overall session
A responds with a normal RTCP Receiver Report (RR) for the overall and for each subflow and host A responds with a normal RTCP Receiver
session as well as the receiver statistics for each subflow. Host B Report (RR) for the overall session as well as the receiver
distributes the packets across the subflows based on the individually statistics for each subflow. Host B distributes the packets across
measured path characteristics. the subflows based on the individually 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
"multipath session upgrade". "multipath session upgrade".
Host A Host B Host A Host B
----------------------- ---------- ----------------------- ----------
Interface A1 Interface A2 Interface B1 Interface A1 Interface A2 Interface B1
skipping to change at page 10, line 33 skipping to change at page 10, line 33
Figure 4: Bidirectional flow Figure 4: Bidirectional flow
6. MPRTP Functional Blocks 6. MPRTP Functional Blocks
This section describes some of the functional blocks needed for This section describes some of the functional blocks needed for
MPRTP. We then investigate each block and consider available MPRTP. We then investigate each block and consider available
mechanisms in the next section. mechanisms in the next section.
1. Session Setup: Interfaces may appear or disappear at anytime 1. Session Setup: Interfaces may appear or disappear at anytime
during the session. To preserve backward compatibility with during the communication session. To preserve backward
legacy applications, a multipath session MUST look like a bundle compatibility with legacy applications, a MPRTP session MUST look
of individual RTP sessions. A multipath session may be upgraded like a bundle of individual RTP sessions. A MPRTP session may
from a typical single path session, as and when new interfaces start using a single path, later start using multiple paths as
appear or disappear. However, it is also possible to setup a and when new interfaces appear or disappear. However, it is also
multipath session from the beginning, if the interfaces are possible to setup a MPRTP session from the beginning, if multiple
available at the start of the multimedia session. interfaces are available at the start of the multimedia session.
2. Expanding RTP: For a multipath session, each subflow MUST look 2. Expanding RTP: For a MPRTP Stream, each subflow MUST look like an
like an independent RTP flow, so that individual RTCP messages independent flow of RTP packets, so that individual RTCP messages
can be generated per subflow. Furthermore, MPRTP splits the can be generated for each subflow. Consequently, MPRTP may split
single multimedia stream into multiple subflows based on path the RTP Stream into multiple subflows based on path
characteristics (e.g. RTT, loss-rate, receiver rate, bandwidth- characteristics (e.g. RTT, fractional losses, receiver rate,
delay product etc.) and dynamically adjusts the load on each bandwidth-delay product, etc.), i.e., dynamically adjusts the
link. load on each subflow.
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 discovered and advertised. This can be done when the MPRTP
and/or during the session. Discovering interfaces is outside the session is set up and/or during the communication session.
scope of this document. Discovering interfaces is outside the 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
sender, it has to re-adjust the load on the available links. On sender, it has to re-adjust the load on the available paths. On
the other hand, if this occurs at the receiver, then the the other hand, if this occurs at the receiver, then the
multimedia data transmitted by the sender to those interfaces is multimedia data transmitted by the sender to those interfaces is
lost. This data may be re-transmitted along a different path lost. This data may be re-transmitted along a different path
i.e., to a different interface on the receiver. Furthermore, the i.e., to a different interface on the receiver. Furthermore, the
endpoint has to either explicitly signal the disappearance of an endpoint has to either explicitly signal the disappearance of an
interface, or the other endpoint has to detect it (by lack of interface, or the other endpoint has to detect it (by lack of
media packets, RTCP feedback, or keep-alive packets). media packets, RTCP feedback, or keep-alive packets).
6. Teardown: The MPRTP layer releases the occupied ports on the 6. Teardown: The MPRTP layer releases the occupied ports on the
interfaces. interfaces.
skipping to change at page 11, line 40 skipping to change at page 11, line 40
7.1. Session Setup 7.1. Session Setup
MPRTP session can be set up in many possible ways e.g., during MPRTP session can be set up in many possible ways e.g., during
handshake, or upgraded mid-session. The capability exchange may be handshake, or upgraded mid-session. The capability exchange may be
done using out-of-band signaling (e.g., Session Description Protocol done using out-of-band signaling (e.g., Session Description Protocol
(SDP) [RFC3264] in Session Initiation Protocol (SIP) [RFC3261], Real- (SDP) [RFC3264] in Session Initiation Protocol (SIP) [RFC3261], Real-
Time Streaming Protocol (RTSP) [I-D.ietf-mmusic-rfc2326bis]) or in- Time Streaming Protocol (RTSP) [I-D.ietf-mmusic-rfc2326bis]) or in-
band signaling (e.g., RTP/RTCP header extension, Session Traversal band signaling (e.g., RTP/RTCP header extension, Session Traversal
Utilities for NAT (STUN) messages). Utilities for NAT (STUN) messages).
[Editor's Note: , with continuous ICE Nomination.]
7.1.1. Connectivity Checks 7.1.1. Connectivity Checks
The endpoint SHOULD be capable of performing connectivity checks The endpoint SHOULD be capable of performing connectivity checks
(e.g., using ICE [RFC5245]). If the IP addresses of the endpoints (e.g., using ICE [RFC5245]). If the IP addresses of the endpoints
are reachable (e.g., globally addressable, same network etc) then are reachable (e.g., globally addressable, same network etc) then
connectivity checks are not needed. connectivity checks are not needed.
7.1.2. Adding New or Updating Interfaces 7.1.2. Adding New or Updating Interfaces
Interfaces can appear and disappear during a session, the endpoint Interfaces can appear and disappear during a MPRTP session, the
MUST be capable of advertising the changes in its set of usable endpoint MUST be capable of advertising the changes in its set of
interfaces. Additionally, the application or OS may define a policy usable interfaces. Additionally, the application or OS may define a
on when and/or what interfaces are usable. However, MPRTP requires a policy on when and/or what interfaces are usable. However, MPRTP
method to advertise or notify the other endpoint about the updated requires a method to advertise or notify the other endpoint about the
set of usable interfaces. updated set of usable interfaces.
7.1.3. In-band vs. Out-of-band Signaling 7.1.3. In-band vs. Out-of-band Signaling
MTRTP nodes will generally use a signaling protocol to establish MPRTP nodes will generally use a signaling protocol to establish
their MPRTP session. With the existence of such a signaling their MPRTP session. With the existence of such a signaling
relationship, two alternatives become available to exchange relationship, two alternatives become available to exchange
information about the available interfaces on each side for extending information about the available interfaces on each side for extending
RTP sessions to MPRTP and for modifying MPRTP sessions: in-band and RTP sessions to MPRTP and for modifying MPRTP sessions: in-band and
out-of-band signaling. out-of-band signaling.
In-band signaling refers to using mechanisms of RTP/RTCP itself to In-band signaling refers to using mechanisms of RTP/RTCP itself to
communicate interface addresses, e.g., a dedicated RTCP extensions communicate interface addresses, e.g., a dedicated RTCP extensions
along the lines of the one defined to communicate information about along the lines of the one defined to communicate information about
the feedback target for RTP over SSM [RFC5760]. In-band signaling the feedback target for RTP over SSM [RFC5760]. In-band signaling
skipping to change at page 13, line 30 skipping to change at page 13, line 36
provide a broad understanding of how the corresponding mechanisms provide a broad understanding of how the corresponding mechanisms
would look like. would look like.
7.2. Expanding RTP 7.2. Expanding RTP
RTCP [RFC3550] is generated per media session. However, with MPRTP, RTCP [RFC3550] is generated per media session. However, with MPRTP,
the media sender spreads the RTP load across several interfaces. The the media sender spreads the RTP load across several interfaces. The
media sender SHOULD make the path selection, load balancing and fault media sender SHOULD make the path selection, load balancing and fault
tolerance decisions based on the characteristics of each path. tolerance decisions based on the characteristics of each path.
Therefore, apart from normal RTP sequence numbers defined in Therefore, apart from normal RTP sequence numbers defined in
[RFC3550], the MPRTP sender MUST add subflow-specific sequence [RFC3550], the MPRTP sender MUST add the following within the SSRC
numbers to help calculate fractional losses, jitter, RTT, playout scope, subflow-specific sequence numbers to help calculate fractional
time, etc., for each path, and a subflow identifier to associate the losses, jitter, RTT, playout time, etc., for each subflow, and a
characteristics with a path. The RTP header extension for MPRTP is subflow identifier to associate the characteristics with a path. The
shown in Section 9.1. RTP header extension for MPRTP is shown in Section 9.1.
7.3. Expanding RTCP 7.3. Expanding RTCP
To provide accurate per path information an MPRTP endpoint MUST send To provide accurate per path information an MPRTP endpoint MUST send
(SR/RR) report for each unique subflow along with the overall session (SR/RR) report for each unique subflow along with the overall session
RTCP report. Therefore, the additional subflow reporting affects the RTCP report. Therefore, the additional subflow reporting affects the
RTCP bandwidth and the RTCP reporting interval. RTCP report RTCP bandwidth and the RTCP reporting interval. RTCP report
scheduling for each subflow may cause a problem for RTCP scheduling for each subflow may cause a problem for RTCP
recombination and reconstruction in cases when 1) RTCP for a subflow recombination and reconstruction in cases when 1) RTCP for a subflow
is lost, and 2) RTCP for a subflow arrives later than the other is lost, and 2) RTCP for a subflow arrives later than the other
skipping to change at page 14, line 14 skipping to change at page 14, line 17
7.4. Failure Handling and Teardown 7.4. Failure Handling and Teardown
An MPRTP endpoint MUST keep alive subflows that have been negotiated An MPRTP endpoint MUST keep alive subflows that have been negotiated
but no media is sent on them. Moreover, using the information in the but no media is sent on them. Moreover, using the information in the
subflow reports, a sender can monitor an active subflow for failure subflow reports, a sender can monitor an active subflow for failure
(errors, unreachability, congestion) and decide not to use (make the (errors, unreachability, congestion) and decide not to use (make the
active subflow passive), or teardown the subflow. active subflow passive), or teardown the subflow.
If an interface disappears, the endpoint MUST send an updated If an interface disappears, the endpoint MUST send an updated
interface advertisement without the interface and release the the interface advertisement without the interface and release the
associated subflows. associated subflows.
8. MPRTP Protocol 8. MPRTP Protocol
Host A Host B Host A Host B
----------------------- ----------------------- ----------------------- -----------------------
Interface A1 Interface A2 Interface B1 Interface B2 Interface A1 Interface A2 Interface B1 Interface B2
----------------------- ----------------------- ----------------------- -----------------------
| | | | | | | |
| | (1) | | | | (1) | |
skipping to change at page 16, line 33 skipping to change at page 16, line 33
performance. performance.
[Editors note: The interaction between the RTP agent and ICE agent is [Editors note: The interaction between the RTP agent and ICE agent is
needed for implementing a scheduling algorithm or congestion control. needed for implementing a scheduling algorithm or congestion control.
See details of a scheduling algorithm in [ACM-MPRTP].] See details of a scheduling algorithm in [ACM-MPRTP].]
8.1.3. Choosing between In-band (in RTCP) and Out-of-band (in SDP) 8.1.3. Choosing between In-band (in RTCP) and Out-of-band (in SDP)
Interface Advertisement Interface Advertisement
If there is no media flowing at the moment and the application wants If there is no media flowing at the moment and the application wants
to use the interfaces from the start of the session, it should to use the interfaces from the start of the communication session, it
advertise them in SDP (See [I-D.singh-mmusic-mprtp-sdp-extension]). should advertise them in SDP (See
Alternatively, the endpoint can setup the session as a single path [I-D.singh-mmusic-mprtp-sdp-extension]). Alternatively, the endpoint
media session and upgrade the session to multipath by advertising the can setup the session as a single path communication session and
session in-band (See Section 8.1.4 or upgrade the session to multipath by advertising the session in-band
[I-D.wing-mmusic-ice-mobility]). Moreover, if an interface appears (See Section 8.1.4 or [I-D.wing-mmusic-ice-mobility]). Moreover, if
and disappears, the endpoint SHOULD prefer to advertise it in-band an interface appears and disappears, the endpoint SHOULD prefer to
because the endpoint would not have to wait for a response from the advertise it in-band because the endpoint would not have to wait for
other endpoint before starting to use the interface. However, if a response from the other endpoint before starting to use the
there is a conflict between an in-band and out-of-band advertisement, interface. However, if there is a conflict between an in-band and
i.e., the endpoint receives an in-band advertisement while it has a out-of-band advertisement, i.e., the endpoint receives an in-band
pending out-of-band advertisement, or vice versa then the session is advertisement while it has a pending out-of-band advertisement, or
setup using out-of-band mechanisms. vice versa then the session is setup using out-of-band mechanisms.
8.1.4. In-band Interface Advertisement 8.1.4. In-band Interface Advertisement
To advertise the multiple interfaces in RTCP, an MPRTP-capable To advertise the multiple interfaces in RTCP, an MPRTP-capable
endpoint MUST add the MPRTP Interface Advertisement defined in endpoint SHOULD add the MPRTP Interface Advertisement defined in
Figure 13 with the RTCP Sender Report (SR). Each unique address is Figure 13 with an RTCP Sender Report (SR) or RTCP Receiver Report
encapsulated in an Interface Advertisement block and contains the IP (RR). If reduced-size [RFC5506] RTCP is used, the interface
address, RTP and RTCP port addresses. The Interface Advertisement advertisements can be sent separately depending on the RTCP timing
blocks are ordered based on a decreasing priority level. On rules.
receiving the MPRTP Interface Advertisement, an MPRTP-capable
receiver MUST respond with the set of interfaces (subset or all Each unique address is encapsulated in an Interface Advertisement
available) it wants to use. block and contains the IP address, RTP port addresses. The Interface
Advertisement blocks are ordered based on a decreasing priority
level. On receiving the MPRTP Interface Advertisement, an MPRTP-
capable receiver MUST respond with the set of interfaces (subset or
all available) it wants to use.
If the sender and receiver have only one interface, then the If the sender and receiver have only one interface, then the
endpoints MUST indicate the negotiated single path IP, RTP port and endpoints MUST indicate the negotiated single path IP, RTP port
RTCP port addresses. addresses.
[Editor: Do we still need this: could use passive/aggressive
nomination? or perform an ice restart?]
8.1.5. Subflow ID Assignment 8.1.5. Subflow ID Assignment
After interface advertisements have been exchanged, the endpoint MUST After interface advertisements have been exchanged, the endpoint MUST
associate a Subflow ID to each unique subflow. Each combination of associate a Subflow ID to each unique subflow. Each combination of
sender and receiver IP addresses and port pairs (5-tuple) is a unique sender and receiver IP addresses and port pairs (5-tuple) is a unique
subflow. If the connectivity checks have been performed then the subflow. If the connectivity checks have been performed then the
endpoint MUST only use the subflows for which the connectivity checks endpoint MUST only use the subflows for which the connectivity checks
have succeeded. have succeeded.
skipping to change at page 18, line 7 skipping to change at page 18, line 18
multiple interfaces for sending the media stream then they MUST use multiple interfaces for sending the media stream then they MUST use
the MPRTP header extensions. They MAY use normal RTP with legacy the MPRTP header extensions. They MAY use normal RTP with legacy
endpoints (see Appendix A). endpoints (see Appendix A).
An MPRTP endpoint sends RTP packets with an MPRTP extension that maps An MPRTP endpoint sends RTP packets with an MPRTP extension that maps
the media packet to a specific subflow (see Figure 8). The MPRTP the media packet to a specific subflow (see Figure 8). The MPRTP
layer SHOULD associate an RTP packet with a subflow based on a layer SHOULD associate an RTP packet with a subflow based on a
scheduling strategy. The scheduling strategy may either choose to scheduling strategy. The scheduling strategy may either choose to
augment the paths to create higher throughput or use the alternate augment the paths to create higher throughput or use the alternate
paths for enhancing resilience or error-repair. Due to the changes paths for enhancing resilience or error-repair. Due to the changes
in path characteristics, the endpoint should be able change its in path characteristics, the endpoint should be able to change its
scheduling strategy during an ongoing session. The MPRTP sender MUST scheduling strategy during an ongoing session. The MPRTP sender MUST
also populate the subflow specific fields described in the MPRTP also populate the subflow specific fields described in the MPRTP
extension header (see Section 9.1.1). extension header (see Section 9.1.1).
[ACM-MPRTP] describes and evaluates a scheduling algorithm for video [ACM-MPRTP] describes and evaluates a scheduling algorithm for video
over multiple interfaces. The video is encoded at a single target over multiple interfaces. The video is encoded at a single target
bit rate and is evaluated in various network scenarios, as discussed bit rate and is evaluated in various network scenarios, as discussed
in [I-D.ietf-rmcat-eval-criteria]. in [I-D.ietf-rmcat-eval-criteria].
8.3. Playout Considerations at the Receiver 8.3. Playout Considerations at the Receiver
skipping to change at page 18, line 40 skipping to change at page 18, line 51
Aggregate RTCP provides the overall media statistics and follows the Aggregate RTCP provides the overall media statistics and follows the
normal RTCP defined in RFC3550 [RFC3550]. However, subflow specific normal RTCP defined in RFC3550 [RFC3550]. However, subflow specific
RTCP provides the per path media statistics because the aggregate RTCP provides the per path media statistics because the aggregate
RTCP report may not provide sufficient per path information to an RTCP report may not provide sufficient per path information to an
MPRTP scheduler. Specifically, the scheduler should be aware of each MPRTP scheduler. Specifically, the scheduler should be aware of each
path's RTT and loss-rate, which an aggregate RTCP cannot provide. path's RTT and loss-rate, which an aggregate RTCP cannot provide.
The aggregate RTCP report (i.e., the regularly scheduled RTCP report) The aggregate RTCP report (i.e., the regularly scheduled RTCP report)
MUST be sent compounded as described in [RFC5506], however, the MUST be sent compounded as described in [RFC5506], however, the
subflow-specific RTCP reports MAY be sent non-compounded. Further, subflow-specific RTCP reports MAY be sent non-compounded (reduced-
each subflow and the aggregate RTCP report MUST follow the timing size). Further, each subflow and the aggregate RTCP report MUST
rules defined in [RFC4585]. follow the timing rules defined in [RFC4585].
The RTCP reporting interval is locally implemented and the scheduling The RTCP reporting interval is locally implemented and the scheduling
of the RTCP reports may depend on the the behavior of each path. For of the RTCP reports may depend on the behavior of each path. For
instance, the RTCP interval may be different for a passive path than instance, the RTCP interval may be different for a passive path than
an active path to keep port bindings alive. Additionally, an an active path to keep port bindings alive. Additionally, an
endpoint may decide to share the RTCP reporting bit rate equally endpoint may decide to share the RTCP reporting bit rate equally
across all its paths or schedule based on the receiver rate on each across all its paths or schedule based on the receiver rate on each
path. path.
8.5. RTCP Transmission 8.5. RTCP Transmission
The sender sends an RTCP SR on each active path. For each SR the The sender sends an RTCP Subflow SR (SSR) on each active path. For
receiver gets, it echoes one back to the same IP address-port pair each SR the receiver gets, it echoes one back to the same IP address-
that sent the SR. The receiver tries to choose the symmetric path port pair that sent the SR. The receiver tries to choose the
and if the routing is symmetric then the per-path RTT calculations symmetric path and if the routing is symmetric then the per-path RTT
will work out correctly. However, even if the paths are not calculations will work out correctly. However, even if the paths are
symmetric, the sender would at maximum, under-estimate the RTT of the not symmetric, the sender would at maximum, under-estimate the RTT of
path by a factor of half of the actual path RTT. the path by a factor of half of the actual path RTT.
9. Packet Formats 9. Packet Formats
In this section we define the protocol structures described in the In this section we define the protocol structures described in the
previous sections. previous sections.
9.1. RTP Header Extension for MPRTP 9.1. RTP Header Extension for MPRTP
The MPRTP header extension is used to distribute a single RTP stream The MPRTP header extension is used to distribute a single RTP stream
over multiple subflows. over multiple subflows.
skipping to change at page 20, line 20 skipping to change at page 20, line 41
+---------------+--------------------------------------------------+ +---------------+--------------------------------------------------+
| MPID ID | Use | | MPID ID | Use |
| Value | | | Value | |
+---------------+--------------------------------------------------+ +---------------+--------------------------------------------------+
| 0x0 | Subflow RTP Header. For this case the Length is | | 0x0 | Subflow RTP Header. For this case the Length is |
| | set to 4 | | | set to 4 |
+---------------+--------------------------------------------------+ +---------------+--------------------------------------------------+
Figure 7: RTP header extension values for MPRTP (H-Ext ID) Figure 7: RTP header extension values for MPRTP (H-Ext ID)
length Length
The 4-bit length field is the length of extension data in bytes The 4-bit length field is the length of extension data in bytes
not including the H-Ext ID and length fields. The value zero not including the H-Ext ID and length fields. The value zero
indicates there is no data following. indicates there is no data following.
MPRTP header data MPRTP header data
Carries the MPID specific data as described in the following Carries the MPID specific data as described in the following
sub-sections. sub-sections.
skipping to change at page 21, line 31 skipping to change at page 21, line 35
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MPRTP header for subflow Figure 8: MPRTP header for subflow
MP ID = 0x0 MP ID = 0x0
Indicates that the MPRTP header extension carries subflow Indicates that the MPRTP header extension carries subflow
specific information. specific information.
length = 4 Length = 4
Subflow ID: Identifier of the subflow. Every RTP packet belonging Subflow ID: Identifier of the subflow. Every RTP packet belonging
to the same subflow carries the same unique subflow identifier. to the same subflow carries the same unique subflow identifier.
Flow-Specific Sequence Number (FSSN): Sequence of the packet in Flow-Specific Sequence Number (FSSN): Sequence of the packet in
the subflow. Each subflow has its own strictly monotonically the subflow. Each subflow has its own strictly monotonically
increasing sequence number space. increasing sequence number space.
9.2. RTCP Extension for MPRTP (MPRTCP) 9.2. RTCP Extension for MPRTP (MPRTCP)
skipping to change at page 36, line 5 skipping to change at page 36, line 5
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI
10.17487/RFC4585, July 2006, 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>. <http://www.rfc-editor.org/info/rfc4585>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, DOI 10.17487/ Control Packets on a Single Port", RFC 5761, DOI 10.17487/
RFC5761, April 2010, RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>. <http://www.rfc-editor.org/info/rfc5761>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>.
15.2. Informative References 15.2. Informative References
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, DOI Text on Security Considerations", BCP 72, RFC 3552, DOI
10.17487/RFC3552, July 2003, 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>. <http://www.rfc-editor.org/info/rfc3552>.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
Iyengar, "Architectural Guidelines for Multipath TCP Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
skipping to change at page 38, line 15 skipping to change at page 38, line 18
packets over multiple paths or detect if a path disappeared. packets over multiple paths or detect if a path disappeared.
An MPRTP receiver can only use one of its interface when An MPRTP receiver can only use one of its interface when
communicating with a legacy sender. communicating with a legacy sender.
Appendix B. Change Log Appendix B. Change Log
Note to the RFC-Editor: please remove this section prior to Note to the RFC-Editor: please remove this section prior to
publication as an RFC. publication as an RFC.
B.1. Changes in draft-ietf-avtcore-mprtp-01, and -02 B.1. Changes in draft-ietf-avtcore-mprtp-03
o Incorporating review comments from Frederic Maze on incorporating
new RTP Taxonomy.
B.2. Changes in draft-ietf-avtcore-mprtp-01, and -02
o Keep-alive versions, document needs review. o Keep-alive versions, document needs review.
o Updated authors' affiliations. o Updated authors' affiliations.
B.2. Changes in draft-ietf-avtcore-mprtp-00 B.3. Changes in draft-ietf-avtcore-mprtp-00
o Submitted as a WG item. o Submitted as a WG item.
B.3. Changes in draft-singh-avtcore-mprtp-10 B.4. Changes in draft-singh-avtcore-mprtp-10
o Editorial updates based on review comments. o Editorial updates based on review comments.
o Renamed length to encaps_length. o Renamed length to encaps_length.
B.4. Changes in draft-singh-avtcore-mprtp-09 B.5. Changes in draft-singh-avtcore-mprtp-09
o Editorial updates based on review comments. o Editorial updates based on review comments.
o Clarified use of a=rtcp-rsize. o Clarified use of a=rtcp-rsize.
o Fixed bug in block length of interface advertisements. o Fixed bug in block length of interface advertisements.
B.5. Changes in draft-singh-avtcore-mprtp-08 B.6. Changes in draft-singh-avtcore-mprtp-08
o Added reference to use of PCP for discovering new interfaces. o Added reference to use of PCP for discovering new interfaces.
B.6. Changes in draft-singh-avtcore-mprtp-06 and -07 B.7. Changes in draft-singh-avtcore-mprtp-06 and -07
o Added reference to Mobility ICE. o Added reference to Mobility ICE.
B.7. Changes in draft-singh-avtcore-mprtp-05 B.8. Changes in draft-singh-avtcore-mprtp-05
o SDP extensions moved to draft-singh-mmusic-mprtp-sdp-extension-00. o SDP extensions moved to draft-singh-mmusic-mprtp-sdp-extension-00.
Kept only the basic 'a=mprtp' attribute in this document. Kept only the basic 'a=mprtp' attribute in this document.
o Cleaned up ICE procedures for advertising only using in-band o Cleaned up ICE procedures for advertising only using in-band
signaling. signaling.
B.8. Changes in draft-singh-avtcore-mprtp-04 B.9. Changes in draft-singh-avtcore-mprtp-04
o Fixed missing 0xBEDE header in MPRTP header format. o Fixed missing 0xBEDE header in MPRTP header format.
o Removed connectivity checks and keep-alives from in-band o Removed connectivity checks and keep-alives from in-band
signaling. signaling.
o MPRTP and MPRTCP are multiplexed on a single port. o MPRTP and MPRTCP are multiplexed on a single port.
o MPRTCP packet headers optimized. o MPRTCP packet headers optimized.
o Made ICE optional o Made ICE optional
o Updated Sections: 7.1.2, 8.1.x, 11.2, 11.4, 11.6. o Updated Sections: 7.1.2, 8.1.x, 11.2, 11.4, 11.6.
o Added how to use MPRTP in RTSP (Section 12). o Added how to use MPRTP in RTSP (Section 12).
o Updated IANA Considerations section. o Updated IANA Considerations section.
B.9. Changes in draft-singh-avtcore-mprtp-03 B.10. Changes in draft-singh-avtcore-mprtp-03
o Added this change log. o Added this change log.
o Updated section 6, 7 and 8 based on comments from MMUSIC. o Updated section 6, 7 and 8 based on comments from MMUSIC.
o Updated section 11 (SDP) based on comments of MMUSIC. o Updated section 11 (SDP) based on comments of MMUSIC.
o Updated SDP examples with ICE and non-ICE in out-of-band signaling o Updated SDP examples with ICE and non-ICE in out-of-band signaling
scenario. scenario.
o Added Appendix A on interop with legacy. o Added Appendix A on interop with legacy.
o Updated IANA Considerations section. o Updated IANA Considerations section.
B.10. Changes in draft-singh-avtcore-mprtp-02 B.11. Changes in draft-singh-avtcore-mprtp-02
o MPRTCP protocol extensions use only one PT=210, instead of 210 and o MPRTCP protocol extensions use only one PT=210, instead of 210 and
211. 211.
o RTP header uses 1-byte extension instead of 2-byte. o RTP header uses 1-byte extension instead of 2-byte.
o Added section on RTCP Interval Calculations. o Added section on RTCP Interval Calculations.
o Added "mprtp-interface" attribute in SDP considerations. o Added "mprtp-interface" attribute in SDP considerations.
B.11. Changes in draft-singh-avtcore-mprtp-01 B.12. Changes in draft-singh-avtcore-mprtp-01
o Added MPRTP and MPRTCP protocol extensions and examples. o Added MPRTP and MPRTCP protocol extensions and examples.
o WG changed from -avt to -avtcore. o WG changed from -avt to -avtcore.
Editorial Comments Editorial Comments
[note-iceornot] Editor: Legacy applications do not require ICE for [note-iceornot] Editor: Legacy applications do not require ICE for
session establishment, therefore, MPRTP should not session establishment, therefore, MPRTP should not
require it as well. require it as well.
 End of changes. 62 change blocks. 
156 lines changed or deleted 201 lines changed or added

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