idnits 2.17.1 draft-pullen-srmp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 37. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1302. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1289), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 310 has weird spacing: '... 4 bits curr...' == Line 316 has weird spacing: '... 4 bits feed...' == Line 323 has weird spacing: '...16 bits rang...' == Line 396 has weird spacing: '... 4 bits curr...' == Line 399 has weird spacing: '... 4 bits valu...' == (11 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: The SRMP daemon should keep a timer, which will be reset when the first SRMP message is added into the bundle. After Bundle_Timeout, the timer will time out, and the current bundle should be transmitted immediately. A new bundle will then be initialized to hold new SRMP messages. Bundle_Timeout SHALL not be less than 1 ms. Recommended value is 10 ms. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Also, the bundle length MUST not exceed LENGTH_MAX. If adding a new SRMP message will produce a greater length, the SRMP daemon MUST initialize a new bundle for the new SRMP messages, and the current bundle should be transmitted immediately. Recommended value for LENGTH_MAX is 1454 bytes (Ethernet MTU minus IP and UDP header lengths). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: o the SegNo has not been received, some segment of the has been received, and a user-defined Segment_Timeout, which SHALL not be less than 50 ms, has expired since receipt of the first SegNo for the . == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: SRMP implementations may support a user-defined Heartbeat_Interval, Which SHALL not be less than one second. At the end of each heartbeat interval, if the sender has not sent any bundle, an empty bundle will be sent in order to trigger Mode 1 loss detection. -- 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 (June 2005) is 6889 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 1248, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2402 (ref. '9') (Obsoleted by RFC 4302, RFC 4305) Summary: 10 errors (**), 0 flaws (~~), 15 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft M. Pullen 3 draft-pullen-srmp-06.txt B. Shanmugam 4 Expires: December 2005 F. Zhao 5 George Mason Univ 6 D. Cohen 7 Sun Microsystems 8 June 2005 10 Selectively Reliable Multicast Protocol (SRMP) 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. 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. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 By submitting this Internet-Draft, each author represents that any 35 applicable patent or other IPR claims of which he or she is aware 36 have been or will be disclosed, and any of which he or she becomes 37 aware will be disclosed, in accordance with Section 6 of BCP 79. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). All Rights Reserved. 43 Abstract 45 The Selectively Reliable Multicast Protocol (SRMP) is a transport 46 protocol, intended to deliver a mix of reliable and best-effort 47 messages in an any-to-any multicast environment, where the best- 48 effort traffic occurs in significantly greater volume than the 49 reliable traffic and therefore can be used to carry sequence 50 numbers of reliable messages for loss detection. SRMP is intended 51 for use in a distributed simulation application environment, where 52 only the latest value of reliable transmission for any particular 53 data identifier requires delivery. 55 SRMP has two sublayers: a bundling sublayer that combines short 56 messages, peforms NAK suppression, and incorporates the TCP-Friendly 57 Multicast Congestion Control of Widmer and Handley, dropping best- 58 effort traffic in order to achieve congestion control; and a 59 selectively reliable transport (SRT) sublayer that formats best- 60 effort and reliable transmissions and also creates negative 61 acknowledgements when loss of reliable messages is detected. 63 In SRMP, selection between reliable and best-effort messages is 64 performed by the application. The protocol bundles messages within 65 a configured time interval, attempting to achieve a configured 66 bundle size which typically is set to the expected smallest MTU 67 in the delivery path. The bundle header carries the latest sequence 68 number for each reliable transmission. Rate reduction is achieved 69 when necessary by dropping best-effort messages at random. 71 Table of Contents 73 1. Introduction 3 74 1.1 Terminology 4 75 2. Protocol description 4 76 3. Message formats 6 77 3.1 Bundle packet format 6 78 3.2 bundle header format 7 79 3.3 feedback message format 9 80 3.4 SRT Mode 0 header format 10 81 3.5 SRT Mode 1 header format 10 82 3.6 SRT Mode 2 header format 11 83 3.7 SRT NACK format 11 84 3.8 User-configurable parameters 12 85 4. TFMCC Operation 12 86 4.1 TCP rate prediction equation 12 87 4.2 Bundling 13 88 4.3 Congestion Control 13 89 4.4 Any-Source Multicast 13 90 4.5 Multiple Sources Issue 14 91 4.6 Bundle Size 14 92 4.7 Data rate control 14 93 4.8 Mode 1 loss detection 14 94 4.8.1 Sending a Negative Acknowledgement 15 95 4.9 Unbundling 15 96 4.10 Heartbeat bundle 16 97 5. SRT Operation 16 98 5.1 Mode 0 operation 16 99 5.1.1 Sending Mode 0 messages 17 100 5.1.2 Receiving Mode 0 Messages 17 101 5.2 Mode 1 operation 17 102 5.2.1 Sending Mode 1 Data messages 17 103 5.2.2 Receiving Mode 1 Data messages 18 104 5.2.3 Scheduling a Negative Acknowledgement 18 105 5.2.4 Receiving a Negative Acknowledgement 19 106 5.3 Mode 2 Operation 20 107 5.3.1 Sending Mode 2 Data messages 20 108 5.3.2 Receiving Mode 2 Data messages 21 109 5.3.3 Sending a Positive Acknowledgement 21 110 5.3.4 Receiving a Positive Acknowledgement 22 111 6. RFC 2357 Analysis 22 112 6.1 Scalability 22 113 6.2 Congestion 22 114 7. IANA considerations 23 115 8. Security considerations 23 116 9. List of Acronyms 25 117 10. Authors' addresses 25 118 11. References 26 119 12. Full copyright statement 27 121 1. Introduction 123 There is no viable generic approach to achieving reliable transport 124 over multicast networks. Existing successful approaches require that 125 the transport protocol take advantage of special properties of the 126 traffic in a way originally proposed by Cohen. The protocol described 127 here is applicable to real-time traffic containing a mix of two 128 categories of messages: a small fraction requiring reliable delivery, 129 mixed with a predominating flow of best-effort messages. This sort of 130 traffic is associated with distributed virtual simulation (RFC 2502 131 [9]) and also with some forms of distributed multimedia conferencing. 132 These applications typically have some data that changes rarely, or 133 not at all, so the best efficiency will be achieved by transmitting 134 that data reliably (the external appearance of a simulated vehicle is 135 an excellent example). They also require real-time transmission of a 136 best-effort stream (for example the position and orientation of the 137 vehicle). There is no value to reliable transmission of this stream 138 because typically new updates arrive faster than loss identification 139 and retransmission could take place. By piggy-backing the sequence 140 number (SN) of the latest reliable transmission on each bundle of 141 traffic, the reliable and best-effort traffic can co-exist 142 synergistically. This approach is implemented in the Selectively 143 Reliable Multicast transport Protocol (SRMP). 145 The IETF has conducted a successful working group on Reliable 146 Multicast Transport (RMT) that has produced RFCs 2357, 2887, and 3450 147 through 3453 which define building block protocols for reliable 148 multicast. Selectively reliable multicast is similar in spirit to 149 these protocols and in fact uses one of them, TCP Friendly Multicast 150 Congestion Control (TFMCC). This document provides the basis for 151 specifying SRMP with TFMCC for use on an experimental basis. Key 152 requirements of the RMT process that is carried forward here are 153 specified in RFC 2357 [3]. These generally relate to scalability and 154 congestion control, and are addressed in section 6 of this document. 156 1.1 Terminology 158 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 159 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 160 and "OPTIONAL" are to be interpreted as described in RFC 2119 [7] and 161 indicate requirement levels for compliant implementations. 163 2. Protocol Description 165 The Selectively Reliable Multicast Protocol (SRMP) has two major 166 components: Selectively Reliable Transport (SRT) and a "bundling 167 sublayer" that implements TCP-Friendly Multicast Congestion 168 Control (TFMCC), as proposed by Widmer and Handley [8], in order 169 to meet the requirements of RFC3269 [3] for congestion avoidance. 171 SRMP is capable of reliable message delivery over multicast 172 networks, when the messages to be delivered reliably represent a 173 fraction of a larger, associated best-effort flow and only the 174 latest reliable message must be delivered. The basic strategy 175 of SRMP is trade as little network capacity as possible for 176 reliability by buffering the latest sent reliable message at each 177 sender and piggybacking its sequence number on associated best- 178 effort messages. For this purpose, three modes of sending are 179 defined: 181 o Mode 0 messages. These will be delivered best-effort; 182 if lost, no retransmission will be done. 184 o Mode 1 messages. When a Mode 1 message loss is detected, the 185 receiver will send back a NACK to the sender, where SRMP will 186 retransmit the latest reliable message from that sender. 187 Senders define data identifiers (DataIDs), allowing multiple 188 reliable message streams to be supported. Mode 1 messages may be 189 up to 131,071 bytes long; SRMP provides for segmentation and 190 reassembly, but only for the latest Mode 1 message for any given 191 . 193 o Mode 2 messages. Through Mode 2 messages, SRMP provides for a 194 lightweight, reliable, connectionless peer-to-peer unicast 195 transaction exchange between any two members of the multicast 196 group. This is a unicast message requiring positive 197 acknowledgement (ACK). 199 | Application | 200 ----------------- ---------- 201 | SRT | 202 ----------------- -> SRMP 203 |Bundling(TFMCC)| 204 ----------------- ---------- 205 | UDP | 207 The Bundling sublayer is transparent to the Selectively Reliable 208 Transport (SRT) sublayer. It implements congestion control both by 209 dropping Mode 0 messages at the source when needed, and also by 210 bundling multiple short messages that are presented by applications 211 within a short time window. It also performs NACK suppression. 213 A bundling sublayer data unit is called a bundle. A bundle is made 214 up of a bundle header and any of Mode 0 and 1 SRMP messages. 215 Retransmission of Mode 1 messages does not imply retransmission of 216 the original bundle; the retransmitted message becomes part of a 217 new bundle. 219 The TFMCC layer's behavior follows the mechanism described by 220 Widmer and Handley. This is an equation-based multicast congestion 221 control mechanism: in a multicast group, each receiver determines 222 its loss rate with regard to the sender, and calculates a desired 223 source sending rate based on an equation that provides that models 224 the steady-state sending rate of TCP. A distributed feedback 225 suppression mechanism restricts feedback to those receivers likely 226 to report the lowest desired rates. Congestion control is achieved 227 by dropping best-effort (Mode 0) messages at random. For example, 228 in distributed simulation Mode 0 messages are part of a stream of 229 state update for dynamic data such as geographic location; therefore 230 the application can continue to function (with lower fidelity) when 231 they are dropped. 233 As described by its authors, TFMCC's congestion control mechanism 234 works as follows: 235 o Each receiver measures the loss event rate and its RTT to the 236 sender. 237 o Each receiver then uses this information, together with an 238 equation for TCP throughput, to derive a TCP-friendly sending 239 rate. 240 o Through a distributed feedback suppression mechanism, only a 241 subset of the receivers are allowed to give feedback to prevent 242 a feedback implosion at the sender. The feedback mechanism 243 ensures that receivers reporting a low desired transmission rate 244 have a high probability of sending feedback. 245 o Receivers whose feedback is not suppressed report the calculated 246 transmission rate back to the sender in so-called receiver 247 reports. The receiver reports serve two purposes: they inform the 248 sender about the appropriate transmit rate, and they allow the 249 receivers to measure their RTT. 251 o The sender selects the receiver that reports the lowest rate as 252 current limiting receiver (CLR). Whenever feedback with an even 253 lower rate reaches the sender, the corresponding receiver becomes 254 CLR and the sending rate is reduced to match that receiver's 255 calculated rate. The sending rate increases when the CLR reports 256 a calculated rate higher than the current sending rate. 257 TFMCC was intended for fixed-size packets with variable rate. SRMP 258 applies it to variable-size SRMP messages that are mostly the same 259 size because the best-effort updates typically all represent the 260 same sort of simulation information and are grouped into bundles of 261 size just under one MTU during periods of heavy netwrok activity. 262 Future developments in TFMCC for variable-size messages will be of 263 high value for inclusion in SRMP if, as expected, they prove to be 264 appropriate for the types of traffic SRMP is intended to support. 266 SRMP is intended for general use under applications that needs its 267 services and may exist in parallel instances on the same host. The 268 UDP port is therefore established ad hoc from available application 269 ports, thus it would not be appropriate to have a well-known port 270 for SRMP. 272 3. Message formats 274 3.1 Bundle message format: 276 -------------------------------------------------------------------- 277 | bundle header | SRT Message 0 | SRT message 1 | SRT message 2 |... 278 -------------------------------------------------------------------- 280 A bundle is an aggregation of multiple SRMP messages fo the same 281 multicast address. A bundle can contain only Mode 0 and Mode 1 282 messages; Mode 2 messages are exchanged using unicast addresses. 284 SRMP identifies sender and receiver using their 32-bit Sender_ID, 285 which may be an IPv4 address. For use with IPv6, a user group will 286 need to establish a unique identifier per host. There is no 287 requirement for this identifier to be unique in the Internet; it 288 need only be unique in the communicating group. 290 3.2 bundle header format: 292 0 8 16 24 32 293 +--------------+--------------+--------------+--------------+ 294 |Version| 000 |fb_nr | flag | bundle_SN | 295 +--------------+--------------+--------------+--------------+ 296 | Sender_ID | 297 +--------------+--------------+--------------+--------------+ 298 | Receiver_ID | 299 +--------------+--------------+--------------+--------------+ 300 | Sender_Timestamp | Receiver_Timestamp | 301 +--------------+--------------+--------------+--------------+ 302 | x_supp | R_max | 303 +--------------+--------------+--------------+--------------+ 304 | DSN_count | padding | Length | 305 +--------------+--------------+--------------+--------------+ 306 | 0 to 255 DSN: of this sender | 307 +-----------------------------------------------------------+ 309 Version: 310 4 bits currently 0010 312 Type: 313 4 bits 0000 - indicates bundle 315 fb_nr: 316 4 bits feedback round, range 0 - 15 318 flag: 319 4 bits 0001 Is_CLR 320 other bits reserved 322 bundle_SN: 323 16 bits range 0-65535 325 Sender_Timestamp: 326 16 bits Representing the time that the bundle was sent out (in 327 milliseconds) based on the sender's local clock. 329 Receiver_Timestamp: 330 16 bits Echo of the Receiver_Time_Stamp field (in milliseconds) 331 of the receiver feedback message. If the sender has time 332 delay between receiving the feedback and echoing the 333 timestamp, it MUST adjust the Receiver_Timestamp value 334 to compensate. 336 Receiver_ID 337 32 bits Unique identifier for the receiver within the multicast 338 group. IPv4 address may be used. 340 Sender_ID: 341 32 bits Unique identifier for the sender within the multicast 342 group. IPv4 address may be used. 344 X_supp: 345 16 bits The suppression rate corresponding with the sender, in 346 bits/s. Only those receivers whose desired rate is less 347 than the suppression rate, or RTT larger than R_max, may 348 send feedback information to the sender. The suppression 349 rate is represented as a 16 bit floating point value 350 with 8 bits for the unsigned exponent and 8 bits for the 351 unsigned mantissa. 353 R_max: 354 16 bits The maximum of the RTTs of all receivers, in 355 milliseconds. The Maximum RTT should be represented as 356 a 16-bit floating point value with 8 bits for the 357 unsigned exponent and 8 bits for the unsigned mantissa. 359 DSN_count: 360 8 bits The count of DSN blocks following the header. 362 Length: 363 16 bits Range from 0~65535. The total length of the bundle 364 (including header). 366 DSN: 367 32 bits There can be up to 256 of these in a header. An SRMP 368 implementation MUST support a minimum of 1. Each DSN 369 consists of three fields: 371 DataID: 372 16 bits A unique number associated with a particular data 373 element on the sending host, used to identify a 374 Mode 1 message 375 SN: 376 9 bits Sequence Number associated with a particular Mode 1 377 transmission of a particular DataID. 378 NoSegs: 379 7 bits Number of segments, if the DataID was long enough 380 to require segmentation; otherwise 0x0. 382 3.3 feedback message format 384 0 8 16 24 32 385 +--------------+--------------+--------------+--------------+ 386 |Version| 001 | fb_nr| flag | X_r | 387 +--------------+--------------+--------------+--------------+ 388 | Sender_Timestamp | Receiver_Timestamp | 389 +--------------+--------------+--------------+--------------+ 390 | Sender_ID | 391 +--------------+--------------+--------------+--------------+ 392 | Receiver_ID | 393 +--------------+--------------+--------------+--------------+ 395 Version: 396 4 bits currently 0010 398 Type: 399 4 bits value 0001 401 fb_nr: 402 4 bits current feedback round of the sender. 404 flag: 405 4 bits 406 0001 - have_RTT 407 0010 - have_loss 408 0100 - receiver_leave 409 other values reserved 410 X_r: 411 16 bits desired sending rate X_r in bits/s, calculated by the 412 receiver to be TCP-friendly 414 Sender_Timestamp: 415 16 bits echo of the Sender_Timestamp in bundle header. If the 416 receiver has time delay between receiving the bundle and 417 echoing the timestamp, it MUST adjust the 418 Sender_Timestamp value correspondently. 420 Receiver_Timestamp: 421 16 bits the time when the feedback message was sent out from the 422 receiver. 424 Receiver_ID: 425 32 bits Unique identifier for the receiver within the multicast 426 group. IPv4 address may be used. (identifies the 427 receiver that sends the feedback message) 428 Sender_ID: 429 32 bits Unique identifier for the sender within the multicast 430 group. IPv4 address may be used. (identifies the sender 431 that is the destination of the current feedback message) 433 X_r: 434 12 bits the receiver's desired rate. The desired rate should be 435 represented as a 12 bits floating point value with 5 436 bits for the unsigned exponent and 7 bits for the 437 unsigned mantissa. 439 3.4 SRT Mode 0 header format 441 0 8 16 24 32 442 +--------------+--------------+--------------+--------------+ 443 |Version| 0000 | 000 | 00000000 | Length | 444 +--------------+--------------+--------------+--------------+ 446 Version: 447 4 bits currently 0010 449 Type: 450 4 bits 0000 452 Mode: 453 3 bits 000 455 Padding 456 8 bits 00000000 458 Length: 459 11 bits Length of the payload data (does not include header) 461 3.5 SRT Mode 1 header format 463 0 8 16 24 32 464 +--------------+--------------+--------------+--------------+ 465 |Version| 0010 | 001 | SegNo | Length | 466 +--------------+--------------+--------------+--------------+ 467 | DSN | 468 +--------------+--------------+--------------+--------------+ 470 Version: 471 4 bits currently 0010 473 Type: 474 4 bits 0000 476 Mode: 477 3 bits 001 479 SegNo: 480 7 bits The index number of this segment 482 Length: 483 14 bits Length of the payload data (does not include header) 485 DSN: 486 32 bits Same as in bundle header. Note that this contains 487 NoSegs, whereas SegNo is a separate element. 489 3.6 SRT Mode 2 header format 491 0 8 16 24 32 492 +--------------+--------------+--------------+--------------+ 493 |Version| 0010 |010 | 00000 | Length | 494 +--------------+--------------+--------------+--------------+ 495 | SN | 496 +--------------+--------------+--------------+--------------+ 498 Version: 499 4 bits currently 0010 501 Type: 502 4 bits 0010 504 Mode: 505 3 bits 010 507 padding: 508 5 bits 00000 510 Length: 511 16 bits Length of the payload data (does not include header) 513 SN: 514 32 bits Same as in bundle header. 516 3.7 SRT NACK format 518 0 8 16 24 32 519 +--------------+--------------+--------------+--------------+ 520 |Version| 0010 |111 | 00000 | reserved | 521 +--------------+--------------+--------------+--------------+ 522 | DSN | 523 +--------------+--------------+--------------+--------------+ 524 | Sender Address | 525 +--------------+--------------+--------------+--------------+ 527 Version: 528 4 bits currently 0010 530 Type: 531 4 bits 0010 533 Mode: 534 3 bits 111 536 padding: 537 5 bits 00000 539 reserved 540 16 bits 542 DSN: 543 32 bits sequence number 545 Sender Address: 546 The IP address of the sender of message being NACKed 548 3.8 User-configurable parameters 550 Name Minimum Value Recommended Value Units 552 DSN_Max 1 32 messages 553 DataID_Timeout none none ms 554 Segment_Timeout 50 250 ms 555 Bundle_Timeout 1 10 ms 556 Heartbeat_Interval 1 none s 557 Mode2_Max 1 none messages 558 ACK_Threshold none worst RTT in group ms 560 4 TFMCC Operation 562 4.1 TCP rate prediction equation for TFMCC 564 The RECOMMENDED throughput equation for SRMP is a slightly simplified 565 version of the throughput equation for Reno TCP from [2]: 567 8 s 568 X = ------------------------------------------------------ (1) 569 R * (sqrt(2*p/3) + (3*sqrt(6*p) * p * (1+32*p^2))) 571 (the formula may be simplified for implementation), where 573 X is the transmit rate in bits/second. 575 s is the message size in bytes. 577 R is the round-trip time in seconds. 579 p is the loss event rate, between 0.0 and 1.0, of the number of 580 loss events as a fraction of the number of messages transmitted. 582 In the future, different TCP formulas may be substituted for this 583 equation. The requirement is that the throughput equation be a 584 reasonable approximation of the sending rate of TCP for conformant 585 TCP congestion control. 587 4.2 Bundling 589 Multiple SRMP messages will be encapsulated into a bundle. When a 590 new SRMP message (mode 0 or mode 1) arrives, the SRMP daemon will 591 try to add the new message into the current bundle. 593 The SRMP daemon should keep a timer, which will be reset when the 594 first SRMP message is added into the bundle. After Bundle_Timeout, 595 the timer will time out, and the current bundle should be 596 transmitted immediately. A new bundle will then be initialized to 597 hold new SRMP messages. Bundle_Timeout SHALL not be less than 1 ms. 598 Recommended value is 10 ms. 600 Also, the bundle length MUST not exceed LENGTH_MAX. If adding a new 601 SRMP message will produce a greater length, the SRMP daemon MUST 602 initialize a new bundle for the new SRMP messages, and the current 603 bundle should be transmitted immediately. Recommended value for 604 LENGTH_MAX is 1454 bytes (Ethernet MTU minus IP and UDP header 605 lengths). 607 In a bundle, there may exist multiple SRMP messages with the same 608 DataID. In this case, only the latest version of that DataID is 609 useful. SRMP may check for duplicate DataIDs in the same bundle 610 and delete all but the latest one. If a mode 1 message appears 611 in the outgoing bundle, then the corresponding DSN should not 612 appear in the bundle header. 614 The bundle header contains the DSN for Mode 1 615 messages from this sender. The absolute maximum number of DSN is 616 255, however an implementation may apply a user-specified DSN_Max, 617 no smaller than 1. An implementation may support a user-defined 618 DataID_Timeout, after which a given DataID will not be announced 619 in the bundle header unless a new Mode 1 message has been sent. If 620 the sender has more DataIDs sent (and not timed out) than will fit 621 in the bundle header, the DSNs MUST be announced on a round-robin 622 basis, with the exception that no bundle header will announce a 623 DSN for a Mode 1 message contained within that bundle. 625 4.3 Congestion Control 627 The congestion control mechanism operates as described in [4]. 629 4.4 Any-Source Multicast 631 SRMP uses Any-Source Multicast Mode. Each sender will determine its 632 Maximum RTT, Suppression data rate and Sending rate with respect to 633 each sender. Each receiver will measure its RTT and Desired Rate to 634 each sender in the group, and send feedback to every sender by 635 sending to the multicast group. 637 4.5 Multiple Sources 639 Under SRMP, each group member in a multicast group is a sender as 640 well as receiver. Each receiver may need to participate in TFMCC 641 information exchange with all senders. Thus, when a receiver sends 642 a feedback message, it must identify to which source the message 643 should be sent using the "Sender ID" field in the header. 645 The feedback is multicast to the group. Depending on the network 646 situation, senders may select different receivers to provide feedback 647 Feedback messages from receivers that are not among those selected by 648 the local TFMCC to provide feedback should be silently discarded. 650 4.6. Bundle Size 652 TFMCC is designed for traffic with fixed message size. The maximum 653 bundle size (including header) for SRMP is set to a configurable 654 maximum, typically 1454 bytes (Ethernet MTU less IP and UDP header 655 length). The bundle size will be used in a TCP throughput equation, 656 to get a desired source rate. However, in SRMP the message size is 657 variable because: 659 1. After bundle time out, the current bundle will not wait for new 660 SRMP messages. This happens with sources sending at a slow rate. 662 2. Long messages; there is no further space in the current bundle for 663 new SRMP messages. This will happen with sources sending at a high 664 rate or sending messages with length over half of the bundle 665 payload size. 667 The case 1 bundle size is likely to be much smaller than that of 668 case 2. 670 Therefore in SRMP the mean value of the 10 most recent bundles' sizes 671 will be used as the bundle size in the TCP throughput equation. 672 This mean value is independent from the network condition and 673 reflects current activity of the source. 675 4.7 Data rate control 677 Each host will have a single instance of SRMP supporting all of its 678 applications. Thus the sender's source rate is the sum of the rates 679 all clients of the same multicast group. 681 If the source rate is larger than the senders desired transmission 682 rate, it is the sender's responsibility to do traffic shaping. Any 683 method that conforms to the target sending rate may be used. The 684 RECOMMENDED method is to randomly discard enough Mode 0 messages to 685 meet the target rate. 687 4.8. Mode 1 loss detection 689 Bundle header processing includes checking each DSN in the bundle 690 header and scheduling a NACK for each DSN bearing a DataID for which 691 some application has indicated interest, if the SN/SegNo in that DSN 692 indicates a NACK is needed. NACKs are sent in bundles, and may be 693 bundled with data messages. A NACK is required if: 695 o the SN is one or more greater (mod 512) than the latest received 696 Mode 1 message for that DataID, or 698 o the SegNo has not been received, some segment of the 699 has been received, and a user-defined Segment_Timeout, which 700 SHALL not be less than 50 ms, has expired since receipt of the 701 first SegNo for the . 703 The bundling sublayer will pass the DSN list in any received bundle 704 header to the SRT sublayer. It also will suppress NACKs in outgoing 705 bundles, as described in the next section. 707 4.8.1 Sending a Negative Acknowledgement 709 Negative acknowledgements are used by SRMP for multicast messages in 710 order to avoid the congestion of an "ACK implosion" at the original 711 sender that would likely occur if positive acknowledgements were 712 used instead. However, with a large multicast group spread out over 713 a congested wide-area network, there is the potential for enough 714 members of the multicast group to fail to receive the message and 715 generate NACKs to cause considerable congestion at the original 716 sender despite the use of negative acknowledgements instead of 717 positive acknowledgements. For this reason, SRMP uses a NACK 718 suppression mechanism to reduce the number of NACKs generated in 719 response to any single lost message. 721 The NACK suppression mechanism uses the Bundle_Timeout to distribute 722 NACKs over an appropriate time window. This assumes that the user has 723 Selected a bundle timeout appropriate to the needs of the 724 application for real-time responsiveness. 726 When the bundling sublayer is ready to send a bundle, it removes 727 from the bundle any NACKs for which a response has been sent by 728 another member of the multicast group within the NACK_Repeat_Timeout 729 window. If the original Bundle_Timeout has not expired, transmission 730 of the bundle may then be delayed until the original Bundle_Timeout 731 expires or the bundle is full, whichever happens first. 733 4.9 Unbundling 735 After a receiver completes congestion control processing on a 736 bundle, it parses the bundle into SRT messages and sends these to 737 SRT sublayer. 739 4.10 Heartbeat bundle 741 SRMP implementations may support a user-defined Heartbeat_Interval, 742 Which SHALL not be less than one second. At the end of each heartbeat 743 interval, if the sender has not sent any bundle, an empty bundle will 744 be sent in order to trigger Mode 1 loss detection. 746 5. SRT Operation 748 SRMP operates in three distinct transmission modes in order to 749 deliver varying levels of reliability: Mode 0 for multicast data 750 that does not require reliable transmission, Mode 1 for data that 751 must be received reliably by all members of a multicast group, and 752 Mode 2 for data that must be received reliably by a single 753 dynamically-determined member of a multicast group. 755 Mode 0 operates as a pure best-effort service. Mode 1 operates 756 with negative acknowledgements only, triggered by bundle arrivals 757 that indicate loss of a Mode 1 message. Mode 2 uses a positive 758 acknowledgement for each message to provide reliability and low 759 latency. Mode 2 is used where a transaction between two members of a 760 multicast group is needed. Because there can be many members in such 761 a group, use of a transaction protocol, with reliability achieved by 762 SRMP retransmission, avoids the potentially large amount of 763 connection setup and associated state that would be required if each 764 pair of hosts in the group established a separate TCP connection. 766 Use of SRMP anticipates that only a small fraction of messages will 767 require reliable multicast, and a comparably small fraction will 768 require reliable unicast. This is due to a property of distributed 769 virtual simulation: the preponderance of messages consist of state 770 update streams for object attributes such as position and 771 orientation. SRMP is unlikely to provide effective reliable 772 multicast if the traffic does not have this property. 774 In SRMP, "DataID" is used to associate related messages with each 775 other. Typically, all messages with the same DataID are associated 776 with the same application entity. All the messages with the same 777 "DataID" must be transmitted in the same Mode. Among all the 778 messages with the same Dataid, the latest version will obsolete all 779 older messages. 781 5.1 Mode 0 operation 783 Mode 0 is for multicast messages that do not require reliable 784 transmission because they are part of a real-time stream of data 785 that is periodically updated with high frequency. Any such message 786 is very likely to have been superceded by a more recent update 787 before retransmission could be completed. 789 5.1.1 Sending Mode 0 messages 791 When an application requests transmission of Mode 0 data, a 792 destination multicast group must be provided to SRMP along 793 with the data to be sent. After verifying the data length and 794 multicast group, the following steps MUST be performed by the SRT 795 sublayer: 797 1. An SRT message MUST be generated with the following 798 characteristics: 800 the version is set to the current version, the message type is 801 set to 0x0, the Mode is set to 0x0. User data is included after 802 the message header. If the message cannot be generated as 803 described above, the user data is discarded and the error MUST 804 be reported to the application. 806 2. If step 1 was completed without error, the newly generated 807 message MUST be sent to the bundling sublayer The 808 implementation MUST report to the application whether or not 809 the message was ultimately accepted by UDP. 811 5.1.2. Receiving Mode 0 Messages 813 When a mode 0 message is received by SRMP it MUST be processed as 814 follows, after verifying the version, message type, and destination 815 multicast address fields, the user data MUST be delivered to all 816 applications that are associated with the multicast group in the 817 message. If the SRMP receiver has never received any Mode 1 messages 818 before the mode 0 message received, the mode 0 message should be 819 silently discarded. 821 It is RECOMMENDED that the following information should be provided 822 to the receiving applications: message body, multicast address. 824 5.2. Mode 1 operation 826 Mode 1 is for multicast data that requires reliable transmission. A 827 Mode 1 message can be either a data message or a NACK. Mode 1 data 828 messages are expected to be part of a data stream. This data stream 829 is likely to contain Mode 0 messages as well (see section 3.1.1), 830 but it is possible for a data stream to be comprised solely of Mode 831 1 messages. 833 5.2.1. Sending Mode 1 Data messages 835 After the data length, dataID, and destination multicast group are 836 verified, SRT MUST take the following steps: 838 1. If the message will not fit in an empty bundle with DSN_Max DSN 839 in the header, the message MUST be segmented. The remaining 840 steps pertain to each segment of the message. Each segment 841 receives a unique SegNo, starting with 0 and ending with 842 (NoSegs-1). 844 2. An SRT message is generated with the following characteristics: 845 the Version is set to 0x02, the message type is set to 0x0, the 846 transmission Mode is set to 0x111, The SN is set equal to the SN 847 of the most recently sent Mode 1 complete message of the same 848 DataID, incremented by 1 modulo 512. If no such mode 1 message 849 exists, the SN is set to 0x0. 851 3. The newly generated message (all segments) must then be 852 buffered, replacing any formerly buffered Mode 1 message of the 853 same DataID, destination multicast address. If the message 854 cannot be buffered, the user data is discarded and the error is 855 reported to the application. 857 4. If step 2 was completed without error, the newly generated 858 message is sent to the TFMCC sublayer. 860 5.2.2. Receiving Mode 1 Data messages 862 When a Mode 1 data message is received by SRT it will be processed 863 as follows (assuming that the version field has already been 864 verified to be 0x02): 866 1. The destination address MUST be verified to be a valid IP 867 multicast address on which this instance of SRMP is a member. 868 If this is not the case, the message should be silently 869 discarded. 871 2. The destination address MUST be verified to be one for which 872 some application has indicated interest. Otherwise, the 873 message should be discarded silently. 875 3. The SN, SegNo, source_ip_address, and the body of the received 876 message MUST be buffered, and the user data MUST then be 877 delivered to all applications that have indicated interest in 878 the multicast group of the received message. 880 4. When a new DSN value is received with NoSegs greater than zero, 881 a timer should be set for Segment_Timeout, after which a NACK 882 should be sent to the bundling sublayer and the timer should be 883 restarted for Segment_Timeout. 885 5. If NoSegs in the received message is not 0, a reassembly 886 process MUST be started. Each segment MUST be buffered. If 887 receipt of the current message completes the segment, the 888 reassembled message MUST be released to the application and the 889 Segment_Timeout timer cancelled. 891 6. If a new DSN is received before all segments of the previous 892 DSN are received, the segments that have been received should 893 be dropped silently. 895 7. It is RECOMMENDED that the following information should be 896 provided to the receiving applications: message body, dataid, 897 source_ip_address, multicast_group address. 899 8. When a client signs on to a new multicast group, all locally 900 buffered mode 1 messages related to that multicast group should 901 be delivered to the client immediately. 903 5.2.3 Scheduling a Negative Acknowledgement 905 Whenever a bundle is received, the bundling sublayer will forward 906 the DSN list from the bundle header to the SRT sublayer. The SRT 907 sublayer will examine buffered values of 908 to determine whether a NACK is required. If so, it will generate a 909 NACK message and send it to the bundling sublayer. The NACK message 910 will have version set to 0x2, message type set to 0x1, transmission 911 mode set to 0x1. DataID, SN, and destination address are set to that 912 of the Mode 1 message for which the NACK is being sent. If a NACK has 913 been received from any member of the destination multicast group for 914 the Mode 1 message in question within the NACK threshold, no NACK is 915 generated. 917 For segmented messages, there are two possible types of NACKs: 919 o Based on the DSN list in the bundle header, the SRT 920 implementation may determine that an entire segmented Mode 1 921 message was lost. In this case the NACK MUST carry Segno=0x127 922 (all one in field). 924 o Based on Segment Timeout, the SRT implementation may determine 925 that one or more segments of a message have not been delivered. 926 In this case, a NACK will be sent for each missing segment. 928 5.2.4 Receiving a Negative Acknowledgement 930 When a NACK is received by SRT, it MUST be processed as follows, 931 after verifying the multicast address, DataID, source IP address, 932 and transmission mode: 934 1. If this instance of SRT's most recent Mode 1 message of the 935 DataID indicated in the NACK has a SN newer than SN in the NACK, 936 that message (which is buffered) should be immediately 937 retransmitted to the multicast address indicated in the 938 received NACK. If the most recent Mode 1 message has a SN 939 equal to the SN indicated in the NACK, and if the SegNo field 940 in the NACK contains 0x127, all segments of the buffered Mode 1 941 message MUST be retransmitted; if the SegNo has some other 942 value, only the indicated segment should be retransmitted. 944 2. Whether or not step 1 results in the retransmission of a 945 message, the event of receiving the NACK and the (local machine) 946 time at which the NACK was received should be buffered. Each 947 instance of SRT MUST buffer the number of NACKs that have been 948 received for each DataID - multicast address pair, since the 949 most recent Mode 1 message of the same pair was received and 950 the time at which the most recent of these NACKs was received. 952 5.3. Mode 2 Operation 954 Mode 2 is for infrequent reliable transaction-oriented communication 955 between two dynamically determined members of a multicast group. TCP 956 could be used for such communication, but there would be unnecessary 957 overhead and delay in establishing a stream-oriented connection for 958 a single exchange of data, whereas there is already an ongoing 959 stream of best-effort data between the hosts that require Mode 2 960 transmission. An example is a Distributed Interactive Simulation 961 (DIS) collision PDU. 963 5.3.1 Sending Mode 2 Data messages 965 When an application requests transmission of Mode 2 data, a 966 DataID and a destination unicast IP address MUST be provided to SRT 967 along with the data to be sent. After verifying the data length, 968 DataID and destination address, SRT MUST perform the following 969 steps: 971 1. An SRT message is generated with the following characteristics: 972 the version is set to 0x02, the message type is set to 0x0, the 973 transmission mode is set to 0x2, the DataID is set to the 974 application-provided value, and the destination address is set 975 to the application-provided IP address. The SN is set equal to 976 the SN of the most recently sent Mode 2 message of the same 977 DataID incremented by 1 modulo 65536. If no such Mode 1 message 978 exists, it is set to 0x0. 980 2. The newly generated message is buffered. This new message does 981 not replace any formerly buffered Mode 2 messages. An 982 implementation MUST provide a Mode 2 message buffer that can 983 hold one or more Mode 2 messages. Mode 2 messages are expected 984 to be infrequent (less than 1% percent of total traffic), but 985 it is still strongly RECOMMENDED that an implementation provide 986 a buffer of user-configurable size Mode2_Max that can hold more 987 than a single Mode 2 message. If the message cannot be 988 buffered, the user data is discarded and the error MUST be 989 reported to the application. 991 3. If step 2 was completed without error, the newly generated 992 message MUST be sent to the IP address contained in its 993 destination address field, encapsulated within a UDP datagram. 994 If the UDP interface on the sending system reports an error to 995 SRT when the attempt to send the SRT message is made, an 996 implementation may attempt to resend the message any finite 997 number of times. However, every implementation MUST provide a 998 mode in which no retries are attempted. Implementations should 999 default to this latter mode of operation. The implementation 1000 MUST report to the application whether or not the message was 1001 ultimately accepted by UDP. 1003 4. If some user-configurable "ACK_Threshold" (which should be 1004 greater than the worst-case round-trip time for the multicast 1005 group) elapses without receipt of an ACK for the Mode 2 1006 message, it is retransmitted. An implementation may define a 1007 maximum number of retransmissions to be attempted before the 1008 Mode 2 message is removed from the buffer. 1010 5.3.2 Receiving Mode 2 Data messages 1012 When a Mode 2 data message is received by SRT it should be processed 1013 as follows after verifying Version, DataID, sender address, and SN: 1015 1. For Mode 2 messages, the sequence number field is used to 1016 associate the required positive acknowledgement with a specific 1017 Mode 2 message. If the message passes verification, the 1018 encapsulated user data is delivered to all applications that 1019 have indicated interest in the DataID and multicast address of 1020 the received message, regardless of the value of the SN field. 1022 2. Additionally, an ACK MUST be sent to the host from which the 1023 Mode 2 data message originated. See section 3.3.3. below for 1024 details. 1026 5.3.3 Sending a Positive Acknowledgement 1028 A positive acknowledgement (ACK) is triggered by the receipt of a 1029 Mode 2 data message. To send an ACK, a new SRT message is generated 1030 with version set to 0x02, message type set to 0x2, and transmission 1031 mode set to 0x2. DataID and SN are those of the Mode 2 data message 1032 being acknowledged. The destination address field is set to the 1033 source IP address from which the data message was received. Since 1034 Mode 2 data messages are unicast there is little concern about an 1035 ACK implosion causing excessive congestion at the original sender, 1036 so no suppression mechanism is necessary. 1038 5.3.4 Receiving a Positive Acknowledgement 1040 When an ACK is received by SRT, after verifying the transmission 1041 mode, DataID, and source IP address against outstanding Mode 2 1042 transmission SRT MUST remove the pending transmission from its 1043 buffer. 1045 6. RFC 2357 Analysis 1047 This section provides answers to the questions posed by RFC 2357 1048 for reliable multicast protocols, which are quoted. 1050 6.1 Scalability 1052 "How scalable is the protocol to the number of senders or receivers 1053 in a group, the number of groups, and wide dispersion of group 1054 members?" SRMP is intended to scale at least to hundreds of group 1055 members. It has been designed not to impose limitations on the 1056 scalability of the underlying multicast network. No problems have 1057 been identified in its mechanisms that would preclude this on 1058 uncongested networks. 1060 "Identify the mechanisms which limit scalability and estimate 1061 those limits." There is a practical concern with use of TFMCC, in 1062 that the receiver with the most congested path constraints delivery 1063 to the entire group. Distributed virtual simulation requires data 1064 delivery at rates perceived as continuous by humans. Therefore it 1065 may prove necessary to assign such receivers to different, lower- 1066 fidelity groups as a practical means of sustaining performance to 1067 the majority of participating hosts. SRMP does not have a mechanism 1068 to support such pruning at this time. 1070 6.2 Congestion 1072 "How does the protocol protect the Internet from congestion? How well 1073 does it perform? When does it fail? Under what circumstances will the 1074 protocol fail to perform the functions needed by the applications it 1075 serves? Is there a congestion control mechanism? How well does it 1076 perform? When does it fail?" Both simulations and tests indicate that 1077 SRMP with TFMCC displays backoff comparable to that of TCP under 1078 conditions of significant packet loss. The mechanism fails in a 1079 network-friendly way, in that under severe congestion it reduces 1080 sending of the best-effort traffic to a very small rate that typically 1081 is unsatisfactory to support a virtual simulation. This is possible 1082 because the reliable traffic typically is a few percent of the overall 1083 traffic and SRMP is NACK-oriented, with NACK suppression, so that 1084 reliable traffic loss adds little traffic to the total. If the traffic 1085 mix assumption is not met, the reliable traffic (which does not back 1086 off under increased RTT) could produce a higher level of traffic than 1087 a comparable TCP connection. However, levels of reliable traffic this 1088 large are not in the intended application domain of SRMP. 1090 "Include a description of trials and/or simulations which support 1091 the development of the protocol and the answers to the above 1092 questions." SRMP has been simulated using a discrete event simulator 1093 developed for academic use [5]. The design assumptions were validated 1094 by the results. It also has been emulated in a LAN-based cluster and 1095 application-tested in a wide-area testbed under its intended traffic 1096 mix (distributed virtual simulation) and using a traffic generator 1097 with losses emulated losses by random dropping of packets [6]. 1099 "Include an analysis of whether the protocol has congestion avoidance 1100 mechanisms strong enough to cope with deployment in the Global 1101 Internet, and if not, clearly document the circumstances in which 1102 congestion harm can occur. How are these circumstances to be 1103 prevented?" Because it provides sending backoff comparable to TCP, 1104 SRMP is able to function as well as TCP for congestion avoidance, 1105 even in the Global Internet. The only way an SRMP sender can generate 1106 congestion is to use the protocol for unintended purposes, for 1107 example reliable transmission of a large fraction of the traffic. 1108 Doing this would produce unsatisfactory results for the application, 1109 as SRMP's mechanism for providing reliability will not function well 1110 if the best-effort traffic is does not constitute the majority of the 1111 total traffic. 1113 "Include a description of any mechanisms which contain the traffic 1114 within limited network environments." SRMP has no such mechanisms, as 1115 it is intended for use over the open Internet. 1117 "Reliable multicast protocols must include an analysis of how they 1118 address a number of security and privacy concerns." See section 9 1119 below. 1121 7. IANA Considerations 1123 There are no IANA actions required for this document. 1125 8. Security Considerations 1127 As a transport protocol, SRMP is subject to denial of service by 1128 hostile third parties sending conflicting values of its parameters 1129 on the multicast address. SRMP could attempt to protect itself 1130 from this sort of behavior, however it can be shielded from such 1131 attacks by traffic authentication at the network layer, as decribed 1132 below. A comparable level of authentication also could be obtained 1133 by message using MD5 or a similar message hash in each bundle 1134 and using the SRMP bundle header to detect duplicate transmissions 1135 from a given host, however this would duplicate the function of 1136 existing network layer authentication protocols. 1138 Specific threats that can be eliminated by packet-level 1139 authentication are: 1141 a. Amplification Attack: SRMP receivers could be manipulated into 1142 sending large amounts of NACK traffic which could cause network 1143 congestion or overwhelm the processing capabilities of a sender. 1144 This could be done by sending them faked traffic indicating that 1145 a reliable transmission has been lost. SRMP's NACK suppression 1146 limits the effect of such manipulation, however true protection 1147 requires authentication of each bundle. 1149 b. Denial of service attack: if an SRMP sender accepts a large 1150 number of forged NACKS, it will flood the multicast group with 1151 repair messages. This attack also is stopped by per-bundle 1152 authentication. 1154 c. Replay Attack: the attacker could copy a valid, authenticated 1155 bundle containing a NACK and send it repeatedly to the original 1156 sender of the NACKed data. Protection against this attack requires 1157 a sequence number per transmission per source host. The SRMP bundle 1158 header sequence number would satisfy this need, however the SN also 1159 can be applied at a lower layer. 1161 d. Reverse Path Forwarding Attack (spoofing): if checks are not 1162 enabled in all network routers and switches along the path from 1163 each sender to all receivers, forged packets can be injected into 1164 the multicast tree data path to manipulate the protocol into sending 1165 large volume of repairs. Packet-level authentication can eliminate 1166 this possibility. 1168 e. Inadvertent errors: A receiver with an incorrect or corrupted 1169 implementation of TFMCC could respond with values of RTT that might 1170 stimulate a TFMCC sender to create or increase congestion in the 1171 path to that sender. It is therefore RECOMMENDED that receivers be 1172 required to identify themselves as legitimate before they receive 1173 the Session Description needed to join the session. How receivers 1174 identify themselves as legitimate is outside the scope of this 1175 document. 1177 The required authentication could become part of SRMP or could be 1178 accomplished by a lower layer protocol. In any case it needs to be 1179 (1) scalable and (2) not very computationally demanding so it can be 1180 performed with minimal delay on a real-time virtual simulation 1181 stream. Public-key encryption meets the first requirement but not 1182 the second. Using the IPSEC Authentication Header (AH) (RFC 2402 [9]) 1183 meets the second requirement using symmetric-key cryptography. 1184 However, RFC 2402 guidance is that a separate Security Association 1185 (SA) should be established for each sender-receiver pair so that 1186 no host in the group can spoof traffic from another source. This 1187 approach is not scalable over a large number of multicast group 1188 members. Moving the authentication function to SRMP would introduce 1189 the same problem. If the policy is to trust all hosts that are 1190 legitimate senders, IPSEC AH with one SA per multicast group meets 1191 both requirements. If the guidance in RFC 2402 is treated as 1192 policy, no scalable solution is known to exist. In practice, users of 1193 distributed simulation are likely to work over a (possibly virtual) 1194 private network and thus not to need special authentication for SRMP. 1195 For those who do not, it is RECOMMENDED that users of SRMP over the 1196 open Internet should use the IPSEC AH but in so doing must accept 1197 the risk of the unlikely case where a member of the trusted group of 1198 hosts undertakes an attack on the group by masquerading as another 1199 group member. 1201 9. List of acronyms used 1203 ACK - positive acknowledgement 1204 AH - Authentication Header 1205 CLR - current limiting receiver 1206 IPSEC - Internet Protocol Security 1207 MTU - maximum transmission unit 1208 NACK - negative acknowledgement 1209 RTT - round-trip time 1210 SA - security association 1211 SRMP - Selectively Reliable Multicast Procotol 1212 SRT - Selectively Reliable Transport 1213 TFMCC - TCP Friendly Multicast Congestion Control 1215 10. Authors' Addresses 1217 J. Mark Pullen 1218 C3I Center 1219 George Mason University 1220 Fairfax, VA 22030 1221 USA 1222 mpullen@gmu.edu 1224 Babu Shanmugam 1225 C3I Center 1226 George Mason University 1227 Fairfax, VA 22030 1228 USA 1229 bshanmug@netlab.gmu.edu 1231 Fei Zhao 1232 C3I Center 1233 George Mason University 1234 Fairfax, VA 22030 1235 USA 1236 fzhao@netlab.gmu.edu 1237 Danny Cohen 1238 Sun Microsystems 1239 6601 Center Drive West 1240 Los Angeles, CA 90045 1241 USA 1242 danny.cohen@sun.com 1244 11. References 1246 11.1 Informative references 1248 [1] J. M. Pullen, J.M., M. Myjak, and C. Bouwens, "Limitations of 1249 Internet Protocol Suite for Distributed Simulation in the Large 1250 Multicast Environment," Internet Engineering Task Force 1251 Informational RFC 2502, Internet Society, 1999 1253 [2] J. Padhye, V. Firoiu, D. Towsley and J. Kurose, "Modeling TCP 1254 Throughput: A Simple Model and its Empirical Validation", 1255 Proceedings of ACM SIGCOMM 1998 1257 [3] A. Mankin, A. Romanow, S. Bradner, and V. Paxson, "IETF Criteria for 1258 Evaluating Reliable Multicast Transport and Application Protocols," 1259 Internet Engineering Task Force Informational RFC 2357, Internet 1260 Society, 1998 1262 [4] S. Floyd, "Congestion Control Principles", Internet Engineering 1263 Task Force Best Current Practice RFC 2914, Internet Society, 1999 1265 [5] J. M. Pullen, "The Network Workbench: Network Simulation Software 1266 for Academic Investigation of Internet Concepts," Computer Networks 1267 Vol 32 No 3 pp 365-378, March 2000 1269 [6] J. M. Pullen, R. Simon, F. Zhao and W. Chang, "NGI-FOM over RTI-NG 1270 and SRMP: Lessons Learned," Proceedings of the IEEE Fall Simulation 1271 Interoperability Workshop, paper 03F-SIW-111, Orlando, FL, September 1272 2003 1274 11.2 Normative references 1276 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1277 Levels, Internet Engineering Task Force RFC 2119, Internet Society, 1278 1997 1280 [8] J. Widmer and M. Handley, "TCP-Friendly Multicast Congestion 1281 Control (TFMCC): Protocol Specification", work in progress, IETF 1282 Reliable Multicast Transport Working Group, October 2004 1284 [9] S. Kent and R. Atkinson, IP Authentication Header, Internet 1285 Engineering Task Force Standards Track RFC 2402, November 1998 1287 12. Full Copyright Statement 1289 Copyright (C) The Internet Society (2005). 1291 This document is subject to the rights, licenses and restrictions 1292 contained in BCP 78, and except as set forth therein, the authors 1293 retain all their rights. 1295 This document and the information contained herein are provided 1296 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1297 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1298 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1299 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1300 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1301 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1302 PARTICULAR PURPOSE.