idnits 2.17.1 draft-miyazaki-avt-rtp-selret-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([9]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 681 has weird spacing: '... Mail akihi...' == Line 688 has weird spacing: '... Mail fukus...' == Line 695 has weird spacing: '... Mail wiebk...' == Line 702 has weird spacing: '... Mail haken...' == Line 709 has weird spacing: '... Mail burme...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 16 looks like a reference -- Missing reference section? '9' on line 396 looks like a reference -- Missing reference section? '2' on line 106 looks like a reference -- Missing reference section? '3' on line 316 looks like a reference -- Missing reference section? '4' on line 118 looks like a reference -- Missing reference section? '7' on line 558 looks like a reference -- Missing reference section? '8' on line 565 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working Group Akihiro Miyazaki 3 Internet Draft Hideaki Fukushima 4 Document: draft-miyazaki-avt-rtp-selret-01.txt Thomas Wiebke 5 July 14, 2000 Rolf Hakenberg 6 Expires: January 14, 2001 Carsten Burmeister 8 Matsushita 10 RTP Payload Format to Enable Multiple Selective Retransmissions 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 1. Abstract 32 This document describes a new RTP payload format and a new RTCP 33 packet format to enable multiple selective retransmissions of 34 generic media data. This payload format is especially applicable in 35 a RTP-RX profile as described in [9]. 37 While RTP is widely used for media streaming applications over the 38 Internet, using it over unreliable links needs some further 39 modifications to achieve a good quality of the media stream at the 40 receiver. 42 The aforementioned RTP-RX profile describes a generic retransmission 43 mechanism to make RTP more reliable. This payload format description 44 increases the reliability and decreases the bandwidth requirements 45 of such a generic profile by introducing the concept of multiple 46 selective retransmissions. 48 Miyazaki Expires January 2001 1 49 Selective Retransmissions for RTP July 14, 2000 51 This paper describes a mechanism to use the lower delay requirements 52 in streaming applications to make RTP more reliable, by the means of 53 multiple selective retransmissions. Therefore a new RTP payload 54 format is defined as well as a new RTCP packet. An example algorithm 55 to use the new payload format fields and the new RTCP packet is 56 introduced and an additional section shows results of a performance 57 evaluation. The evaluation is done by simulating a video streaming 58 application over an mobile communication system. 60 Table of Contents 61 ----------------- 63 1. Abstract 65 2. Conventions used in this document 67 3. Introduction 69 4. Proposed solution 71 5. Concept of a second sequence number 73 6. Required RTP header additions 75 7. Required additional RTCP packet 77 8. Indicating usage in SDP 79 9. An example use of the payload format 80 9.1 Selective retransmission 81 9.2 Multiple retransmission attempts 82 9.3 Retransmission with time limit based on client judgement 84 10. Performance evaluation of the proposed solution 85 10.1 Application 86 10.2 Environment 87 10.3 Performance results 88 10.4 Conclusions 90 11. Security considerations 92 12. Intellectual property consideration 94 13. References 96 14. Author's addresses 98 Miyazaki Expires January 2001 2 99 Selective Retransmissions for RTP July 14, 2000 101 2. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 105 this document are to be interpreted as described in RFC-2119 [2]. 107 3. Introduction 109 The Real-Time Transport Protocol (RTP)[3] was designed as an Internet 110 protocol to transmit real-time (or near real-time) data over 111 multicast or unicast. Even though the multicast capability is a 112 strong feature of RTP, a common use of it is non-interactive unicast 113 transmission of media streams. This application, further referred to 114 as media streaming, has lower delay requirements. A constant offset 115 delay, in which already received packets are stored at the client, is 116 tolerable. 118 Typically RTP is run over the User Datagram Protocol (UDP)[4]. While 119 the unreliable UDP performs good for reliable channels, the quality 120 of the received media stream is bad, when transmitted over error- 121 prone links. Especially compressed streams, such as MPEG video-data, 122 are highly susceptible to packet loss, which will lead to a bad 123 video quality at the client. E.g. in a wireless environment with a 124 unstable transmission quality (bit error rate (BER) about 10E-3 .. 125 10E-6) a sufficient quality of video and voice transmitted by RTP 126 cannot be achieved. 128 The scenario for such a media streaming over an error-prone link 129 might be the one in Figure 1. Media files are stored on a media 130 server which is connected via an internet link to a mobile network. 131 The wireless link between the mobile network and the mobile 132 terminal, which works as the client in this scenario, is generally 133 unreliable and subject to bit errors. 135 Media Mobile Mobile 136 Server Network Terminal 137 (Client) 139 *** | 140 +----+ ** ** +--+ 141 | | * * | | 142 | | -------------- * * ~ ~ ~ ~ ~ ~ ~ | | 143 +----+ * * +--+ 144 ** ** 145 Internet *** Wireless 146 Link Link 148 Figure 1 : Scenario for media streaming 150 Miyazaki Expires January 2001 3 151 Selective Retransmissions for RTP July 14, 2000 153 To achieve a better quality of the received media stream, especially 154 when transmitted over error-prone links, retransmissions of lost 155 packets of the stream seems to be a possible solution. However the 156 quite low delay requirements of media streaming applications and the 157 bandwidth limitations of the wireless link have to be considered. In 158 wireless systems bandwidth is a scarce resource and efficient use of 159 this resource is of vital importance. Hence reliability for the 160 complete media stream might not be achievable. 162 Furthermore in compressed media streams, e.g. MPEG video stream, not 163 every frame is equal important. In this example some frames contain 164 data that other data depends upon, which makes these frames more 165 important. Current protocols applying retransmission for reliable 166 transmission (e.g. TCP) make no use of this characteristic of 167 compressed media streams. 169 4. Proposed solution 171 Much work has been done recently to make RTP more reliable. As one 172 result a new profile for unicast sessions is proposed [9]. This 173 profile includes the ability to request retransmissions of lost 174 packets. However the profile is kept very general and leaves space 175 for a payload format to define further details and enhance the 176 functionality. 178 The solution presented in this document is based on the concept of 179 multiple selective retransmissions of data packets in case of packet 180 loss. This functionality is added to the RTP RX profile by the means 181 of this payload format. 183 As mentioned before, compressed media streams generally consist of 184 data packets of high importance and data packets of lower 185 importance. In the proposed solution data packets of high importance 186 are retransmitted in case of packet loss and by this the quality of 187 the received media stream is increased significantly. 188 However single retransmission of lost data packets, which are 189 transmitted over links with high bit error rates are still far from 190 being reliable. Even though no 100% reliability is desired, the 191 delay requirements and bandwidth limitations might allow more than 192 one retransmission of important parts of the media stream. Therefore 193 mechanisms for multiple retransmission attempts are included in our 194 proposal. 196 On the other hand by limiting the retransmissions on only the data 197 packets of high importance and transmitting the data packets of 198 lower importance the usual unreliable way the delay requirements of 199 media streaming can still be meet. Additionally the total bandwidth 200 requirements for transmission and retransmission of the media stream 202 Miyazaki Expires January 2001 4 203 Selective Retransmissions for RTP July 14, 2000 205 data are kept at a low level suitable and advantageous for usage 206 over bandwidth limited, wireless links. 208 To keep also the bandwidth requirements on the link back from the 209 client to the media server at a minimum level, means for a judgement 210 at the client, whether a retransmission would still arrive in time 211 (retransmission judgement), is proposed. With our solution it is 212 possible to calculate the time when the lost packet has to be 213 received at the client at latest. This time is compared against the 214 round trip time. Only if this calculation predicts that a 215 retransmission of the lost packet will be received in time, a 216 retransmission is generated at the client and send to the server. 217 Therefore no bandwidth is wasted for unnecessary retransmission 218 requests and subsequent retransmissions. 220 In summary we propose the following enhancements/extensions to RTP: 222 1) Selective retransmission 223 Retransmission of lost packets, but limited to lost packets of 224 high importance. 226 2) Multiple retransmission attempts 227 In case retransmission of a lost data packet fails, further 228 attempts can be requested. 230 3) Retransmission with time limit based on client judgement 231 Means to calculate the time when a lost packet has to be received 232 at the client at latest to perform a efficient client based 233 retransmission judgement. 235 RTP packet retransmissions in a unicast scenario are an essential 236 part of the proposed RTP-RX profile [9]. The profile is kept very 237 general and could be used as a starting point. However, to enable 238 the items listed above, additions are needed. These are described in 239 the following sections. 241 5. Concept of a second sequence number 243 In this section the concept of a second sequence number is 244 described, which enables to do multiple retransmissions very 245 efficiently. 247 Normally a loss of a transmitted RTP packet can be realized by a gap 248 in the sequence numbers of the received packets. This is a very time 249 efficient way to detect packet loss, since it does not introduce 250 additional traffic or delay. 252 However, retransmissions of lost RTP packets need to have the same 253 sequence number as the original transmitted packet, because the 255 Miyazaki Expires January 2001 5 256 Selective Retransmissions for RTP July 14, 2000 258 sequence number is used for other purposes than packet loss 259 detection as well (e.g. synchronization, coping with reordering). 260 Therefore it is not possible to detect a lost retransmission by 261 looking at the sequence numbers. 263 Other mechanisms to detect packet loss (e.g. acknowledgements, 264 timer-based loss detection) have the disadvantage that they either 265 introduce additional traffic or delay. Both is not desirable, 266 especially not for delay sensitive traffic over a bandwidth limited 267 channel. 269 To overcome these problems, the following mechanism is used to 270 detect lost retransmissions. A second sequence number (SSN) is 271 introduced. For every packet that is (re)transmitted the source 272 decides if the packet should be retransmitted if it gets lost. If it 273 should be retransmitted it gets a new SSN assigned. If it should not 274 be retransmitted, it carries the SSN of the previous packet. With 275 this mechanism, the client can detect lost packets, which should be 276 retransmitted. 278 6. Payload header in a new RTP payload format 280 In order achieve the solution described above, we extend the RTP 281 header in the RTP payload format by the following fields. 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 |V=2|P|X| CC |M| PT=MulSelRx | sequence number | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | timestamp | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | synchronization source (SSRC) identifier | 291 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 292 | contributing source (CSRC) identifiers | 293 | .... | 294 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 295 |S| PT | SSN |D| Diff Time | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 The first part of the header is the usual RTP header with a payload 299 format identifier set to this new payload format "MulSelRx". The 300 payload contains an additional payload header consisting of 4 bytes. 301 The fields of this additional header are explained as follows: 303 Miyazaki Expires January 2001 6 304 Selective Retransmissions for RTP July 14, 2000 306 SSN Indicator (S): 1bit 307 If this bit is set to one, the packet should be retransmitted 308 if it is lost. Therefore it has a new SSN value assigned, 309 which is incremented by one to the previous packet�s SSN. 310 If this bit is set to zero, the packet should not be 311 retransmitted if it is lost and therefore carries the SSN 312 value of the previous packet. 314 Payload Type (PT): 7 bits 315 This fields identifies the payload format that follows the 316 header additions and is used as described in [3]. 318 Second Sequence Number (SSN): 8 bit 319 The second sequence number is carried in this field. It is 320 used as describe in section 5. 322 Diff Time Indicator(D): 1 bit 323 If DTI field is set to one, the diff time field is 324 included in the RTP header extension. For further information 325 please refer to description of diff time field. 326 If it is set to 0 no diff time is transmitted and the 327 diff time field is not valid. 329 Diff Time: 15 bit 330 This field indicates the difference between the time stamp of 331 the last RTP packet that should be retransmitted if lost 332 (i.e. S==1) and that of the current RTP packet. It can be 333 used by the receiver to compute the timestamp of a lost 334 packet. 335 The default unit of this field is [ms] and by default the 336 following table is used to encode the diff time values. 338 Diff Time [ms] | bits 339 -----------------+------------------- 340 more than 16383 | 011 1111 1111 1111 341 16382 | 011 1111 1111 1110 342 16381 | 011 1111 1111 1101 343 : | : 344 2 | 000 0000 0000 0010 345 1 | 000 0000 0000 0001 346 0 | 000 0000 0000 0000 347 -1 | 111 1111 1111 1111 348 -2 | 111 1111 1111 1110 349 : | : 350 -16382 | 100 0000 0000 0010 351 -16383 | 100 0000 0000 0001 352 less than �16384 | 100 0000 0000 0000 354 It is possible to define other units or coding tables, 355 however, how to specify and negotiate this is outside the 357 Miyazaki Expires January 2001 7 358 Selective Retransmissions for RTP July 14, 2000 360 scope of this document. 362 7. RTCP packet type 364 The retransmission request, which is sent from the sender to the 365 receiver to request the retransmission of a lost packet has to 366 contain the SSN value that is requested. The RTCP packet that is 367 used in the RTP-RX profile to request retransmissions can be used 368 for this purposes. It contains a 16 bit packet identification (PID) 369 and 16 payload specific bits. These fields are used as follows: 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |V=2|P| RC |PT=RTCP_NACK | length | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | SSRC | 377 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 378 | SSRC_1 | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | PID = SSN | SSN BLP | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 version(V), padding(P), report count(RC), packet type(PT), 384 length, SSRC and SSRC_1: 385 as described in [9], Section 4.2. 387 packet identification(PID): 388 The SSN value of the requested packet is inserted in this 389 field. Since the SSN is only 8 bit long, the upper 8 bits are 390 not used in this field. 391 If several packets are requested (i.e. SSN_BLP != 0) this 392 indicates the lowest SSN value of all requested packets. 394 SSN bitmask of following lost packets(SSN_BLP): 395 By the means of this bitmask it is possible to request more 396 than one lost packet. The use is similar as described in [9] 397 section 4.3. 399 8. Indicating usage in SDP 401 Packets of this format contain RTP packets with dynamic payload type 402 values. These values have to be indicated in SDP as well as the 403 value for this payload format. An example indication within SDP 404 would be: 406 m= video 0 RTP/AVP-RX xx yy 408 Miyazaki Expires January 2001 8 409 Selective Retransmissions for RTP July 14, 2000 411 The first payload type value indicate the multiple selective 412 retransmission payload type and the second the used media payload 413 type. 415 9. An example use of the payload format 417 In sections 4 and 5 we proposed a solution to enhance the quality of 418 media stream, transmitted over an unreliable link. How this solution 419 can be achieved by using the header fields as described in section 6 420 and 7 is shown in form of an example in this section. 422 9.1 Selective retransmission 424 As described before a media stream contains more or less important 425 parts. In section 6 we introduced a SSN indicator bit (S) which is 426 used to mark packets, that should be retransmitted if they are lost. 427 Hence these packets should contain the important parts of the media 428 stream. With this it is possible to distinguish between two priority 429 levels, and to allow retransmissions of only the important packets. 431 9.2 Multiple retransmission attempts 433 If a retransmission fails, further attempts to retransmit the lost 434 packet MAY be requested. While the detection of a lost packet is 435 normally straight forward (e.g. by checking the sequence number), 436 detecting a lost retransmission requires further mechanisms. This is 437 done by the means of the SSN field as described in section 5. 439 The SSN value MUST be incremented by one for every packet that 440 should be retransmitted, regardless whether it is a retransmission 441 or sent for the first time. By comparing the actual received with 442 the most recent SSN value, the client will detect the loss of a high 443 priority packet immediately (i.e. if the SSN value was increased, 444 but no packet with S=1 was received, it must have been lost). This 445 enables the client to send another retransmission request and the 446 server to do multiple retransmissions. 448 9.3 Retransmission with time limit based on client judgement 450 As described in section 3, bandwidth might be a very scarce 451 resource. Therefore requesting the retransmission or retransmitting 452 packets that will not be received in time anyway, SHOULD be avoided. 453 Hence in this example the client estimates the arrival time of the 454 requested lost packet and the time after which it will become 455 useless. Therefore the RTP timestamp of the lost packet is needed, 456 which is achieved by using the diff-timestamp field. 458 In these fields the difference between the actual packet's time 459 stamp and the most recent packet's timestamp that should be 461 Miyazaki Expires January 2001 9 462 Selective Retransmissions for RTP July 14, 2000 464 retransmitted is calculated. At detecting a lost packet with S=1, it 465 is possible to calculate the timestamp of the lost packet by the 466 means of this field, because the received packet contains its own 467 timestamp and the difference to the lost packet's timestamp. 469 The knowledge of the lost packet's time stamp enables the client to 470 judge if a retransmission request would still make sense or if the 471 bandwidth should be saved. 473 10. Performance evaluation of the proposed solution 475 The previous sections introduced a solution, how to enhance the 476 capabilities of media streaming application over unreliable links. 477 The solution implies a new RTP payload format and a new RTCP packet 478 as described in sections 6 and 7. How these fields can be used in 479 general is described in an example in section 8. 481 This section will show the increased performance that is possible 482 with our solution. This is done by simulating a video streaming 483 application over a unreliable wireless link. 485 10.1 Application 487 In this performance evaluation we simulate a MPEG4 video streaming 488 application. MPEG4 video data is streamed from a server to a client 489 (i.e. unicast). In the client the received frames are buffered 490 before they are displayed at their scheduled playing time. Therefore 491 the delay requirements are not exactly real-time. The scheduled 492 playing time includes an additional buffering delay. 494 We consider a transmission of a real MPEG4 video stream, with a 495 total play time of about 120s and an average bit rate of 33100 bps. 496 The frame rate is 10 fps. The frame length is variable between 497 100byte and 2000byte. The additional allowed buffering delay is set 498 in our simulations to 2 seconds. 500 The MPEG4 video stream consists of Intra coded (I-)frames and 501 Predictive coded (P-)frames. While the I-frames are completely 502 independent and can be displayed all by themselves, the P-frames 503 contain only the difference to the previous frame and hence need the 504 previous frame to be received correctly to be displayed. This leads 505 to I-frames having a higher importance than P-frames. The different 506 frames are mapped into different RTP packets with packets containing 507 an I-frame having S=1 and packets containing P-frames having S=0 508 assigned. 510 Miyazaki Expires January 2001 10 511 Selective Retransmissions for RTP July 14, 2000 513 10.2 Environment 515 A mobile environment is considered as a typical representation for 516 unreliable, bandwidth limited links. Figure 1 illustrates the 517 general scenario that is evaluated. The used protocols for the 518 evaluation are shown in Figure 2. 520 Media Server Mobile Network Mobile Client 522 +-----------+ +-----------+ 523 | Video- | | Display- | 524 |Application| |Application| 525 +-----------+ +-----------+ 526 | RTP | | RTP | 527 +-----------+ +-----------+ 528 | UDP | | UDP | 529 +-----------+ +-----------+ +-----------+ 530 | IP |<--------->| IP | | IP | 531 +-----------+ +-----------+ +-----------+ 532 | W-CDMA |<--------->| W-CDMA | 533 +-----------+ +-----------+ 534 Internet Wireless 535 Link Link 537 Figure 2 539 The RTP layer implies the newly defined RTP payload format and RTCP 540 packet as described in sections 5 and 6 and the use of the 541 additional fields as given in the example in section 7. Additional 542 to the client's retransmission judgement, a similar mechanism is 543 used on the server side, to avoid unnecessary retransmissions. 545 The Internet link is modeled as error-free, loss-less and with a 546 constant delay of 50 ms. 548 For the wireless link a W-CDMA channel is considered. W-CDMA, as a 549 third generation mobile communication system with high Quality-of- 550 Service (QoS) capabilities, is a well suited network for this kind 551 of applications in a mobile use. 553 The W-CDMA system is standardized at the 3rd Generation Partnership 554 Project (3GPP). The standardization is still under progress and no 555 final specifications are finished. For the simulations the 556 specifications of December 1999 are considered. The wireless link 557 and its link layer protocols are simulated according to this 558 specifications (see [7] for details). 560 Miyazaki Expires January 2001 11 561 Selective Retransmissions for RTP July 14, 2000 563 A single user is considered for the mobile channel, hence the 564 bandwidth is not shared between different users here. The channel is 565 simulated with the fading model, as described in [8]. The fading 566 process has a mean signal-to-noise ratio per received symbol of 567 Es/N0. Different mean Es/N0 values are simulated, which reflect 568 different channel conditions. 570 The back channel in our simulations is modeled as error-free and 571 therefore loss-less. 573 The propagation delay of the mobile channel, is strongly dependent 574 on the length of the packet that is to be sent. The minimum delay of 575 50ms applies for all transmitted frames, due to the coding, 576 interleaving etc. in the physical layer. 578 10.3 Performance results 580 This section shows some results of the simulations as described 581 above. To measure the quality of the received video stream, the 582 number of displayed frames, relative to the number of sent frames, 583 is considered. 585 The next figure shows the amount of received frames for RTP and the 586 extended RTP for different channel conditions. 588 It can be seen from this figures, that both applications suffer from 589 bad channel conditions. 591 Miyazaki Expires January 2001 12 592 Selective Retransmissions for RTP July 14, 2000 594 In states, where Es/N0 is smaller than 5dB, not even half of the 595 video frames can be displayed, using normal RTP. In those conditions 596 many errors occur, which leads to a loss of many frames. 597 Additionally, if an I-frame gets lost, all following P-frames, even 598 if they would be received correctly, are discarded. 599 The application using the extended RTP as described in section 7, 600 performs much better. Even though it suffers from bad channel 601 conditions as well, the repetition of lost I-frames, leads to an 602 increased performance. 603 The next figure shows the amount of displayed P-frames for different 604 channel conditions. 606 Even though the lost P-frames are not retransmitted, more frames are 607 displayed, using the extended RTP. This is due to the fact, that 608 fewer correctly received frames are discarded, because of a lost I- 609 frame. 611 Miyazaki Expires January 2001 13 612 Selective Retransmissions for RTP July 14, 2000 614 The next figure shows the amount of received I-frames for different 615 channel conditions. 617 From this figure the effect of the extended RTP is visible best. 618 Nearly all I-frames are displayed at the receiver in this case, 619 while only half of the frames can be displayed with normal RTP in 620 bad channel conditions. 622 10.4 Conclusions 624 It was shown in the previous sections that repetition of important 625 media data, leads to a better media quality at the receiver. These 626 repetitions are possible, if the lower delay requirements in 627 streaming applications are used wisely. To do so, a newly defined 628 RTP payload format and RTCP packet are introduced, which enable a 629 media server to do multiple, selective retransmissions. 631 11. Security Considerations 633 Security is not considered in this draft. 635 12. Intellectual property considerations 637 Matsushita has filed patent applications that might possibly have 638 technical relation to this contribution. 640 Miyazaki Expires January 2001 14 641 Selective Retransmissions for RTP July 14, 2000 643 13. References 645 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 646 9, RFC 2026, October 1996. 648 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 649 Levels", BCP 14, RFC 2119, March 1997 651 3 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: 652 A Transport Protocol for real-time applications", RFC 1889, 653 January 1996. 655 4 Postel, J.,"User Datagram Protocol", STD 6, RFC 768, August 1980. 657 5 Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 659 6 Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 660 Specification", RFC 2460, December 1998. 662 7 Homepage of 3GPP: http://www.3gpp.org 664 8 "Procedure for Evaluation of Transmission Technologies for 665 FPLMTS", ITU-R TG8-1, 8-1/TEMP/233-E, September 1995. 667 9 Yano, K., Podolsky, M., McCanne, S., "RTP Profile for RTCP-based 668 Retransmission Request for Unicast session", IETF Internet Draft, 669 work in progress, July 2000. 671 Miyazaki Expires January 2001 15 672 Selective Retransmissions for RTP July 14, 2000 674 14. Author's Addresses 676 Akihiro Miyazaki 677 Matsushita Electric Industrial Co., Ltd 678 1006, Kadoma, Kadoma City, Osaka, Japan 679 Tel. +81-6-6900-9192 680 Fax. +81-6-6900-9193 681 Mail akihiro@isl.mei.co.jp 683 Hideaki Fukushima 684 Matsushita Electric Industrial Co., Ltd 685 1006, Kadoma, Kadoma City, Osaka, Japan 686 Tel. +81-6-6900-9192 687 Fax. +81-6-6900-9193 688 Mail fukusima@isl.mei.co.jp 690 Thomas Wiebke 691 Panasonic European Laboratories GmbH 692 Monzastr. 4c, 63225 Langen, Germany 693 Tel. +49-(0)6103-766-161 694 Fax. +49-(0)6103-766-166 695 Mail wiebke@panasonic.de 697 Rolf Hakenberg 698 Panasonic European Laboratories GmbH 699 Monzastr. 4c, 63225 Langen, Germany 700 Tel. +49-(0)6103-766-162 701 Fax. +49-(0)6103-766-166 702 Mail hakenberg@panasonic.de 704 Carsten Burmeister 705 Panasonic European Laboratories GmbH 706 Monzastr. 4c, 63225 Langen, Germany 707 Tel. +49-(0)6103-766-263 708 Fax. +49-(0)6103-766-166 709 Mail burmeister@panasonic.de 711 Miyazaki Expires January 2001 16 712 Selective Retransmissions for RTP July 14, 2000 714 Full Copyright Statement 716 "Copyright (C) The Internet Society (date). All Rights Reserved. 717 This document and translations of it may be copied and furnished to 718 others, and derivative works that comment on or otherwise explain it 719 or assist in its implementation may be prepared, copied, published 720 and distributed, in whole or in part, without restriction of any 721 kind, provided that the above copyright notice and this paragraph 722 are included on all such copies and derivative works. However, this 723 document itself may not be modified in any way, such as by removing 724 the copyright notice or references to the Internet Society or other 725 Internet organizations, except as needed for the purpose of 726 developing Internet standards in which case the procedures for 727 copyrights defined in the Internet Standards process must be 728 followed, or as required to translate it into languages other than 729 English. 731 Miyazaki Expires January 2001 17