RFC 5325

Licklider Transmission Protocol - Motivation

📅 published September 2008, from ietf

Licklider Transmission Protocol - Motivation 🦋

okay bestie, this is RFC 5325, and it's giving motivation letter for a protocol called LTP 🚀 (Licklider Transmission Protocol, named after ARPA/Internet pioneer JCR Licklider 👑). The authors are S. Burleigh (NASA/Jet Propulsion Laboratory), M. Ramadas (ISTRAC, ISRO), and S. Farrell (Trinity College Dublin). It's an Informational document, dated September 2008, and the header doesn't list anything it obsoletes or updates. 🌸

Status of This Memo 📝

ngl this part is lowkey a disclaimer 🙈 It says this memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind. They're literally asking for feedback and suggestions for improvement, and distribution of the memo is unlimited 💖

IESG Note 🎀

This RFC is not a candidate for any level of Internet Standard 💅 It represents the consensus of the Delay Tolerant Networking (DTN) Research Group of the Internet Research Task Force (IRTF). If you want more info, check out RFC 3932 🌈

Abstract ✨

Okay so the main idea is this: LTP gives you retransmission-based reliability over links with extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity 😭 Interplanetary space is the most iconic example of this, so LTP is mainly built for "long-haul" reliable transmission out there, though it can work in other places too 🪐

In an Interplanetary Internet setting that uses the Bundle protocol, LTP acts as a reliable convergence layer over single-hop deep-space radio frequency (RF) links 📡 It does Automatic Repeat reQuest (ARQ) for data transmissions by asking for selective-acknowledgment reception reports. It's stateful, and there is no negotiation or handshakes at all. Zero drama, very efficient 💅

This document is a product of the Delay Tolerant Networking Research Group, and that group reviewed it. No objections to publishing it as an RFC were raised 🫶

Table of Contents 📜

   1. Introduction ....................................................2
   2. Problem .........................................................3
      2.1. IPN Operating Environment ..................................3
      2.2. Why Not TCP or SCTP? .......................................5
   3. Protocol Overview ...............................................6
      3.1. Nominal Operation ..........................................6
           3.1.1. Link State Cues .....................................9
           3.1.2. Deferred Transmission ...............................9
           3.1.3. Timers .............................................10
      3.2. Retransmission ............................................13
      3.3. Accelerated Retransmission ................................16
      3.4. Session Cancellation ......................................17
   4. Security Considerations ........................................17
   5. IANA Considerations ............................................20
   6. Acknowledgments ................................................20
   7. References .....................................................20
      7.1. Informative References ....................................20

1. Introduction 🌟

So LTP is designed to give you retransmission-based reliability over links where the message round-trip times are extremely long and/or the connection keeps dropping 🌙 Talking across interplanetary space is the biggest example of this, and LTP is mainly built for "long-haul" reliable transmission over deep-space RF links 🛰️ More specifically, it's meant to be a reliable "convergence layer" protocol underneath the Delay-Tolerant Networking (DTN) [DTN] Bundle protocol [BP], in DTN setups where the data links have very long round-trip times 💜

This document explains the why behind LTP: its features, functions, and overall design 🧠 It's part of a series. The other docs are the main protocol specification [LTPSPEC] and the protocol extensions document [LTPEXT], so go check those out too 🎀

The protocol is named in honor of ARPA/Internet pioneer JCR Licklider 👑 iconic, honestly.

2. Problem 💥

2.1. IPN Operating Environment 🪐

There are a bunch of fundamental differences between regular terrestrial communication (the stuff you see on the Internet) and the environments imagined for the Interplanetary Internet (IPN) [IPN] 🚀 It's literally a whole different vibe.

The biggest difference between talking among points on Earth and talking among planets is round-trip delay. It comes from two main sources, and both are pretty intractable: physics and economics 😩

The more obvious kind of delay is nature's doing: signal propagation time. Round-trip times between Earth and Jupiter's moon Europa, for example, run between 66 and 100 minutes 🌍➡️🧊

The less obvious and more dynamic delay comes from occultation 🌘 Planets talk using radiant transmission, which is usually only possible when the communicating entities are in line of sight of each other. While communication is impossible, delivery is impaired and messages have to wait in a queue for later transmission. Not me waiting in a queue 💀

The good news is that round-trip times and occultations can be readily computed from the ephemerides of the communicating entities 📐 The additional delay that's harder to predict comes from discontinuous transmission support, which is rooted in economics 💸

Talking across interplanetary distances also requires expensive special equipment: large antennas, high-performance receivers, and so on 🛸

For most deep-space missions, even non-NASA ones, that equipment is currently provided by NASA's Deep Space Network (DSN) [DSN] 📡 The DSN's communication resources are currently oversubscribed and will probably stay that way for the foreseeable future 😭 So radio contact via the DSN has to be carefully scheduled and is often severely limited. Main character problems, but make it NASA 👑

Because of that over-subscription, the round-trip times packets experience aren't just affected by signal propagation delay and occultation. They're also affected by the scheduling and queuing delays from managing Earth-based resources. Packets headed to a given destination may have to wait until the next scheduled contact period, which might be hours, days, or even weeks away 🥲

All of these operating conditions add a bunch of extra constraints on any protocol trying to ensure reliable communication over deep-space links 🫠

  • Long round-trip times mean there's a big delay between sending a block of data and getting an acknowledgment from the block's destination that it arrived. If LTP waited to send more blocks until it heard that all the prior blocks had arrived, the little deep-space bandwidth available would be wasted forever 😤 So multiple parallel data block transmission "sessions" have to be running at the same time to avoid under-utilizing the links 🔥
  • Like any reliable transport service that uses ARQ, LTP is "stateful" 🧠 To make sure a block it sent was received, LTP has to keep every portion of that block that might not have been received yet, so it can retransmit it. To do that, it has to track which portions are known to have been received so far and which aren't, along with any extra info needed to retransmit part or all of the block 📦
  • In the IPN, round-trip times can be so long and communication windows so brief that a negotiation exchange, like adjusting the transmission rate, might not finish before connectivity is lost 😬 Even when connectivity isn't interrupted, waiting for negotiation to finish before revising data transmission parameters could easily cause costly under-utilization of link resources 💸
  • Another way LTP is different from TCP: TCP connections are bidirectional (blocks of application data can flow in both directions on a single connection), but LTP sessions are unidirectional 🪄 That's because data flow in deep-space flight missions is usually unidirectional. (Long round-trip times make interactive spacecraft operation infeasible, so spacecraft are largely autonomous and command traffic is very light.) Where bidirectional data flow is possible, it's done using two unidirectional links in opposite directions and at different data rates ↔️
  • Last but not least, timeout interval computation is a different problem in the environment LTP is mainly meant for than it is on the Internet ⏱️ Since multiple sessions can run in parallel, holding up transmission on one session while waiting for a timeout doesn't have to hurt communication performance on the association as a whole. Timeout intervals that would be intolerably optimistic in TCP don't necessarily hurt LTP's bandwidth utilization 🙌

But the reciprocal half-duplex nature of LTP communication makes it infeasible to use statistical analysis of round-trip history to predict round-trip time 🚫 The round-trip time for transmitted segment N could easily be orders of magnitude greater than that for segment N-1 if there happened to be a transient loss of connectivity between the segment transmissions. So a different mechanism for computing timeout intervals is needed 🦋

2.2. Why Not TCP or SCTP? 🦋

okay so these environment vibes, long and wildly variable delays, on-and-off connectivity, and kinda high error rates, mean that using plain unmodified TCP for end-to-end communication in the IPN is just not it 💀 Using the TCP throughput equation from [TFRC], we can work out the loss event rate (p) you'd need to hit a given steady-state throughput. We're assuming the minimum RTT to Mars from Earth is 8 minutes (the one-way speed of light delay to Mars at its closest approach to Earth is 4 minutes), a packet size of 1500 bytes, and that the receiver acknowledges every other packet. We also ignore the negligible higher-order terms in p (so, the second additive term in the denominator of the TCP throughput equation) 🧮 and the result is this table of loss event rates for different throughputs:

   Throughput              Loss event rate (p)
   ----------              -------------------
     10 Mbps                  4.68 * 10^(-12)
      1 Mbps                  4.68 * 10^(-10)
    100 Kbps                  4.68 * 10^(-8)
     10 Kbps                  4.68 * 10^(-6)

Note that even though multiple losses within a single RTT count as one loss event in the TCP throughput equation [TFRC], those loss event rates are still unrealistic on deep-space links 🙈

For this discussion, we're not looking at the more aggressive TCP throughput equation that HighSpeed TCP [HSTCP] uses. Not the vibe we need right now ✨

Then there's TCP's initial three-way handshake for every new connection, followed by slow-start. Those are another blocker, because the handshake delay plus the extra slow-start delay could be absolutely exorbitant in a long-delay environment 😭

SCTP [SCTP] can multiplex "chunks" (units of application data) for multiple sessions over a single-layer connection (called an 'association' in SCTP terminology), just like LTP does 🫶 But it still needs multiple round trips before it can send any application data for session setup, so it clearly doesn't suit the IPN operating environment 💅

3. Protocol Overview 🌸

3.1. Nominal Operation 🚀

The nominal sequence of events in an LTP transmission session goes like this.

It all starts when a client service instance asks an LTP engine to transmit a block of data to a remote client service instance.

LTP treats each block of data as having two parts: a "red-part", whose delivery must be assured by acknowledgment and retransmission as necessary, followed by a "green-part" whose delivery is attempted but not assured 💖 Either part can have a length of zero, so a block can be entirely red (retransmission keeps going until the receiver has asserted reception of the whole block) or entirely green (no part of the block is acknowledged or retransmitted). That means LTP can give you both TCP-like and UDP-like functionality at the same time on a single session 🎀

Note that in a red-green block transmission, the red-part data does NOT have any urgency or higher-priority semantics relative to the block's green-part data 🚨 The red-part data is just data the user asked to send reliably, and it's possibly (though not necessarily) data the green-part can't be useful without, like an application-layer header or other metadata.

The client service instance uses the LTP implementation's application programming interface to tell LTP the identity of the remote client service instance the data must go to, where the data is located, the total length of the data, and how many leading data bytes should be sent reliably as "red" data 💅 The sending engine then starts a transmission session for this block and tells the client service instance the session has started. LTP communication session parameters aren't negotiated, though. They're asserted unilaterally, subject to application-level network management activity. The sending engine does not negotiate the start of the session with the remote client service instance's engine 🙅‍♀️

Next, the sending engine makes the original transmission: it queues as many data segments as needed to send the entire block, within the maximum segment size limits imposed by the underlying communication service 🧚 The last segment of the red-part is marked as the end of red-part (EORP), which signals the end of red-part data for the block. It's also marked as a checkpoint (identified by a unique checkpoint serial number), which tells the receiving engine it must issue a reception report upon receiving that segment. The very last segment of the block overall is marked end of block (EOB), so the receiving engine can work out the size of the block by adding up the offset and length of the data in that segment 🍓

LTP is designed to run directly over a data-link layer protocol, but it can also be deployed directly over UDP in some cases (i.e., for software development or in private local area networks) 💜 Either way, the protocol layer directly beneath LTP is called the "local data-link layer" here.

At the next opportunity, and subject to bandwidth being allocated to the queue the block's data segments were written into, the enqueued segments and their lengths get passed down to the local data-link layer protocol (which might be UDP/IP) through that protocol's API, for transmission to the LTP engine serving the remote client service instance 🌈

A timer starts for the EORP, so it can be retransmitted automatically if no response comes back ⏰

Each local data-link layer protocol data unit (link-layer frame or UDP datagram) is required to contain an integral number of LTP segments, and the local data-link layer protocol is required never to deliver incomplete LTP segments to the receiving LTP engine 👑 When the local data-link layer protocol is UDP, the LTP authentication [LTPEXT] extension should be used to ensure data integrity, unless the end-to-end path is one where either corrupted datagram content is negligible (like some private local area networks) or receiving and processing corrupt LTP segments has insignificant consequences (maybe during software development) 🔥 When the LTP authentication extension isn't used, LTP requires the local data-link layer protocol to do integrity checking on all segments it receives. Specifically, the local data-link layer protocol is required to detect any corrupted segments that arrive and discard them silently 🤫

Any received segments that weren't discarded get passed up to the receiving LTP engine through the API supported by the local data-link layer protocol ✨

When the first data segment for the block arrives, the receiving engine starts a reception session for this block and tells the local instance of the relevant client service that the session has started 🎀 In the nominal case, it receives every segment of the original transmission without error. So when it gets the EORP data segment, it (a) queues a report segment for transmission to the sending engine, indicating complete reception, and (b) delivers the received red-part of the block to the local instance of the client service. For each data segment of the green-part, it immediately delivers the received data to the local instance of the client service 🦋

All delivery of data and protocol event notices to the local client service instance is done using the LTP implementation's application programming interface 📮

Note that since LTP data flows are unidirectional, LTP's data acknowledgments (the "reception reports") can't be piggybacked on data segments the way they are in TCP 🙃 They're carried in a separate segment type instead.

At the next opportunity, the enqueued report segment is immediately sent to the sending engine, and a timer starts so the report segment can be retransmitted automatically if no response comes back 💌

The sending engine receives the report segment, turns off the timer for the EORP, queues a report-acknowledgment segment for transmission to the receiving engine, and tells the local client service instance that the red-part of the block has been successfully transmitted. The session's red-part transmission has now ended 🥹

At the next opportunity, the enqueued report-acknowledgment segment is immediately sent to the receiving engine 🌷

The receiving engine gets the report-acknowledgment segment and turns off the timer for the report segment. The session's red-part reception has now ended, and transmission of the block is complete 🎉

Setting up a communication link across interplanetary distances may require hardware configuration changes based on the presumed operational state of the remote communicating entity. For example:

  • orienting a directional antenna correctly;
  • tuning a transponder to pre-selected transmission and/or reception frequencies; and
  • diverting precious electrical power to the transponder at the last possible moment, and for the minimum necessary length of time ⚡

So we assume the operating environment LTP runs in can pass information about link status (called "link state cues" in this document) to LTP 🛰️ That tells LTP which remote LTP engine(s) should currently be transmitting to the local LTP engine, and vice versa. The operating environment itself has to have this information in order to configure the communication link hardware correctly 💜

3.1.2. Deferred Transmission

okay so link state cues also tell LTP when it's possible to send segments and when it's not 🛰️✨ in deep space there is never any expectation of two-way connectivity, bestie 😭 so LTP can ALWAYS be generating outbound segments (because of received segments, timeouts, or requests from client services) that can't go out right away. those segments have to wait in line until a link is up, which a link state cue tells us about 🫶

in concept, every outbound LTP segment gets added to one of two queues 💅 those two queues together make a queue-set for the LTP engine that is that segment's destination. one queue is the "internal operations queue" of that queue set, and the other is the application data queue for that same queue set 🎀 de-queuing a segment always means handing it to the underlying communication system for immediate transmission 🚀 whenever the internal operations queue has anything in it, the oldest segment in that queue is the next one out the door to the destination. otherwise, the oldest segment in the application data queue goes next 🌸

the production and enqueuing of a segment and its actual transmission afterward are, in principle, totally asynchronous 🦋

so when does a segment skip the line? 👑 it gets transmitted immediately upon production when all three of these are true:

  • (a) a transmission link to the destination is currently active
  • (b) the queue it's being appended to is otherwise empty
  • (c) either that queue is the internal operations queue, or the internal operations queue is empty

transmission of a newly queued segment gets deferred in every other situation 🙈

conceptually, de-queuing from the traffic queues bound for a given destination starts when a link state cue says the underlying communication system is now transmitting to that destination (aka the link is active) 💜 and it stops when a link state cue says the system is no longer transmitting to that destination (aka the link is no longer active) 🌈

3.1.3. Timers

LTP needs accurate guesses for when report and acknowledgment segments should arrive, so it knows when to retransmit proactively 🧚 if a calculated time is even a little bit early, you get costly, unnecessary retransmissions 😩 but calculated arrival times can safely run several seconds late! the only downsides of a late timeout and retransmission are slightly delayed data delivery and slightly delayed release of session resources, which is honestly pretty chill 🍓

since statistics from round-trip history can't safely be used to predict LTP round-trip times, we have to assume round-trip timing is at least roughly deterministic 🔮 that means accurate enough RTT estimates can be computed one at a time, in real time, from the info that's available ✨

this computation happens in two stages:

  • we start with a first approximation of RTT by doubling the known one-way light time to the destination and adding an arbitrary margin for any other anticipated latency, like queuing and processing delay at both ends of the transmission 💖 for deep-space operations, the margin is typically a small number of whole seconds. yes it's enormous by Internet standards 😭 but it's totally insignificant compared to the two-way light time in deep space. we choose to risk a tardy retransmission (which only postpones delivery of one block by a relatively tiny increment) over a premature retransmission (which would waste precious bandwidth and degrade overall performance) 💅
  • then, to account for the extra delay caused by interrupted connectivity, we dynamically suspend timers during periods when the relevant remote LTP engines are known to be unable to transmit responses 🦋 this knowledge about the operational state of remote entities is assumed to come from link state cues in the operating environment 👑

the following discussion is the basis for LTP's expected arrival time calculations 🌸

the total time for a single "round trip" (sending and receiving the original segment, then sending and receiving the acknowledging segment) has these components:

  • Protocol processing time: the time spent issuing the original segment, receiving it, generating and issuing the acknowledging segment, and receiving the acknowledging segment.
  • Outbound queuing delay: the delay at the sender of the original segment while it sits in a queue waiting for transmission, plus the delay at the sender of the acknowledging segment while that one waits in a queue for transmission.
  • Radiation time: the time that passes while all bits of the original segment are being radiated, plus the time while all bits of the acknowledging segment are being radiated. (this only matters at extremely low data transmission rates 🐢)
  • Round-trip light time: the signal propagation delay at the speed of light, in both directions 🌟
  • Inbound queuing delay: the delay at the receiver of the original segment while it's in a reception queue, plus the delay at the receiver of the acknowledging segment while it's in a reception queue.
  • Delay in transmission of the original segment or the acknowledging segment due to loss of connectivity. that means an interruption in outbound link activity at the sender of either segment, because of occultation, a scheduled end of tracking pass, etc. 🌙

in this context, where errors on the order of seconds or even minutes are tolerable, protocol processing time at each end of the session is assumed to be negligible 🧁

inbound queuing delay is also assumed to be negligible, because even on small spacecraft, LTP processing speeds are high compared to data transmission rates 🚀

there are two mechanisms that make outbound queuing delay negligible:

  • the expected arrival time of an acknowledging segment doesn't get calculated until the exact moment the underlying communication system tells LTP that radiation of the original segment has begun. by that point, all outbound queuing delay for the original segment has already happened 💜
  • LTP's deferred transmission model keeps latency low when delivering acknowledging segments (reports and acknowledgments) to the underlying communication system 🫶 in concept, acknowledging segments get added to the internal operations queue instead of the application data queue, so they have higher transmission priority than any other outbound segments. that means they should always be de-queued for transmission first 🔥 this limits outbound queuing delay for a given acknowledging segment to just the time needed to de-queue and radiate all previously generated acknowledging segments that haven't been de-queued yet. since acknowledging segments are sent infrequently and are normally very small, their outbound queuing delay is likely to be minimal ✨

calculating the expected arrival time of the acknowledging segment only when the original segment is radiated has an extra perk: it removes from consideration any transmission delay of the original segment caused by loss of connectivity at the original segment's sender 🌈

radiation delay at each end of the session is simply segment size divided by transmission data rate 🍓 it's insignificant unless the data rate is extremely low (for example, 10 bps). in that case, LTP may well be inadvisable for other reasons. (LTP header overhead, for example, could be too much at data rates like that 🙈) so radiation delay is normally assumed to be negligible 💅

we assume that one-way light time to the nearest second can always be known (for example, provided by the operating environment) 🛰️

so the initial expected arrival time for each acknowledging segment is typically computed as the current time at the moment radiation of the original segment begins, plus twice the one-way light time, plus 2*N seconds of margin. that margin covers processing and queuing delays and radiation time at both ends 🎀 N is a parameter set by network management, and 2 seconds seems to be a reasonable default value for it 💖

this leaves only one unknown: the additional round-trip time introduced by loss of connectivity at the sender of the acknowledging segment. to account for it, we again rely on external link state cues 🦋 whenever a link state cue signals that transmission at a remote LTP engine has been interrupted, we suspend the countdown timers for all acknowledging segments expected from that engine ⏸️ then, when a signal says transmission has resumed at that engine, we resume those timers. effectively, we add the length of the timer suspension interval to each expected arrival time 🌸 bestie, that's the whole timer situation, and it's giving precision 👑💅

3.2. Retransmission ✨

okay so, losing or corrupting transmitted segments can totally knock LTP off the nominal sequence of events we just went over 🙈

Losing one or more red-part data segments (other than the EORP segment) triggers data retransmission 💅 The receiving engine sends back a reception report listing all the contiguous ranges of red-part data it actually got. This assumes no discretionary checkpoints were received, which we'll get to in a sec 🦋 The reception report is normally sent in a single report segment that carries a unique report serial number and the scope of red-part data it covers. Example time: if the red-part data covered block offsets [0:1000] and everything except the segment in range [500:600] arrived, the report segment with a unique serial number (say 100) and scope [0:1000] would carry two report entries: (0:500) and (600:1000) 🍓

The max size of a report segment, like all LTP segments, is limited by the data-link MTU 📏 So if a bunch of non-contiguous segments went missing in a big block transmission and/or the data-link MTU is pretty small, multiple report segments need to be generated. In that case LTP generates as many report segments as necessary and splits the scope of red-part data covered across them, so that each one can stand on its own 👑 For example, if three report segments are needed for a reception report covering red-part data in range [0:1,000,000], they could look like this: RS 19, scope [0:300,000], RS 20, scope [300,000:950,000], and RS 21, scope [950,000:1,000,000]. In all cases, a timer is started upon transmission of each report segment of the reception report ⏰

When the sending engine gets each report segment, it does the following:

  • It turns off the timer for the checkpoint referenced by the report segment, if there is one.
  • It enqueues a reception-acknowledgment segment acknowledging the report segment (this turns off the report retransmission timer at the receiving engine). This segment is sent immediately at the next transmission opportunity.
  • If the reception claims in the report segment show that not all data within the scope has been received, it normally kicks off a retransmission by enqueuing all data segments not yet received. The last such segment is marked as a checkpoint and contains the report serial number of the report segment that the retransmission is responding to. These segments are likewise sent at the next transmission opportunity, but only after all data segments previously queued for the receiving engine have been sent. A timer is started for the checkpoint, so it can be retransmitted automatically if no responsive report segment shows up 🔁
  • On the other hand, if the reception claims in the report segment show that all data within the scope of the report segment has been received, and the union of all reception claims received so far in this session shows that all data in the red-part of the block has been received, then the sending engine tells the local client service instance that the red-part of the block was successfully transmitted. The session's red-part transmission has ended 🎉

When the receiver gets a report-acknowledgment segment, it turns off the timer for the referenced report segment ✅

When the receiving engine gets a checkpoint segment with a non-zero report serial number, it does the following:

  • It returns a reception report made up of as many report segments as needed to report in detail on all data reception within the scope of the referenced report segment. A timer is started for each report segment.
  • If at this point all data in the red-part of the block has been received, the receiving engine delivers the received block's red-part to the local instance of the client service. Then, once it gets reception-acknowledgment segments acknowledging all report segments, the session's red-part reception ends and transmission of the block is complete. Otherwise, the data retransmission cycle keeps going 🔄

If a checkpoint segment or the report segment generated in response gets lost, that causes a timer expiry. When this happens, the sending engine normally retransmits the checkpoint segment 😭 Same vibe for the other side: if a report segment or its corresponding report-acknowledgment segment is lost, the report segment's timer expires, and the receiving engine normally retransmits the report segment 💀

Also, a redundant reception of a report segment (one that the sender already received and processed), like when it gets retransmitted because the report-acknowledgment segment was lost, causes another report-acknowledgment segment to be sent back in response. Otherwise it's ignored 🙈 If any data segments that were retransmitted in response to the original reception of the report segment got lost, those will be requested again by the reception report generated in response to the last retransmitted data segment marked as a checkpoint. So unnecessary retransmission is suppressed. no extra traffic, bestie 🫶

Also also, the responsibility for dealing with segment loss in LTP is shared between the sender and the receiver of a block 🤝 The sender retransmits checkpoint segments in response to checkpoint timeouts, and it retransmits missing data in response to reception reports that show incomplete reception. Meanwhile, the receiver retransmits report segments in response to timeouts. An alternative design would have been to make the sender responsible for all retransmission. In that case the receiver wouldn't expect report-acknowledgment segments and wouldn't retransmit report segments. There are two disadvantages to that approach:

First, because of constraints on segment size that the underlying communication service might impose, it's at least remotely possible that the response to any single checkpoint could be multiple report segments. An additional sender-side mechanism would be needed to detect and respond to the loss of some proper subset of those reception reports. We believe the current design is simpler 🧠

Second, an engine that receives a block needs a way to figure out when the session can be closed. Without an explicit final report acknowledgment (which would mean retransmitting the report if the report acknowledgment got lost), the options are (a) to close the session immediately on transmission of the report segment that signifies complete reception, or (b) to close the session on receipt of an explicit authorization from the sender. With option (a), if the final report segment gets lost, the sender retransmits a checkpoint, but the session no longer exists when that retransmitted checkpoint shows up. The checkpoint could reasonably be read as the first data segment of a new block, most of which was lost in transit, and the result would be redundant retransmission of the entire block 😩 With option (b), the explicit session termination segment and the responsive acknowledgment from the receiver (needed to turn off the timer for the termination segment, which would be needed in case the termination segment gets lost or corrupted in transit) would make the protocol more complicated, use up more bandwidth, and delay the release of session state resources at the sender. Once again, we think the current design is simpler and more efficient 💅

3.3. Accelerated Retransmission ⚡

Data segment retransmission only happens when a report segment indicating incomplete reception is received. Report segments are normally transmitted only at the end of the original transmission of the red-part of a block, or at the end of a retransmission. Some applications might want to trigger data segment retransmission incrementally while the red-part is still being originally transmitted, so that missing segments get recovered sooner 🏃‍♀️ There are two ways to make that happen:

  • Any red-part data segment prior to the EORP can also be flagged as a checkpoint. Each time one of these "discretionary" checkpoints is received, the receiving engine issues a reception report.
  • At any time during the original transmission of a block's red-part (that is, before any data segment of the block's green-part has been received), the receiving engine can unilaterally issue additional asynchronous reception reports. Fun fact: the CFDP protocol's "Immediate" mode is an example of this sort of asynchronous reception reporting [CFDP]. The reception reports generated for accelerated retransmission are processed in exactly the same way as the standard reception reports 🦋

3.4. Session Cancellation 🛑

A transmission session can be canceled by either the sending or the receiving engine. That can happen in response to a request from the local client service instance, or to an LTP operational failure as noted earlier. Here's how session cancellation works 📝

The canceling engine deletes all currently queued segments for the session and tells the local instance of the affected client service that the session is canceled. If no segments for this session have been sent to or received from the corresponding LTP engine yet, then at this point the canceling engine just closes its state record for the session, and cancellation is complete 🎀

Otherwise, a session cancellation segment is queued for transmission. At the next opportunity, the enqueued cancellation segment is immediately transmitted to the LTP engine serving the remote client service instance. A timer is started for the segment, so it can be retransmitted automatically if no response comes back 🔔

The corresponding engine receives the cancellation segment, enqueues a cancellation-acknowledgment segment for transmission to the canceling engine, deletes all other currently queued segments for the indicated session, tells the local client service instance that the block has been canceled, and closes its state record for the session 👋

At the next opportunity, the enqueued cancellation-acknowledgment segment is immediately transmitted to the canceling engine.

When the canceling engine receives the cancellation-acknowledgment, it turns off the timer for the cancellation segment and closes its state record for the session ✨

If a cancellation segment or the responsive cancellation-acknowledgment gets lost, the cancellation segment timer expires. When that happens, the canceling engine retransmits the cancellation segment 🥺

4. Security Considerations 🔐

okay bestie, we need to talk about security 😭 There's a real risk that unintended receivers can eavesdrop on LTP transmissions over satellite and other radio broadcast data links 📡. Those unintended recipients might also be able to tamper with LTP segments whenever they feel like it 💀

So we potentially need confidentiality, integrity, and anti-DoS (Denial of Service) security services and mechanisms 🛡️

DoS problems are way more serious for LTP than for typical Internet protocols ⚠️ LTP keeps state around for long periods and has really long time-out values ⏳ And it could be hard to reset LTP nodes to recover from an attack 🙈 So any adversary who can actively attack an LTP transmission can cause severe DoS conditions for the LTP receiver. Not it 💅

Here's a terrestrial example 🌍 If LTP were used in a sparse sensor network, DoS attacks could make nodes miss critical information, like communications schedule updates 📉 In that case, one successful DoS attack could knock a node completely off the network until someone physically visited it and reset it 😭

Even for deep-space applications of LTP, we still need to think about certain terrestrial attacks 🚀 Especially the ones that insert messages into an ongoing session, usually without having seen the exact bytes of the previous messages in that session 👀 These attacks are likely when firewalls fail at various nodes in the network, or when Trojan software is running on an authorized host 🦠 Lots of message insertion attacks depend on the attacker correctly "guessing" something about the state of the LTP peers, but experience shows that successful guesses are easier than you'd think [DDJ] 🎲

Now let's look at which layer(s) security mechanisms can be deployed at to boost the security properties of LTP, plus the trade-offs that come with each one ✨

The Application layer (above-LTP) 🎀

Higher-layer security mechanisms clearly protect the LTP payload, but they leave the LTP headers open 🔓 They provide little or no protection against DoS type attacks against LTP, but they may well provide sufficient data integrity and ought to be able to provide data confidentiality 💖

The LTP layer 🌸

An authentication header (similar to IPsec [AH]) can help protect against replay attacks and other bogus packets 🛡️ However, an adversary may still see the LTP header of segments passing by in the ether 👁️ This approach also requires some key management infrastructure to be in place in order to provide strong authentication, which may not always be an acceptable overhead 😩 Still, such an authentication header could mitigate many DoS attacks 💜

A confidentiality service could also be defined for LTP payload and (some) header fields 🔐 But this seems less attractive, since (a) confidentiality is arguably better provided either above or below the LTP layer, (b) key management for such a service is harder (in a high-delay context) than for an integrity service, and (c) forcing LTP engines to attempt decryption of incoming segments can in itself provide a DoS opportunity 🙅‍♀️

Within the LTP layer we can also make various design decisions to reduce the probability of successful DoS attacks 🧠 In particular, we can mandate that values for certain fields in the header (session numbers, for example) be chosen randomly 🎲

The lower layers can clearly provide confidentiality and integrity services 🔒 But that security may cause unnecessary overhead if the cryptographic service is not required for all data 😬 For example, it can be harder to manage the lower layers so that only the data that needs encryption is actually encrypted 🫠 Encrypting everything could be a significant overhead for some LTP use cases 📦 Still, the lower layers are often where compression and error-correction happen, so they may well be the optimal place to do encryption too, since the same issues with applying or not applying the service apply to both encryption and compression ✨

In light of these considerations, LTP includes the following security mechanisms:

  • The optional LTP Authentication mechanism is an LTP segment extension 🪪 It comprises a ciphersuite identifier and optional key identifier that precede the segment's content, plus an authentication value (either a message authentication code or a digital signature) that follows the segment's content. The ciphersuite ID is used to indicate the length and format of the authentication value. The authentication mechanism serves to assure the segment's integrity and, depending on the ciphersuite selected and the key management regime, its authenticity 💅
  • The optional LTP cookie mechanism is an LTP segment extension 🍪 It comprises a "cookie" -- a randomly chosen numeric value -- that precedes the segment's content. By increasing the number of bytes in a segment that cannot be easily predicted by an inauthentic data source, and by requiring that segments lacking the correct values of these bytes be silently discarded, the cookie mechanism makes it harder to mount a successful denial-of-service attack on an LTP engine 🛑

The above mechanisms are defined in detail in the LTP extensions document [LTPEXT] 📚

Also, the serial numbers of LTP checkpoints and reports are required to be randomly chosen integers, and implementers are encouraged to choose session numbers randomly as well 🎰 This randomness adds one more layer of protection against DoS attacks 🛡️ See [PRNG] for recommendations related to randomness 🌈

5. IANA Considerations 🎀

Please see the IANA Considerations sections of [LTPSPEC] and [LTPEXT] 📋

6. Acknowledgments 💌

Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for their thoughts on this protocol and its role in Delay-Tolerant Networking architecture 🙏 🫶

Part of the research described in this document was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration 🚀 This work was performed under DOD Contract DAA-B07-00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA Contract NAS7-1407 📑

Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel Myers at Ohio University for their suggestions and advice in making various design decisions 🎓 This work was done when Manikantan Ramadas was a graduate student at the EECS Dept., Ohio University, in the Internetworking Research Group Laboratory 🌟

Part of this work was carried out at Trinity College Dublin as part of the SeNDT contract funded by Enterprise Ireland's research innovation fund 🍀

7. References 📚

7.1. Informative References 🔎

[LTPSPEC] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
          Transmission Protocol - Specification", RFC 5326, September
          2008.

[LTPEXT]  Farrell, S., Ramadas, M., and S. Burleigh, "Licklider
          Transmission Protocol - Security Extensions", RFC 5327,
          September 2008.

[AH]      Kent, S., "IP Authentication Header", RFC 4302, December
          2005.

[BP]      Scott, K. and S. Burleigh, "Bundle Protocol Specification",
          RFC 5050, November 2007.

[CFDP]    CCSDS File Delivery Protocol (CFDP). Recommendation for
          Space Data System Standards, CCSDS 727.0-B-2 BLUE BOOK
          Issue 1, October 2002.

[DDJ]     I. Goldberg and E. Wagner, "Randomness and the Netscape
          Browser", Dr. Dobb's Journal, 1996, (pages 66-70).

[DSN]     Deep Space Mission Systems Telecommunications Link Design
          Handbook (810-005) web-page,
          "http://eis.jpl.nasa.gov/deepspace/dsndocs/810-005/"

[DTN]     K. Fall, "A Delay-Tolerant Network Architecture for
          Challenged Internets", In Proceedings of ACM SIGCOMM 2003,
          Karlsruhe, Germany, Aug 2003.

[IPN]     InterPlanetary Internet Special Interest Group web page,
          "http://www.ipnsig.org".

[TFRC]    Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
          Friendly Rate Control (TFRC): Protocol Specification", RFC
          3448, January 2003.

[HSTCP]   Floyd, S., "HighSpeed TCP for Large Congestion Windows",
          RFC 3649, December 2003.

[SCTP]    Stewart, R., Ed., "Stream Control Transmission Protocol",
          RFC 4960, September 2007.

[PRNG]    Eastlake, D., 3rd, Schiller, J., and S. Crocker,
          "Randomness Requirements for Security", BCP 106, RFC 4086,
          June 2005.

Authors' Addresses 🏡

Scott C. Burleigh
Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S: 301-485B
Pasadena, CA 91109-8099
Telephone: +1 (818) 393-3353
Fax: +1 (818) 354-1075
EMail: Scott.Burleigh@jpl.nasa.gov


Manikantan Ramadas
ISRO Telemetry Tracking and Command Network (ISTRAC)
Indian Space Research Organization (ISRO)
Plot # 12 & 13, 3rd Main, 2nd Phase
Peenya Industrial Area
Bangalore 560097
India
Telephone: +91 80 2364 2602
EMail: mramadas@gmail.com


Stephen Farrell
Computer Science Department
Trinity College Dublin
Ireland
Telephone: +353-1-896-1761
EMail: stephen.farrell@cs.tcd.ie

Copyright (C) The IETF Trust (2008) 🩷

This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights ✍️

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🙃

Intellectual Property 💼

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights 🤷‍♀️ Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79 📖

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr 🗂️

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org 💌🦋

📦 where this page comes from