Licklider Transmission Protocol (LTP): An Overview

1. Scott Burleigh Jet Propulsion Laboratory California Institute of Technology 24 July 2007 Licklider Transmission Protocol (LTP):An Overview

2. What it is • A retransmission protocol for delay-tolerant reliable communication between two adjacent points in a network. • Descended from the acknowledged transmission procedures of CFDP, the CCSDS (Consultative Committee for Space Data Systems) File Delivery Protocol. • Originally designed to serve as a “convergence-layer” protocol for the interplanetary leg(s) of an end-to-end path in a delay-tolerant network (DTN). • Runs just above link layer, e.g., CCSDS Telemetry/Telecommand. • May also be useful for some kinds of terrestrial applications, running above UDP/IP.

3. file transfer, messaging, etc. application (convergence-layer adapters) TCP UDP LTP point-to-point reliability LTP point-to-point reliability IP IP PPP, Ethernet, 802.11, SONET… PPP, Ethernet, 802.11, SONET… CCSDS TM/TC CCSDS Prox-1 Where it fits in Bundle Protocol: routing, custody transfer In DTN stack for space network Stand-alone, for terrestrial apps

4. Chronology • Late 2000 – initial LTP design drafts circulated within DTN team. • February 2002 – CFDP approved by CCSDS. • December 2003 – Mani Ramadas (Ohio University) volunteers to work on an Internet Draft for LTP. • March 2004 – Stephen Farrell (Trinity College, Dublin) joins up. • 12 May 2004 – first LTP Internet Draft posted. • Summer of 2004 – Stephen writes first implementation in C++. • 19 August 2005 – Mani releases reference implementation in Java. • 1 December 2006 – Chris Krupiarz (Johns Hopkins University Applied Physics Lab) reports on MESSENGER flight software testbed exercise of an LTP implementation in C.

5. Features • Can handle very large bandwidth-delay product. • Tolerates lengthy, irregular interruption of link without data loss. • No reliance on stability of round-trip time. • Minimizes overhead on low-capacity and/or asymmetric links. • Selective NAKs. Aggregation of small client service data units into larger blocks, acknowledged at block granularity. • Accelerated retransmission: multiple checkpoints per transmitted block, or interim reports prior to reception of checkpoint. • Partial reliability: checkpointing and retransmission for only the first N bytes of a block, and N can be zero. • Extension mechanism is built into the specification. • Currently defined extension segments implement security.

6. How it works • A block of client service data to be transmitted is divided into segments. When the segments are transmitted, some are flagged as checkpoints. Whena checkpoint is received, the receiver returns a report of cumulative reception for that block. • Reports acknowledge checkpoints and either signal successful reception or else trigger retransmission. • Reports are explicitly acknowledged. Reports and checkpoints are on timers, are retransmitted if not acknowledged. • Known changes in remote peer’s transmission state may dynamically revise timers. • Deferred transmission. Multiple transmissions between two peers may be in progress concurrently.

7. OWLT deliver block to client timeoutinterval deliver block to client deliver block to client deliver block to client timeoutinterval no mutual visibility (timersuspended)

8. Timer revision (1 of 3) (A) transmit original segment (D) receive ACK (sender) Original countdown timer OWLT OWLT (S) remote engine suspends transmission (R) remote engine resumes transmission (receiver) (C) transmit ACK (B) receive original segment, queue ACK queuing (etc.) margin time signal propagation time delay for suspended transmission

9. Timer revision (2 of 3) (A) transmit original segment (D) receive ACK (sender) Original countdown timer OWLT OWLT (S) remote engine suspends transmission (R) remote engine resumes transmission (receiver) (C) transmit ACK (B) receive original segment, queue ACK queuing (etc.) margin time signal propagation time delay for suspended transmission

10. Timer revision (3 of 3) (A) transmit original segment (D) receive ACK (D’) receive ACK (sender) Original countdown timer OWLT OWLT (S) remote engine suspends transmission (R) remote engine resumes transmission (receiver) adjusted countdown timer OWLT OWLT (C) transmit ACK (C’) transmit ACK (B) receive original segment, queue ACK queuing (etc.) margin time signal propagation time delay for suspended transmission

11. LTP vs TCP (1 of 2)

12. LTP vs TCP (2 of 2)

13. Status of specifications • Three LTP Internet Drafts began IRSG review in April: • "Licklider Transmission Protocol - Motivation", 4-Apr-07, <draft-irtf-dtnrg-ltp-motivation-04.txt> • "Licklider Transmission Protocol - Specification", 4-Apr-07, <draft-irtf-dtnrg-ltp-06.txt> • "Licklider Transmission Protocol - Extensions", 5-Apr-07, <draft-irtf-dtnrg-ltp-extensions-05.txt>

14. Implementations • Stephen Farrell’s implementation in C++ • Mani Ramadas’s implementation in Java • Chris Krupiarz’s implementation in C, now being extended at JPL • Successful interoperation tests between C++ and Java implementations at November 2006 IETF meeting in San Diego: • nominal operation in both directions • successful operation in both directions with segment drops • red/green in both directions • red/green with drops in C++ Java direction

15. Tracking the work • Home page • http://masaka.cs.ohiou.edu/ltp/ • Mailing list • http://irg.cs.ohiou.edu/mailman/listinfo/ltp/

16. Acknowledgment Part of this work was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration.