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