idnits 2.17.1 draft-irtf-dtnrg-ltp-motivation-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1031. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1008. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1015. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1021. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3448 (ref. 'TFRC') (Obsoleted by RFC 5348) -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. 'SCTP') (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay Tolerant Networking Research Group S. Burleigh 3 Internet Draft NASA/Jet Propulsion Laboratory 4 Intended Status: Informational M. Ramadas 5 Ohio University 6 June 24 2008 S. Farrell 7 Expires December 24 2008 Trinity College Dublin 9 Licklider Transmission Protocol - Motivation 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in 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 This Internet-Draft will expire on March 17, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document describes the motivation for the development of the 43 Licklider Transmission Protocol (LTP) designed to provide 44 retransmission-based reliability over links characterized by 45 extremely long message round-trip times (RTTs) and/or frequent 46 interruptions in connectivity. Since communication across 47 interplanetary space is the most prominent example of this sort of 48 environment, LTP is principally aimed at supporting "long-haul" 49 reliable transmission in interplanetary space, but it has 50 applications in other environments as well. 52 In an Interplanetary Internet setting deploying the Bundle protocol, 53 LTP is intended to serve as a reliable convergence layer over single 54 hop deep-space RF links. LTP does Atomatic Repeat reQuest (ARQ) of 55 data transmissions by soliciting selective-acknowledgment reception 56 reports. It is stateful and has no negotiation or handshakes. 58 This document is a product of the Delay Tolerant Networking Research 59 Group and has been reviewed by that group. No objections to its 60 publication as an RFC were raised. 62 Table of Contents 64 1. Introduction ................................................. 2 65 2. Problem ...................................................... 3 66 2.1 IPN Operating Environment ................................... 3 67 2.2 Why not TCP or SCTP? ........................................ 5 68 3. Protocol Overview ............................................. 6 69 3.1 Nominal Operation ........................................... 6 70 3.1.1 Link state cues ........................................... 9 71 3.1.2 Deferred transmission ..................................... 9 72 3.1.3 Timers .................................................... 10 73 3.2 Retransmission .............................................. 13 74 3.3 Accelerated Retransmission .................................. 16 75 3.4 Session Cancellation ........................................ 17 76 4. Security Considerations ....................................... 18 77 5. IANA Considerations .......................................... 20 78 6. Acknowledgments .............................................. 20 79 7. References ................................................... 21 80 7.1 Informative References ....................................... 21 81 8. Author's Addresses ........................................... 22 83 1. Introduction 85 The Licklider Transmission Protocol (LTP) is designed to provide 86 retransmission-based reliability over links characterized by 87 extremely long message round-trip times and/or frequent interruptions 88 in connectivity. Communication in interplanetary space is the most 89 prominent example of this sort of environment, and LTP is principally 90 aimed at supporting "long-haul" reliable transmission over deep-space 91 RF links. Specifically, LTP is intended to serve as a reliable 92 "convergence layer" protocol, underlying the Delay-Tolerant 93 Networking [DTN] Bundle protocol [BP], in DTN deployments where 94 datalinks are characterized by very long round-trip times. 96 This document describes the motivation for LTP, its features, 97 functions, and overall design. It is part of a series of documents 98 describing LTP. Other documents in the series include the main 99 protocol specification document [LTPSPEC] and the protocol extensions 100 document [LTPEXT] respectively. 102 The protocol is named in honor of ARPA/Internet pioneer JCR 103 Licklider. 105 2. Problem 107 2.1 IPN Operating Environment 109 There are a number of fundamental differences between the environment 110 for terrestrial communications (such as seen in the Internet) and the 111 operating environments envisioned for the Interplanetary Internet 112 (IPN). [IPN] 114 The most challenging difference between communication among points on 115 Earth and communication among planets is round-trip delay, of which 116 there are two main sources, both relatively intractable: physics and 117 economics. 119 The more obvious type of delay imposed by nature is signal 120 propagation time. Round-trip times between Earth and Jupiter's moon 121 Europa, for example, run between 66 and 100 minutes. 123 Less obvious and more dynamic is the delay imposed by occultation. 124 Communication between planets must be by radiant transmission, which 125 is usually possible only when the communicating entities are in line 126 of sight of each other. During the time that communication is 127 impossible, delivery is impaired and messages must wait in a queue 128 for later transmission. 130 Round-trip times and occultations can at least be readily computed 131 given the ephemerides of the communicating entities. Additional 132 delay that is less easily predictable is introduced by discontinuous 133 transmission support, which is rooted in economics. 135 Communicating over interplanetary distances requires expensive 136 special equipment: large antennas, high-performance receivers, etc. 138 For most deep-space missions, even non-NASA ones, these are currently 139 provided by NASA's Deep Space Network (DSN) [DSN]. The communication 140 resources of the DSN are currently oversubscribed and will probably 141 remain so for the foreseeable future. Radio contact via the DSN must 142 therefore be carefully scheduled and is often severely limited. 144 This over-subscription means that the round-trip times experienced by 145 packets will be affected not only by the signal propagation delay and 146 occultation, but also by the scheduling and queuing delays imposed by 147 the management of Earth-based resources: packets to be sent to a 148 given destination may have to be queued until the next scheduled 149 contact period, which may be hours, days, or even weeks away. 151 These operating conditions imply a number of additional constraints 152 on any protocol designed to assure reliable communication over deep 153 space links. 155 - Long round-trip times mean substantial delay between the 156 transmission of a block of data and the reception of an 157 acknowledgment from the block's destination, signaling arrival of 158 the block. If LTP postponed transmission of additional blocks of 159 data until it received acknowledgment of the arrival of all prior 160 blocks, valuable opportunities to utilize what little deep space 161 transmission bandwidth is available would be forever lost. 162 Multiple parallel data block transmission "sessions" must be in 163 progress concurrently in order to avoid under-utilization of the 164 links. 166 - Like any reliable transport service employing ARQ, LTP is 167 "stateful". In order to assure the reception of a block of data 168 it has sent, LTP must retain for possible retransmission all 169 portions of that block which might not have been received yet. In 170 order to do so, it must keep track of which portions of the block 171 are known to have been received so far and which are not, together 172 with any additional information needed for purposes of 173 retransmitting part or all of that block. 175 - In the IPN, round-trip times may be so long and communication 176 opportunities so brief that a negotiation exchange, such as an 177 adjustment of transmission rate, might not be completed before 178 connectivity is lost. Even if connectivity is uninterrupted, 179 waiting for negotiation to complete before revising data 180 transmission parameters might well result in costly under- 181 utilization of link resources. 183 - Another respect in which LTP differs from TCP is that, while TCP 184 connections are bidirectional (blocks of application data may be 185 flowing in both directions on any single connection), LTP sessions 186 are unidirectional. This design decision derives from the fact 187 that the flow of data in deep space flight missions is usually 188 unidirectional. (Long round trip times make interactive 189 spacecraft operation infeasible, so spacecraft are largely 190 autonomous and command traffic is very light.) Bidirectional data 191 flow, where possible, is performed using two unidirectional links 192 in opposite directions and at different data rates. 194 - Finally, the problem of timeout interval computation in the 195 environment for which LTP is mainly intended is different from the 196 analogous problem in the Internet. Since multiple sessions can be 197 conducted in parallel, retardation of transmission on any single 198 session while awaiting a timeout need not degrade communication 199 performance on the association as a whole. Timeout intervals that 200 would be intolerably optimistic in TCP don't necessarily degrade 201 LTP's bandwidth utilization. 203 But the reciprocal half-duplex nature of LTP communication makes 204 it infeasible to use statistical analysis of round-trip history as 205 a means of predicting round-trip time. The round-trip time for 206 transmitted segment N could easily be orders of magnitude greater 207 than that for segment N-1 if there happened to be a transient loss 208 of connectivity between the segment transmissions. A different 209 mechanism for timeout interval computation is needed. 211 2.2 Why not TCP or SCTP? 213 These environmental characteristics - long and highly variable 214 delays, intermittent connectivity, and relatively high error rates - 215 make using unmodified TCP for end-to-end communications in the IPN 216 infeasible. Using the TCP throughput equation from [TFRC] we can 217 calculate the loss event rate (p) required to achieve a given steady- 218 state throughput. Assuming the minimum RTT to Mars from planet Earth 219 is 8 minutes (one-way speed of light delay to Mars at its closest 220 approach to Earth is 4 minutes), assuming a packet size of 1500 221 bytes, assuming that the receiver acknowledges every other packet, 222 and ignoring negligible higher order terms in p (i.e., ignoring the 223 second additive term in the denominator of the TCP throughput 224 equation), we obtain the following table of loss event rates required 225 to achieve various throughput values. 227 Throughput Loss event rate (p) 228 ---------- ------------------- 229 10 Mbps 4.68 * 10^(-12) 230 1 Mbps 4.68 * 10^(-10) 231 100 Kbps 4.68 * 10^(-8) 232 10 Kbps 4.68 * 10^(-6) 234 Note that although multiple losses encountered in a single RTT are 235 treated as a single loss event in the TCP throughput equation [TFRC], 236 such loss event rates are still unrealistic on deep space links. 238 For the purposes of this discussion we are not considering the more 239 aggressive TCP throughput equation that characterizes HighSpeed TCP. 240 [HSTCP] 242 The TCP characteristic of an initial three-way handshake for each new 243 connection, followed by slow-start, is a further obstacle, because 244 the delay of the three-way handshake and the additional delay of 245 slow-start could be exhorbitant in a long-delay environment. 247 The SCTP [SCTP] protocol can multiplex "chunks" (units of application 248 data) for multiple sessions over a single layer connection (called an 249 'association' in SCTP terminology) as LTP does, but it still requires 250 multiple round trips prior to transmitting application data for 251 session setup and so clearly does not suit the needs of the IPN 252 operating environment. 254 3. Protocol Overview 256 3.1 Nominal Operation 258 The nominal sequence of events in an LTP transmission session is as 259 follows. 261 Operation begins when a client service instance asks an LTP engine to 262 transmit a block of data to a remote client service instance. 264 LTP regards each block of data as comprising two parts: a "red-part", 265 whose delivery must be assured by acknowledgment and retransmission 266 as necessary, followed by a "green-part" whose delivery is attempted, 267 but not assured. The length of either part may be zero; that is, any 268 given block may be designated entirely red (retransmission continues 269 until reception of the entire block has been asserted by the 270 receiver) or entirely green (no part of the block is acknowledged or 271 retransmitted). Thus LTP can provide both TCP-like and UDP-like 272 functionality concurrently on a single session. 274 Note that in a red-green block transmission, the red-part data does 275 NOT have any urgency or higher-priority semantics relative to the 276 block's green-part data. The red-part data is merely data for which 277 the user has requested reliable transmission, possibly (though not 278 necessarily) data without which the green-part data may be useless, 279 such as an application-layer header or other metadata. 281 The client service instance uses the LTP's implementation's 282 application programming interface to specify to LTP the identity of 283 the remote client service instance to which the data must be 284 transmitted, the location of the data to be transmitted, the total 285 length of data to be transmitted, and the number of leading data 286 bytes that are to be transmitted reliably as "red" data. The sending 287 engine starts a transmission session for this block and notifies the 288 client service instance that the session has been started. Note that 289 LTP communication session parameters are not negotiated but are 290 instead asserted unilaterally, subject to application-level network 291 management activity; the sending engine does not negotiate the start 292 of the session with the remote client service instance's engine. 294 The sending engine then initiates the original transmission: it 295 queues for transmission as many data segments as are necessary to 296 transmit the entire block, within the constraints on maximum segment 297 size imposed by the underlying communication service. The last 298 segment of the red-part of the block is marked as the End of Red-Part 299 (EORP) indicating the end of red-part data for the block, and as a 300 checkpoint (identified by a unique checkpoint serial number) 301 indicating that the receiving engine must issue a reception report 302 upon receiving the segment. The last segment of the block overall is 303 marked End of Block (EOB) indicating that the receiving engine can 304 calculate the size of the block by summing the offset and length of 305 the data in the segment. 307 LTP is designed to run directly over a data-link layer protocol, but 308 it may instead be deployed directly over UDP in some casees, (i.e. 309 for software development or in private local area networks). In 310 either case, the protocol layer immediately underlying LTP is here 311 referred to as the "local data-link layer". 313 At the next opportunity, subject to allocation of bandwidth to the 314 queue into which the block data segments were written, the enqueued 315 segments and their lengths are passed to the local data-link layer 316 protocol (which might be UDP/IP) via the API supported by that 317 protocol, for transmission to the LTP engine serving the remote 318 client service instance. 320 A timer is started for the EORP, so that it can be retransmitted 321 automatically if no response is received. 323 The content of each local data-link layer protocol data unit (link- 324 layer frame or UDP datagram) is required to be an integral number of 325 LTP segments, and the local data-link layer protocol is required 326 never to deliver incomplete LTP segments to the receiving LTP engine. 327 When the local data-link layer protocol is UDP, the LTP 328 authentication [LTPEXT] extension should be used to assure data 329 integrity unless the end-to-end path is one in which either the 330 likelihood of datagram content corruption is negligible (as in some 331 private local area networks) or the consequences of receiving and 332 processing corrupt LTP segments are insignificant (as perhaps during 333 software development). When the LTP authentication extension is not 334 used, LTP requires the local data-link layer protocol to perform 335 integrity checking of all segments received; specifically, the local 336 data-link layer protocol is required to detect any corrupted segments 337 that are received and to discard them silently. 339 Received segments that are not discarded are passed up to the 340 receiving LTP engine via the API supported by the local data-link 341 layer protocol. 343 On reception of the first data segment for the block, the receiving 344 engine starts a reception session for this block and notifies the 345 local instance of the relevant client service that the session has 346 been started. In the nominal case it receives all segments of the 347 original transmission without error. Therefore on reception of the 348 EORP data segment it responds by (a) queuing for transmission to the 349 sending engine a report segment indicating complete reception and (b) 350 delivering the received red-part of the block to the local instance 351 of the client service; on reception of each data segment of the 352 green-part, it responds by immediately delivering the received data 353 to the local instance of the client service. 355 All delivery of data and protocol event notices to the local client 356 service instance is performed using the LTP implementation's 357 application programming interface. 359 Note that, since LTP data flows are unidirectional, LTP's data 360 acknowledgments - "reception reports" - can't be piggybacked on data 361 segments as in TCP. They are instead carried in a separate segment 362 type. 364 At the next opportunity, the enqueued report segment is immediately 365 transmitted to the sending engine and a timer is started so that the 366 report segment can be retransmitted automatically if no response is 367 received. 369 The sending engine receives the report segment, turns off the timer 370 for the EORP, enqueues for transmission to the receiving engine a 371 report-acknowledgment segment, and notifies the local client service 372 instance that the red-part of the block has been successfully 373 transmitted. The session's red-part transmission has now ended. 375 At the next opportunity, the enqueued report-acknowledgment segment 376 is immediately transmitted to the receiving engine. 378 The receiving engine receives the report-acknowledgment segment and 379 turns off the timer for the report segment. The session's red-part 380 reception has now ended and transmission of the block is complete. 382 3.1.1 Link state cues 384 Establishing a communication link across interplanetary distance 385 entails enacting several hardware configuration measures based on the 386 presumed operational state of the remote communicating entity like: 388 o orienting a directional antenna correctly; 390 o tuning a transponder to pre-selected transmission and/or 391 reception frequencies; 393 o diverting precious electrical power to the transponder at the 394 last possible moment, and for the minimum necessary length of 395 time. 397 We therefore assume that the operating environment in which LTP 398 functions is able to pass information on the link status (termed 399 "link state cues" in this document) to LTP, telling it which remote 400 LTP engine(s) should currently be transmitting to the local LTP 401 engine and vice versa. The operating environment itself must have 402 this information in order to configure communication link hardware 403 correctly. 405 3.1.2 Deferred transmission 407 Link state cues also notify LTP when it is and isn't possible to 408 transmit segments. In deep space communications, at no moment can 409 there ever be any expectation of two-way connectivity. It is always 410 possible for LTP to be generating outbound segments - in response to 411 received segments, timeouts, or requests from client services - that 412 cannot immediately be transmitted. These segments must be queued for 413 transmission at a later time when a link has been established, as 414 signaled by a link state cue. 416 In concept, every outbound LTP segment is appended to one of two 417 queues -- forming a queue-set -- of traffic bound for the LTP engine 418 that is that segment's destination. One such traffic queue is the 419 "internal operations queue" of that queue set; the other is the 420 application data queue for the queue set. The de-queuing of a 421 segment always implies delivering it to the underlying communication 422 system for immediate transmission. Whenever the internal operations 423 queue is non-empty, the oldest segment in that queue is the next 424 segment de-queued for transmission to the destination; at all other 425 times, the oldest segment in the application data queue is the next 426 segment de-queued for transmission to the destination. 428 The production and enqueuing of a segment and the subsequent actual 429 transmission of that segment are in principle wholly asynchronous. 431 In the event that (a) a transmission link to the destination is 432 currently active and (b) the queue to which a given outbound segment 433 is appended is otherwise empty and (c) either this queue is the 434 internal operations queue or else the internal operations queue is 435 empty, the segment will be transmitted immediately upon production. 436 Transmission of a newly queued segment is necessarily deferred in all 437 other circumstances. 439 Conceptually, the de-queuing of segments from traffic queues bound 440 for a given destination is initiated upon reception of a link state 441 cue indicating that the underlying communication system is now 442 transmitting to that destination, i.e., the link to that destination 443 is now active. It ceases upon reception of a link state cue 444 indicating that the underlying communication system is no longer 445 transmitting to that destination, i.e., the link to that destination 446 is no longer active. 448 3.1.3 Timers 450 LTP relies on accurate calculation of expected arrival times for 451 report and acknowledgment segments in order to know when proactive 452 retransmission is required. If a calculated time were even slightly 453 early, the result would be costly unnecessary retransmission. On the 454 other hand, calculated arrival times may safely be several seconds 455 late: the only penalties for late timeout and retransmission are 456 slightly delayed data delivery and slightly delayed release of 457 session resources. 459 Since statistics derived from round-trip history cannot safely be 460 used as a predictor of LTP round-trip times, we have to assume that 461 round-trip timing is at least roughly deterministic - i.e., that 462 sufficiently accurate RTT estimates can be computed individually in 463 real time from available information. 465 This computation is performed in two stages: 467 - We calculate a first approximation of RTT by simply doubling the 468 known one-way light time to the destination and adding an 469 arbitrary margin for any additional anticipated latency, such as 470 queuing and processing delay at both ends of the transmission. 471 For deep space operations, the margin value is typically a small 472 number of whole seconds. Although such a margin is enormous by 473 Internet standards, it is insignificant compared to the two-way 474 light time component of round-trip time in deep space. We choose 475 to risk tardy retransmission, which will postpone delivery of one 476 block by a relatively tiny increment, in preference to premature 477 retransmission, which will unnecessarily consume precious 478 bandwidth and thereby degrade overall performance. 480 - Then, to account for the additional delay imposed by interrupted 481 connectivity, we dynamically suspend timers during periods when 482 the relevant remote LTP engines are known to be unable to transmit 483 responses. This knowledge of the operational state of remote 484 entities is assumed to be provided by link state cues from the 485 operating environment. 487 The following discussion is the basis for LTP's expected arrival time 488 calculations. 490 The total time consumed in a single "round trip" (transmission and 491 reception of the original segment, followed by transmission and 492 reception of the acknowledging segment) has the following components: 494 Protocol processing time: The time consumed in issuing the 495 original segment, receiving the original segment, generating and 496 issuing the acknowledging segment, and receiving the acknowledging 497 segment. 499 Outbound queuing delay: The delay at the sender of the original 500 segment while that segment is in a queue waiting for transmission, 501 and delay at the sender of the acknowledging segment while that 502 segment is in a queue waiting for transmission. 504 Radiation time: The time that passes while all bits of the 505 original segment are being radiated, and the time that passes 506 while all bits of the acknowledging segment are being radiated. 507 (This is significant only at extremely low data transmission 508 rates.) 510 Round-trip light time: The signal propagation delay at the speed 511 of light, in both directions. 513 Inbound queuing delay: delay at the receiver of the original 514 segment while that segment is in a reception queue, and delay at 515 the receiver of the acknowledging segment while that segment is in 516 a reception queue. 518 Delay in transmission of the original segment or the acknowledging 519 segment due to loss of connectivity - that is, interruption in 520 outbound link activity at the sender of either segment due to 521 occultation, scheduled end of tracking pass, etc. 523 In this context, where errors on the order of seconds or even minutes 524 may be tolerated, protocol processing time at each end of the session 525 is assumed to be negligible. 527 Inbound queuing delay is also assumed to be negligible because, even 528 on small spacecraft, LTP processing speeds are high compared to data 529 transmission rates. 531 Two mechanisms are used to make outbound queuing delay negligible: 533 - The expected arrival time of an acknowledging segment is not 534 calculated until the moment the underlying communication system 535 notifies LTP that radiation of the original segment has begun. 536 All outbound queuing delay for the original segment has already 537 been incurred at that point. 539 - LTP's deferred transmission model minimizes latency in the 540 delivery of acknowledging segments (reports and acknowledgments) 541 to the underlying communication system; that is, acknowledging 542 segments are (in concept) appended to the internal operations 543 queue rather than the application data queue, so they have higher 544 transmission priority than any other outbound segments, i.e., they 545 should always be de-queued for transmission first. This limits 546 outbound queuing delay for a given acknowledging segment to the 547 time needed to de-queue and radiate all previously generated 548 acknowledging segments that have not yet been de-queued for 549 transmission. Since acknowledging segments are sent infrequently 550 and are normally very small, outbound queuing delay for a given 551 acknowledging segment is likely to be minimal. 553 Deferring calculation of the expected arrival time of the 554 acknowledging segment until the moment at which the original segment 555 is radiated has the additional effect of removing from consideration 556 any original segment transmission delay due to loss of connectivity 557 at the original segment sender. 559 Radiation delay at each end of the session is simply segment size 560 divided by transmission data rate. It is insignificant except when 561 data rate is extremely low (for example, 10 bps), in which case the 562 use of LTP may well be inadvisable for other reasons (LTP header 563 overhead for example, could be too much under such data rates). 564 Therefore radiation delay is normally assumed to be negligible. 566 We assume that one-way light time to the nearest second can always be 567 known (for example, provided by the operating environment). 569 So the initial expected arrival time for each acknowledging segment 570 is typically computed as simply the current time at the moment that 571 radiation of the original segment begins, plus twice the one-way 572 light time, plus 2*N seconds of margin to account for processing and 573 queuing delays and for radiation time at both ends. N is a parameter 574 set by network management for which 2 seconds seem to be a reasonable 575 default value. 577 This leaves only one unknown, the additional round trip time 578 introduced by loss of connectivity at the sender of the acknowledging 579 segment. To account for this, we again rely on external link state 580 cues. Whenever interruption of transmission at a remote LTP engine 581 is signaled by a link state cue, we suspend the countdown timers for 582 all acknowledging segments expected from that engine. Upon a signal 583 that transmission has resumed at that engine, we resume those timers 584 after (in effect) adding to each expected arrival time the length of 585 the timer suspension interval. 587 3.2 Retransmission 589 Loss or corruption of transmitted segments may cause the operation of 590 LTP to deviate from the nominal sequence of events described above. 592 Loss of one or more red-part data segments other than the EORP 593 segment triggers data retransmission: the receiving engine returns a 594 reception report detailing all the contiguous ranges of red-part data 595 received (assuming no discretionary checkpoints were received, which 596 are described below). The Reception Report is normally sent in a 597 single Report segment which carries a unique report serial number and 598 the scope of red-part data covered. For example, if the red-part 599 data covered block offsets [0:1000] and all but the segment in range 600 [500:600] were received, the report segment with a unique serial 601 number (say 100) and scope [0:1000] would carry two report entries: 602 (0:500) and (600:1000). The maximum size of a report segment, like 603 all LTP segments, is constrained by the datalink MTU; if many non- 604 contiguous segments were lost in a large block transmission and/or 605 the datalink MTU was relatively small, multiple report segments need 606 to be generated. In this case, LTP generates as many report segments 607 as are necessary and splits the scope of red-part data covered across 608 multiple report segments so that each of them may stand on their own. 609 For example, if three report segments are to be generated as part of 610 a reception report covering red-part data in range [0:1,000,000], 611 they could look like this: RS 19, scope [0:300,000], RS 20, scope 612 [300,000:950,000], and RS 21, scope [950,000:1,000,000]. In all 613 cases, a timer is started upon transmission of each report segment of 614 the reception report. 616 On reception of each report segment the sending engine responds as 617 follows: 619 - It turns off the timer for the checkpoint referenced by the 620 report segment, if any. 622 - It enqueues a reception-acknowledgment segment acknowledging the 623 report segment (to turn off the report retransmission timer at the 624 receiving engine). This segment is sent immediately at the next 625 transmission opportunity. 627 - If the reception claims in the report segment indicate that not 628 all data within the scope have been received, it normally 629 initiates a retransmission by enqueuing all data segments not yet 630 received. The last such segment is marked as a checkpoint and 631 contains the report serial number of the report segment to which 632 the retransmission is a response. These segments are likewise 633 sent at the next transmission opportunity, but only after all data 634 segments previously queued for transmission to the receiving 635 engine have been sent. A timer is started for the checkpoint, so 636 that it can be retransmitted automatically if no responsive report 637 segment is received. 639 - On the other hand, if the reception claims in the report segment 640 indicate that all data within the scope of the report segment have 641 been received, and the union of all reception claims received so 642 far in this session indicates that all data in the red-part of the 643 block have been received, then the sending engine notifies the 644 local client service instance that the red-part of the block has 645 been successfully transmitted; the session's red-part transmission 646 has ended. 648 On reception of a report-acknowledgment segment, the receiver turns 649 off the timer for the referenced report segment. On reception of a 650 checkpoint segment with a non-zero report serial number, the 651 receiving engine responds as follows : 653 - It returns a reception report comprising as many report segments 654 as are needed in order to report in detail on all data reception 655 within the scope of the referenced report segment, and a timer is 656 started for each report segment. 658 - If at this point all data in the red-part of the block have been 659 received, the receiving engine delivers the received block's red- 660 part to the local instance of the client service and, upon 661 reception of reception-acknowledgment segments acknowledging all 662 report segments, the session's red-part reception ends and 663 transmission of the block is complete. Otherwise the data 664 retransmission cycle continues. 666 Loss of a checkpoint segment or the report segment generated in 667 response causes timer expiry; when this occurs, the sending engine 668 normally retransmits the checkpoint segment. Similarly, the loss of 669 a report segment or the corresponding report-acknowledgment segment 670 causes the report segment's timer to expire; when this occurs, the 671 receiving engine normally retransmits the report segment. 673 Note that the redundant reception of a report segment (i.e., one that 674 was already received and processed by the sender), retransmitted due 675 to loss of the corresponding report-acknowledgment segment for 676 example, causes another report-acknowledgment segment to be 677 transmitted in response but is otherwise ignored; if any of the data 678 segments retransmitted in response to the original reception of the 679 report segment were lost, further retransmission of those data 680 segments will be requested by the reception report generated in 681 response to the last retransmitted data segment marked as a 682 checkpoint. Thus unnecessary retransmission is suppressed. 684 Note also that the responsibility for responding to segment loss in 685 LTP is shared between the sender and receiver of a block: the sender 686 retransmits checkpoint segments in response to checkpoint timeouts, 687 and retransmits missing data in response to reception reports 688 indicating incomplete reception, while the receiver retransmits 689 report segments in response to timeouts. An alternative design would 690 have been to make the sender responsible for all retransmission, in 691 which case the receiver would not expect report-acknowledgment 692 segments and would not retransmit report segments. There are two 693 disadvantages to this approach: 695 First, because of constraints on segment size that might be imposed 696 by the underlying communication service, it is at least remotely 697 possible that the response to any single checkpoint might be multiple 698 report segments. An additional sender-side mechanism for detecting 699 and appropriately responding to the loss of some proper subset of 700 those reception reports would be needed. We believe that the current 701 design is simpler. 703 Second, an engine that receives a block needs a way to determine when 704 the session can be closed. In the absence of explicit final report 705 acknowledgment (which entails retransmission of the report in case of 706 the loss of the report acknowledgment), the alternatives are (a) to 707 close the session immediately on transmission of the report segment 708 that signifies complete reception and (b) to close the session on 709 receipt of an explicit authorization from the sender. In case (a), 710 loss of the final report segment would cause retransmission of a 711 checkpoint by the sender, but the session would no longer exist at 712 the time the retransmitted checkpoint arrived; the checkpoint could 713 reasonably be interpreted as the first data segment of a new block, 714 most of which was lost in transit, and the result would be redundant 715 retransmission of the entire block. In case (b), the explicit 716 session termination segment and the responsive acknowledgment by the 717 receiver (needed in order to turn off the timer for the termination 718 segment, which in turn would be needed in case of in- transit loss or 719 corruption of the termination segment) would somewhat complicate the 720 protocol, increase bandwidth consumption, and retard the release of 721 session state resources at the sender. Here again we believe that 722 the current design is simpler and more efficient. 724 3.3 Accelerated Retransmission 726 Data segment retransmission occurs only on receipt of a report 727 segment indicating incomplete reception; report segments are normally 728 transmitted only at the end of original transmission of the red-part 729 of a block or at the end of a retransmission. For some applications 730 it may be desirable to trigger data segment retransmission 731 incrementally during the course of red-part original transmission so 732 that the missing segments are recovered sooner. This can be 733 accomplished in two ways: 735 - Any red-part data segment prior to the EORP can additionally be 736 flagged as a checkpoint. Reception of each such "discretionary" 737 checkpoint causes the receiving engine to issue a reception 738 report. 740 - At any time during the original transmission of a block's red- 741 part (that is, prior to reception of any data segment of the 742 block's green-part), the receiving engine can unilaterally issue 743 additional asynchronous reception reports. Note that the CFDP 744 protocol's "Immediate" mode is an example of this sort of 745 asynchronous reception reporting. [CFDP] The reception reports 746 generated for accelerated retransmission are processed in exactly 747 the same way as the standard reception reports. 749 3.4 Session Cancellation 751 A transmission session may be canceled by either the sending or the 752 receiving engine in response either to a request from the local 753 client service instance or to an LTP operational failure as noted 754 earlier. Session cancellation is accomplished as follows. 756 The canceling engine deletes all currently queued segments for the 757 session and notifies the local instance of the affected client 758 service that the session is canceled. If no segments for this 759 session have yet been sent to or received from the corresponding LTP 760 engine, then at this point the canceling engine simply closes its 761 state record for the session and cancellation is complete. 763 Otherwise, a session cancellation segment is queued for transmission. 764 At the next opportunity, the enqueued cancellation segment is 765 immediately transmitted to the LTP engine serving the remote client 766 service instance. A timer is started for the segment, so that it can 767 be retransmitted automatically if no response is received. 769 The corresponding engine receives the cancellation segment, enqueues 770 for transmission to the canceling engine a cancellation- 771 acknowledgment segment, deletes all other currently queued segments 772 for the indicated session, notifies the local client service instance 773 that the block has been canceled, and closes its state record for the 774 session. 776 At the next opportunity, the enqueued cancellation-acknowledgment 777 segment is immediately transmitted to the canceling engine. 779 The canceling engine receives the cancellation-acknowledgment, turns 780 off the timer for the cancellation segment, and closes its state 781 record for the session. 783 Loss of a cancellation segment or of the responsive cancellation- 784 acknowledgment causes the cancellation segment timer to expire. When 785 this occurs, the canceling engine retransmits the cancellation 786 segment. 788 4. Security Considerations 790 There is a clear risk that unintended receivers can listen in on LTP 791 transmissions over satellite and other radio broadcast datalinks. 792 Such unintended recipients of LTP transmissions may also be able to 793 manipulate LTP segments at will. 795 Hence there is a potential requirement for confidentiality, integrity 796 and anti-DoS (Denial of Service) security services and mechanisms. 798 In particular, DoS problems are more severe for LTP compared to 799 typical Internet protocols because LTP inherently retains state for 800 long periods and has very long time-out values. Further, it could be 801 difficult to reset LTP nodes to recover from an attack. Thus any 802 adversary who can actively attack an LTP transmission has the 803 potential to create severe DoS conditions for the LTP receiver. 805 To give a terrestrial example: were LTP to be used in a sparse sensor 806 network, DoS attacks could be mounted resulting in nodes missing 807 critical information, such as communications schedule updates. In 808 such cases, a single successful DoS attack could take a node entirely 809 off the network until the node was physically visited and reset. 811 Even for deep space applications of LTP we need to consider certain 812 terrestrial attacks, in particular those involving insertion of 813 messages into an on-going session (usually without having seen the 814 exact bytes of the previous messages in the session). Such attacks 815 are likely in the presence of firewall failures at various nodes in 816 the network, or due to Trojan software running on an authorized host. 817 Many message insertion attacks will depend on the attacker correctly 818 "guessing" something about the state of the LTP peers, but experience 819 shows that successful guesses are easier than might be thought [DDJ]. 821 We now consider the appropriate layer(s) at which security mechanisms 822 can be deployed to increase the security properties of LTP, and the 823 trade-offs entailed in doing so. 825 The Application layer (above-LTP) 826 Higher layer security mechanisms clearly protect LTP payload, but 827 leave LTP headers open. Such mechanisms provide little or no 828 protection against DoS type attacks against LTP, but may well 829 provide sufficient data integrity and ought to be able to provide 830 data confidentiality. 832 The LTP layer 834 An authentication header (similar to IPsec [AH]) can help protect 835 against replay attacks and other bogus packets. However, an 836 adversary may still see the LTP header of segments passing by in 837 the ether. This approach also requires some key management 838 infrastructure to be in place in order to provide strong 839 authentication, which may not always be an acceptable overhead. 840 Such an authentication header could mitigate many DoS attacks. 842 Similarly, a confidentiality service could be defined for LTP 843 payload and (some) header fields. However, this seems less 844 attractive since (a) confidentiality is arguably better provided 845 either above or below the LTP layer, (b) key management for such a 846 service is harder (in a high-delay context) than for an integrity 847 service, and (c) forcing LTP engines to attempt decryption of 848 incoming segments can in itself provide a DoS opportunity. 850 Further, within the LTP layer we can make various design decisions 851 to reduce the probability of successful DoS attacks. In 852 particular, we can mandate that values for certain fields in the 853 header (session numbers, for example) be chosen randomly. 855 The Datalink layer (below-LTP) 857 The lower layers can clearly provide confidentiality and integrity 858 services, although such security may result in unnecessary 859 overhead if the cryptographic service provided is not required for 860 all data. For example, it can be harder to manage lower layers so 861 that only the data that requires encryption is in fact encrypted. 862 Encrypting all data could represent a significant overhead for 863 some LTP use cases. However, the lower layers are often the place 864 where compression and error-correction is done, and so may well 865 also be the optimal place to do encryption since the same issues 866 with applying or not applying the service apply to both encryption 867 and compression. 869 In light of these considerations, LTP includes the following security 870 mechanisms: 872 The optional LTP Authentication mechanism is an LTP segment 873 extension comprising a ciphersuite identifier and optional key 874 identifier that precede the segment's content, plus an 875 authentication value (either a message authentication code or a 876 digital signature) that follows the segment's content; the 877 ciphersuite ID is used to indicate the length and format of the 878 authentication value. The authentication mechanism serves to 879 assure the segment's integrity and, depending on the ciphersuite 880 selected and the key management regime, its authenticity. 882 The optional LTP Cookie mechanism is an LTP segment extension 883 comprising a "cookie" -- a randomly chosen numeric value -- that 884 precedes the segment's content. By increasing the number of bytes 885 in a segment that cannot be easily predicted by an inauthentic 886 data source, and by requiring that segments lacking the correct 887 values of these bytes be silently discarded, the cookie mechanism 888 increases the difficulty of mounting a successful denial-of- 889 service attack on an LTP engine. 891 The above mechanisms are defined in detail in the LTP Extensions 892 document [LTPEXT]. 894 In addition, the serial numbers of LTP checkpoints and reports are 895 required to be randomly chosen integers, and implementors are 896 encouraged to choose session numbers randomly as well. This 897 randomness adds a further increment of protection agains DoS 898 attacks. See [PRNG] for recommendations related to randomness. 900 5. IANA Considerations 902 Please see the IANA Considerations sections of [LTPSPEC, LTPEXT]. 904 6. Acknowledgments 906 Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian 907 Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for 908 their thoughts on this protocol and its role in Delay-Tolerant 909 Networking architecture. 911 Part of the research described in this document was carried out at 912 the Jet Propulsion laboratory, California Institute of Technology, 913 under a contract with the National Aeronautics and Space 914 Administration. This work was performed under DOD Contract DAA-B07- 915 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; 916 and NASA Contract NAS7-1407. 918 Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel Myers 919 at Ohio University for their suggestions and advice in making various 920 design decisions. 922 Part of this work was carried out at Trinity College Dublin as part 923 of the SeNDT contract funded by Enterprise Ireland's research 924 innovation fund. 926 7. References 928 7.1 Informative References 930 [LTPSPEC] Ramadas, M., Burleigh, S., and Farrell, S., "Licklider 931 Transmission Protocol - Specification", draft-irtf-dtnrg-ltp-10.txt 932 (Work in Progress), June 2008. 934 [LTPEXT] Farrell, S., Ramadas, M., and Burleigh, S., "Licklider 935 Transmission Protocol - Security Extensions", draft-irtf-dtnrg-ltp- 936 extensions-08.txt (Work in Progress), June 2008. 938 [AH] S. Kent, "IP Authentication Header", RFC 4302, December 2005. 940 [BP] K. Scott, and S. Burleigh, "Bundle Protocol Specification", RFC 941 5050, November 2007. 943 [CFDP] CCSDS File Delivery Protocol (CFDP). Recommendation for Space 944 Data System Standards, CCSDS 727.0-B-2 BLUE BOOK Issue 1, October 945 2002. 947 [DDJ] I. Goldberg and E. Wagner, "Randomness and the Netscape 948 Browser", Dr. Dobb's Journal, 1996, (pages 66-70). 950 [DSN] Deep Space Mission Systems Telecommunications Link Design 951 Handbook (810-005) web-page, 952 "http://eis.jpl.nasa.gov/deepspace/dsndocs/810-005/" 954 [DTN] K. Fall, "A Delay-Tolerant Network Architecture for Challenged 955 Internets", In Proceedings of ACM SIGCOMM 2003, Karlsruhe, Germany, 956 Aug 2003. 958 [IPN] InterPlanetary Internet Special Interest Group web page, 959 "http://www.ipnsig.org". 961 [TFRC] M. Handley, S. Floyd, J. Padhye, and J. Widmer, "TCP Friendly 962 Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003. 964 [HSTCP] S. Floyd, "HighSpeed TCP for Large Congestion Windows", RFC 965 3649, December 2003. 967 [SCTP] R. Stewart et al, "Stream Control Transmission Protocol", RFC 968 4960, September 2007. 970 [PRNG] D. Eastlake et al, "Randomness Requirements for Security", RFC 971 4086, June 2005. 973 8. Author's Addresses 975 Scott C. Burleigh 976 Jet Propulsion Laboratory 977 4800 Oak Grove Drive 978 M/S: 301-485B 979 Pasadena, CA 91109-8099 980 Telephone +1 (818) 393-3353 981 FAX +1 (818) 354-1075 982 Email Scott.Burleigh@jpl.nasa.gov 984 Manikantan Ramadas 985 Internetworking Research Group 986 301 Stocker Center 987 Ohio University 988 Athens, OH 45701 989 Telephone +1 (740) 593-1562 990 Email mramadas@irg.cs.ohiou.edu 992 Stephen Farrell 993 Computer Science Department 994 Trinity College Dublin 995 Ireland 996 Telephone +353-1-896-1761 997 Email stephen.farrell@cs.tcd.ie 999 Intellectual Property Statement 1001 The IETF takes no position regarding the validity or scope of any 1002 Intellectual Property Rights or other rights that might be claimed to 1003 pertain to the implementation or use of the technology described in 1004 this document or the extent to which any license under such rights 1005 might or might not be available; nor does it represent that it has 1006 made any independent effort to identify any such rights. Information 1007 on the procedures with respect to rights in RFC documents can be 1008 found in BCP 78 and BCP 79. 1010 Copies of IPR disclosures made to the IETF Secretariat and any 1011 assurances of licenses to be made available, or the result of an 1012 attempt made to obtain a general license or permission for the use of 1013 such proprietary rights by implementers or users of this 1014 specification can be obtained from the IETF on-line IPR repository at 1015 http://www.ietf.org/ipr. 1017 The IETF invites any interested party to bring to its attention any 1018 copyrights, patents or patent applications, or other proprietary 1019 rights that may cover technology that may be required to implement 1020 this standard. Please address the information to the IETF at ietf- 1021 ipr@ietf.org. 1023 Disclaimer of Validity 1025 This document and the information contained herein are provided on an 1026 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1027 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1028 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1029 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1030 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1031 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1033 Copyright Statement 1035 Copyright (C) The IETF Trust (2008). This document is subject to the 1036 rights, licenses and restrictions contained in BCP 78, and except as 1037 set forth therein, the authors retain all their rights. 1039 Acknowledgment 1041 Funding for the RFC Editor function is currently provided by the 1042 Internet Society.