idnits 2.17.1 draft-parnes-rtp-ext-srm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (November 16, 1996) is 10023 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) -- Looks like a reference, but probably isn't: 'RFC1889' on line 316 ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Peter Parnes 2 INTERNET-DRAFT LuTH/CDT 3 draft-parnes-rtp-ext-srm-00.txt November 16, 1996 4 Expires: May, 1997 6 RTP extension for Scalable Reliable Multicast 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as "work in 19 progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 Abstract 31 This document describes how the Real-time Transport Protocol, RTP 32 (RFC1189), could be extended to include support for parts of the 33 framework called Scalable Reliable Multicast. The scheme proposed 34 could be used for transporting a data flow reliably over the 35 transport protocols supported by RTP in a light-weight way. This 36 could be used for numerous applications, for instance white-boards, 37 semi-reliable audio/video and messaging/data-transfers within 38 group-ware applications. 40 1. Introduction 42 The Real-time Transport Protocol, (RTP) [1] is based on UDP which is 43 a best-effort transport protocol meaning that packets can be lost. 44 For some applications this is acceptable but for other, for instance 45 white-board-applications, it is necessary to do retransmission so an 46 end-user can rely on that he has received everything that everybody 47 else has sent. 49 This document describe how RTP could be extended to include support 50 for the framework of the so called Scalable Reliable Multicast [2]. 51 The scheme proposed could be used for transporting a data flow 52 reliably over the transport protocols supported by RTP. 54 This new RTP/SRM-platform could be used for numerous applications, 55 including for instance semi-reliable audio/video and distributed 56 group-ware applications. 58 2. The Scalable Reliable Multicast Framework 60 Scalable Reliable Multicast,(SRM) [2] is a reliable multicast 61 framework for application level framing and light-weight sessions. 62 The algorithms of this framework are efficient, robust and scale well 63 to both very large networks and very large sessions. The framework 64 has been prototyped in wb, a distributed white-board application, and 65 has been extensively tested on a global scale with sessions ranging 66 from a few to more than 1000 participants. 68 2.1 The SRM ideas 70 The ideas of SRM can briefly be described as follows: 72 1) Every packet transmitted is uniquely identified by a sender- 73 identification and a sequence-number that is incremented by one 74 for each transmitted packet. 76 2) Every member of the session buffers a certain amount of packets, 77 even if she is only a receiver and not a sender, so if necessary 78 she can participate in 'repairs' of lost packets. 80 3) When a receiver notices that she has lost packets (by checking 81 if the difference of the sequence-numbers of the incoming packet 82 and the last heard packet before that is greater than 1) she 83 sends a negative acknowledgment, NACK, using multicasting so all 84 members of the session sees the NACK. But before sending the 85 NACK she waits for a random time determined by the distance of 86 the original source and if she hears a NACK for the same packet 87 from another member she suppress her own NACK-transmission. See 88 section 2.2 for a discussion of how the timers and the distance 89 is calculated. 91 4) Any member that gets a NACK and has the packet requested can 92 send a repair but just as in the NACK-case she waits a random 93 time before sending the repair. Again see section 2.2 for the 94 calculation of the repair-timers. 96 5) Loss is detected by finding a gap in the sequence space but 97 since it is possible the last data-packet is dropped, each 98 sender sends a low-rate periodic message, a heartbeat, 99 announcing the highest sequence number used. 101 Please note that this only gives the basic ideas of the algorithms 102 used and implementers should read the SRM-paper first. 104 2.2 Calculating timers in SRM 106 Every timer is based on the distance, D, between the sender and the 107 receiver. A member that only is active in repairs is also called a 108 sender. 110 2.2.1 NACK timers (point 6) 112 When loss is detected a NACK-timer is started. The expire-time is 113 chosen from the uniform distribution of 115 2^i*[C1*Dsa, (C1+C2)*Dsa] 117 seconds, where Dsa is host A's estimate of the one-way delay to the 118 original source S of the missing data, C1 and C2 are parameters of 119 the request algorithm and i is the count of how many times back-off 120 has been issued. See section 2.2.3 for initial values of C1 and C2. 121 The initial value of i is 0. When the request timer expires, host A 122 multicasts the NACK for the missing data, and doubles the request- 123 timer by increasing i by one to wait for the repair. 125 If host A receives a NACK for the missing data before its own 126 request-timer for that missing data expires, host A does a 127 exponential back-off, and resets its request timer. This means that 128 the new timers expire-time is randomly chosen from the uniform 129 distribution of 131 2^(i+1)*[C1*Dsa, (C1+C2)*Dsa]. 133 To improve the repair time we don't back-off the request timer for 134 every duplicate request that is received. For example, if a member 135 receives several duplicate requests immediately after receiving the 136 initial request, that member only backs off its request timer once. 137 After the initial timer back-off, we only back-off the timer again if 138 a request is received close to the time when the timer is set to 139 expire. More precisely, when we back-off the request timer, we set an 140 ignore-back-off variable to a time halfway between the current time 141 and the expiration time, and we ignore additional duplicate requests 142 until the ignore-back-off time. 144 2.2.2 Repair-timers (point 7) 146 When host B receives a request from A that host B is capable of 147 answering, host B sets a repair timer to a random value from the 148 uniform distribution of 150 [D1*Dab, (D1+D2)*Dab] 152 seconds where Dab is host B's estimate of the one-way delay to host 153 A, and D1 and D2 are parameters of the repair algorithm. See section 154 2.2.3 for initial values of D1 and D2. If host B receives a repair 155 for the missing data before its repair timer expires, host B cancels 156 the timer. Otherwise, when host B's repair timer for that data 157 expires host B multicasts the repair. 159 A host could receive duplicate NACKs immediately after sending a 160 repair. In order to prevent these duplicate NACKs from triggering a 161 responding set of duplicate repairs, host B ignores NACKs for data d 162 for 3*Dsb seconds after sending or receiving a repair for that data. 163 Host s is either the original source of data d or the source of the 164 first NACK. 166 2.2.3 Initial values of the timer parameters 168 The initial values of the timer parameters should be set to C1=C2=2, 169 D1=D2=log10(G), where G is is the current number of members in the 170 session. 172 An adaptive algorithm for changing these parameters is presented in 173 [2]. 175 2.3 Calculating the host-to-host distances 177 In order to be able to calculate the NACK and repair timers we need 178 to have some knowledge of the host-to-host distance. This distance is 179 calculated in seconds based on how long it takes for a packet to 180 travel from host A to host B. 182 To be able to do this each member of the session sends a time-stamp 183 which is used in the following way to calculate the host-to-host 184 distance: 186 Assume that host A sends a session packet P1 at time t1 and host B 187 receives P1 at time t2. At some later time, t3, host B generates a 188 session packet P2, containing (t1, d), where d = t3 - t2 (time t1 189 is included in P2 to make the algorithm robust to lost session 190 packets). Upon receiving P2 at time t4, host A can estimate the 191 latency from host B to host A as (t4 - t1 - d)/2. Note that while 192 this estimate does assume that the paths are symmetric, it does not 193 assume synchronized clocks. 195 3. How does SRM fit into RTP? 197 Here follows a description of how the SRM ideas fit into RTP 198 according to the points in the earlier sections. Points marked with a 199 needed changes. 201 1) RTP has a unique sender-ID, the Synchronization Source (SSRC) 202 and each data-packet has a sequence-number. 204 2) The buffering can be accomplished without interfering with the 205 protocol itself. 207 3*) The transmission of NACKs has to be incorporated into RTP using 208 for instance the Real-time Transport Control Protocol, RTCP. 210 4*) The transmission of repairs have to be incorporated into RTP. 212 5*) The heartbeats have to be incorporated into RTP/RTCP. 214 6) The timer calculations don't imply any changes to RTP/RTCP. 216 7*) The time-stamps should be incorporated into RTCP. The NTP- 217 time-stamp in the RTCP/SR packet is to be used but this implies 218 that all clients has to implement the usage of this field (the 219 RTP specification has left it optional for clients to use this 220 field). In order to calculate the host-to-host delay all 221 clients need to have some notion of wall-clock time or elapsed 222 time. 224 Out-of-order packets could initially be seen as lost packets and lead 225 to a started NACK-timer but when the "lost" packet(s) arrives the 226 NACK-timer should be cancelled and an ignore flag should be raised 227 for a time of 3*Dsa, where Dsa is the receivers notion of the 228 distance to the sender. All NACKs received within this time should be 229 ignored. 231 4. What extensions are needed to RTP/RTCP 233 This section explains the needed additions to RTP/RTCP. The new 234 needed packet-formats are discussed section 5. 236 The additional SRM-generated-traffic can be incorporated into RTP 237 basically in two ways; either incorporate all additional packets and 238 data into the same channel as the original RTP or send all traffic on 239 a separate multicast-group as a new channel. 241 The first method would allow for clients that don't understand the 242 SRM additions to benefit from the retransmitted repairs but would 243 destroy their jitter-calculations and traffic-monitoring 244 applications. 246 The second method means that all additional SRM-generated-packets 247 are sent on a separate RTP-data/RTCP channel. Only "standard" RTP- 248 data/RTCP packets are sent on the base-channel. This would allow 249 clients that doesn't understand the SRM extension to join and 250 listen to the session. This is for instance preferable when doing 251 semi-reliable audio/video transfers where clients understanding the 252 extension could get extra value. 254 The second method is the one chosen and discussed in the rest of this 255 draft. The added channel is called the "SRM-channel". 257 4.1 NACKs (point 3) 259 The NACK-transmissions should be implemented using RTCP by adding a 260 new RTCP packet-type, 205 is proposed for now. 262 4.2 Retransmission of data-packets (point 4) 264 The retransmissions can be handled in three ways: 266 * Either we just let applications that don't understand the SRM- 267 extension to see the retransmitted packets as original data and 268 interpret them as duplicates or late packets. This would be nice 269 because applications that don't understand SRM would benefit, but 270 it would unfortunately 'break' traffic estimation and analysis 271 programs. It would also break applications, like for instance the 272 MBone-tool VAT, because they adjust the play-out delay according 273 to the jitter of the incoming packets. 275 * Or all the retransmitted packets could be encapsulated using a 276 new payload-type for redundant data. This would not break 277 existing applications as RTP states that unknown payload-types 278 should be ignored. 280 * Or the extra data-packets could be sent on a separate RTP-channel 281 using layered encoding. This means that the extension- 282 understanding client would listen to at least two channels, the 283 base-channel (an ordinary RTP-channel) and a secondary channel, 284 the SRM-channel, where all SRM-originated traffic is sent. The 285 SRM-channel should be run on a separate multicast group to 286 benefit from group pruning. 288 The third method is to be used. 290 4.3 Heartbeats (point 5) 292 The heartbeats could be incorporated into the SR-packets using the 293 "profile-specific-extensions" but two things argue against this: 295 * This isn't inter-operable with other payload-specific-extensions 296 as there can only be one header-extension. 298 * The SR-packets are only sent during and once right after a sender 299 transmits data but the heartbeats should be sent all the time, so 300 a receiver that have lost several packets directly after the end 301 of a data-flow would notice that she has lost packets. 303 Instead the heartbeats should be sent using the new RTCP-SRM packet- 304 type on the SRM-channel. 306 These heartbeats should be sent more often right after a sender has 307 stopped sending so receivers can notice that they have lost packets 308 more quickly. This isn't a problem for small groups as the dynamic 309 delay between RTCP-packets is small but in larger groups the delay 310 could become a problem. 312 4.4 Time-stamps (point 7) 314 Time-stamps for active senders on the RTP-channel are calculated 315 using the Sender- and Receiver reports (SR and RR) in RTP as 316 described in section 6.3.1 of [RFC1889]. No extra information is 317 needed for this. 319 This section describe how time-stamps for passive members should be 320 calculated. 322 The time-stamps are added into the new RTCP-packet-type and divided 323 into two types. 325 The first type is "time-stamp queries" where a member sends out his 326 wall-clock time-stamp and every other member of the session is 327 expected to answer this query using the second type "time-stamp 328 replies". 330 A time-stamp query should be included in the first RTCP-packet that a 331 new member sends out after joining the session. 333 Replies to pending queries (if any) should be sent each time we send 334 a RTCP-packet. Several replies can be contained in the same RTCP- 335 packet as it would lower the overhead. The time-stamp replies for a 336 new member should have higher priority than replies to an old member. 338 When old receivers see a new member they should set a query-timer 339 chosen randomly from the interval [0.5 , 5]*current_RTCP_interval 340 with a minimum of 5 seconds and a maximum of 2 minutes. If they 341 before the expire don't see another query they send out a query of 342 their own. If they on the other hand do see a query they reset their 343 query-timer and choose a new random expire-time. 345 Each 5*current_RTCP_interval since last query, (minimum 2 minutes, 346 maximum 5 minutes) the member sends out a new query. 348 5. Packet format 350 This section explains the format of the new RTCP-SRM packets. 352 A new RTCP packet type is defined, PT = 205. 354 5.1 Header format 356 The header is the same for all RTCP-SRM packets: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 |V=2|CM | Count | PT | length | header 362 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 364 Version (V): 2 bits 365 Identifies the version of RTP, two (2). 367 Command (CM): 2 bits 368 The SRM-command as defined below. 370 Count: 4 bits 371 The number of command-data-fields minus one included in this 372 packet. How this field is used depends on the command, see 373 below. 375 Packet type (PT): 8 bits 376 Contains the constant 205 to identify this RTCP packet as a 377 SRM packet. 379 Packet length (length): 16 bits 380 The length of this RTCP packet in 32-bit words minus one, 381 including the header. (The offset of one makes zero a valid 382 length and avoids a possible infinite loop in scanning a 383 compound RTCP packet, while counting 32-bit words avoids a 384 validity check for a multiple of 4.) 386 Depending on the Command (CM) field the header is followed by any of 387 the following: 389 5.2 Heartbeat (CM=0) 391 For heartbeats CM contains the constant 0 and the header is followed 392 by 16-bits containing the latest sequence number used by the sender 393 when this report was issued. The next 16 bits contain the cycle 394 number which indicate how many times the sender has wrapped his 395 sequence number. This allows for clients detect that they have lost 396 more that 2^16 packets (when the sequence number counter wraps 397 around) which can happen during net-failure and/or high 398 transmission-speeds. 400 The sender is identified by the SSRC field in the SR or RR-report 401 that must come before this SRM-packet. 403 0 1 2 3 404 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 405 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 406 | Sequence number | Cycle number | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Sequence number: 16 bits 410 The highest sequence number used by the sender when sending 411 this report. 413 Cycle number: 16 bits 414 How many times the sender has wrapped his sequence number. 416 5.3 Time-stamp queries (CM=1) 418 To be able to calculate the host-to-host delay a member has to send 419 out a time-stamp. The time-stamp is composed of the 32 middle bits of 420 a 64 bits NTP time-stamp, meaning the 16 first bits signify the 421 seconds and the later 16 bits signify the fraction. 423 The CM-field in the header contains the constant 1 and the count 424 field is not used. 426 The header is followed by the following: 428 0 1 2 3 429 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 430 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 431 | time-stamp | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 time-stamp: 32 bits 435 The senders current wall-clock time as defined above. 437 5.4 Time-stamp replies (CM=2) 439 Several time-stamp replies can be contained in the same SRM-packet 440 and the number of replies are count+1. 442 A reply-packet for a certain receiver should only be issued if we 443 earlier have received a time-stamp query. 445 The header is followed by the following: 447 0 1 2 3 448 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 449 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 450 | SSRC_1 |block1 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Last time-stamp(LTQ) | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | DLTQ | 455 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 456 | SSRC_2 |block2 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | .... | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 SSRC_n: 32 bits 462 The SSRC of the sender to whom we are answering. 464 Last time-stamp query (LTQ): 32 bits 465 The time-stamp that SSRC_n sent out earlier 467 Delay since last time-stamp query (DLTQ): 32 bits 468 The delay, expressed in units of 1/65536 seconds, between 469 receiving the last time-stamp query packet from source SSRC_n 470 and sending this reply. 472 If SSRC_n receives this reply at time A the host-to-host delay, D, 473 can be calculated as 475 D = (A - LTQ - DLTQ) / 2 477 5.5 NACKs (CM=3) 479 Three different types of NACK-packets are currently defined: 481 Single NACKs for specific packets from one sender. 483 Sequential NACKs requesting a series of lost packets. 485 Application specific NACKs. 487 Each RTCP-NACK can include NACKs for one sender, but several NACKs 488 for different senders may be included into a compound RTCP-packet. 490 Different NACK-types are distinguished by the NACK-Type-field, NT. 492 Each NACK-request also include an urgent-flag (U) indicating (if 493 raised) that this request should be prioritized over requests that 494 don't have the flag set. How this flag is used is application 495 specific (see section 6). 497 5.5.1 Single NACKs, (NT=0) 499 This type of NACK is used for requesting lost packets by specifying 500 each lost packet. 502 The CM-field contains the constant 0 and the count field contains the 503 number of NACKs minus one included in this SRM-packet. This makes 504 zero a useful number as it doesn't make much sense to send an empty 505 NACK packet just containing the SSRC. 507 The header is followed by the following: 509 0 1 2 3 510 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 511 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 512 |NT |U| not used | Cycle count | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | SSRC | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | First Sequence number | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 : .... : 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Last Sequence number | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 NACK-Type (NT): 2 bits 524 Indicates the type of the NACK as a single NACK, 0. 526 Urgent (U): 1 bit 527 Indicating that this is an urgent request. 529 Cycle count: 16 bits 530 The cycle count for the first sequence number as reported in 531 an earlier heartbeat. 533 SSRC: 32 bits 534 The SSRC of the sender from whom we have lost the packets. 536 First/Last Sequence number: 32 bits 537 The sequence numbers of the packets lost from this SSRC. The 538 number of sequence numbers is determined by the count-field in 539 the header. 541 5.5.2 Sequential NACKs, (NT=1) 543 This type of NACK is used for requesting lost packets by specifying a 544 sequence number and the number of following lost packets. 546 The CM-field contains the constant 1 and the count field contains the 547 number of NACKs minus one included in this SRM-packet. This makes 548 zero a useful number as it doesn't make much sense to send an empty 549 NACK packet just containing the SSRC. 551 The header is followed by the following: 553 0 1 2 3 554 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 555 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 556 |NT |U| Number of lost packets | Cycle count | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | SSRC | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | First Sequence number | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 NACK-Type (NT): 2 bits 564 Indicates the type of the NACK as a sequential NACK, 1. 566 Urgent (U): 1 bit 567 Indicating that this is an urgent request. 569 Number of lost packets: 13 bits 570 The number of lost packets following the specified sequence 571 number. 573 Cycle count: 16 bits 574 The cycle count for the first sequence number as reported in 575 an earlier heartbeat. 577 SSRC: 32 bits 578 The SSRC of the sender from whom we have lost the packets. 580 First Sequence number: 32 bits 581 The sequence number of the first packets lost from this SSRC 582 in this sequence of lost packets. 584 5.5.2 Application specific NACKs, (NT=2) 586 This type of NACK is used for requesting lost packets in a way that 587 is specific for the application using this RTP/SRM scheme. It can be 588 used by applications to optimize the buffering by allowing repairers 589 to reconstruct repair-packets from some other representation of the 590 data. This could be used for file-transmissions where the incoming 591 data is transformed into a file. 593 The CM-field contains the constant 2 and the length of this packet is 594 determined by the length field in the header. 596 The header is at-least followed by 4 bytes where the first byte is 597 defined as follows: 599 0 1 2 3 600 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 601 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 602 |NT | Un-specified | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 : ... : 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 : ... : 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 NACK-Type (NT): 2 bits 610 Indicates the type of the NACK as a application specific NACK, 611 2. 613 6. Semi-reliable sessions 615 Not all applications can wait a long time-period before 616 receiving a repair for a lost packet. For instance, real-time 617 data as audio and video that is played out almost immediately 618 as received would have to get their repairs almost 619 immediately. This leads to that the NACKs for such streams has 620 to be prioritized over other NACKs if contained within the 621 same RTP-session. The U-flag in the NACK-RTCP-packet can be 622 used for this. 624 For some applications it might not make any sense in receiving 625 the repair after a certain time-period (as the real-time data 626 might already have been played out). These applications might 627 decide not to retransmit a certain repair if the time since 628 they received the NACK plus the network distance is larger 629 that some number. This number is application specific. 631 This type of sessions are called semi-reliable sessions. 633 7. Further issues 635 [2] presents algorithms for dynamically adjusting the timer 636 parameters C1,C2,D1 and D2. These algorithms should be included but 637 do not imply any changes to the actual packet-format. 639 [2] also presents methods for "local recovery" meaning that we don't 640 multicast NACKs to the whole session but instead minimize the scope 641 of the NACKs by adjusting the TTL. This TTL is adaptively changing as 642 clients get to know their "loss neighbourhood". 644 8. Acknowledgments 646 I'd like to thank Jon Crowcroft, Anders Klemets and Todd Montgomery 647 for creative comments and encouragements. 649 This work is done within the Multimedia Assisted distributed Tele- 650 Engineering Services, MATES, project (ESPRIT 20598). I want to thank 651 the Department of Computer Science and the Centre for Distance- 652 spanning Technology at the Lulea Technical University for giving me 653 the opportunity to do this work. 655 9. Author's Address 657 Peter Parnes 658 Dept. of Computer Science/Centre for Distance-spanning Technology 659 Lulea Technical University 660 S-971 87 Lulea, Sweden 661 Tel: +46 920 72421 662 Fax: +46 920 72191 663 E-Mail: peppar@cdt.luth.se 664 WWW: 666 10. References 668 [1] Schulzrine/Casner/Frederic/Jacobson, "RTP: A Transport 669 Protocol for Real-Time Applications", RFC 1889, January 1996 671 [2] Floyd/Jacobson/McCanne/Liu/Zhang, "A Reliable Multicast 672 Framework for Light-weight Sessions and Application Level 673 Framing", Proceedings of ACM SIGCOMM 95, 674 . An 675 extended and corrected version is submitted to IEEE/ACM 676 Transactions on Networking, 677