idnits 2.17.1 draft-wu-avt-retransmission-supression-rtp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2010) is 5170 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3550' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 314, but no explicit reference was found in the text == Unused Reference: 'I-D.hunt-avt-monarch-01' is defined on line 322, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pmol-metrics-framework-02' is defined on line 326, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- No information found for draft-hunt-avt-monarch-01 - is the name correct? -- No information found for draft-ietf-pmol-metrics-framework-02 - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Wu 3 Internet-Draft F. Xia 4 Intended status: Standards Track R. Even 5 Expires: August 26, 2010 Huawei 6 February 22, 2010 8 Proposal for an extension to RTCP for Retransmission Storm Suppression 9 of RTP Stream 10 draft-wu-avt-retransmission-supression-rtp-00 12 Abstract 14 This document extends Receiver Summary Information (RSI) report block 15 to define a new sub-report block for retransmission suppression 16 within the framework of RTP retransmission. One of initial 17 retransmission requests for the missing packets is RTCP NACK. This 18 feedback message conveys packet loss events. Unlike NACK, this new 19 sub-report block, which is referred to as the Retransmission Storm 20 Suppression Report, also carries the information regarding 21 retransmission suppression early indication events to the receiver 22 before the receiver detects an original packet loss and all the 23 packet loss repair methods are applied. By using Retransmission 24 Suppression together with NACK, the delay for the receiver to recover 25 from the packet loss can be reduced and the risk of increasing 26 network congestion can be mitigated or avoided. This document also 27 registers a new sub-report block type for Retransmission Storm 28 Suppression within RTP retransmission framework. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt. 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 This Internet-Draft will expire on August 26, 2010. 53 Copyright Notice 55 Copyright (c) 2010 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 83 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 3. Basic Operation . . . . . . . . . . . . . . . . . . . . . . . 5 85 4. Sub-Report Block for Retransmission Suppression Early 86 Indication . . . . . . . . . . . . . . . . . . . . . . . . . . 5 87 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 88 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 6 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 90 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 91 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 92 Appendix A. Example scenarios for Retransmission Storm 93 Suppression . . . . . . . . . . . . . . . . . . . . . 8 94 A.1. Scenario 1: One media Sender, one Distribution Source . . 8 95 A.2. Scenario 2: One Media Sender, more distribution sources . 8 96 Appendix B. Applicability of Retransmission Suppression Early 97 Indication . . . . . . . . . . . . . . . . . . . . . 9 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 100 1. Introduction 102 RTP retransmission is an effective packet loss recovery technique for 103 real-time applications with relaxed delay bounds [RFC4588],e.g., 104 streaming media. The conventional RTCP feedback (NACK) message that 105 indicates the sequence number of the lost RTP packets can be used to 106 request the retransmission of the missing packets [RFC4585]. 108 This RTCP NACK message conveys the RTP sequence number of the lost 109 packets and request the sender to compensate the missing RTP packets 110 based on the RTP sequence number of these packets. However, in lots 111 of multicast environments, packet loss occurs between the media 112 sender and the intermediate network element (e.g., Distribution 113 Source) due to oversaturated network link, faulty networking hardware 114 or corrupted packets rejected in-transit. It may result in 115 retransmission storm targeting at the same sender, i.e., massive 116 retransmission request for the same RTP packets through RTCP NACK to 117 the same multicast sender. To increase the robustness to the loss of 118 a NACK or of a retransmission packet, a receiver may also send 119 multiple NACKs for the same packet. As the retransmission storm 120 progresses, the network is overwhelmed with constant retransmission 121 traffic, in the worsening case, RTP retransmission poses a risk of 122 increasing network congestion, with excessive traffic and degrading 123 network performance, this can eventually lead to a complete loss of 124 network connectivity as the retransmission packets proliferate, the 125 network may become unusable. 127 In order to solve this, the current text in RTCP-SSM allows the 128 distribution source to filter out the NACK messages while this 129 document propose an option to let the receivers know that NACK is not 130 needed in the specified cases. i.e., generating a new RSI sub-report 131 block, which reflects the packet receipt/loss events before the 132 receiver detects an original packet loss and retransmission 133 suppression early indication events before all the packet loss repair 134 methods are applied. 136 This new RSI sub-report block, which we refer to as Retransmission 137 Suppression Early Indication, indicates suppressing requests for 138 transmission of lost packets before the receiver sends a NACK for 139 those packets. In order to detect the original packet loss in the 140 upstream direction before the receiver perceives it, the distribution 141 source located between the sender and receiver may reserve space to 142 replicate one copy of multicast data and check the sequence number 143 consistency of the original multicast packets. Also the distribution 144 source should take into account such factors as the tolerable 145 application delay, the network environment, and the media type. When 146 the packet loss is detected immediately and initial latency is 147 tolerable, in the upstream direction towards the sender, the 148 distribution source may ask for retransmission of the lost packet 149 from the sender using RTCP NACK, in the meanwhile, in the downstream 150 direction from the sender, the distribution source may convey 151 Retransmission Suppression Indication to all the receivers concerned 152 to indicate the receiver not to request packet retransmission. When 153 the sender receives the packet retransmission request from the 154 distribution source, the sender resends the missing packet to the 155 receiver via RTP using retransmission payload format [RFC4588]. 157 Similar to RTCP NACK, the Retransmission Suppression Early Indication 158 also conveys the packet receipt/loss events at the packet level and 159 considers missing packets as unrepaired. But different from RTCP 160 NACK, the retransmission Suppression Early Indication is used by the 161 intermediate network element to suppress retransmission from the 162 receiver and can not be taken as feedback-based error repair 163 mechanism but network based packet loss repair method. 165 Note that the retransmission suppression Early Indication should 166 collectively work together with RTCP NACK to repair the lost source 167 packets. Thus, the delay for the receiver to recover from the packet 168 loss can be reduced and the risk of increasing network congestion can 169 be mitigated or avoided. The receive may send a NACK message before 170 receiving the indication but will not need to resend the NACK message 171 after receiving the indication. Also the idea of retransmission 172 Suppression Early Indication can be further extended when the 173 distributed content distribution network are considered. That is to 174 say several distribution sources and media senders may constitute one 175 hierarchical model. In this distributed hierarchical content 176 distribution environment, the Retransmission Suppression Early 177 Indication not only can be used to suppress all the receivers behind 178 itself not to send NACK but also suppress the neighboring nodes not 179 to send NACK for the missing packets via unicast. How the 180 neighboring node is discovered is beyond scope of this document. 182 This document registers a new sub-report block type for 183 Retransmission Storm Suppression within RTP retransmission framework. 184 Applications that are employing one or more loss-repair methods MAY 185 use retransmission Suppression Early Indication approach together 186 with these loss-repair methods for every packet they receive or for a 187 set of specific packets they have received. 189 2. Terminology 191 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in [RFC2119]. 195 3. Basic Operation 197 The new sub-report block of the retransmission suppression Early 198 Indication (RSEI) will work in Simple Feedback and in Distribution 199 Source Feedback Summary Models defined in [I-D.ietf-avt-rtcpssm]. 200 The distribution source will include the support for retransmission 201 as part of the offered SDP and will expect such support from the 202 Media Sender. 204 The distribution source may send this new sub-report block RSEI to 205 the receivers when detecting a loss on its incoming link while send a 206 NACK to the media sender. The distribution source may receive NACK 207 messages from the receivers and may filter them out if it already 208 sent a NACK for the requested packet to the media source. 210 If the receiver understands this message it will not send NACKs for 211 the missing packets reported in the message and will accept a 212 retransmission stream. The receiver may send NACK messages if it did 213 not understand this new message. 215 4. Sub-Report Block for Retransmission Suppression Early Indication 217 The Retransmission suppression Early Indication (RSEI) sub-report 218 block uses the similar format of sub-report block specific to the RSI 219 packet defined in the section 7.1.2 of [I-D.ietf-avt-rtcpssm]. The 220 report format is shown in Figure 1. Using this RSEI sub-report block 221 with RTCP NACK can efficiently prevent Retransmission Storm to 222 happen. The format of this sub-report block is: 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | SRBT(RSEI) | Length | Reserved | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | SLSN | LLSN | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 1: Format for the RSEI sub-report block 234 SRBT:8bits 236 Report block type for retransmission Suppression Early Indication. 238 Length:8bits 240 The length of the sub-report in 32-bit words. 242 Reserved:16bits 244 Starting Loss Sequence Number (SLSN):16bits 246 The SSN field is used to specify the contiguous packet lost. The 247 SSN field refers to the RTP sequence number of the first lost 248 packet. 250 Last Loss Sequence Number (LLSN): 16 bits 252 The LSN field is used to specify the contiguous packet loss. The 253 LSN refers to the RTP sequence number of the last lost packet. 255 5. SDP Signaling 257 No new parameter needs to be defined for the Retransmission Storm 258 Suppression Indication message to be used with Session Description 259 Protocol (SDP) [RFC4566]using the Augmented Backus-Naur Form (ABNF) 260 [RFC5234]. It uses the same syntax within the "rtcp-unicast" 261 attribute [I-D.ietf-avt-rtcpssm]. 263 Refer to Section 10.1 of [I-D.ietf-avt-rtcpssm] for a detailed 264 description and the full syntax of the "rtcp-unicast" attribute. 266 6. IANA Consideration 268 New sub-report block types for RTCP RSI block are subject to IANA 269 registration. For general guidelines on IANA considerations for RTCP 270 RSI, refer to [I-D.ietf-avt-rtcpssm]. 272 This document assigns the sub-report block type (SRBT) value x in the 273 RTCP RSI sub-report Block Type Registry to "Retransmission Storm 274 Suppression Indication Report Block", with the following 275 registrations format: 277 Name: RSEI 278 Long name: Retransmission Suppression Early Indication 279 Value: TBD 280 Reference: This Document. 282 The contact information for the registrations is: 284 Qin Wu 285 sunseawq@huawei.com 286 Site B, Floor 12F,Huihong Mansion, No.91,Baixia Rd. 287 Nanjing, JiangSu 210001 China 289 7. References 291 7.1. Normative References 293 [I-D.ietf-avt-rtcpssm] 294 Ott, J., Chesterfield , J., and E. Schooler, "RTCP 295 Extensions for Single- Source Multicast Sessions with 296 Unicast Feedback", September 2009. 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, March 1997. 301 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 302 "Extended RTP Profile for Real-time Transport Control 303 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 304 July 2006. 306 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 307 Jacobson, "RTP: A Transport Protocol for Real-Time 308 Applications", STD 64, RFC 3550, July 2003. 310 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 311 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 312 July 2006. 314 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 315 Description Protocol", RFC 4566, July 2006. 317 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 318 Specifications: ABNF", STD 68, RFC 5234, January 2008. 320 7.2. Informative References 322 [I-D.hunt-avt-monarch-01] 323 Hunt, G. and P. Arden, "Monitoring Architectures for RTP", 324 August 2008. 326 [I-D.ietf-pmol-metrics-framework-02] 327 Clark, A., "Framework for Performance Metric Development". 329 Appendix A. Example scenarios for Retransmission Storm Suppression 331 A.1. Scenario 1: One media Sender, one Distribution Source 333 The general architecture is displayed below in Figure 2. In this 334 figure, one or more Media Senders send RTP packets to the 335 Distribution Source. The Distribution Source relays the RTP packets 336 to the receivers using a source-specific multicast channel. In the 337 reverse direction, the receivers transmit RTCP packets via unicast to 338 the distribution source. The Distribution Source in turn relays RTCP 339 packets to the media sender and then transmits the RTCP packets back 340 to the receivers, using source-specific multicast. When packet loss 341 happens between Media sender and distribution source, it may result 342 in massive retransmission request for the same RTP packets from all 343 the receivers using RTCP NACK to the same multicast sender. We refer 344 to it as Retransmission Storm. 346 +-------+ 347 |---->|RTP_Rx1| 348 +--------+ | +-------+ 349 | | +--------------+ | 350 | | | | | +-------+ 351 | Media |-------| Distribution |-------|---->|RTP_Rx2| 352 | | | Source | | +-------+ 353 | Sender | | | | . 354 | | +--------------+ | . 355 | | | . 356 +--------+ | +-------+ 357 |---->|RTP_Rxn| 358 +-------+ 360 Figure 2: One media Sender, one Distribution Source 362 A.2. Scenario 2: One Media Sender, more distribution sources 364 The hierarchical model is displayed below in Figure 3. In this 365 figure, one media sender and two Distribution source constitute one 366 hierarchical model. In this model, one Media Senders send RTP 367 packets to two Distribution Sources respectively. These Distribution 368 Sources relay the RTP packets respectively to the receivers behind 369 itself using a source-specific multicast channel. In the reverse 370 direction, the receivers transmit RTCP packets via unicast to the 371 distribution source. The Distribution Source in turn relays RTCP 372 packets to the media sender and then transmits the RTCP packets back 373 to the receivers, using source-specific multicast. When packet loss 374 happens between Media sender and distribution source, it may result 375 in massive retransmission request for the same RTP packets from all 376 the receivers using RTCP NACK to the same multicast sender. We refer 377 to it as Retransmission Storm. 379 +--------+ 380 |---->|RTP_Rx11| 381 | +--------+ 382 +--------------+ | 383 | | | +--------+ 384 |--->| Distribution |----|---->|RTP_Rx12| 385 | | Source1 | | +--------+ 386 | | | | . 387 +--------+ | +--------------+ | . 388 | | | | . 389 | | | | +--------+ 390 | Media | | |---->|RTP_Rx1k| 391 | |---| +--------+ 392 | Sender | | +--------+ 393 | | | |---->|RTP_Rx21| 394 | | | | +--------+ 395 +--------+ | +--------------+ | 396 | | | | +--------+ 397 | | Distribution |----|---->|RTP_Rx22| 398 |--->| Source2 | | +--------+ 399 | | | . 400 +--------------+ | . 401 | . 402 | +--------+ 403 |---->|RTP_Rx2j| 404 +--------+ 406 Figure 3: One Media Sender, more distribution sources 408 Appendix B. Applicability of Retransmission Suppression Early 409 Indication 411 This document defines new RTCP RSI sub-report block, which we refer 412 to as Retransmission Suppression Early Indication to deal with 413 Retransmission Storm mentioned above. Here we give two examples to 414 show how this new RTCP sub-report block is applied into two scenarios 415 described in section A.1 for Retransmission Storm Suppression. 417 Applicability of Retransmission Storm Suppression in Scenario 1 418 described in Figure 2 is shown in the Figure 4. In this figure, the 419 distribution source detect the packet loss before the receiver 420 perceive it and ask for retransmission of the missing packets from 421 the media sender, in the meanwhile, the distribution source transmits 422 the RTCP Retransmission Storm Suppression Indication back to the 423 receivers using source-specific multicast channel. In this way, the 424 delay for the receiver to recover from the packet loss can be reduced 425 and the risk of increasing network congestion can be mitigated. 427 +------+ +--------------+ +--------+ 428 |Media | | Distribution | | | 429 |Sender| | Source | | RTP_Rx | 430 +--+---+ +------+-------+ +---+----+ 431 | | | 432 | | | 433 |------------------->|------RTP Multicast---->| 434 | | | 435 | | | 436 | +--------+----------+ | 437 | |Detect Packet Loss | | 438 | |and Identify the SN| | 439 | |of missing Packets | | 440 | +--------+----------+ | 441 |<-----RTCP NACK-----| | 442 | | | 443 | +--Multicast RTCP RSSI-->| 444 | RTP Retransmission | | 445 |------------------->| | 446 | |------RTP Multicast---->| 447 | | Retransmission | 448 | | | 449 | | | 450 | | | 452 Figure 4: Applicability of Retransmission Suppression Early 453 Indication 455 Applicability of Retransmission Storm Suppression in Scenario 2 456 described in Figure 3 is shown in the figure A.2.2. The procedure in 457 the figure A.2.2 is similar to the one in the figure Figure 5. The 458 only difference is distribution source should not only notify all the 459 receiver behind itself not to send NACK but also propagate the 460 retransmission suppression indication to the neighboring distribution 461 sources. In this way, all the receivers behind all the neighboring 462 distribution source can avoid sending massive retransmission request 463 to the media sender. 465 +------+ +-------+ +--------+ +-------+ +--------+ 466 |Media | | | | RTP_Rx | | | | RTP_Rx | 467 |Sender| | DS1 | | (DS1) | | DS2 | | (DS2) | 468 +--+---+ +---+---+ +---+----+ +---+---+ +---+----+ 469 | | | | | 470 | |RTP Multicast | | | 471 |----------->|------------->| | | 472 | | | | | 473 | | | |RTP Multicast| 474 |------------------------------------------->|------------>| 475 | | | | | 476 | +--------+------------+ | | | 477 | |Detect Packet Loss | | | | 478 | |and Identify the SN | | | | 479 | |of the missing Packets | | | 480 | +--------+------------+ | | | 481 | | | | | 482 |<-RTCP NACK-| Multicast RTCP RSSI | | 483 | |------------->| | | 484 | | | | | 485 | |-----Unicast RTCP RSSI-------->|Multicast RTCP RSSI 486 | | | |------------>| 487 |RTP Retransmission | | | 488 |----------->| | | | 489 | | | | | 490 | | RTP Retransmission | | 491 |------------+--------------+--------------->| | 492 | | | | | 493 | | RTP Multicast| | RTP Multicast 494 | |Retransmission| |Retransmission 495 | |------------->| |------------>| 496 | | | | | 497 DS1: Distribution Source 1 498 DS2: Distribution Source 2 500 Figure 5: Applicability of Retransmission Suppression Early 501 Indication 503 Authors' Addresses 505 Qin Wu 506 Huawei 507 Site B,Floor 12F,Huihong Mansion, No.91 Baixia Rd. 508 Nanjing, Jiangsu 21001 509 China 511 Phone: +86-25-84565892 512 Email: sunseawq@huawei.com 514 Frank Xia 515 Huawei 516 1700 Alma Dr. Suite 500 517 Plano, TX 75075 518 USA 520 Phone: +1 972-509-5599 521 Email: xiayangsong@huawei.com 523 Roni Even 524 Huawei 525 14 David Hamelech 526 Tel Aviv 64953 527 Israel 529 Email: even.roni@huawei.com