-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdraft-ietf-avtcore-cc-feedback-message-06.txt
840 lines (594 loc) · 36.2 KB
/
draft-ietf-avtcore-cc-feedback-message-06.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
IETF RMCAT Working Group Z. Sarker
Internet-Draft Ericsson AB
Intended status: Standards Track C. Perkins
Expires: September 10, 2020 University of Glasgow
V. Singh
callstats.io
M. Ramalho
March 9, 2020
RTP Control Protocol (RTCP) Feedback for Congestion Control
draft-ietf-avtcore-cc-feedback-message-06
Abstract
This document describes an RTCP feedback message intended to enable
congestion control for interactive real-time traffic using RTP. The
feedback message is designed for use with a sender-based congestion
control algorithm, in which the receiver of an RTP flow sends RTCP
feedback packets to the sender containing the information the sender
needs to perform congestion control.
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 https://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 September 10, 2020.
Copyright Notice
Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Sarker, et al. Expires September 10, 2020 [Page 1]
Internet-Draft Congestion Control Feedback in RTCP March 2020
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. RTCP Feedback for Congestion Control . . . . . . . . . . . . 3
3.1. RTCP Congestion Control Feedback Report . . . . . . . . . 4
4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7
5. Response to Loss of Feedback Packets . . . . . . . . . . . . 7
6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8
7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 8
8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
For interactive real-time traffic, such as video conferencing flows,
the typical protocol choice is the Real-time Transport Protocol (RTP)
running over the User Datagram Protocol (UDP). RTP does not provide
any guarantee of Quality of Service (QoS), reliability, or timely
delivery, and expects the underlying transport protocol to do so.
UDP alone certainly does not meet that expectation. However, the RTP
Control Protocol (RTCP) provides a mechanism by which the receiver of
an RTP flow can periodically send transport and media quality metrics
to the sender of that RTP flow. This information can be used by the
sender to perform congestion control. In the absence of standardized
messages for this purpose, designers of congestion control algorithms
have developed proprietary RTCP messages that convey only those
parameters needed for their respective designs. As a direct result,
the different congestion control (i.e., rate adaptation) designs are
not interoperable. To enable algorithm evolution as well as
interoperability across designs (e.g., different rate adaptation
algorithms), it is highly desirable to have generic congestion
control feedback format.
To help achieve interoperability for unicast RTP congestion control,
this memo proposes a common RTCP feedback packet format that can be
Sarker, et al. Expires September 10, 2020 [Page 2]
Internet-Draft Congestion Control Feedback in RTCP March 2020
used by NADA [I-D.ietf-rmcat-nada], SCReAM [RFC8298], Google
Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck
Detection [RFC8382], and hopefully also by future RTP congestion
control algorithms.
2. Terminology
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].
In addition the terminology defined in [RFC3550], [RFC3551],
[RFC3611], [RFC4585], and [RFC5506] applies.
3. RTCP Feedback for Congestion Control
Based on an analysis of NADA [I-D.ietf-rmcat-nada], SCReAM [RFC8298],
Google Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck
Detection [RFC8382], the following per-RTP packet congestion control
feedback information has been determined to be necessary:
o RTP sequence number: The receiver of an RTP flow needs to feedback
the sequence numbers of the received RTP packets to the sender, so
the sender can determine which packets were received and which
were lost. Packet loss is used as an indication of congestion by
many congestion control algorithms.
o Packet Arrival Time: The receiver of an RTP flow needs to feedback
the arrival time of each RTP packet to the sender. Packet delay
and/or delay variation (jitter) is used as a congestion signal by
some congestion control algorithms.
o Packet Explicit Congestion Notification (ECN) Marking: If ECN
[RFC3168], [RFC6679] is used, it is necessary to feedback the
2-bit ECN mark in received RTP packets, indicating for each RTP
packet whether it is marked not-ECT, ECT(0), ECT(1), or ECN-CE.
If the path used by the RTP traffic is ECN capable the sender can
use Congestion Experienced (ECN-CE) marking information as a
congestion control signal.
Every RTP flow is identified by its Synchronization Source (SSRC)
identifier. Accordingly, the RTCP feedback format needs to group its
reports by SSRC, sending one report block per received SSRC.
As a practical matter, we note that host operating system (OS)
process interruptions can occur at inopportune times. Accordingly,
recording RTP packet send times at the sender, and the corresponding
RTP packet arrival times at the receiver, needs to be done with
Sarker, et al. Expires September 10, 2020 [Page 3]
Internet-Draft Congestion Control Feedback in RTCP March 2020
deliberate care. This is because the time duration of host OS
interruptions can be significant relative to the precision desired in
the one-way delay estimates. Specifically, the send time needs to be
recorded at the last opportunity prior to transmitting the RTP packet
at the sender, and the arrival time at the receiver needs to be
recorded at the earliest available opportunity.
3.1. RTCP Congestion Control Feedback Report
Congestion control feedback can be sent as part of a regular
scheduled RTCP report, or in an RTP/AVPF early feedback packet. If
sent as early feedback, congestion control feedback MAY be sent in a
non-compound RTCP packet [RFC5506] if the RTP/AVPF profile [RFC4585]
or the RTP/SAVPF profile [RFC5124] is used.
Irrespective of how it is transported, the congestion control
feedback is sent as a Transport Layer Feedback Message (RTCP packet
type 205). The format of this RTCP packet is shown in Figure 1:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=CCFB | PT = 205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of RTCP packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of 1st RTP Stream |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | num_reports |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|ECN| Arrival time offset | ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of nth RTP Stream |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | num_reports |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|ECN| Arrival time offset | ... |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Timestamp (32bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTCP Congestion Control Feedback Packet Format
Sarker, et al. Expires September 10, 2020 [Page 4]
Internet-Draft Congestion Control Feedback in RTCP March 2020
The first eight octets comprise a standard RTCP header, with PT=205
and FMT=CCFB indicating that this is a congestion control feedback
packet, and with the SSRC set to that of the sender of the RTCP
packet. (NOTE TO RFC EDITOR: please replace CCFB here and in the
above diagram with the IANA assigned RTCP feedback packet type, and
remove this note)
Section 6.1 of [RFC4585] requires the RTCP header to be followed by
the SSRC of the RTP flow being reported upon. Accordingly, the RTCP
header is followed by a report block for each SSRC from which RTP
packets have been received, followed by a Report Timestamp.
Each report block begins with the SSRC of the received RTP Stream on
which it is reporting. Following this, the report block contains a
16-bit packet metric block for each RTP packet with sequence number
in the range begin_seq to begin_seq+num_reports inclusive (calculated
using arithmetic modulo 65536 to account for possible sequence number
wrap-around). If the number of 16-bit packet metric blocks included
in the report block is not a multiple of two, then 16 bits of zero
padding MUST be added after the last packet metric block, to align
the end of the packet metric blocks with the next 32 bit boundary.
The value of num_reports MAY be zero, indicating that there are no
packet metric blocks included for that SSRC. Each report block MUST
NOT include more than 16384 packet metric blocks (i.e., it MUST NOT
report on more than one quarter of the sequence number space in a
single report).
The contents of each 16-bit packet metric block comprises the L, ECN,
and ATO fields are as follows:
o L (1 bit): is a boolean to indicate if the packet was received. 0
represents that the packet was not yet received and all the
subsequent bits (ECN and ATO) are also set to 0. 1 represent the
packet was received and the subsequent bits in the block need to
be parsed.
o ECN (2 bits): is the echoed ECN mark of the packet. These are set
to 00 if not received, or if ECN is not used.
o Arrival time offset (ATO, 13 bits): is the arrival time of the RTP
packet at the receiver, as an offset before the time represented
by the Report Timestamp (RTS) field of this RTCP congestion
control feedback report. The ATO field is in units of 1/1024
seconds (this unit is chosen to give exact offsets from the RTS
field) so, for example, an ATO value of 512 indicates that the
corresponding RTP packet arrived exactly half a second before the
time instant represented by the RTS field. If the measured value
is greater than 8189/1024 seconds (the value that would be coded
Sarker, et al. Expires September 10, 2020 [Page 5]
Internet-Draft Congestion Control Feedback in RTCP March 2020
as 0x1FFD), the value 0x1FFE MUST be reported to indicate an over-
range measurement. If the measurement is unavailable, or if the
arrival time of the RTP packet is after the time represented by
the RTS field, then an ATO value of 0x1FFF MUST be reported for
the packet.
The RTCP congestion control feedback report packet concludes with the
Report Timestamp field (RTS, 32 bits). This denotes the time instant
on which this packet is reporting, and is the instant from which the
arrival time offset values are calculated. The value of RTS field is
derived from the same clock used to generate the NTP timestamp field
in RTCP Sender Report (SR) packets. It is formatted as the middle 32
bits of an NTP format timestamp, as described in Section 4 of
[RFC3550].
RTCP congestion control feedback packets SHOULD include a report
block for every active SSRC. The sequence number ranges reported on
in consecutive reports for a given SSRC will generally be contiguous,
but overlapping reports MAY be sent (and need to be sent in cases
where RTP packet reordering occurs across the boundary between
consecutive reports). If reports covering overlapping sequence
number ranges are sent, information in later reports updates that in
sent previous reports for RTP packets included in both reports. If
an RTP packet was reported as received in one report, that packet
MUST also be reported as received in any overlapping reports sent
later that cover its sequence number range.
RTCP congestion control feedback packets can be large if they are
sent infrequently relative to the number of RTP data packets. If an
RTCP congestion control feedback packet is too large to fit within
the path MTU, its sender SHOULD split it into multiple feedback
packets. The RTCP reporting interval SHOULD be chosen such that
feedback packets are sent often enough that they are small enough to
fit within the path MTU ([I-D.ietf-rmcat-rtp-cc-feedback] provides
guidance on how to choose the reporting interval).
If duplicate copies of a particular RTP packet are received, then the
arrival time of the first copy to arrive MUST be reported. If any of
the copies of the duplicated packet are ECN-CE marked, then an ECN-CE
mark MUST be reported that for packet; otherwise the ECN mark of the
first copy to arrive is reported.
If no packets are received from an SSRC in a reporting interval, a
report block MAY be sent with begin_seq set to the highest sequence
number previously received from that SSRC and num_reports set to zero
(or, the report can simply to omitted). The corresponding SR/RR
packet will have a non-increased extended highest sequence number
received field that will inform the sender that no packets have been
Sarker, et al. Expires September 10, 2020 [Page 6]
Internet-Draft Congestion Control Feedback in RTCP March 2020
received, but it can ease processing to have that information
available in the congestion control feedback reports too.
A report block indicating that certain RTP packets were lost is not
to be interpreted as a request to retransmit the lost packets. The
receiver of such a report might choose to retransmit such packets,
provided a retransmission payload format has been negotiated, but
there is no requirement that it do so.
4. Feedback Frequency and Overhead
There is a trade-off between speed and accuracy of reporting, and the
overhead of the reports. [I-D.ietf-rmcat-rtp-cc-feedback] discusses
this trade-off, suggests desirable RTCP feedback rates, and provides
guidance on how to configure the RTCP bandwidth fraction, etc., to
make appropriate use of the reporting block described in this memo.
Specifications for RTP congestion control algorithms can also provide
guidance.
It is generally understood that congestion control algorithms work
better with more frequent feedback. However, RTCP bandwidth and
transmission rules put some upper limits on how frequently the RTCP
feedback messages can be sent from an RTP receiver to the RTP sender.
It has been shown [I-D.ietf-rmcat-rtp-cc-feedback] that in many cases
sending feedback one per frame is an upper bound before the reporting
overhead becomes excessive, although this will depend on the media
rate and more frequent feedback might be needed with high-rate media
flows. Analysis [feedback-requirements] has also shown that some
candidate congestion control algorithms can operate with less
frequent feedback, using a feedback interval range of 50-200ms.
Applications need to negotiate an appropriate congestion control
feedback interval at session setup time, based on the choice of
congestion control algorithm, the expected media bit rate, and the
acceptable feedback overhead.
5. Response to Loss of Feedback Packets
Like all RTCP packets, RTCP congestion control feedback packets might
be lost. All RTP congestion control algorithms MUST specify how they
respond to the loss of feedback packets.
If only a single congestion control feedback packet is lost, an
appropriate response is to assume that the level of congestion has
remained roughly the same as the previous report. However, if
multiple consecutive congestion control feedback packets are lost,
the sender SHOULD rapidly reduce its sending rate towards zero, as
this likely indicates a path failure. The RTP circuit breaker
[RFC8083] provides further guidance.
Sarker, et al. Expires September 10, 2020 [Page 7]
Internet-Draft Congestion Control Feedback in RTCP March 2020
6. SDP Signalling
A new "ack" feedback parameter, "ccfb", is defined for use with the
"a=rtcp-fb:" SDP extension to indicate the use of the RTP Congestion
Control feedback packet format defined in Section 3. The ABNF
definition of this SDP parameter extension is:
rtcp-fb-ack-param = <See Section 4.2 of [RFC4585]>
rtcp-fb-ack-param =/ ccfb-par
ccfb-par = SP "ccfb"
When used with "ccfb" feedback, the wildcard payload type ("*") MUST
be used. This implies that the congestion control feedback is sent
for all payload types in use in the session, including any FEC and
retransmission payload types. An example of the resulting SDP
attribute is:
a=rtcp-fb:* ack ccfb
The offer/answer rules for these SDP feedback parameters are
specified in Section 4.2 of the RTP/AVPF profile [RFC4585].
An SDP offer might indicate support for both the congestion control
feedback mechanism specified in this memo and one or more alternative
congestion control feedback mechanisms that offer substantially the
same semantics. In this case, the answering party SHOULD include
only one of the offered congestion control feedback mechanisms in its
answer. If a re-invite offering the same set of congestion control
feedback mechanisms is received, the generated answer SHOULD choose
the same congestion control feedback mechanism as in the original
answer where possible.
When the SDP BUNDLE extension
[I-D.ietf-mmusic-sdp-bundle-negotiation] is used for multiplexing,
the "a=rtcp-fb:" attribute has multiplexing category IDENTICAL-PER-PT
[I-D.ietf-mmusic-sdp-mux-attributes].
7. Relation to RFC 6679
Use of Explicit Congestion Notification (ECN) with RTP is described
in [RFC6679]. That specifies how to negotiate the use of ECN with
RTP, and defines an RTCP ECN Feedback Packet to carry ECN feedback
reports. It uses an SDP "a=ecn-capaable-rtp:" attribute to negotiate
use of ECN, and the "a=rtcp-fb:" attributes with the "nack" parameter
"ecn" to negotiate the use of RTCP ECN Feedback Packets.
The RTCP ECN Feedback Packet is not useful when ECN is used with the
RTP Congestion Control Feedback Packet defined in this memo since it
Sarker, et al. Expires September 10, 2020 [Page 8]
Internet-Draft Congestion Control Feedback in RTCP March 2020
provides duplicate information. Accordingly, when congestion control
feedback is to be used with RTP and ECN, the SDP offer generated MUST
include an "a=ecn-capable-rtp:" attribute to negotiate ECN support,
along with an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb"
to indicate that the RTP Congestion Control Feedback Packet is to be
used for feedback. The "a=rtcp-fb:" attribute MUST NOT include the
"nack" parameter "ecn", so the RTCP ECN Feedback Packet will not be
used.
8. Design Rationale
The primary function of RTCP SR/RR packets is to report statistics on
the reception of RTP packets. The reception report blocks sent in
these packets contain information about observed jitter, fractional
packet loss, and cumulative packet loss. It was intended that this
information could be used to support congestion control algorithms,
but experience has shown that it is not sufficient for that purpose.
An efficient congestion control algorithm requires more fine grained
information on per packet reception quality than is provided by SR/RR
packets to react effectively. The feedback format defined in this
memo provides such fine grained feedback.
Several other RTCP extensions also provide more detailed feedback
than SR/RR packets:
TMMBR: The Codec Control Messages for the RTP/AVPF profile [RFC5104]
include a Temporary Maximum Media Bit Rate (TMMBR) message. This
is used to convey a temporary maximum bit rate limitation from a
receiver of RTP packets to their sender. Even though it was not
designed to replace congestion control, TMMBR has been used as a
means to do receiver based congestion control where the session
bandwidth is high enough to send frequent TMMBR messages,
especially when used with non-compound RTCP packets [RFC5506].
This approach requires the receiver of the RTP packets to monitor
their reception, determine the level of congestion, and recommend
a maximum bit rate suitable for current available bandwidth on the
path; it also assumes that the RTP sender can/will respect that
bit rate. This is the opposite of the sender based congestion
control approach suggested in this memo, so TMMBR cannot be used
to convey the information needed for a sender based congestion
control. TMMBR could, however, be viewed a complementary
mechanism that can inform the sender of the receiver's current
view of acceptable maximum bit rate. The Received Estimated
Maximum Bit-rate (REMB) mechanism [I-D.alvestrand-rmcat-remb]
provides similar feedback.
RTCP Extended Reports (XR): Numerous RTCP extended report (XR)
blocks have been defined to report details of packet loss, arrival
Sarker, et al. Expires September 10, 2020 [Page 9]
Internet-Draft Congestion Control Feedback in RTCP March 2020
times [RFC3611], delay [RFC6843], and ECN marking [RFC6679]. It
is possible to combine several such XR blocks into a compound RTCP
packet, to report the detailed loss, arrival time, and ECN marking
marking information needed for effective sender-based congestion
control. However, the result has high overhead both in terms of
bandwidth and complexity, due to the need to stack multiple
reports.
Transport-wide Congestion Control: The format defined in this memo
provides individual feedback on each SSRC. An alternative is to
add a header extension to each RTP packet, containing a single,
transport-wide, packet sequence number, then have the receiver
send RTCP reports giving feedback on these additional sequence
numbers [I-D.holmer-rmcat-transport-wide-cc-extensions]. Such an
approach adds the per-packet overhead of the header extension (8
octets per packet in the referenced format), but reduces the size
of the feedback packets, and can simplify the rate calculation at
the sender if it maintains a single rate limit that applies to all
RTP packets sent irrespective of their SSRC. Equally, the use of
transport-wide feedback makes it more difficult to adapt the
sending rate, or respond to lost packets, based on the reception
and/or loss patterns observed on a per-SSRC basis (for example, to
perform differential rate control and repair for audio and video
flows, based on knowledge of what packets from each flow were
lost). Transport-wide feedback is also a less natural fit with
the wider RTP framework, which makes extensive use of per-SSRC
sequence numbers and feedback.
Considering these issues, we believe it appropriate to design a new
RTCP feedback mechanism to convey information for sender based
congestion control algorithms. The new congestion control feedback
RTCP packet described in Section 3 provides such a mechanism.
9. Acknowledgements
This document is based on the outcome of a design team discussion in
the RTP Media Congestion Avoidance Techniques (RMCAT) working group.
The authors would like to thank David Hayes, Stefan Holmer, Randell
Jesup, Ingemar Johansson, Jonathan Lennox, Sergio Mena, Nils
Ohlmeier, Magnus Westerlund, and Xiaoqing Zhu for their valuable
feedback.
10. IANA Considerations
The IANA is requested to register one new RTP/AVPF Transport-Layer
Feedback Message in the table for FMT values for RTPFB Payload Types
[RFC4585] as defined in Section 3.1:
Sarker, et al. Expires September 10, 2020 [Page 10]
Internet-Draft Congestion Control Feedback in RTCP March 2020
Name: CCFB
Long name: RTP Congestion Control Feedback
Value: (to be assigned by IANA)
Reference: (RFC number of this document, when published)
The IANA is also requested to register one new SDP "rtcp-fb"
attribute "ack" parameter, "ccfb", in the SDP ("ack" and "nack"
Attribute Values) registry:
Value name: ccfb
Long name: Congestion Control Feedback
Usable with: ack
Reference: (RFC number of this document, when published)
11. Security Considerations
The security considerations of the RTP specification [RFC3550], the
applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]),
and the RTP congestion control algorithm that is in use (e.g.,
[I-D.ietf-rmcat-nada], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382])
apply.
A receiver that intentionally generates inaccurate RTCP congestion
control feedback reports might be able trick the sender into sending
at a greater rate than the path can support, thereby congesting the
path. This will negatively impact the quality of experience of that
receiver. Since RTP is an unreliable transport, a sender can
intentionally leave a gap in the RTP sequence number space without
causing harm, to check that the receiver is correctly reporting
losses.
An on-path attacker that can modify RTCP congestion control feedback
packets can change the reports to trick the sender into sending at
either an excessively high or excessively low rate, leading to denial
of service. The secure RTCP profile [RFC3711] can be used to
authenticate RTCP packets to protect against this attack.
12. References
12.1. Normative References
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-54 (work in progress), December 2018.
Sarker, et al. Expires September 10, 2020 [Page 11]
Internet-Draft Congestion Control Feedback in RTCP March 2020
[I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), February 2018.
[I-D.ietf-rmcat-rtp-cc-feedback]
Perkins, C., "RTP Control Protocol (RTCP) Feedback for
Congestion Control in Interactive Multimedia Conferences",
draft-ietf-rmcat-rtp-cc-feedback-05 (work in progress),
November 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003,
<https://www.rfc-editor.org/info/rfc3551>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003,
<https://www.rfc-editor.org/info/rfc3611>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/info/rfc4585>.
Sarker, et al. Expires September 10, 2020 [Page 12]
Internet-Draft Congestion Control Feedback in RTCP March 2020
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <https://www.rfc-editor.org/info/rfc5506>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <https://www.rfc-editor.org/info/rfc6679>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", RFC 8083,
DOI 10.17487/RFC8083, March 2017,
<https://www.rfc-editor.org/info/rfc8083>.
12.2. Informative References
[feedback-requirements]
"RMCAT Feedback Requirements",
<://www.ietf.org/proceedings/95/slides/slides-95-rmcat-
1.pdf>.
[I-D.alvestrand-rmcat-remb]
Alvestrand, H., "RTCP message for Receiver Estimated
Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in
progress), October 2013.
[I-D.holmer-rmcat-transport-wide-cc-extensions]
Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions
for Transport-wide Congestion Control", draft-holmer-
rmcat-transport-wide-cc-extensions-01 (work in progress),
October 2015.
[I-D.ietf-rmcat-gcc]
Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S.
Mascolo, "A Google Congestion Control Algorithm for Real-
Time Communication", draft-ietf-rmcat-gcc-02 (work in
progress), July 2016.
[I-D.ietf-rmcat-nada]
Zhu, X., *, R., Ramalho, M., and S. Cruz, "NADA: A Unified
Congestion Control Scheme for Real-Time Media", draft-
ietf-rmcat-nada-13 (work in progress), September 2019.
Sarker, et al. Expires September 10, 2020 [Page 13]
Internet-Draft Congestion Control Feedback in RTCP March 2020
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <https://www.rfc-editor.org/info/rfc5104>.
[RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol
(RTCP) Extended Report (XR) Block for Delay Metric
Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013,
<https://www.rfc-editor.org/info/rfc6843>.
[RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December
2017, <https://www.rfc-editor.org/info/rfc8298>.
[RFC8382] Hayes, D., Ed., Ferlin, S., Welzl, M., and K. Hiorth,
"Shared Bottleneck Detection for Coupled Congestion
Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382,
June 2018, <https://www.rfc-editor.org/info/rfc8382>.
Authors' Addresses
Zaheduzzaman Sarker
Ericsson AB
Torshamnsgatan 21
Stockholm 164 40
Sweden
Phone: +46107173743
Email: [email protected]
Colin Perkins
University of Glasgow
School of Computing Science
Glasgow G12 8QQ
United Kingdom
Email: [email protected]
Varun Singh
CALLSTATS I/O Oy
Annankatu 31-33 C 42
Helsinki 00100
Finland
Email: [email protected]
URI: http://www.callstats.io/
Sarker, et al. Expires September 10, 2020 [Page 14]
Internet-Draft Congestion Control Feedback in RTCP March 2020
Michael A. Ramalho
6310 Watercrest Way Unit 203
Lakewood Ranch, FL 34202-5122
USA
Phone: +1 732 832 9723
Email: [email protected]
URI: http://ramalho.webhop.info/
Sarker, et al. Expires September 10, 2020 [Page 15]