-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-ietf-avtcore-mprtp-01.txt
2296 lines (1461 loc) · 85.5 KB
/
draft-ietf-avtcore-mprtp-01.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
AVT Core Working Group V. Singh
Internet-Draft T. Karkkainen
Intended status: Experimental J. Ott
Expires: January 7, 2016 S. Ahsan
Aalto University
L. Eggert
NetApp
July 6, 2015
Multipath RTP (MPRTP)
draft-ietf-avtcore-mprtp-01
Abstract
The Real-time Transport Protocol (RTP) is used to deliver real-time
content and, along with the RTP Control Protocol (RTCP), forms the
control channel between the sender and receiver. However, RTP and
RTCP assume a single delivery path between the sender and receiver
and make decisions based on the measured characteristics of this
single path. Increasingly, endpoints are becoming multi-homed, which
means that they are connected via multiple Internet paths. Network
utilization can be improved when endpoints use multiple parallel
paths for communication. The resulting increase in reliability and
throughput can also enhance the user experience. This document
extends the Real-time Transport Protocol (RTP) so that a single
session can take advantage of the availability of multiple paths
between two endpoints.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2016.
Singh, et al. Expires January 7, 2016 [Page 1]
Internet-Draft Multipath RTP July 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 39
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Functional goals . . . . . . . . . . . . . . . . . . . . 5
2.2. Compatibility goals . . . . . . . . . . . . . . . . . . . 6
3. RTP Topologies . . . . . . . . . . . . . . . . . . . . . . . 6
4. MPRTP Architecture . . . . . . . . . . . . . . . . . . . . . 6
5. Example Media Flow Diagrams . . . . . . . . . . . . . . . . . 8
5.1. Streaming use-case . . . . . . . . . . . . . . . . . . . 8
5.2. Conversational use-case . . . . . . . . . . . . . . . . . 9
6. MPRTP Functional Blocks . . . . . . . . . . . . . . . . . . . 10
7. Available Mechanisms within the Functional Blocks . . . . . . 11
7.1. Session Setup . . . . . . . . . . . . . . . . . . . . . . 11
7.1.1. Connectivity Checks . . . . . . . . . . . . . . . . . 11
7.1.2. Adding New or Updating Interfaces . . . . . . . . . . 11
7.1.3. In-band vs. Out-of-band Signaling . . . . . . . . . . 12
7.2. Expanding RTP . . . . . . . . . . . . . . . . . . . . . . 13
7.3. Expanding RTCP . . . . . . . . . . . . . . . . . . . . . 13
7.4. Failure Handling and Teardown . . . . . . . . . . . . . . 14
8. MPRTP Protocol . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1.1. Gather or Discovering Candidates . . . . . . . . . . 15
8.1.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . 15
8.1.3. Choosing between In-band (in RTCP) and Out-of-band
(in SDP) Interface Advertisement . . . . . . . . . . 16
8.1.4. In-band Interface Advertisement . . . . . . . . . . . 16
8.1.5. Subflow ID Assignment . . . . . . . . . . . . . . . . 17
8.1.6. Active and Passive Subflows . . . . . . . . . . . . . 17
8.2. RTP Transmission . . . . . . . . . . . . . . . . . . . . 17
Singh, et al. Expires January 7, 2016 [Page 2]
Internet-Draft Multipath RTP July 2015
8.3. Playout Considerations at the Receiver . . . . . . . . . 18
8.4. Subflow-specific RTCP Statistics and RTCP Aggregation . . 18
8.5. RTCP Transmission . . . . . . . . . . . . . . . . . . . . 19
9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. RTP Header Extension for MPRTP . . . . . . . . . . . . . 19
9.1.1. MPRTP RTP Extension for a Subflow . . . . . . . . . . 20
9.2. RTCP Extension for MPRTP (MPRTCP) . . . . . . . . . . . . 21
9.2.1. MPRTCP Extension for Subflow Reporting . . . . . . . 23
9.2.1.1. MPRTCP for Subflow-specific SR, RR and XR . . . . 25
9.3. MPRTCP Extension for Interface advertisement . . . . . . 27
10. RTCP Timing reconsiderations for MPRTCP . . . . . . . . . . . 28
11. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 29
11.1. Signaling MPRTP Header Extension in SDP . . . . . . . . 29
11.2. Signaling MPRTP capability in SDP . . . . . . . . . . . 29
11.3. MPRTP with ICE . . . . . . . . . . . . . . . . . . . . . 30
11.4. Increased Throughput . . . . . . . . . . . . . . . . . . 30
11.5. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 31
11.5.1. In-band Signaling Example . . . . . . . . . . . . . 31
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
12.1. MPRTP Header Extension . . . . . . . . . . . . . . . . . 32
12.2. MPRTCP Packet Type . . . . . . . . . . . . . . . . . . . 32
12.3. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 33
12.3.1. "mprtp" attribute . . . . . . . . . . . . . . . . . 33
13. Security Considerations . . . . . . . . . . . . . . . . . . . 34
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
15.1. Normative References . . . . . . . . . . . . . . . . . . 35
15.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Interoperating with Legacy Applications . . . . . . 37
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 37
B.1. Changes in draft-ietf-avtcore-mprtp-00 . . . . . . . . . 37
B.2. Changes in draft-singh-avtcore-mprtp-10 . . . . . . . . . 37
B.3. Changes in draft-singh-avtcore-mprtp-09 . . . . . . . . . 38
B.4. Changes in draft-singh-avtcore-mprtp-08 . . . . . . . . . 38
B.5. Changes in draft-singh-avtcore-mprtp-06 and -07 . . . . . 38
B.6. Changes in draft-singh-avtcore-mprtp-05 . . . . . . . . . 38
B.7. Changes in draft-singh-avtcore-mprtp-04 . . . . . . . . . 38
B.8. Changes in draft-singh-avtcore-mprtp-03 . . . . . . . . . 38
B.9. Changes in draft-singh-avtcore-mprtp-02 . . . . . . . . . 39
B.10. Changes in draft-singh-avtcore-mprtp-01 . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction
Multi-homed endpoints are becoming common in today's Internet, e.g.,
devices that support multiple wireless access technologies such as 3G
and Wireless LAN. This means that there is often more than one
network path available between two endpoints. Transport protocols,
Singh, et al. Expires January 7, 2016 [Page 3]
Internet-Draft Multipath RTP July 2015
such as RTP, have not been designed to take advantage of the
availability of multiple concurrent paths and therefore cannot
benefit from the increased capacity and reliability that can be
achieved by pooling their respective capacities.
Multipath RTP (MPRTP) is an OPTIONAL extension to RTP [RFC3550] that
allows splitting a single RTP stream into multiple subflows that are
transmitted over different paths. In effect, this pools the resource
capacity of multiple paths. Multipath RTCP (MPRTCP) is an extension
to RTCP, it is used along with MPRTP to report per-path sender and
receiver characteristics.
Other IETF transport protocols that are capable of using multiple
paths include SCTP [RFC4960], MPTCP [RFC6182] and SHIM6 [RFC5533].
However, these protocols are not suitable for real-time
communications.
1.1. Requirements Language
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 [RFC2119].
1.2. Terminology
o Endpoint: host either initiating or terminating an RTP flow.
o Interface: logical or physical component that is capable of
acquiring a unique IP address.
o Path: sequence of links between a sender and a receiver.
Typically, defined by a set of source and destination addresses.
o Subflow: flow of RTP packets along a specific path, i.e., a subset
of the packets belonging to an RTP stream. The combination of all
RTP subflows forms the complete RTP stream. Typically, a subflow
would map to a unique path, i.e., each combination of IP addresses
and port pairs (5-tuple, including protocol) is a unique subflow.
1.3. Use-cases
The primary use-case for MPRTP is transporting high bit-rate
streaming multimedia content between endpoints, where at least one is
multi-homed. Such endpoints could be residential IPTV devices that
connect to the Internet through two different Internet service
providers (ISPs), or mobile devices that connect to the Internet
through 3G and WLAN interfaces. By allowing RTP to use multiple
paths for transmission, the following gains can be achieved:
Singh, et al. Expires January 7, 2016 [Page 4]
Internet-Draft Multipath RTP July 2015
o Higher quality: Pooling the resource capacity of multiple Internet
paths allows higher bit-rate and higher quality codecs to be used.
From the application perspective, the available bandwidth between
the two endpoints increases.
o Load balancing: Transmitting an RTP stream over multiple paths
reduces the bandwidth usage on a single path, which in turn
reduces the impact of the media stream on other traffic on that
path.
o Fault tolerance: When multiple paths are used in conjunction with
redundancy mechanisms (FEC, re-transmissions, etc.), outages on
one path have less impact on the overall perceived quality of the
stream.
A secondary use-case for MPRTP is transporting Voice over IP (VoIP)
calls to a device with multiple interfaces. Again, such an endpoint
could be a mobile device with multiple wireless interfaces. In this
case, little is to be gained from resource pooling, i.e., higher
capacity or load balancing, because a single path should be easily
capable of handling the required load. However, using multiple
concurrent subflows can improve fault tolerance, because traffic can
shift between the subflows when path outages occur. This results in
very fast transport-layer handovers that do not require support from
signaling.
2. Goals
This section outlines the basic goals that multipath RTP aims to
meet. These are broadly classified as Functional goals and
Compatibility goals.
2.1. Functional goals
Allow unicast RTP session to be split into multiple subflows in order
to be carried over multiple paths. This may prove beneficial in case
of video streaming.
o Increased Throughput: Cumulative capacity of the two paths may
meet the requirements of the multimedia session. Therefore, MPRTP
MUST support concurrent use of the multiple paths.
o Improved Reliability: MPRTP SHOULD be able to send redundant
packets or re-transmit packets along any available path to
increase reliability.
Singh, et al. Expires January 7, 2016 [Page 5]
Internet-Draft Multipath RTP July 2015
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
paths disappear.
2.2. Compatibility goals
MPRTP MUST be backwards compatible; an MPRTP stream needs to fall
back to be compatible with legacy RTP stacks if MPRTP support is not
successfully negotiated.
o Application Compatibility: MPRTP service model MUST be backwards
compatible with existing RTP applications, i.e., an MPRTP stack
MUST be able to work with legacy RTP applications and not require
changes to them. Therefore, the basic RTP APIs MUST remain
unchanged, but an MPRTP stack MAY provide extended APIs so that
the application can configure any additional features provided by
the MPRTP stack.
o Network Compatibility: individual RTP subflows MUST themselves be
well-formed RTP flows, so that they are able to traverse NATs and
firewalls. This MUST be the case even when interfaces appear
after session initiation. Interactive Connectivity Establishment
(ICE) [RFC5245] MAY be used for discovering new interfaces or
performing connectivity checks.
3. RTP Topologies
RFC 5117 [RFC5117] describes a number of scenarios using mixers and
translators in single-party (point-to-point), and multi-party (point-
to-multipoint) scenarios. RFC 3550 [RFC3550] (Section 2.3 and 7.x)
discuss in detail the impact of mixers and translators on RTP and
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
multiple paths go via this component.
4. MPRTP Architecture
In a typical scenario, an RTP session uses a single path. In an
MPRTP scenario, an RTP session uses multiple subflows that each use a
different path. Figure 1 shows the difference.
Singh, et al. Expires January 7, 2016 [Page 6]
Internet-Draft Multipath RTP July 2015
+--------------+ Signaling +--------------+
| |------------------------------------>| |
| Client |<------------------------------------| Server |
| | Single RTP flow | |
+--------------+ +--------------+
+--------------+ Signaling +--------------+
| |------------------------------------>| |
| Client |<------------------------------------| Server |
| |<------------------------------------| |
+--------------+ MPRTP subflows +--------------+
Figure 1: Comparison between traditional RTP streaming and MPRTP
+-----------------------+ +-------------------------------+
| Application | | Application |
+-----------------------+ +-------------------------------+
| | | MPRTP |
+ RTP + +- - - - - - - -+- - - - - - - -+
| | | RTP subflow | RTP subflow |
+-----------------------+ +---------------+---------------+
| UDP | | UDP | UDP |
+-----------------------+ +---------------+---------------+
| IP | | IP | IP |
+-----------------------+ +---------------+---------------+
Figure 2: MPRTP Architecture
Figure 2 illustrates the differences between the standard RTP stack
and the MPRTP stack. MPRTP receives a normal RTP session from the
application and splits it into multiple RTP subflows. Each subflow
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
receiver, the subflows are combined to recreate the original RTP
session. The MPRTP layer performs the following functions:
o Path Management: The layer is aware of alternate paths to the
other host, which may, for example, be the peer's multiple
interfaces. This enables the endpoint to transmit differently
marked packets along separate paths. MPRTP also selects
interfaces to send and receive data. Furthermore, it manages the
port and IP address pair bindings for each subflow.
o Packet Scheduling: the layer splits a single RTP flow into
multiple subflows and sends them across multiple interfaces
(paths). The splitting MAY BE done using different path
characteristics.
Singh, et al. Expires January 7, 2016 [Page 7]
Internet-Draft Multipath RTP July 2015
o Subflow recombination: the layer creates the original stream by
recombining the independent subflows. Therefore, the multipath
subflows appear as a single RTP stream to applications.
5. Example Media Flow Diagrams
There may be many complex technical scenarios for MPRTP, however,
this memo only considers the following two scenarios: 1) a
unidirectional media flow that represents the streaming use-case, and
2) a bidirectional media flow that represents a conversational use-
case.
5.1. Streaming use-case
In the unidirectional scenario, the receiver (client) initiates a
multimedia session with the sender (server). The receiver or the
sender may have multiple interfaces and both endpoints are MPRTP-
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. If the interfaces are reachable, then host B
streams multimedia data along multiple paths to host A. Moreover,
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
session as well as the receiver statistics for each subflow. Host B
distributes the packets across the subflows based on the individually
measured path characteristics.
Alternatively, to reduce media startup time, host B may start
streaming multimedia data to host A's initiating interface and then
perform connectivity checks for the other interfaces. This method of
updating a single path session to a multipath session is called
"multipath session upgrade".
Singh, et al. Expires January 7, 2016 [Page 8]
Internet-Draft Multipath RTP July 2015
Host A Host B
----------------------- ----------
Interface A1 Interface A2 Interface B1
----------------------- ----------
| |
|------------------------------------->| Session setup with
|<-------------------------------------| multiple interfaces
| | |
| | |
| (RTP data B1->A1, B1->A2) |
|<=====================================|
| |<========================|
| | |
Note: there may be more scenarios.
Figure 3: Unidirectional media flow
5.2. Conversational use-case
In the bidirectional scenario, multimedia data flows in both
directions. The two hosts exchange their lists of interfaces with
each other and perform connectivity checks. Communication begins
after each host finds suitable address, port pairs. Interfaces that
receive data send back RTCP receiver statistics for that path (based
on the 5-tuple). The hosts balance their multimedia stream across
multiple paths based on the per path reception statistics and its own
volume of traffic. Figure 4 describes an example of a bidirectional
flow.
Singh, et al. Expires January 7, 2016 [Page 9]
Internet-Draft Multipath RTP July 2015
Host A Host B
--------------------------- ---------------------------
Interface A1 Interface A2 Interface B1 Interface B2
--------------------------- ---------------------------
| | | |
| | | |Session setup
|----------------------------------->| |with multiple
|<-----------------------------------| |interfaces
| | | |
| | | |
| (RTP data B1<->A1, B2<->A2) | |
|<===================================| |
| |<===================================|
|===================================>| |
| |===================================>|
| | | |
Note: the address pairs may have other permutations,
and they may be symmetric or asymmetric combinations.
Figure 4: Bidirectional flow
6. MPRTP Functional Blocks
This section describes some of the functional blocks needed for
MPRTP. We then investigate each block and consider available
mechanisms in the next section.
1. Session Setup: Interfaces may appear or disappear at anytime
during the session. To preserve backward compatibility with
legacy applications, a multipath session MUST look like a bundle
of individual RTP sessions. A multipath session may be upgraded
from a typical single path session, as and when new interfaces
appear or disappear. However, it is also possible to setup a
multipath session from the beginning, if the interfaces are
available at the start of the multimedia session.
2. Expanding RTP: For a multipath session, each subflow MUST look
like an independent RTP flow, so that individual RTCP messages
can be generated per subflow. Furthermore, MPRTP splits the
single multimedia stream into multiple subflows based on path
characteristics (e.g. RTT, loss-rate, receiver rate, bandwidth-
delay product etc.) and dynamically adjusts the load on each
link.
3. Adding Interfaces: Interfaces on the host need to be regularly
discovered and advertised. This can be done at session setup
and/or during the session. Discovering interfaces is outside the
scope of this document.
Singh, et al. Expires January 7, 2016 [Page 10]
Internet-Draft Multipath RTP July 2015
4. Expanding RTCP: MPRTP MUST provide per path RTCP reports for
monitoring the quality of the path, for load balancing, or for
congestion control, etc. To maintain backward compatibility with
legacy applications, the receiver MUST also send aggregate RTCP
reports along with the per-path reports.
5. Maintenance and Failure Handling: In a multi-homed endpoint
interfaces may appear and disappear. If this occurs at the
sender, it has to re-adjust the load on the available links. On
the other hand, if this occurs at the receiver, then the
multimedia data transmitted by the sender to those interfaces is
lost. This data may be re-transmitted along a different path
i.e., to a different interface on the receiver. Furthermore, the
endpoint has to either explicitly signal the disappearance of an
interface, or the other endpoint has to detect it (by lack of
media packets, RTCP feedback, or keep-alive packets).
6. Teardown: The MPRTP layer releases the occupied ports on the
interfaces.
7. Available Mechanisms within the Functional Blocks
This section discusses some of the possible alternatives for each
functional block mentioned in the previous section.
7.1. Session Setup
MPRTP session can be set up in many possible ways e.g., during
handshake, or upgraded mid-session. The capability exchange may be
done using out-of-band signaling (e.g., Session Description Protocol
(SDP) [RFC3264] in Session Initiation Protocol (SIP) [RFC3261], Real-
Time Streaming Protocol (RTSP) [I-D.ietf-mmusic-rfc2326bis]) or in-
band signaling (e.g., RTP/RTCP header extension, Session Traversal
Utilities for NAT (STUN) messages).
7.1.1. Connectivity Checks
The endpoint SHOULD be capable of performing connectivity checks
(e.g., using ICE [RFC5245]). If the IP addresses of the endpoints
are reachable (e.g., globally addressable, same network etc) then
connectivity checks are not needed.
7.1.2. Adding New or Updating Interfaces
Interfaces can appear and disappear during a session, the endpoint
MUST be capable of advertising the changes in its set of usable
interfaces. Additionally, the application or OS may define a policy
on when and/or what interfaces are usable. However, MPRTP requires a
Singh, et al. Expires January 7, 2016 [Page 11]
Internet-Draft Multipath RTP July 2015
method to advertise or notify the other endpoint about the updated
set of usable interfaces.
7.1.3. In-band vs. Out-of-band Signaling
MTRTP nodes will generally use a signaling protocol to establish
their MPRTP session. With the existence of such a signaling
relationship, two alternatives become available to exchange
information about the available interfaces on each side for extending
RTP sessions to MPRTP and for modifying MPRTP sessions: in-band and
out-of-band signaling.
In-band signaling refers to using mechanisms of RTP/RTCP itself to
communicate interface addresses, e.g., a dedicated RTCP extensions
along the lines of the one defined to communicate information about
the feedback target for RTP over SSM [RFC5760]. In-band signaling
does not rely on the availability of a separate signaling connection
and the information flows along the same path as the media streams,
thus minimizing dependencies. Moreover, if the media channel is
secured (e.g., by means of SRTP), the signaling is implicitly
protected as well if SRTCP encryption and authentication are chosen.
In-band signaling is also expected to take a direct path to the peer,
avoiding any signaling overlay-induced indirections and associated
processing overheads in signaling elements -- avoiding such may be
especially worthwhile if frequent updates may occur as in the case of
mobile users. Finally, RTCP is usually sent sufficiently frequently
(in point-to-point settings) to provide enough opportunities for
transmission and (in case of loss) retransmission of the
corresponding RTCP packets.
Examples for in-band signaling include RTCP extensions as noted above
or suitable extensions to STUN [I-D.wing-mmusic-ice-mobility].
Out-of-band signaling refers to using a separate signaling connection
(via SIP, RTSP, or HTTP) to exchange interface information, e.g.,
expressed in SDP. Clear benefits are that signaling occurs at setup
time anyway and that experience and SDP syntax (and procedures) are
available that can be re-used or easily adapted to provide the
necessary capabilities. In contrast to RTCP, SDP offers a reliable
communication channel so that no separate retransmissions logic is
necessary. In SDP, especially when combined with ICE, connectivity
check mechanisms including sophisticated rules are readily available.
While SDP is not inherently protected, suitable security may need to
be applied anyway to the basic session setup.
Examples for out-of-band signaling are dedicated extensions to SDP;
those may be combined with ICE.
Singh, et al. Expires January 7, 2016 [Page 12]
Internet-Draft Multipath RTP July 2015
Both types of mechanisms have their pros and cons for middleboxes.
With in-band signaling, control packets take the same path as the
media packets and they can be directly inspected by middleboxes so
that the elements operating on the signaling channel do not need to
understand new SDP. With out-of-band signaling, only the middleboxes
processing the signaling need to be modified and those on the data
forwarding path can remain untouched.
Overall, it may appear sensible to provide a combination of both
mechanisms: out-of-band signaling for session setup and initial
interface negotiation and in-band signaling to deal with frequent
changes in interface state (and for the potential case, albeit rather
theoretical case of MPRTP communication without a signaling channel).
In its present version, this document explores both options to
provide a broad understanding of how the corresponding mechanisms
would look like.
7.2. Expanding RTP
RTCP [RFC3550] is generated per media session. However, with MPRTP,
the media sender spreads the RTP load across several interfaces. The
media sender SHOULD make the path selection, load balancing and fault
tolerance decisions based on the characteristics of each path.
Therefore, apart from normal RTP sequence numbers defined in
[RFC3550], the MPRTP sender MUST add subflow-specific sequence
numbers to help calculate fractional losses, jitter, RTT, playout
time, etc., for each path, and a subflow identifier to associate the
characteristics with a path. The RTP header extension for MPRTP is
shown in Section 9.1.
7.3. Expanding RTCP
To provide accurate per path information an MPRTP endpoint MUST send
(SR/RR) report for each unique subflow along with the overall session
RTCP report. Therefore, the additional subflow reporting affects the
RTCP bandwidth and the RTCP reporting interval. RTCP report
scheduling for each subflow may cause a problem for RTCP
recombination and reconstruction in cases when 1) RTCP for a subflow
is lost, and 2) RTCP for a subflow arrives later than the other
subflows. (There may be other cases as well.)
The sender distributes the media across different paths using the per
path RTCP reports. However, this document doesn't cover algorithms
for congestion control or load balancing.
Singh, et al. Expires January 7, 2016 [Page 13]
Internet-Draft Multipath RTP July 2015
7.4. Failure Handling and Teardown
An MPRTP endpoint MUST keep alive subflows that have been negotiated
but no media is sent on them. Moreover, using the information in the
subflow reports, a sender can monitor an active subflow for failure
(errors, unreachability, congestion) and decide not to use (make the
active subflow passive), or teardown the subflow.
If an interface disappears, the endpoint MUST send an updated
interface advertisement without the interface and release the the
associated subflows.
8. MPRTP Protocol
Host A Host B
----------------------- -----------------------
Interface A1 Interface A2 Interface B1 Interface B2
----------------------- -----------------------
| | | |
| | (1) | |
|--------------------------------------->| |
|<---------------------------------------| |
| | (2) | |
|<=======================================| |
|<=======================================| (3) |
| | (4) | |
|<- - - - - - - - - - - - - - - - - - - -| |
|<- - - - - - - - - - - - - - - - - - - -| |
|<- - - - - - - - - - - - - - - - - - - -| |
| | (5) | |
|- - - - - - - - - - - - - - - - - - - ->| |
|<=======================================| (6) |
|<=======================================| |
| |<========================================|
|<=======================================| |
| |<========================================|
Key:
| Interface
---> Signaling Protocol
<=== RTP Packets
- -> RTCP Packet
Figure 5: MPRTP New Interface
Singh, et al. Expires January 7, 2016 [Page 14]
Internet-Draft Multipath RTP July 2015
8.1. Overview
The bullet points explain the different steps shown in Figure 5 for
upgrading a single path multimedia session to multipath session.
(1) The first two interactions between the hosts represents the
establishment of a normal RTP session. This may performed e.g.
using SIP or RTSP.
(2) When the RTP session has been established, host B streams
media using its interface B1 to host A at interface A1.
(3) Host B supports sending media using MPRTP and becomes aware of
an additional interface B2.
(4) Host B advertises the multiple interface addresses.
(5) Host A supports receiving media using MPRTP and becomes aware
of an additional interface A2.
Side note, even if an MPRTP-capable host has only one interface,
it MUST respond to the advertisement with its single interface.
(6) Each host receives information about the additional interfaces
and the appropriate endpoints starts to stream the multimedia
content using the additional paths.
If needed, each endpoint will need to independently perform
connectivity checks (not shown in figure) and ascertain
reachability before using the paths.
8.1.1. Gather or Discovering Candidates
The endpoint periodically polls the operating system or is notified
when an additional interface appears. If the endpoint wants to use
the additional interface for MPRTP it MUST advertise it to the other
peers. The endpoint may also use ICE [RFC5245] to gather additional
candidates.
8.1.2. NAT Traversal
After gathering their interface candidates, the endpoints decide
internally if they wish to perform connectivity checks.
[note-iceornot]
If the endpoint chooses to perform connectivity checks then it MUST
first advertise the gathered candidates as ICE candidates in SDP
Singh, et al. Expires January 7, 2016 [Page 15]
Internet-Draft Multipath RTP July 2015
during session setup and let ICE perform the connectivity checks. As
soon as a sufficient number of connectivity checks succeed, the
endpoint can use the successful candidates to advertise its MPRTP
interface candidates.
Alternatively, if the endpoint supports mobility extensions for ICE
[I-D.wing-mmusic-ice-mobility], it can let the ICE agent gather and
perform the connectivity checks. When the connectivity checks
succeed, the ICE agent should notify the MPRTP layer of these new
paths (5-tuples), these new paths are then used by MPRTP to send
media packets depending on the scheduling algorithm.
If an endpoint supports Interface selection via PCP Flow Extension
[I-D.reddy-mmusic-ice-best-interface-pcp], it will receive
notifications when new interfaces become available and additionally
when the link quality of a currently available interface changes.
The application can advertise and perform connectivity checks with
the new interface and in the case of changes in link quality pass the
information to the scheduling algorithm for better application
performance.
[Editors note: The interaction between the RTP agent and ICE agent is
needed for implementing a scheduling algorithm or congestion control.
See details of a scheduling algorithm in [ACM-MPRTP].]
8.1.3. Choosing between In-band (in RTCP) and Out-of-band (in SDP)
Interface Advertisement
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
advertise them in SDP (See [I-D.singh-mmusic-mprtp-sdp-extension]).
Alternatively, the endpoint can setup the session as a single path
media session and upgrade the session to multipath by advertising the
session in-band (See Section 8.1.4 or
[I-D.wing-mmusic-ice-mobility]). Moreover, if an interface appears
and disappears, the endpoint SHOULD prefer to advertise it in-band
because the endpoint would not have to wait for a response from the
other endpoint before starting to use the interface. However, if
there is a conflict between an in-band and out-of-band advertisement,
i.e., the endpoint receives an in-band advertisement while it has a
pending out-of-band advertisement, or vice versa then the session is
setup using out-of-band mechanisms.
8.1.4. In-band Interface Advertisement
To advertise the multiple interfaces in RTCP, an MPRTP-capable
endpoint MUST add the MPRTP Interface Advertisement defined in
Figure 13 with the RTCP Sender Report (SR). Each unique address is
Singh, et al. Expires January 7, 2016 [Page 16]
Internet-Draft Multipath RTP July 2015
encapsulated in an Interface Advertisement block and contains the IP
address, RTP and RTCP 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
endpoints MUST indicate the negotiated single path IP, RTP port and
RTCP port addresses.
8.1.5. Subflow ID Assignment
After interface advertisements have been exchanged, the endpoint MUST
associate a Subflow ID to each unique subflow. Each combination of
sender and receiver IP addresses and port pairs (5-tuple) is a unique
subflow. If the connectivity checks have been performed then the
endpoint MUST only use the subflows for which the connectivity checks
have succeeded.
8.1.6. Active and Passive Subflows
To send and receive data an endpoint MAY use any number of subflows
from the set of available subflows. The subflows that carry media
data are called active subflows, while those subflows that don't send
any media packets (fallback paths) are called passive subflows.
An endpoint MUST multiplex the subflow specific RTP and RTCP packets
on the same port to keep the NAT bindings alive. This is inline with
the recommendation made in RFC6263[RFC6263]. Moreover, if an
endpoint uses ICE, multiplexing RTP and RTCP reduces the number of
components from 2 to 1 per media stream. If no MPRTP or MPRTCP
packets are received on a particular subflow at a receiver, the
receiver SHOULD remove the subflow from active and passive lists and
not send any MPRTCP reports for that subflow. It may keep the
bindings in a dead-pool, so that if the 5-tuple or subflow reappears,
it can quickly reallocate it based on past history.
8.2. RTP Transmission
If both endpoints are MPRTP-capable and if they want to use their
multiple interfaces for sending the media stream then they MUST use
the MPRTP header extensions. They MAY use normal RTP with legacy
endpoints (see Appendix A).
An MPRTP endpoint sends RTP packets with an MPRTP extension that maps
the media packet to a specific subflow (see Figure 8). The MPRTP
layer SHOULD associate an RTP packet with a subflow based on a
Singh, et al. Expires January 7, 2016 [Page 17]
Internet-Draft Multipath RTP July 2015
scheduling strategy. The scheduling strategy may either choose to
augment the paths to create higher throughput or use the alternate
paths for enhancing resilience or error-repair. Due to the changes
in path characteristics, the endpoint should be able change its
scheduling strategy during an ongoing session. The MPRTP sender MUST
also populate the subflow specific fields described in the MPRTP
extension header (see Section 9.1.1).
[ACM-MPRTP] describes and evaluates a scheduling algorithm for video
over multiple interfaces. The video is encoded at a single target
bit rate and is evaluated in various network scenarios, as discussed
in [I-D.ietf-rmcat-eval-criteria].
8.3. Playout Considerations at the Receiver
A media receiver, irrespective of MPRTP support or not, should be
able to playback the media stream because the received RTP packets
are compliant to [RFC3550], i.e., a non-MPRTP receiver will ignore
the MPRTP header and still be able to playback the RTP packets.
However, the variation of jitter and loss per path may affect proper
playout. The receiver can compensate for the jitter by modifying the
playout delay (i.e., by calculating skew across all paths) of the
received RTP packets. For example, an adaptive playout algorithm is
discussed in [ACM-MPRTP].
8.4. Subflow-specific RTCP Statistics and RTCP Aggregation
Aggregate RTCP provides the overall media statistics and follows the
normal RTCP defined in RFC3550 [RFC3550]. However, subflow specific
RTCP provides the per path media statistics because the aggregate
RTCP report may not provide sufficient per path information to an
MPRTP scheduler. Specifically, the scheduler should be aware of each
path's RTT and loss-rate, which an aggregate RTCP cannot provide.
The aggregate RTCP report (i.e., the regularly scheduled RTCP report)
MUST be sent compounded as described in [RFC5506], however, the
subflow-specific RTCP reports MAY be sent non-compounded. Further,
each subflow and the aggregate RTCP report MUST follow the timing
rules defined in [RFC4585].
The RTCP reporting interval is locally implemented and the scheduling
of the RTCP reports may depend on the the behavior of each path. For
instance, the RTCP interval may be different for a passive path than
an active path to keep port bindings alive. Additionally, an