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