-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdraft-dt-rmcat-feedback-message-01.txt
672 lines (454 loc) · 27.5 KB
/
draft-dt-rmcat-feedback-message-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
IETF RMCAT Working Group Z. Sarker
Internet-Draft Ericsson AB
Intended status: Standards Track C. Perkins
Expires: May 1, 2017 University of Glasgow
V. Singh
callstats.io
M. Ramalho
Cisco Systems
October 28, 2016
RTP Control Protocol (RTCP) Feedback for Congestion Control
draft-dt-rmcat-feedback-message-01
Abstract
This document describes a feedback message intended to enable
congestion control for interactive real-time traffic. The RTP Media
Congestion Avoidance Techniques (RMCAT) Working Group formed a design
team to analyze feedback requirements from various congestion control
algorithms and to design a generic feedback message to help ensure
interoperability across those algorithms. The feedback message is
designed for a sender-based congestion control, which means the
receiver of the media will send necessary feedback to the sender of
the media to perform the congestion control at the sender.
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 May 1, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sarker, et al. Expires May 1, 2017 [Page 1]
Internet-Draft Congestion Control Feedback in RTCP October 2016
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Feedback Message . . . . . . . . . . . . . . . . . . . . . . 3
3.1. RTCP XR Block for Reporting Congestion Control Feedback . 4
3.2. RTP/AVPF Transport Layer Feedback for Congestion Control 6
4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7
5. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 9
7.2. RTCP XR Report Blocks . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
For interactive real-time traffic the typical protocol choice is
Realtime Transport Protocol (RTP) over User Datagram Protocol (UDP).
RTP does not provide any guarantee of Quality of Service (QoS),
reliable or timely delivery and expects the underlying transport
protocol to do so. UDP alone certainly does not meet that
expectation. However, RTP Control Protocol (RTCP) provides a
mechanism to periodically send transport and media metrics to the
media sender which can be utilized and extended for the purposes of
RMCAT congestion control. For a congestion control algorithm which
operates at the media sender, RTCP messages can be transmitted from
the media receiver back to the media sender to enable congestion
control. In the absence of standardized messages for this purpose,
the congestion control algorithm designers have designed proprietary
RTCP messages that convey only those parameters required for their
respective designs. As a direct result, the different congestion
control (a.k.a. rate adaptation) designs are not interoperable. To
enable algorithm evolution as well as interoperability across designs
Sarker, et al. Expires May 1, 2017 [Page 2]
Internet-Draft Congestion Control Feedback in RTCP October 2016
(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 format that can be used by
NADA [I-D.ietf-rmcat-nada], SCReAM [I-D.ietf-rmcat-scream-cc], Google
Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck
Detection [I-D.ietf-rmcat-sbd], and hopefully future RTP congestion
control algorithms as well.
[Editor's Note: consider removing this part of the section in the
later versions ] In preparing this memo, we have considered the
following:
o What are the feedback requirements for the proposed RTP congestion
control candidate solution?
o Can we design a feedback message that is future proof, and general
enough to meet the needs of algorithms that have yet to be
defined?
o Can we use existing RTCP Extended Report (XR) blocks and/or RTCP
Feedback Messages? If not, what is the rationale behind new XR
blocks and/or RTCP feedback messages?
o What will be the wire format of the generic feedback message?
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. Feedback Message
The design team analyzed the feedback requirements from the different
proposed candidate in RMCAT WG. The analysis showed some
commonalities between the proposed solution candidate and some can be
derived from other information. The design team has agreed to have
following packet information block in the feedback message to satisfy
different requirement analyzed.
o Packet Identifier : RTP sequence number. The RTP packet header
includes an incremental packet sequence number that the sender
Sarker, et al. Expires May 1, 2017 [Page 3]
Internet-Draft Congestion Control Feedback in RTCP October 2016
needs to correlate packets sent at the sender with packets
received at the receiver.
o Packet Arrival Time : Arrival time stamp at the receiver of the
media. The sender requires the arrival time stamp of the
respective packet to determine delay and jitter the packet had
experienced during transmission. In a sender based congestion
control solution the sender requires to keep track of the sent
packets - usually packet sequence number, packet size and packet
send time. With the packet arrival time the sender can detect the
delay and jitter information. Along with packet loss and delay
information the sender can estimate the available bandwidth and
thus adapt to the situation.
o Packet Explicit Congestion Notification (ECN) Marking : If ECN
[RFC3168] is used, it is necessary to report on the 2-bit ECN mark
in received packets, indicating for each packet whether it is
marked not-ECT, ECT(0), ECT(1), or ECN-CE. If the path on which
the media traffic traversing is ECN capable then the sender can
use the Congestion Experienced (ECN-CE) marking information for
congestion control. It is important that the receiver sends the
ECN-CE marking information of the packet back to the sender to
take the advantages of ECN marking. Note that how the receiver
gets the ECN marking information at application layer is out of
the scope of this design team. Additional information for ECN use
with RTP can be found at [RFC6679].
The feedback messages can have one or more of the above information
blocks. For RTCP based feedback message the packet information block
will be grouped by Synchronization Source (SSRC) identifier.
As a practical matter, we note that host Operating System (OS)
process interruptions can occur at inopportune times. Thus, the
recording of the sent times at the sender and arrival times at the
receiver should be made with 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 should be recorded at the latest opportunity prior to
outputting the media packet at the sender (e.g., socket or RTP API)
and the arrival time at the receiver (e.g., socket or RTP API) should
be recorded at the earliest opportunity available to the receiver.
3.1. RTCP XR Block for Reporting Congestion Control Feedback
Congestion control feedback can be sent as part of a scheduled RTCP
report, or as RTP/AVPF early feedback. If sent as part of a
scheduled RTCP report, the feedback is sent as an XR block, as part
of a regular compound RTCP packet. The format of the RTCP XR report
Sarker, et al. Expires May 1, 2017 [Page 4]
Internet-Draft Congestion Control Feedback in RTCP October 2016
block is as follows (this will be preceded in the compound RTCP
packet by an RTCP XR header, described in [RFC3611], that includes
the SSRC of the report sender):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=RC2F | Report count | Block Length = TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Timestamp (32bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of 1st media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|ECN| Arrival time offset | ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of nth media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|ECN| Arrival time offset | ... |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The XR Discard RLE report block uses the same format as specified for
the loss and duplicate report blocks in [RFC3611]. The fields "block
length", "begin_seq", and "end_seq" have the same semantics and
representation as defined in [RFC3611]
Block Type (BT, 8 bits): The RMCAT congestion control feedback Report
Block is identified by the constant RC2F. [Note to RFC Editor:
Please replace RC2F with the IANA provided RTCP XR block type for
this block.]
Report Count (8 bits): field describes the number of SSRCs reported
by this report block. The number should at least be 1.
Report Timestamp (RTS, 32 bits): represents the timestamp when this
report was generated. The sender of the feedback message decides on
the wall-clock. Usually, it should be derived from the same wall-
clock that is used for timestamping RTP packets arrival . Consistency
in the unit and resolution (10th of millisecond should be good enough
Sarker, et al. Expires May 1, 2017 [Page 5]
Internet-Draft Congestion Control Feedback in RTCP October 2016
) is important here. In addition, the media sender can ask for a
specific resolution it wants.
Each sequence number between the begin_seq and end_seq (both
inclusive) is represented by a packet metric block of 16-bits that
contains the L, ECN, and ATO metrics. If an odd number of reports
are included, i.e., end_seq - begin_seq is odd then it should be
rounded up to four (4) bytes boundary. [FIXME : the solution will
depend on the compression used (if any), revisit this if packet
format is changed later]
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.
ECN (2 bits): is the echoed ECN mark of the packet (00 if not
received or if ECN is not used).
Arrival time offset (ATO, 13 bits): it the relative arrival time of
the RTP packets at the receiver before this feedback report was
generated measured in milliseconds. It is calculated by subtracting
the reception timestamp of the RTP packet denoted by this 16bit block
and the timestamp (RTS) of this report.
[FIXME: should reserve 0xFFF to mean anything greater than 0xFFE?
This needs to wait until we have fixed the packet format ]
3.2. RTP/AVPF Transport Layer Feedback for Congestion Control
Congestion control feedback can also be sent in a non-compound RTCP
packet [RFC5506] if the RTP/AVPF profile [RFC4585] or the RTP/SAVPF
profile [RFC5124] is used. In this case, the congestion control
feedback is sent as a Transport Layer FB message (RTCP packet type
205), with FMT=2 (congestion control feedback). The format of this
RTCP packet is as follows:
Sarker, et al. Expires May 1, 2017 [Page 6]
Internet-Draft Congestion Control Feedback in RTCP October 2016
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 = 2 | PT = 205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of 1st media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|ECN| Arrival time offset | ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of nth media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|ECN| Arrival time offset | ... |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Timestamp (32bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first 8 octets are the RTCP header, with PT=205 and FMT=2
specifying the remainder is a congestion control feedback packet, and
including the SSRC of the packet sender.
Section 6.1 of [RFC4585] requires this is followed by the SSRC of the
media source being reported upon. Accordingly, the format of the
report is changed from that of the RTCP XR report block, to move the
timestamp to the end. The meaning of all the fields is a described
in Section 3.1.
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, and the possible rates of feedback.
It is a general understanding that the congestion control algorithms
will work better with more frequent feedback - per packet feedback.
However, RTCP bandwidth and transmission rules put some upper limits
on how frequently the RTCP feedback messages can be send from the
Sarker, et al. Expires May 1, 2017 [Page 7]
Internet-Draft Congestion Control Feedback in RTCP October 2016
media receiver to the media sender. It has been shown
[I-D.ietf-rmcat-rtp-cc-feedback] that in most cases a per frame
feedback is a reasonable assumption on how frequent the RTCP feedback
messages can be transmitted. The design team also have noted that
even if a higher frequency of feedback is desired it is not viable if
the feedback messages starts to compete against the media traffic on
the feedback path during congestion period. Analyzing the feedback
interval requirement [feedback-requirements] it can be seen that the
candidate algorithms can perform with a feedback interval range of
50-200ms. A value within this range need to be negotiated at session
setup.
5. Design Rationale
The primary function of RTCP Sender Report (SR) / Receiver Report
(RR) is to report the reception quality of media. The regular SR /
RR reports contain information about observed jitter, fractional
packet loss and cumulative packet loss. The original intent of this
information was to assist flow and congestion control mechanisms.
Even though it is possible to do congestion control based on
information provided in the SR/RR reports it is not sufficient to
design an efficient congestion control algorithm for interactive
real-time communication. An efficient congestion control algorithm
requires more fine grain information on per packet (see Section 3) to
react to the congestion or to avoid funder congestion on the path.
Codec Control Message for AVPF [RFC5104] defines Temporary Maximum
Media Bit Rate (TMMBR) message which conveys a temporary maximum
bitrate limitation from the receiver of the media to the sender of
the media. Even though it is 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 with reduced sized reports
[RFC5506]. This requires the receiver of the media to analyze the
data reception, detect congestion level and recommend a maximum
bitrate suitable for current available bandwidth on the path with an
assumption that the sender of the media always honors the TMMBR
message. This requirement is completely opposite of the sender based
congestion control approach. Hence, TMMBR cannot be as a signaling
means for a sender based congestion control mechanism. However,
TMMBR should be viewed a complimentary signaling mechanism to
establish receiver's current view of acceptable maximum bitrate which
a sender based congestion control should honor.
There are number of RTCP eXtended Report (XR) blocks have been
defined for reporting of delay, loss and ECN marking. It is possible
to combine several XR blocks to report the loss and ECN marking at
Sarker, et al. Expires May 1, 2017 [Page 8]
Internet-Draft Congestion Control Feedback in RTCP October 2016
the cost of overhead and complexity. However, there is no existing
RTCP XR block to report packet arrival time.
Considering the issues discussed here it is rational to design a new
congestion control feedback signaling mechanism for sender based
congestion control algorithm.
6. Acknowledgements
This document is an outcome of RMCAT design team discussion. We
would like to thank all participants specially Xiaoquing Zhu, Stefan
Holmer, David, Ingemar Johansson and Randell Jesup for their valuable
contribution to the discussions and to the document.
7. IANA Considerations
7.1. RTP/AVPF Transport Layer Feedback Message
TBD
7.2. RTCP XR Report Blocks
TBD
8. Security Considerations
There is a risk of causing congestion if an on-path attacker modifies
the feedback messages in such a manner to make available bandwidth
greater than it is in reality. [More on security consideration TBD.]
9. References
9.1. Normative References
[I-D.ietf-rmcat-rtp-cc-feedback]
Perkins, C., "Using RTP Control Protocol (RTCP) Feedback
for Unicast Multimedia Congestion Control", draft-ietf-
rmcat-rtp-cc-feedback-01 (work in progress), July 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://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,
<http://www.rfc-editor.org/info/rfc3168>.
Sarker, et al. Expires May 1, 2017 [Page 9]
Internet-Draft Congestion Control Feedback in RTCP October 2016
[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, <http://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,
<http://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,
<http://www.rfc-editor.org/info/rfc3611>.
[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,
<http://www.rfc-editor.org/info/rfc4585>.
[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, <http://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, <http://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, <http://www.rfc-editor.org/info/rfc6679>.
9.2. Informative References
[feedback-requirements]
"RMCAT Feedback Requirements",
<://www.ietf.org/proceedings/95/slides/slides-95-rmcat-
1.pdf>.
[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.
Sarker, et al. Expires May 1, 2017 [Page 10]
Internet-Draft Congestion Control Feedback in RTCP October 2016
[I-D.ietf-rmcat-nada]
Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu,
J., D'Aronco, S., and C. Ganzhorn, "NADA: A Unified
Congestion Control Scheme for Real-Time Media", draft-
ietf-rmcat-nada-03 (work in progress), September 2016.
[I-D.ietf-rmcat-sbd]
Hayes, D., Ferlin, S., Welzl, M., and K. Hiorth, "Shared
Bottleneck Detection for Coupled Congestion Control for
RTP Media.", draft-ietf-rmcat-sbd-05 (work in progress),
September 2016.
[I-D.ietf-rmcat-scream-cc]
Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
for Multimedia", draft-ietf-rmcat-scream-cc-06 (work in
progress), August 2016.
[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, <http://www.rfc-editor.org/info/rfc5104>.
Authors' Addresses
Zaheduzzaman Sarker
Ericsson AB
Luleae
Sweden
Phone: +46107173743
Email: [email protected]
Colin Perkins
University of Glasgow
School of Computing Science
Glasgow G12 8QQ
United Kingdom
Email: [email protected]
Sarker, et al. Expires May 1, 2017 [Page 11]
Internet-Draft Congestion Control Feedback in RTCP October 2016
Varun Singh
Nemu Dialogue Systems Oy
Runeberginkatu 4c A 4
Helsinki 00100
Finland
Email: [email protected]
URI: http://www.callstats.io/
Michael A. Ramalho
Cisco Systems, Inc.
6310 Watercrest Way Unit 203
Lakewood Ranch, FL 34202
USA
Phone: +1 919 476 2038
Email: [email protected]
Sarker, et al. Expires May 1, 2017 [Page 12]