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