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
|
<pre>Internet Engineering Task Force (IETF) R. Huang
Request for Comments: 7509 Huawei
Category: Standards Track V. Singh
ISSN: 2070-1721 Aalto University
May 2015
<span class="h1">RTP Control Protocol (RTCP) Extended Report (XR)</span>
<span class="h1">for Post-Repair Loss Count Metrics</span>
Abstract
This document defines an RTP Control Protocol (RTCP) Extended Report
(XR) block that allows reporting of a post-repair loss count metric
for a range of RTP applications. In addition, another metric,
repaired loss count, is also introduced in this report block for
calculating the pre-repair loss count when needed, so that the RTP
sender or a third-party entity is able to evaluate the effectiveness
of the repair methods used by the system.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7509">http://www.rfc-editor.org/info/rfc7509</a>.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Singh & Huang Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7509">RFC 7509</a> Post-Repair Non-RLE Loss Count May 2015</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Post-Repair Loss Count Metrics Report Block .....................<a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Report Block Structure .....................................<a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. Example Usage ..............................................<a href="#page-5">5</a>
<a href="#section-4">4</a>. SDP Signaling ...................................................<a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. SDP rtcp-xr-attrib Attribute Extension .....................<a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. Offer/Answer Usage .........................................<a href="#page-7">7</a>
<a href="#section-5">5</a>. Security Considerations .........................................<a href="#page-7">7</a>
<a href="#section-6">6</a>. IANA Considerations .............................................<a href="#page-7">7</a>
<a href="#section-6.1">6.1</a>. New RTCP XR Block Type Value ...............................<a href="#page-7">7</a>
<a href="#section-6.2">6.2</a>. New RTCP XR SDP Parameter ..................................<a href="#page-7">7</a>
<a href="#section-6.3">6.3</a>. Contact Information for Registrations ......................<a href="#page-7">7</a>
<a href="#section-7">7</a>. References ......................................................<a href="#page-8">8</a>
<a href="#section-7.1">7.1</a>. Normative References .......................................<a href="#page-8">8</a>
<a href="#section-7.2">7.2</a>. Informative References .....................................<a href="#page-9">9</a>
<a href="#appendix-A">Appendix A</a>. Metrics Represented Using the Template from <a href="./rfc6390">RFC 6390</a> ..10
Acknowledgments ...................................................<a href="#page-11">11</a>
Authors' Addresses ................................................<a href="#page-11">11</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
RTCP Sender Reports (SRs) / Receiver Reports (RRs) [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] contain
some rough statistics about the data received from the particular
source indicated in that block. One of them is the cumulative number
of packets lost, which is called the pre-repair loss metric in this
document. This metric conveys information regarding the total number
of RTP data packets that have been lost since the beginning of the
RTP session.
However, this metric is measured on the media stream before any loss-
repair mechanism, e.g., retransmission [<a href="./rfc4588" title=""RTP Retransmission Payload Format"">RFC4588</a>] or Forward Error
Correction (FEC) [<a href="./rfc5109" title=""RTP Payload Format for Generic Forward Error Correction"">RFC5109</a>], is applied. Using a repair mechanism
usually results in recovering some or all of the lost packets. The
recovery process does not reduce the values reported by the two loss
metrics in RTCP RR [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] -- namely, the fraction lost and the
cumulative loss. Hence, the sending endpoint cannot infer the
performance of the repair mechanism based on the aforementioned
metrics in [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>].
Consequently, [<a href="./rfc5725" title=""Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)"">RFC5725</a>] specifies a post-repair loss Run-Length
Encoding (RLE) XR report block to address this issue. The sending
endpoint is able to infer which packets were repaired from the RLE
report block, but the reporting overhead for the packet-by-packet
report block is higher compared to other report blocks.
<span class="grey">Singh & Huang Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7509">RFC 7509</a> Post-Repair Non-RLE Loss Count May 2015</span>
When applications use multiple XR blocks, the endpoints may require
more concise reporting to save bandwidth. This document defines a
new XR block type to augment those defined in [<a href="./rfc3611" title=""RTP Control Protocol Extended Reports (RTCP XR)"">RFC3611</a>] and
complement the report block defined in [<a href="./rfc5725" title=""Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)"">RFC5725</a>] for use in a range
of RTP applications. This new block type reports the post-repair
loss count metric, which records the number of primary source RTP
packets that are still lost after applying one or more loss-repair
mechanisms. In addition, another metric, repaired loss count, is
also introduced in this report block for calculating the pre-repair
loss count during this range, so that the RTP sender or a third-party
entity is able to evaluate the effectiveness of the repair methods
used by the system. The metrics defined in this document are packet
level rather than slice/picture level; this means the partial
recovery of a packet will not be regarded as a repaired packet.
The metrics defined in this document belong to the class of
transport-related metrics defined in [<a href="./rfc6792" title=""Guidelines for Use of the RTP Monitoring Framework"">RFC6792</a>] and are specified in
accordance with the guidelines in [<a href="./rfc6390" title=""Guidelines for Considering New Performance Metric Development"">RFC6390</a>] and [<a href="./rfc6792" title=""Guidelines for Use of the RTP Monitoring Framework"">RFC6792</a>]. These
metrics are applicable to any RTP application, especially those that
use loss-repair mechanisms.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
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 [<a href="#ref-KEYWORDS" title=""Key words for use in RFCs to Indicate Requirement Levels"">KEYWORDS</a>].
primary source RTP packet: The original RTP packet sent from the RTP
sender for the first time. A lost primary source RTP packet may
be repaired by some other RTP packets used in repair mechanisms
like FEC or retransmission.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Post-Repair Loss Count Metrics Report Block</span>
This block reports the number of packets lost after applying repair
mechanisms (e.g., FEC). It complements the RTCP XR metrics defined
in [<a href="./rfc5725" title=""Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)"">RFC5725</a>]. As noted in [<a href="./rfc5725" title=""Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)"">RFC5725</a>], ambiguity may occur when
comparing this metric with a pre-repair loss metric reported in an
RTCP SR/RR, i.e., some packets were not repaired in the current RTCP
interval, but they may be repaired later. Therefore, this block uses
a begin sequence number and an end sequence number to explicitly
indicate the actual sequence number range reported by this RTCP XR.
Accordingly, only packets that have no further chance of being
repaired and that have been repaired are included in this report
block.
<span class="grey">Singh & Huang Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7509">RFC 7509</a> Post-Repair Non-RLE Loss Count May 2015</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Report Block Structure</span>
The Post-Repair Loss Count Metrics Report Block has the following
format:
0 1 2 3 4
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=33 | Reserved | Block length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Post-repair loss count | Repaired loss count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Block Type (BT): 8 bits
A Post-Repair Loss Count Metrics Report Block is identified by the
constant 33.
Reserved: 8 bits
These bits are reserved for future use. They MUST be set to zero
by senders and ignored by receivers (see <a href="./rfc6709#section-4.2">Section 4.2 of
[RFC6709]</a>).
Block length: 16 bits
This field is in accordance with the definition in [<a href="./rfc3611" title=""RTP Control Protocol Extended Reports (RTCP XR)"">RFC3611</a>]. In
this report block, it MUST be set to 4. The block MUST be
discarded if the block length is set to a different value.
SSRC of source: 32 bits
As defined in <a href="./rfc3611#section-4.1">Section 4.1 of [RFC3611]</a>.
begin_seq: 16 bits
The first sequence number that this block reports on. It can
remain fixed when calculating metrics over several RTCP reporting
intervals.
end_seq: 16 bits
The last sequence number that this block reports on plus one.
<span class="grey">Singh & Huang Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7509">RFC 7509</a> Post-Repair Non-RLE Loss Count May 2015</span>
Post-repair loss count: 16 bits
Total number of packets finally lost after applying one or more
loss-repair methods, e.g., FEC and/or retransmission, during the
actual sequence number range indicated by begin_seq and end_seq.
This metric MUST NOT count the lost packets for which repair might
still be possible. Note that this metric MUST measure only
primary source RTP packets.
Repaired loss count: 16 bits
Total number of packets fully repaired after applying one or more
loss-repair methods, e.g., FEC and/or retransmission, during the
actual sequence number range indicated by begin_seq and end_seq.
Note that this metric MUST measure only primary source RTP
packets.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Example Usage</span>
The metrics defined in this report block are all measured at the RTP
receiver. However, the receiving endpoint can report the metrics in
two different ways:
1) Cumulative report
In this case, implementations may set begin_seq to the first packet
in the RTP session, and it will remain fixed across all reports.
Hence, the "Post-repair loss count" and "Repaired loss count",
respectively, will correspond to "Cumulative post-repair loss count"
and "Cumulative repaired loss count" in this case. These cumulative
metrics when combined with the cumulative loss metrics reported in an
RTCP RR (pre-repair) assist in calculating the "Still-to-be-repaired
lost packets":
Still-to-be-repaired lost packets =
Cumulative number of packets lost -
Cumulative post-repair loss count -
Cumulative repaired loss count
2) Interval report
Some implementations may align the begin_seq and end_seq number with
the highest sequence numbers of consecutive RTCP RRs (RTCP interval).
This is NOT RECOMMENDED as packets that are not yet repaired in this
current RTCP interval and may be repaired in the subsequent intervals
will not be reported. An interval report is illustrated in the
following example:
<span class="grey">Singh & Huang Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7509">RFC 7509</a> Post-Repair Non-RLE Loss Count May 2015</span>
Interval A: The extended highest sequence number received in RTCP
RR is 20. Begin_seq is 10 and end_seq is 20.
Interval B: The extended highest sequence number received in RTCP
RR is 30. Begin_seq is 20 and end_seq is 30.
If packets 17 and 19 are lost and not yet repaired in interval A and
subsequently repaired in interval B, they will not be reported
because their sequence numbers do not belong in interval B.
Therefore, if implementations want these packets to be reported as
repaired, they MUST NOT align the begin_seq and end_seq to the RTCP
intervals.
Alternatively, implementations may choose the begin_seq and end_seq
numbers that cover several RTCP intervals. Additionally, the
reported range of sequence numbers may overlap with the previous
report blocks, so that the packets that were not yet repaired in one
interval, but were subsequently repaired or deemed unrepairable, were
reported in subsequent intervals.
In this case, the "Cumulative number of packets lost" cannot be
easily compared with the post-repair metrics. However, the sending
endpoint can calculate the efficiency of the error resilience
algorithm using the post-repair and repaired loss count,
respectively.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. SDP Signaling</span>
[<a id="ref-RFC3611">RFC3611</a>] defines the use of SDP (Session Description Protocol) for
signaling the use of RTCP XR blocks. However, XR blocks MAY be used
without prior signaling (see <a href="./rfc3611#section-5">Section 5 of [RFC3611]</a>).
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. SDP rtcp-xr-attrib Attribute Extension</span>
This session augments the SDP attribute "rtcp-xr" defined in <a href="./rfc3611#section-5.1">Section</a>
<a href="./rfc3611#section-5.1">5.1 of [RFC3611]</a> by providing an additional value of "xr-format" to
signal the use of the report block defined in this document. The
ABNF [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>] syntax is as follows.
xr-format =/ xr-prlr-block
xr-prlr-block = "post-repair-loss-count"
<span class="grey">Singh & Huang Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7509">RFC 7509</a> Post-Repair Non-RLE Loss Count May 2015</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Offer/Answer Usage</span>
When SDP is used in offer/answer context, the SDP Offer/Answer usage
defined in [<a href="./rfc3611" title=""RTP Control Protocol Extended Reports (RTCP XR)"">RFC3611</a>] for the unilateral "rtcp-xr" attribute
parameters applies. For detailed usage of Offer/Answer for
unilateral parameters, refer to <a href="./rfc3611#section-5.2">Section 5.2 of [RFC3611]</a>.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
This proposed RTCP XR block introduces no new security considerations
beyond those described in [<a href="./rfc3611" title=""RTP Control Protocol Extended Reports (RTCP XR)"">RFC3611</a>]. This block does not provide
per-packet statistics, so the risk to confidentiality documented in
<a href="#section-7">Section 7</a>, paragraph 3 of [<a href="./rfc3611" title=""RTP Control Protocol Extended Reports (RTCP XR)"">RFC3611</a>] does not apply.
An attacker may put incorrect information in the Post-Repair Loss
Count reports, which will affect the performance of loss-repair
mechanisms. Implementers should consider the guidance in [<a href="./rfc7202" title=""Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution"">RFC7202</a>]
for using appropriate security mechanisms, i.e., where security is a
concern, the implementation should apply encryption and
authentication to the report block. For example, this can be
achieved by using the AVPF profile together with the Secure RTP
profile as defined in [<a href="./rfc3711" title=""The Secure Real-time Transport Protocol (SRTP)"">RFC3711</a>]; an appropriate combination of the
two profiles (an "SAVPF") is specified in [<a href="./rfc5124" title=""Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)"">RFC5124</a>]. However, other
mechanisms also exist (documented in [<a href="./rfc7201" title=""Options for Securing RTP Sessions"">RFC7201</a>]) and might be more
suitable.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
New block types for RTCP XR are subject to IANA registration. For
general guidelines on IANA considerations for RTCP XR, refer to
[<a href="./rfc3611" title=""RTP Control Protocol Extended Reports (RTCP XR)"">RFC3611</a>].
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. New RTCP XR Block Type Value</span>
This document assigns the block type value 33 in the IANA "RTP
Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
the "Post-Repair Loss Count Metrics Report Block".
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. New RTCP XR SDP Parameter</span>
This document also registers a new parameter "post-repair-loss-count"
in the "RTP Control Protocol Extended Reports (RTCP XR) Session
Description Protocol (SDP) Parameters Registry".
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Contact Information for Registrations</span>
The contact information for the registrations is:
RAI Area Directors <rai-ads@ietf.org>
<span class="grey">Singh & Huang Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7509">RFC 7509</a> Post-Repair Non-RLE Loss Count May 2015</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-KEYWORDS">KEYWORDS</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3550">RFC3550</a>] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, <a href="./rfc3550">RFC 3550</a>, DOI 10.17487/RFC3550,
July 2003, <<a href="http://www.rfc-editor.org/info/rfc3550">http://www.rfc-editor.org/info/rfc3550</a>>.
[<a id="ref-RFC3611">RFC3611</a>] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)",
<a href="./rfc3611">RFC 3611</a>, DOI 10.17487/RFC3611, November 2003,
<<a href="http://www.rfc-editor.org/info/rfc3611">http://www.rfc-editor.org/info/rfc3611</a>>.
[<a id="ref-RFC3711">RFC3711</a>] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
<a href="./rfc3711">RFC 3711</a>, DOI 10.17487/RFC3711, March 2004,
<<a href="http://www.rfc-editor.org/info/rfc3711">http://www.rfc-editor.org/info/rfc3711</a>>.
[<a id="ref-RFC5124">RFC5124</a>] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", <a href="./rfc5124">RFC 5124</a>, DOI 10.17487/RFC5124, February
2008, <<a href="http://www.rfc-editor.org/info/rfc5124">http://www.rfc-editor.org/info/rfc5124</a>>.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>,
DOI 10.17487/RFC5234, January 2008,
<<a href="http://www.rfc-editor.org/info/rfc5234">http://www.rfc-editor.org/info/rfc5234</a>>.
[<a id="ref-RFC5725">RFC5725</a>] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE
Report Block Type for RTP Control Protocol (RTCP) Extended
Reports (XRs)", <a href="./rfc5725">RFC 5725</a>, DOI 10.17487/RFC5725, February
2010, <<a href="http://www.rfc-editor.org/info/rfc5725">http://www.rfc-editor.org/info/rfc5725</a>>.
<span class="grey">Singh & Huang Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7509">RFC 7509</a> Post-Repair Non-RLE Loss Count May 2015</span>
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-RFC4588">RFC4588</a>] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", <a href="./rfc4588">RFC 4588</a>,
DOI 10.17487/RFC4588, July 2006,
<<a href="http://www.rfc-editor.org/info/rfc4588">http://www.rfc-editor.org/info/rfc4588</a>>.
[<a id="ref-RFC5109">RFC5109</a>] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", <a href="./rfc5109">RFC 5109</a>, DOI 10.17487/RFC5109, December
2007, <<a href="http://www.rfc-editor.org/info/rfc5109">http://www.rfc-editor.org/info/rfc5109</a>>.
[<a id="ref-RFC6390">RFC6390</a>] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", <a href="https://www.rfc-editor.org/bcp/bcp170">BCP 170</a>, <a href="./rfc6390">RFC 6390</a>,
DOI 10.17487/RFC6390, October 2011,
<<a href="http://www.rfc-editor.org/info/rfc6390">http://www.rfc-editor.org/info/rfc6390</a>>.
[<a id="ref-RFC6709">RFC6709</a>] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", <a href="./rfc6709">RFC 6709</a>, DOI
10.17487/RFC6709, September 2012,
<<a href="http://www.rfc-editor.org/info/rfc6709">http://www.rfc-editor.org/info/rfc6709</a>>.
[<a id="ref-RFC6792">RFC6792</a>] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use
of the RTP Monitoring Framework", <a href="./rfc6792">RFC 6792</a>,
DOI 10.17487/RFC6792, November 2012,
<<a href="http://www.rfc-editor.org/info/rfc6792">http://www.rfc-editor.org/info/rfc6792</a>>.
[<a id="ref-RFC7201">RFC7201</a>] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", <a href="./rfc7201">RFC 7201</a>, DOI 10.17487/RFC7201, April 2014,
<<a href="http://www.rfc-editor.org/info/rfc7201">http://www.rfc-editor.org/info/rfc7201</a>>.
[<a id="ref-RFC7202">RFC7202</a>] Perkins, C. and M. Westerlund, "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media
Security Solution", <a href="./rfc7202">RFC 7202</a>, DOI 10.17487/RFC7202, April
2014, <<a href="http://www.rfc-editor.org/info/rfc7202">http://www.rfc-editor.org/info/rfc7202</a>>.
<span class="grey">Singh & Huang Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7509">RFC 7509</a> Post-Repair Non-RLE Loss Count May 2015</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Metrics Represented Using the Template from <a href="./rfc6390">RFC 6390</a></span>
a. Post-Repair RTP Packet Loss Count Metric
* Metric Name: Post-Repair RTP Packet Loss Count Metric.
* Metric Description: Total number of RTP packets still lost
after loss-repair methods are applied.
* Method of Measurement or Calculation: See the "Post-repair
loss count" definition in <a href="#section-3.1">Section 3.1</a>. It is directly
measured and must be measured for the primary source RTP
packets with no further chance of repair.
* Units of Measurement: This metric is expressed as a 16-bit
unsigned integer value giving the number of RTP packets.
* Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream.
* Measurement Timing: This metric relies on the sequence number
interval to determine measurement timing. See the Cumulative
and Interval reports defined in <a href="#section-3.2">Section 3.2</a>.
* Use and Applications: These metrics are applicable to any RTP
application, especially those that use loss-repair mechanisms.
See <a href="#section-1">Section 1</a> for details.
* Reporting Model: See <a href="./rfc3611">RFC 3611</a>.
b. Repaired RTP Packet Loss Count Metric
* Metric Name: Repaired RTP Packet Count Metric.
* Metric Description: The number of RTP packets lost but
repaired after applying loss-repair methods.
* Method of Measurement or Calculation: See the "Repaired loss
count" in <a href="#section-3.1">Section 3.1</a>. It is directly measured and must be
measured for the primary source RTP packets with no further
chance of repair.
* Units of Measurement: This metric is expressed as a 16-bit
unsigned integer value giving the number of RTP packets.
* Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream.
<span class="grey">Singh & Huang Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7509">RFC 7509</a> Post-Repair Non-RLE Loss Count May 2015</span>
* Measurement Timing: This metric relies on the sequence number
interval to determine measurement timing. See the Cumulative
and Interval reports defined in <a href="#section-3.2">Section 3.2</a>.
* Use and Applications: These metrics are applicable to any RTP
application, especially those that use loss-repair mechanisms.
See <a href="#section-1">Section 1</a> for details.
* Reporting Model: See <a href="./rfc3611">RFC 3611</a>.
Acknowledgments
The authors would like to thank Roni Even, Colin Perkins, and Qin Wu
for giving valuable comments and suggestions.
Authors' Addresses
Rachel Huang
Huawei
101 Software Avenue, Yuhua District
Nanjing 210012
China
EMail: rachel.huang@huawei.com
Varun Singh
Aalto University
School of Electrical Engineering
Otakaari 5 A
Espoo, FIN 02150
Finland
EMail: varun@comnet.tkk.fi
URI: <a href="http://www.netlab.tkk.fi/~varun/">http://www.netlab.tkk.fi/~varun/</a>
Singh & Huang Standards Track [Page 11]
</pre>
|
