idnits 2.17.1 draft-irtf-dtnrg-ltp-motivation-00.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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1275. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Sec 6' is mentioned on line 864, but not defined == Unused Reference: 'IPN' is defined on line 1218, but no explicit reference was found in the text == Unused Reference: 'ECS94' is defined on line 1231, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-ltp-02 ** Downref: Normative reference to an Experimental draft: draft-irtf-dtnrg-ltp (ref. 'LTP') == Outdated reference: A later version (-08) exists of draft-irtf-dtnrg-ltp-extensions-00 ** Downref: Normative reference to an Experimental draft: draft-irtf-dtnrg-ltp-extensions (ref. 'LTPEXT') -- Obsolete informational reference (is this intentional?): RFC 3448 (ref. 'TFRC') (Obsoleted by RFC 5348) -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. 'ECS94') (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. 'SCTP') (Obsoleted by RFC 4960) Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 7 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 M. Ramadas 5 December 2004 Ohio University 6 Expires June 2005 S. Farrell 7 Trinity College Dublin 9 Licklider Transmission Protocol - Motivation 11 Status of this Memo 13 By submitting this Internet-Draft, we certify that any applicable 14 patent or other IPR claims of which we are aware have been disclosed, 15 or will be disclosed, and any of which we become aware will be 16 disclosed, in accordance with RFC 3668. 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 a "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in [B97]. 38 Discussions on this internet-draft are being made in the Delay 39 Tolerant Networking Research Group (DTNRG) mailing list. More 40 information can be found in the DTNRG web-site at 41 http://www.dtnrg.org 43 Abstract 45 This document describes the Licklider Transmission Protocol (LTP) 46 designed to provide retransmission-based reliability over links 47 characterized by extremely long message round-trip times (RTTs) 48 and/or frequent interruptions in connectivity. Since communication 49 across interplanetary space is the most prominent example of this 50 sort of environment, LTP is principally aimed at supporting "long- 51 haul" reliable transmission in interplanetary space, but has 52 applications in other environments as well. 54 In an Interplanetary Internet setting deploying the Bundling protocol 55 being developed by the Delay Tolerant Networking Research Group, LTP 56 is intended to serve as a reliable convergence layer over single hop 57 deep-space RF links. LTP does ARQ of data transmissions by soliciting 58 selective-acknowledgment reception reports. It is stateful and has 59 no negotiation or handshakes. 61 Table of Contents 63 1. Introduction ................................................. 3 64 2. Motivation ................................................... 4 65 2.1 IPN Operating Environment ................................ 4 66 2.2 Why not Standard Internet Protocols? ..................... 6 67 3. Features ..................................................... 7 68 3.1 Massive State Retention .................................. 8 69 3.1.1 Multiplicity of Protocol State Machines ............. 9 70 3.1.2 Session IDs ......................................... 9 71 3.1.3 Use of Non-volatile Storage ......................... 9 72 3.2 Absence of Negotiation ................................... 10 73 3.3 Partial Reliability ...................................... 10 74 3.4 Laconic Acknowledgment ................................... 11 75 3.5 Adjacency ................................................ 12 76 3.6 Optimistic and Dynamic Timeout Interval Computation ...... 13 77 3.7 Deferred Transmission .................................... 14 78 4. Overall Operation ............................................ 14 79 4.1 Nominal Operation ........................................ 14 80 4.2 Retransmission ........................................... 15 81 4.3 Accelerated Retransmission ............................... 18 82 4.4 Session Cancellation ..................................... 19 83 5. Functional Model ............................................. 19 84 5.1 Deferred Transmission .................................... 20 85 5.2 Timers ................................................... 20 86 6. Tracing LTP back to CFDP ..................................... 23 87 7. Security Considerations ...................................... 25 88 8. IANA Considerations .......................................... 25 89 9. Acknowledgments .............................................. 25 90 10. References ................................................... 25 91 10.1 Normative References ..................................... 25 92 10.2 Informative References ................................... 25 93 11. Author's Addresses ........................................... 26 94 12. Copyright Statement .......................................... 27 96 1. Introduction 98 The Licklider Transmission Protocol (LTP) described in this memo is 99 designed to provide retransmission-based reliability over links 100 characterized by extremely long message round-trip times and/or 101 frequent interruptions in connectivity. Communication in 102 interplanetary space is the most prominent example of this sort of 103 environment, and LTP is principally aimed at supporting "long-haul" 104 reliable transmission over deep-space RF links. 106 Since 1982 the principal source of standards for space communications 107 has been the Consultative Committee for Space Data Systems (CCSDS) 108 [CCSDS]. Engineers of CCSDS member agencies have developed 109 communication protocols that function within the constraints imposed 110 by operations in deep space. These constraints differ sharply from 111 those within which the Internet typically functions: 113 o Extremely long signal propagation delays, on the order of 114 seconds, minutes, or hours rather than milliseconds. 116 o Frequent and lengthy interruptions in connectivity. 118 o Low levels of traffic coupled with high rates of 119 transmission error. 121 o Meager bandwidth and highly asymmetrical data rates. 123 The CCSDS File Delivery Protocol (CFDP) [CFDP] in particular, 124 automates reliable file transfer across interplanetary distances by 125 detecting data loss and initiating the requisite retransmission 126 without mission operator intervention. 128 CFDP by itself is sufficient for operating individual missions, but 129 its built-in networking capabilities are rudimentary. In order to 130 operate within the IPN environment it must rely on the routing and 131 incremental retransmission capabilities of the Bundling protocol [BP] 132 defined for Delay-Tolerant Networks [DTN]. LTP is intended to serve 133 as a reliable "convergence layer" protocol underlying Bundling in DTN 134 regions whose links are characterized by very long round-trip times. 135 Its design notions are directly descended from the retransmission 136 procedures defined for CFDP. 138 This document describes the motivation for LTP, its features, 139 functions, and overall design, and is part of a series of documents 140 describing LTP. Other documents in the series include the main 141 protocol specification document [LTP] and the protocol extensions 142 document [LTPEXT] respectively. 144 2. Motivation 146 2.1 IPN Operating Environment 148 There are a number of fundamental differences between the environment 149 for terrestrial communications and the operating environments 150 envisioned for the IPN. 152 The most challenging difference between communication among points on 153 Earth and communication among planets is round-trip delay, of which 154 there are two main sources, both relatively intractable: natural law 155 and economics. 157 The more obvious type of delay imposed by nature is signal 158 propagation time. Our inability to transmit data at speeds higher 159 than the speed of light means that while round-trip times in the 160 terrestrial Internet range from milliseconds to a few seconds, 161 minimum round-trip times to Mars range from 8 to 40 minutes, 162 depending on the planet's position. Round-trip times between Earth 163 and Jupiter's moon Europa run between 66 and 100 minutes. 165 Less obvious and more dynamic is the delay imposed by occultation. 166 Communication between planets must be by radiant transmission, which 167 is usually possible only when the communicating entities are in line 168 of sight of each other. An entity residing on a planetary surface 169 will be periodically taken out of sight by the planet's rotation (it 170 will be "on the other side of" the planet); an entity that orbits a 171 planet will be periodically taken out of sight by orbital motion (it 172 will be "behind" the planet); and planets themselves lose mutual 173 visibility when their trajectories take them to opposite sides of the 174 Sun. During the time that communication is impossible, delivery is 175 impaired and messages must wait in a queue for later transmission. 177 Round-trip times and occultations can at least be readily computed 178 given the ephemerides of the communicating entities. Additional 179 delay that is less easily predictable is introduced by discontinuous 180 transmission support, which is rooted in economics. 182 Communicating over interplanetary distances requires expensive 183 special equipment: large antennas, high-performance receivers, etc. 184 For most deep-space missions, even non-NASA ones, these are currently 185 provided by NASA's Deep Space Network (DSN) [DSN]. The communication 186 resources of the DSN are currently oversubscribed and will probably 187 remain so for the foreseeable future. While studies have been done 188 as to the feasibility of upgrading or replacing the current DSN, the 189 number of deep space missions will probably continue to grow faster 190 than the terrestrial infrastructure that supports them, making over- 191 subscription a persistent problem. Radio contact via the DSN must 192 therefore be carefully scheduled and is often severely limited. 194 This over-subscription means that the round-trip times experienced by 195 packets will be affected not only by the signal propagation delay and 196 occultation, but also by the scheduling and queuing delays imposed by 197 management of Earth-based resources: packets to be sent to a given 198 destination may have to be queued until the next scheduled contact 199 period, which may be hours, days, or even weeks away. While queuing 200 and scheduling delays are generally known well in advance except when 201 missions need emergency service (such as during landings and 202 maneuvers), the long and highly variable delays make the design of 203 timers, and retransmission timers in particular, quite difficult. 205 Another significant difference between deep space and terrestrial 206 communication is bandwidth availability. The combined effects of 207 large distances (resulting in signal attenuation), the expense and 208 difficulty of deploying large antennas to distant planets, and the 209 difficulty of generating electric power in space all mean that the 210 available bandwidth for communication in the IPN will likely remain 211 modest compared to terrestrial systems. Maximum data rates on the 212 order of a few tens of megabits per second will probably be the norm 213 for the next few decades. 215 Moreover, the available bandwidths are highly asymmetrical: data are 216 typically transmitted at different rates in different directions on 217 the same link. Current missions are usually designed with a much 218 higher data "return" rate (from spacecraft to Earth) than "command" 219 rate (from Earth to spacecraft). The reason for the asymmetry is 220 simple: nobody ever wanted a high-rate command channel, and, all else 221 being equal, it was deemed better to have a more reliable command 222 channel than a faster one. This design choice has led to data rate 223 asymmetries in excess of 100:1, sometimes approaching 1000:1. A 224 strong desire for a very robust command channel will probably remain, 225 so any transport protocol designed for use in the IPN will need to 226 function with a relatively low-bandwidth outbound channel to 227 spacecraft and landers. 229 The difficulty of generating power on and around other planets will 230 also result in relatively low signal-to-noise ratios and thus high 231 bit error rates. Current deep-space missions operate with raw bit 232 error rates on the order of 10^(-1), or one error in ten bits; heavy 233 coding is used to reduce these rates, and of course this coding 234 further reduces the residual bandwidth available for data 235 transmission. 237 Signal propagation delay is the only truly immutable characteristic 238 that distinguishes the IPN from terrestrial communications. Queuing 239 and scheduling delays, low data rates, intermittent connectivity, and 240 high bit error rates can all be mitigated or eliminated by adding 241 more infrastructure. But this additional infrastructure is likely to 242 be provided (if at all) only in the more highly developed core areas 243 of the IPN. We see the IPN growing outwards from Earth as we explore 244 more and more planets, moons, asteroids, and possibly other stars. 245 This suggests that there will always be a "fringe" to the fabric of 246 the IPN, an area without a rich communications infrastructure. The 247 delay, data rate, connectivity, and error characteristics mentioned 248 above will probably always be an issue somewhere in the IPN. 250 2.2 Why not Standard Internet Protocols? 252 These environmental characteristics - long delays, low and asymmetric 253 bandwidth, intermittent connectivity, and relatively high error rates 254 - make using unmodified TCP for end to end communications in the IPN 255 infeasible. Using the TCP throughput equation from [TFRC] we can 256 calculate the loss event rate (p) required to achieve a given steady- 257 state throughput. Assuming the minimum RTT to Mars from planet Earth 258 is 8 minutes (one-way speed of light delay to Mars at its closest 259 approach to Earth is 4 minutes), assuming a packet size of 1500 260 bytes, assuming that the receiver acknowledges every other packet, 261 and ignoring negligible higher order terms in p (i.e., ignoring the 262 second additive term in the denominator of the TCP throughput 263 equation), we obtain the following table of loss event rates required 264 to achieve various throughput values. 266 Throughput Loss event rate (p) 267 ---------- ------------------- 268 10 Mbps 4.68 * 10^(-12) 269 1 Mbps 4.68 * 10^(-10) 270 100 Kbps 4.68 * 10^(-8) 271 10 Kbps 4.68 * 10^(-6) 273 Note that although multiple losses encountered in a single RTT are 274 treated as a single loss event in the TCP throughput equation from 275 [TFRC], such loss event rates are still unrealistic in deep space 276 links where typical raw bit error rates are in the order of 10^(-1). 278 The above values are upper bounds on steady-state throughput. Since 279 the number of packets in an episode of connectivity will generally be 280 under 10,000 due to the low available bandwidth, TCP performance 281 would be dominated by its behavior during slow-start. This means 282 that even when Mars is at its closest approach to Earth it would take 283 a TCP session nearly 100 minutes to ramp up to an Earth-Mars 284 transmission rate of 20kbps. 286 Note: Lab experiments using a channel emulator and standard 287 applications show that even if TCP could be pushed to work 288 efficiently at such distances, many applications either rely on 289 several rounds of handshaking or have built-in timers that render 290 them non-functional when the round-trip-time is over a couple of 291 minutes. For example, it typically takes eight round trips for FTP 292 to get to a state where data can begin flowing. Since an FTP server 293 may time out and reset the connection after 5 minutes of inactivity, 294 a conformant standard FTP server could be unusable for communicating 295 even with the closest planets. 297 The SCTP [SCTP] protocol can multiplex bundles (Note : defined 298 differently from the DTN "bundle") for multiple sessions over a 299 single layer connection just as LTP, but still requires multiple 300 round trips prior to transmitting application data for session setup 301 and so clearly does not suit the needs of the IPN operating 302 environment. 304 3. Features 306 The design of LTP differs from that of TCP in several significant 307 ways. The common themes running through these differences are two 308 central design assumptions, both of which amount to making virtues of 309 necessity. 311 First: given the severe innate constraints on interplanetary 312 communication discussed above, we assume that the computational 313 resources available to LTP engines will always be ample compared to 314 the communication resources available on the link between them. 316 Certainly in many cases the computational resources available to a 317 given LTP engine - such as one on board a small robotic spacecraft - 318 will not be ample by the standards of the Internet. But in those 319 cases we expect that the associated communication resources 320 (transmitter power, antenna size) will be even less ample, preserving 321 the expected disproportion between the two. 323 Second, we note that establishing a communication link across 324 interplanetary distance entails enacting several hardware 325 configuration measures based on the presumed operational state of the 326 remote communicating entity like: 328 o orienting a directional antenna correctly; 330 o tuning a transponder to pre-selected transmission and/or 331 reception frequencies; 333 o diverting precious electrical power to the transponder at the 334 last possible moment, and for the minimum necessary length of 335 time. 337 We therefore assume that the operating environment in which LTP 338 functions is able to pass information on the link status (termed 339 "link state cues" in this document) to LTP, telling it which remote 340 LTP engine(s) should currently be transmitting to the local LTP 341 engine and vice versa. The operating environment itself must have 342 this information in order to configure communication link hardware 343 correctly. 345 3.1 Massive State Retention 347 Like any reliable transport service employing ARQ, LTP is "stateful". 348 In order to assure the reception of a block of data it has sent, LTP 349 must retain for possible retransmission all portions of that block 350 which might not have been received yet. In order to do so, it must 351 keep track of which portions of the block are known to have been 352 received so far, and which are not, together with any additional 353 information needed for purposes of retransmitting part or all of that 354 block. 356 Long round-trip times mean substantial delay between the transmission 357 of a block of data and the reception of an acknowledgment from the 358 block's destination, signaling arrival of the block. If LTP 359 postponed transmission of additional blocks of data until it received 360 acknowledgment of the arrival of all prior blocks, valuable 361 opportunities to utilize what little deep space transmission 362 bandwidth is available would be forever lost. 364 For this reason, LTP is based in part on a notion of massive state 365 retention. Any number of requested transmissions may be concurrently 366 "in flight" at various displacements along the link between two LTP 367 engines, and the LTP engines must necessarily retain transmission 368 status and retransmission resources for all of them. Moreover, if 369 any of the data of a given block are lost en route, it will be 370 necessary to retain the state of that transmission during an 371 additional round trip while the lost data are retransmitted; even 372 multiple retransmission cycles may be necessary. 374 In sum, LTP transmission state information persists for a long time 375 because a long time must pass before LTP can be assured of 376 transmission success - so LTP must retain a great deal of state 377 information. 379 Since the alternatives are non-reliability on the one hand and severe 380 under-utilization of transmission opportunities on the other, we 381 believe such massive statefulness is cost-justified (though probably 382 not in all applications). 384 3.1.1 Multiplicity of Protocol State Machines 386 This design decision is reflected in a significant structural 387 difference between LTP and TCP. 389 Both TCP and LTP provide mechanisms for multiplexing access by a 390 variety of higher-layer services or applications: LTP's "client 391 service IDs" correspond to TCP's port numbers. Also, both TCP and 392 LTP implement devices for encapsulating threads of retransmission 393 protocol (protocol state machines): LTP's "sessions" functionally 394 correspond to TCP connections. At any moment each such thread of 395 retransmission protocol is engaged in conveying a single block of 396 data from one protocol end-point to another. 398 However, a single TCP association (local host address, local port 399 number, foreign host address, foreign port number) can accommodate at 400 most one connection at any one time. In contrast, a single LTP 401 association (local engine ID, local client service ID, foreign engine 402 ID, foreign client service ID) can accommodate multiple concurrent 403 sessions, one for each block of data in transit on the association. 405 3.1.2 Session IDs 407 In TCP, the fact that any single association is occupied by at most 408 one connection at any time enables the protocol to use host addresses 409 and port numbers to demultiplex arriving data to the appropriate 410 protocol state machines. LTP's possible multiplicity of sessions per 411 association makes it necessary for each segment of application data 412 to include an additional demultiplexing token, a "session ID" that 413 uniquely identifies the session in which the segment was issued and, 414 implicitly, the block of data being conveyed by this session. 416 3.1.3 Use of Non-volatile Storage 418 Another important implication of massive statefulness is that 419 implementations of LTP should consider retaining transmission state 420 information in non-volatile storage of some kind, such as magnetic 421 disk or flash memory. 423 Transport protocols such as TCP typically retain transmission state 424 in dynamic RAM. If the device on which the software resides is 425 rebooted or powered down then, although all transmissions currently 426 in progress are aborted, the resulting degree of communication 427 disruption is limited because the number of concurrent connections is 428 limited. Rebooting or power-cycling a computer on which an LTP 429 engine resides could abort a much larger number of transmission 430 sessions in various stages of completion, at a much larger total 431 cost. 433 3.2 Absence of Negotiation 435 In the IPN, round-trip times may be so long and communication 436 opportunities so brief that a negotiation exchange, such as an 437 adjustment of transmission rate, might not be completed before 438 connectivity is lost. Even if connectivity is uninterrupted, waiting 439 for negotiation to complete before revising data transmission 440 parameters might well result in costly under-utilization of link 441 resources. 443 For this reason, LTP communication session parameters are asserted 444 unilaterally, subject to application-level network management 445 activity that may not take effect for hours, days, or weeks. 447 3.3 Partial Reliability 449 For some applications, bandwidth utilization may be improved if part 450 of a given block of data is sent on a "best efforts" basis, i.e., is 451 not subject to acknowledgement and possible retransmission. The 452 motivation for "partially reliable" transmission, as opposed to an 453 alternative unreliable mode, is to provide a mechanism for upper 454 layer protocols to get their header and meta-data transmitted 455 reliably (as necessary) but have the actual data transmitted 456 unreliably. We believe that unreliable transmission of data for many 457 application layers using LTP is likely to be useful only if at least 458 the application headers and meta-data are received. 460 For example, suppose a block contains a high-definition photograph: 461 the first 40 bytes of the block might be a prologue containing 462 information without which the photograph is useless, such as camera 463 settings and time of exposure, while the remainder of the block is an 464 array of fixed-length scan lines. In this case the assured delivery 465 of the first 40 bytes of the block is critical but the loss of a few 466 individual scan lines may not be important enough to justify the cost 467 of retransmission. 469 LTP therefore regards each block of data as comprising two parts: a 470 "red-part", whose delivery must be assured by acknowledgement and 471 retransmission as necessary, and a "green-part" whose delivery is 472 attempted but not assured. 474 Note that the length of either part may be zero; that is, any given 475 block may be designated entirely red (retransmission continues until 476 reception of the entire block has been asserted by the receiver) or 477 entirely green (no part of the block is acknowledged or 478 retransmitted). Thus LTP can provide both TCP-like and UDP-like 479 functionality concurrently on a single association. 481 3.4 Laconic Acknowledgment 483 Another respect in which LTP differs from TCP is that, while TCP 484 connections are bidirectional (blocks of application data may be 485 flowing in both directions on any single connection), LTP sessions 486 are unidirectional. This design decision derives from the fact that 487 the flow of data in deep space flight missions is usually 488 unidirectional. (Long round trip times make interactive spacecraft 489 operation infeasible, so spacecraft are largely autonomous and 490 command traffic is very light.) 492 One could imagine an LTP instance, upon being asked to transmit a 493 block of data, searching through all existing sessions in hopes of 494 finding one that was established upon reception of data from the new 495 block's destination; transmission of the new block could be 496 piggybacked on the acknowledgment traffic for that session. But the 497 prevailing unidirectionality of space data communications means that 498 such a search would frequently fail and a new unidirectional session 499 would have to be established anyway. Session bidirectionality 500 therefore seemed to entail somewhat greater complexity unmitigated by 501 any clear performance advantage, so we abandoned it. Bidirectional 502 data transfer is instead accomplished by opening two individual LTP 503 sessions. 505 Since they are not piggybacked on data segments, LTP data 506 acknowledgments - "reception reports" - are carried in a separate 507 segment type. To minimize consumption of low and asymmetric 508 transmission bandwidth in the IPN, these report segments are sent 509 infrequently; each one contains a comprehensive report of all data 510 received within some specified range of offsets from the start of the 511 transmitted block. The expectation is that most data segments will 512 arrive safely, so individual acknowledgment of each one would be 513 expensive in information-theoretical terms: the real information 514 provided per byte of acknowledgment data transmitted would be very 515 small. Instead, report segments are normally sent only upon 516 encountering explicit solicitations for reception reports - 517 "checkpoints" - in the sequence of incoming data segments. 519 The aggregate nature of reception reports gives LTP transmission an 520 episodic character: 522 o "Original transmissions" are sequences of data segments issued 523 in response to transmission requests from client services. 525 o "Retransmissions" are sequences of data segments issued in 526 response to the arrival of report segments that indicate 527 incomplete reception. 529 Checkpoints are mandatory only at the end of the red-part of each 530 original transmission and at the end of each retransmission. For 531 applications that require accelerated retransmission (and can afford 532 the additional bandwidth consumption entailed), reception reporting 533 can be more aggressive. Additional checkpoints may optionally be 534 inserted at other points in the red-part of an original transmission, 535 and additional reception reports may optionally be sent on an 536 asynchronous basis during reception of the red-part of an original 537 transmission. 539 3.5 Adjacency 541 TCP reliability is "end to end": traffic between two TCP endpoints 542 may traverse any number of intermediate network nodes, and two 543 successively transmitted segments may travel by entirely different 544 routes to reach the same destination. The underlying IP network- 545 layer protocol accomplishes this routing. Although TCP always 546 delivers data segments to any single port in order and without gaps, 547 the IP datagrams delivered to TCP itself may not arrive in the order 548 in which they were transmitted. 550 In contrast, LTP is a protocol for "point to point" reliability on a 551 single link: traffic between two LTP engines is expected not to 552 traverse any intermediate relays. Point-to-point topology is innate 553 in the nature of deep space communication, which is simply the 554 exchange of radiation between two mutually visible antennae. No 555 underlying network infrastructure is presumed, so no underlying 556 network-layer protocol activity is expected; the underlying 557 communication service is assumed to be a point-to-point link-layer 558 protocol such as CCSDS Telemetry/Telecommand [TM][TC] (or, for 559 terrestrial applications, PPP). The contents of link-layer frames 560 delivered to LTP are always expected to arrive in the order in which 561 they were transmitted, though possibly with any number of gaps due to 562 data loss or corruption. 564 Note that building an interplanetary network infrastructure - the 565 DTN-based architecture of the IPN - *on top of* LTP does not conflict 566 with LTP design principles. Bundling functions as an overlay network 567 protocol, and LTP bears essentially the same relationship to Bundling 568 that a reliable link protocol (for example, the ARQ capabilities of 569 LLC) would bear to IP. 571 The design of LTP relies heavily on this topological premise, in at 572 least two ways: 574 If two successively transmitted segments could travel by 575 materially different routes to reach the same destination, then 576 the assumption of rough determinism in timeout interval 577 computation discussed below would not hold. Our inability to 578 estimate timeout intervals with any accuracy would severely 579 compromise performance. 581 If data arrived at an LTP engine out of transmission order, then 582 the assumptions on which the rules for reception reporting are 583 based would no longer hold. A more complex and/or less efficient 584 retransmission mechanism would be needed. 586 3.6 Optimistic and Dynamic Timeout Interval Computation 588 TCP determines timeout intervals by measuring and recording actual 589 round trip times, then applying statistical techniques to recent RTT 590 history to compute a predicted round trip time for each transmitted 591 segment. 593 The problem is at once both simpler and more difficult for LTP: 595 Since multiple sessions can be conducted on any single 596 association, retardation of transmission on any single session 597 while awaiting a timeout need not degrade communication 598 performance on the association as a whole. Timeout intervals that 599 would be intolerably optimistic in TCP don't necessarily degrade 600 LTP's bandwidth utilization. 602 But the reciprocal half-duplex nature of LTP communication makes 603 it infeasible to use statistical analysis of round-trip history as 604 a means of predicting round-trip time. The round-trip time for 605 transmitted segment N could easily be orders of magnitude greater 606 than that for segment N-1 if there happened to be a transient loss 607 of connectivity between the segment transmissions. 609 Since statistics derived from round-trip history cannot safely be 610 used as a predictor of LTP round-trip times, we have to assume that 611 round-trip timing is at least roughly deterministic - i.e., that 612 sufficiently accurate RTT estimates can be computed individually in 613 real time from available information. 615 This computation is performed in two stages: 617 We calculate a first approximation of RTT by simply doubling the 618 known one-way light time to the destination and adding an 619 arbitrary margin for any additional anticipated latency, such as 620 queuing and processing delay at both ends of the transmission. 621 For deep space operations, the margin value is typically a small 622 number of whole seconds. Although such a margin is enormous by 623 Internet standards, it is insignificant compared to the two-way 624 light time component of round-trip time in deep space. We choose 625 to risk tardy retransmission, which will postpone delivery of one 626 block by a relatively tiny increment, in preference to premature 627 retransmission, which will unnecessarily consume precious 628 bandwidth and thereby degrade overall performance. 630 Then, to account for the additional delay imposed by interrupted 631 connectivity, we dynamically suspend timers during periods when 632 the relevant remote LTP engines are known to be unable to transmit 633 responses. This knowledge of the operational state of remote 634 entities is assumed to be provided by link state cues from the 635 operating environment, as discussed earlier. 637 3.7 Deferred Transmission 639 Link state cues also notify LTP when it is and isn't possible to 640 transmit segments by passing them to the underlying communication 641 service. 643 Continuous duplex communication is the norm for TCP operations in the 644 Internet; when communication links are not available, TCP simply does 645 not operate. In deep space communications, however, at no moment can 646 there ever be any expectation of two-way connectivity. It is always 647 possible for LTP to be generating outbound segments - in response to 648 received segments, timeouts, or requests from client services - that 649 cannot immediately be transmitted. These segments must be queued for 650 transmission at a later time when a link has been established, as 651 signaled by a link state cue. 653 4. Overall Operation 655 4.1 Nominal Operation 657 The nominal sequence of events in an LTP transmission session is as 658 follows. 660 Operation begins when a client service instance asks an LTP engine to 661 transmit a block to a remote client service instance. The sending 662 engine opens a Sending State Record (SSR) for a new session, thereby 663 starting the session, and notifies the client service instance that 664 the session has been started. The sending engine then initiates an 665 original transmission: it queues for transmission as many data 666 segments as are necessary to transmit the entire block, within the 667 constraints on maximum segment size imposed by the underlying 668 communication service. The last segment of the red-part of the block 669 is marked as the EORP, a checkpoint, indicating that the receiving 670 engine must issue a reception report upon receiving the segment. The 671 last segment of the block is marked as an EOB (indicating that the 672 receiving engine can calculate the size of the block by summing the 673 offset and length of the data in the segment). 675 At the next opportunity, subject to allocation of bandwidth to the 676 queue into which the block data segments were written, the enqueued 677 segments are transmitted to the LTP engine serving the remote client 678 service instance. A timer is started for the EORP, so that it can be 679 retransmitted automatically if no response is received. 681 On reception of the first data segment for the block, the receiving 682 engine opens a Receiving State Record (RSR) for the new session and 683 notifies the local instance of the relevant client service that the 684 session has been started. In the nominal case it receives all 685 segments of the original transmission without error. Therefore on 686 reception of the EORP data segment it responds by (a) queuing for 687 transmission to the sending engine a report segment indicating 688 complete reception and (b) delivering the received red-part of the 689 block to the local instance of the client service; on reception of 690 each data segment of the green-part, it responds by immediately 691 delivering the received data to the local instance of the client 692 service. 694 At the next opportunity, the enqueued report segment is immediately 695 transmitted to the sending engine and a timer is started so that the 696 report segment can be retransmitted automatically if no response is 697 received. 699 The sending engine receives the report segment, turns off the timer 700 for the EORP, enqueues for transmission to the receiving engine a 701 report-acknowledgment segment, notifies the local client service 702 instance that the red-part of the block has been successfully 703 transmitted, and closes the SSR for the session. 705 At the next opportunity, the enqueued report-acknowledgment segment 706 is immediately transmitted to the receiving engine. 708 The receiving engine receives the report-acknowledgment segment, 709 turns off the timer for the report segment, and closes the RSR for 710 the session. 712 Closing both the SSR and RSR for a session terminates the session. 714 4.2 Retransmission 716 Loss or corruption of transmitted segments may cause the operation of 717 LTP to deviate from the nominal sequence of events described above. 719 Loss of one or more red-part data segments other than the EORP 720 segment triggers data retransmission: 722 Rather than returning a single reception report indicating complete 723 reception, the receiving engine returns a reception report comprising 724 as many report segments as are needed in order to report in detail on 725 all red-part data reception for this session (other than data 726 reception that was previously reported in response to any 727 discretionary checkpoints, described later), within the constraints 728 on maximum segment size imposed by the underlying communication 729 service. [Still, only one report segment is normally returned; 730 multiple report segments are needed only when a large number of 731 segments comprising non-contiguous intervals of red-part block data 732 are lost or when the receiver-to-sender path MTU is small.] A timer 733 is started for each report segment. 735 On reception of each report segment the sending engine responds as 736 follows : 738 It turns off the timer for the checkpoint referenced by the report 739 segment, if any. 741 It enqueues a reception-acknowledgment segment acknowledging the 742 report segment (to turn off the report retransmission timer at the 743 receiving engine). This segment is sent immediately at the next 744 transmission opportunity. 746 If the reception claims in the report segment indicate that not 747 all data within the scope have been received, it normally 748 initiates a retransmission by enqueuing all data segments not yet 749 received. The last such segment is marked a checkpoint and 750 contains the report serial number of the report segment to which 751 the retransmission is a response. These segments are likewise 752 sent at the next transmission opportunity, but only after all data 753 segments previously queued for transmission to the receiving 754 engine have been sent. A timer is started for the checkpoint, so 755 that it can be retransmitted automatically if no responsive report 756 segment is received. 758 On the other hand, if the reception claims in the report segment 759 indicate that all data within the scope of the report segment have 760 been received, and the union of all reception claims received so 761 far in this session indicate that all data in the red-part of the 762 block have been received, then the sending engine notifies the 763 local client service instance that the red-part of the block has 764 been successfully transmitted and closes the SSR for the session. 766 On reception of a checkpoint segment with a non-zero report serial 767 number, the receiving engine responds as follows : 769 It first turns off the timer for the referenced report segment. 771 It then returns a reception report comprising as many report 772 segments as are needed in order to report in detail on all data 773 reception within the scope of the referenced report segment, 774 within the constraints on maximum segment size imposed by the 775 underlying communication service; a timer is started for each 776 report segment. 778 If at this point all data in the red-part of the block have been 779 received, the receiving engine delivers the received block's red- 780 part to the local instance of the client service and, upon 781 reception of reception-acknowledgment segments acknowledging all 782 report segments, closes the RSR for the session. Otherwise the 783 data retransmission cycle continues. 785 Loss of any checkpoint segment or of the responsive report segment 786 causes the checkpoint timer to expire. When this occurs, the sending 787 engine normally retransmits the checkpoint segment. Similarly, loss 788 of a report segment or of the responsive report-acknowledgment 789 segment causes the report segment's timer to expire. When this 790 occurs, the receiving engine normally retransmits the report segment. 792 Note that reception of a previously received report segment that was 793 retransmitted due to loss of the report-acknowledgment segment causes 794 another responsive report-acknowledgment segment to be transmitted, 795 but is otherwise ignored; if any of the data retransmitted in 796 response to the previously received report segment were lost, further 797 retransmission of those data will be requested by one or more new 798 report segments issued in response to that earlier retransmission's 799 checkpoint. Thus unnecessary retransmission is suppressed. 801 Note also that the responsibility for responding to segment loss in 802 LTP is shared between the sender and receiver of a block: the sender 803 retransmits checkpoint segments in response to checkpoint timeouts, 804 and it retransmits missing data in response to reception reports 805 indicating incomplete reception, while the receiver additionally 806 retransmits report segments in response to timeouts. An alternative 807 design would have been to make the sender responsible for all 808 retransmission, in which case the receiver would not expect report- 809 acknowledgment segments and would not retransmit report segments. 810 There are two disadvantages to this approach: 812 First, because of constraints on segment size that might be 813 imposed by the underlying communication service, it is at least 814 remotely possible that the response to any single checkpoint might 815 be multiple report segments. An additional sender-side mechanism 816 for detecting and appropriately responding to the loss of some 817 proper subset of those reception reports would be needed. We 818 believe the current design is simpler. 820 Second, an engine that receives a block needs a way to determine 821 when the session can be closed. In the absence of explicit final 822 report acknowledgment (which entails retransmission of the report 823 in case of the loss of the report acknowledgment), the 824 alternatives are (a) to close the session immediately on 825 transmission of the report segment that signifies complete 826 reception and (b) to close the session on receipt of an explicit 827 authorization from the sender. In case (a), loss of the final 828 report segment would cause retransmission of a checkpoint by the 829 sender, but the session would no longer exist at the time the 830 retransmitted checkpoint arrived; the checkpoint could reasonably 831 be interpreted as the first data segment of a new block, most of 832 which was lost in transit, and the result would be redundant 833 retransmission of the entire block. In case (b), the explicit 834 session termination segment and the responsive acknowledgment by 835 the receiver (needed in order to turn off the timer for the 836 termination segment, which in turn would be needed in case of in- 837 transit loss or corruption of that segment) would somewhat 838 complicate the protocol, increase bandwidth consumption, and 839 retard the release of session state resources at the sender. Here 840 again we believe that the current design is simpler and more 841 efficient. 843 4.3 Accelerated Retransmission 845 Data segment retransmission occurs only on receipt of a report 846 segment indicating incomplete reception; report segments are normally 847 transmitted only at the end of original transmission of the red-part 848 of a block or at the end of a retransmission. For some applications 849 it may be desirable to trigger data segment retransmission 850 incrementally during the course of red-part original transmission so 851 that the retransmitted segments arrive sooner. This can be 852 accomplished in two ways: 854 Any red-part data segment prior to the EORP can additionally be 855 flagged as a checkpoint. Reception of each such "discretionary" 856 checkpoint causes the receiving engine to issue a reception 857 report. 859 At any time during the original transmission of a block's red-part 860 (that is, prior to reception of any data segment of the block's 861 green-part), the receiving engine can unilaterally issue 862 additional asynchronous reception reports. Note that the CFDP 863 protocol's "Immediate" mode is an example of this sort of 864 asynchronous reception reporting [Sec 6]. The reception reports 865 generated for accelerated retransmission are processed in exactly 866 the same way as the standard reception reports. 868 4.4 Session Cancellation 870 A transmission session may be canceled by either the sending or the 871 receiving engine in response either to a request from the local 872 client service instance or to an LTP operational failure as noted 873 earlier. Session cancellation is accomplished as follows. 875 The canceling engine deletes all currently queued segments for the 876 session and notifies the local instance of the affected client 877 service that the session is canceled. If no segments for this 878 session have yet been sent to or received from the corresponding LTP 879 engine, then at this point the canceling engine simply closes its 880 state record for the session and cancellation is complete. 882 Otherwise, the canceling engine queues for transmission to the 883 corresponding engine a session cancellation segment. At the next 884 opportunity, the enqueued cancellation segment is immediately 885 transmitted to the LTP engine serving the remote client service 886 instance. A timer is started for the segment, so that it can be 887 retransmitted automatically if no response is received. 889 The corresponding engine receives the cancellation segment, enqueues 890 for transmission to the canceling engine a cancellation- 891 acknowledgment segment, deletes all other currently queued segments 892 for the indicated session, notifies the local client service instance 893 that the block has been canceled, and closes its state record for the 894 session. 896 At the next opportunity, the enqueued cancellation-acknowledgment 897 segment is immediately transmitted to the canceling engine. 899 The canceling engine receives the cancellation-acknowledgment, turns 900 off the timer for the cancellation segment, and closes its state 901 record for the session. 903 Loss of a cancellation segment or of the responsive cancellation- 904 acknowledgment causes the cancellation segment timer to expire. When 905 this occurs, the canceling engine normally retransmits the 906 cancellation segment. 908 5. Functional Model 910 The functional model underlying the specification of LTP is one of 911 deferred, opportunistic transmission, with access to the active 912 transmission link apportioned between two (conceptual) outbound 913 traffic queues. The accuracy of LTP retransmission timers depend in 914 large part on a faithful adherence to this model. 916 5.1 Deferred Transmission 918 In concept, every outbound LTP segment is appended to one of two 919 queues -- forming a "queue set" -- of traffic bound for the LTP 920 engine that is that segment's destination. One such traffic queue is 921 the "internal operations queue" of that queue set; the other is the 922 application data queue for the queue set. The de-queuing of a 923 segment always implies delivering it to the underlying communication 924 system for immediate transmission. Whenever the internal operations 925 queue is non-empty, the oldest segment in that queue is the next 926 segment de-queued for transmission to the destination; at all other 927 times, the oldest segment in the application data queue is the next 928 segment de-queued for transmission to the destination. 930 The production and enqueuing of a segment and the subsequent actual 931 transmission of that segment are in principle wholly asynchronous. 933 In the event that (a) a transmission link to the destination is 934 currently active and (b) the queue to which a given outbound segment 935 is appended is otherwise empty and (c) either this queue is the 936 internal operations queue or else the internal operations queue is 937 empty, the segment will be transmitted immediately upon production. 938 Transmission of a newly queued segment is necessarily deferred in all 939 other circumstances. 941 Conceptually, the de-queuing of segments from traffic queues bound 942 for a given destination is initiated upon reception of a link state 943 cue indicating that the underlying communication system is now 944 transmitting to that destination, i.e., the link to that destination 945 is now active. It ceases upon reception of a link state cue 946 indicating that the underlying communication system is no longer 947 transmitting to that destination, i.e., the link to that destination 948 is no longer active. 950 5.2 Timers 952 LTP relies on accurate calculation of expected arrival times for 953 report and acknowledgment segments in order to know when proactive 954 retransmission is required. If a calculated time were even slightly 955 early, the result would be costly unnecessary retransmission. On the 956 other hand, calculated arrival times may safely be several seconds 957 late: the only penalties for late timeout and retransmission are 958 slightly delayed data delivery and slightly delayed release of 959 session resources. 961 The following discussion is the basis for LTP's expected arrival time 962 calculations. 964 The total time consumed in a single "round trip" (transmission and 965 reception of the original segment, followed by transmission and 966 reception of the acknowledging segment) has the following components: 968 Protocol processing time: The time consumed in issuing the 969 original segment, receiving the original segment, generating and 970 issuing the acknowledging segment, and receiving the acknowledging 971 segment. 973 Outbound queuing delay: The delay at the sender of the original 974 segment while that segment is in a queue waiting for transmission, 975 and delay at the sender of the acknowledging segment while that 976 segment is in a queue waiting for transmission. 978 Radiation time: The time that passes while all bits of the 979 original segment are being radiated, and the time that passes 980 while all bits of the acknowledging segment are being radiated. 981 (This is significant only at extremely low data transmission 982 rates.) 984 Round-trip light time: The signal propagation delay at the speed 985 of light, in both directions. 987 Inbound queuing delay: delay at the receiver of the original 988 segment while that segment is in a reception queue, and delay at 989 the receiver of the acknowledging segment while that segment is in 990 a reception queue. 992 Delay in transmission of the original segment or the acknowledging 993 segment due to loss of connectivity - that is, interruption in 994 outbound link activity at the sender of either segment due to 995 occultation, scheduled end of tracking pass, etc. 997 In this context, where errors on the order of seconds or even minutes 998 may be tolerated, protocol processing time at each end of the session 999 is assumed to be negligible. 1001 Inbound queuing delay is also assumed to be negligible because, even 1002 on small spacecraft, LTP processing speeds are high compared to data 1003 transmission rates. 1005 Two mechanisms are used to make outbound queuing delay negligible: 1007 The expected arrival time of an acknowledging segment is not 1008 calculated until the moment the underlying communication system 1009 notifies LTP that radiation of the original segment has begun. 1010 All outbound queuing delay for the original segment has already 1011 been incurred at that point. 1013 LTP's deferred transmission model [Sec 5.1] minimizes latency in 1014 the delivery of acknowledging segments (reports and 1015 acknowledgments) to the underlying communication system; that is, 1016 acknowledging segments are (in concept) appended to the internal 1017 operations queue rather than the application data queue, so they 1018 have higher transmission priority than any other outbound 1019 segments, i.e., they should always be de-queued for transmission 1020 first. This limits outbound queuing delay for a given 1021 acknowledging segment to the time needed to de-queue and radiate 1022 all previously generated acknowledging segments that have not yet 1023 been de-queued for transmission. Since acknowledging segments are 1024 sent infrequently and are normally very small, outbound queuing 1025 delay for a given acknowledging segment is likely to be minimal. 1027 Deferring calculation of the expected arrival time of the 1028 acknowledging segment until the moment at which the original segment 1029 is radiated has the additional effect of removing from consideration 1030 any original segment transmission delay due to loss of connectivity 1031 at the original segment sender. 1033 Radiation delay at each end of the session is simply segment size 1034 divided by transmission data rate. It is insignificant except when 1035 data rate is extremely low (for example, 10 bps), in which case the 1036 use of LTP may well be inadvisable for other reasons. Therefore 1037 radiation delay is normally assumed to be negligible. 1039 We assume that one-way light time to the nearest second can always be 1040 known (for example, provided by the operating environment). 1042 So the initial expected arrival time for each acknowledging segment 1043 is typically computed as simply the current time at the moment that 1044 radiation of the original segment begins, plus twice the one-way 1045 light time, plus 2*N seconds of margin to account for processing and 1046 queuing delays and for radiation time at both ends. N is a parameter 1047 set by network management for which 2 seconds seem to be a reasonable 1048 default value. 1050 This leaves only one unknown, the additional round trip time 1051 introduced by loss of connectivity at the sender of the acknowledging 1052 segment. To account for this, we again rely on external link state 1053 cues. Whenever interruption of transmission at a remote LTP engine 1054 is signaled by a link state cue, we suspend the countdown timers for 1055 all acknowledging segments expected from that engine. Upon a signal 1056 that transmission has resumed at that engine, we resume those timers 1057 after (in effect) adding to each expected arrival time the length of 1058 the timer suspension interval. 1060 6. Tracing LTP back to CFDP 1062 LTP in effect implements most of the "core procedures" of the CCSDS 1063 File Delivery Protocol (CFDP) specification, minus flow labels and 1064 all features that are specific to operations on files and filestores 1065 (file systems). In the IPN architecture we expect that file and 1066 filestore operations will be conducted by file transfer application 1067 protocols -- notably CFDP itself -- operating on top of the DTN 1068 Bundling protocol. Bundling's QoS features serve the same purposes 1069 as CFDP's flow labels, so flow labeling is omitted from LTP. 1070 Bundling in effect implements the CFDP "extended procedures" in a 1071 more robust and scalable manner than is prescribed by the CFDP 1072 standard. 1074 The fundamental difference between LTP and CFDP is that, while CFDP 1075 delivers named files end-to-end, LTP is used to transmit arbitrary, 1076 unnamed blocks of data point-to-point. 1078 Some differences between LTP and CFDP are simply matters of 1079 terminology; the following table summarizes the correspondences in 1080 language between the two. 1082 --------------LTP------------- ------------CFDP----------- 1084 LTP engine CFDP entity 1086 Segment Protocol Data Unit (PDU) 1088 Reception Report NAK 1090 Client service request Service request 1092 Client service notice Service indication 1094 CFDP specifies four mechanisms for initiating data retransmission, 1095 called "lost segment detection modes". LTP effectively supports all 1096 four: 1098 "Deferred" mode is implemented in LTP by the Request flag in the 1099 EORP data segment, which triggers reception reporting upon receipt 1100 of the EORP. 1102 "Prompted" mode is implemented in LTP by turning on Request flags 1103 in data segments that precede the EORP; these additional 1104 checkpoints trigger interim reception reporting under the control 1105 of the source LTP engine. 1107 "Asynchronous" mode is implemented in LTP by the autonomous 1108 production, under locally specified conditions, of additional 1109 reception reports prior to arrival of the EORP. 1111 "Immediate" mode is simply a special case of asynchronous mode, 1112 where the condition that triggers autonomous reception reporting 1113 is detection of a gap in the incoming data. 1115 CFDP uses a cyclic timer to iterate reception reporting until 1116 reception is complete. Because choosing a suitable interval for such 1117 a timer is potentially quite difficult, LTP instead flags the last 1118 data segment of each retransmission as a checkpoint, sent reliably; 1119 the cascading reliable transmission of checkpoint and RS segments 1120 assures the continuous progress of the transmission session. 1122 As the following table indicates, most of the functions of CFDP PDUs 1123 are accomplished in some way by LTP segments. 1125 --------------LTP------------- -------------CFDP---------- 1127 Data segments File data and metadata PDUs 1129 Flags on data segments EOF (Complete), Prompt (NAK), 1130 Prompt (Keep Alive) 1132 Report segment ACK (EOF Complete), NAK, 1133 Keep Alive, Finished (Complete) 1135 Report-acknowledgment ACK (Finished Complete) 1137 Cancel segment EOF (Cancel, Protocol Error) 1138 Finished (Cancel, Protocol Error) 1140 Cancellation Acknowledgment ACK (EOF (Cancel, Protocol Error), 1141 Finished (Cancel, Protocol Error)) 1143 But some CFDP PDUs have no LTP equivalent because in an IPN 1144 architecture they will likely be implemented elsewhere. CFDP's EOF 1145 (Filestore error) and Finished (Filestore error) PDUs would be 1146 implemented in an IPN application-layer file transfer protocol, e.g., 1147 CFDP itself. CFDP's Finished [End System] PDU is a feature of the 1148 Extended Procedures, which would in effect be implemented by the 1149 Bundling protocol. 1151 7. Security Considerations 1153 Not relevant for this document. 1155 8. IANA Considerations 1157 Not relevant for this document. Please follow the IANA Considerations 1158 sections of the internet-drafts on the series (main protocol 1159 specification and protocol extensions). 1161 9. Acknowledgments 1163 Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian 1164 Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for 1165 their thoughts on this protocol and its role in Delay-Tolerant 1166 Networking architecture. 1168 Part of the research described in this document was carried out at 1169 the Jet Propulsion laboratory, California Institute of Technology, 1170 under a contract with the National Aeronautics and Space 1171 Administration. This work was performed under DOD Contract DAA-B07- 1172 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; 1173 and NASA Contract NAS7-1407. 1175 Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel Myers 1176 at Ohio University for their suggestions and advice in making various 1177 design decisions. 1179 Part of this work was carried out at Trinity College Dublin as part 1180 of the SeNDT contract funded by Enterprise Ireland's research 1181 innovation fund. 1183 10. References 1185 10.1 Normative References 1187 [B97] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1188 Levels", BCP 14, RFC 2119, March 1997. 1190 [LTP] Ramadas, M., Burleigh, S., and Farrell, S., "Licklider 1191 Transmission Protocol - Specification", draft-irtf-dtnrg-ltp-02.txt 1192 (Work in Progress), December 2004. 1194 [LTPEXT] Farrell, S., Ramadas, M., and Burleigh, S., "Licklider 1195 Transmission Protocol - Extensions", draft-irtf-dtnrg-ltp- 1196 extensions-00.txt (Work in Progress), December 2004. 1198 10.2 Informative References 1200 [BP] K. Scott, and S. Burleigh, "Bundle Protocol Specification", Work 1201 in Progress, October 2003. 1203 [CCSDS] Consultative Committee for Space Data Systems web page, 1204 "http://www.ccsds.org". 1206 [CFDP] CCSDS File Delivery Protocol (CFDP). Recommendation for Space 1207 Data System Standards, CCSDS 727.0-B-2 BLUE BOOK Issue 1, October 1208 2002. 1210 [DSN] Deep Space Mission Systems Telecommunications Link Design 1211 Handbook (810-005) web-page, 1212 "http://eis.jpl.nasa.gov/deepspace/dsndocs/810-005/" 1214 [DTN] K. Fall, "A Delay-Tolerant Network Architecture for Challenged 1215 Internets", In Proceedings of ACM SIGCOMM 2003, Karlsruhe, Germany, 1216 Aug 2003. 1218 [IPN] InterPlanetary Internet Special Interest Group web page, 1219 "http://www.ipnsig.org". 1221 [TFRC] M. Handley, S. Floyd, J. Padhye, and J. Widmer, "TCP Friendly 1222 Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003. 1224 [TM] Packet Telemetry Specification. Recommendation for Space Data 1225 System Standards, CCSDS 103.0-B-2 BLUE BOOK Issue 2, June 2001. 1227 [TC] Telecommand Part 2 - Data Routing Service. Recommendation for 1228 Space Data System Standards, CCSDS 202.0-B-3 BLUE BOOK Issue 3, June 1229 2001. 1231 [ECS94] D. Eastlake, S. Crocker, and J. Schiller, "Randomness 1232 Recommendations for Security", RFC 1750, December 1994. 1234 [SCTP] R. Stewart et al, "Stream Control Transmission Protocol", RFC 1235 2960, October 2000. 1237 11. Author's Addresses 1239 Scott C. Burleigh 1240 Jet Propulsion Laboratory 1241 4800 Oak Grove Drive 1242 M/S: 179-206 1243 Pasadena, CA 91109-8099 1244 Telephone +1 (818) 393-3353 1245 FAX +1 (818) 354-1075 1246 Email Scott.Burleigh@jpl.nasa.gov 1247 Manikantan Ramadas 1248 Internetworking Research Group 1249 301 Stocker Center 1250 Ohio University 1251 Athens, OH 45701 1252 Telephone +1 (740) 593-1562 1253 Email mramadas@irg.cs.ohiou.edu 1255 Stephen Farrell 1256 Distributed Systems Group 1257 Computer Science Department 1258 Trinity College Dublin 1259 Ireland 1260 Telephone +353-1-608-3070 1261 Email stephen.farrell@cs.tcd.ie 1263 12. Copyright Statement 1265 Copyright (C) The Internet Society (2004). This document is subject 1266 to the rights, licenses and restrictions contained in BCP 78, and 1267 except as set forth therein, the authors retain all their rights." 1269 This document and the information contained herein are provided on an 1270 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1271 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1272 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1273 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1274 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1275 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.