Licklider Transmission Protocol (LTP): An Overview

1
Licklider Transmission Protocol (LTP)An Overview

• Scott Burleigh
• Jet Propulsion Laboratory
• California Institute of Technology
• 24 July 2007

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
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.
  When a 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 peers 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)
(D) receive ACK
(A) transmit original segment
(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)
TCP LTP
architectural elements One durable, unbounded connection per pair of ports. Window is buffer of bytes in transit on connection. One temporary, bounded session per transmission unit. Block is buffer of bytes in transit within session.
acknowledgments ACKs on ranges of bytes in window SACK optional. Selective NAKs on ranges of bytes in block.
configuration of communication Connections are dynamically opened, parameters negotiated. No connection protocol. Parameters are managed and asserted.
demux Port number. Different port number at receiver for each connection. Session number. Any number of sessions may be delivering to the same client.
concurrency Number of concurrent open connections is typically limited by number of FDs. Number of concurrently open sessions is limited by available space, possibly management.
12
LTP vs TCP (2 of 2)
TCP LTP
sites of retransmission End-to-end. Retransmission sites are co-located with applications. Point-to-point. Retransmission sites are co-located with routers.
delivery order Bytes delivered in-order within connection. Bytes delivered in-order within session, but sessions may complete out of order.
timers Timeout interval computed from RTT history. Timeout interval computed from known OWLT and link state schedule.
flow control Number of unacknowledged bytes in buffer is limited by each connections window size. Number of unacknowledged bytes in all blocks may be limited by max number of sessions.
congestion control Control window size for each connection slow start, AIMD. No congestion control bundle protocol may do rate control.
13
Status of specifications

• Three LTP Internet Drafts began IRSG review in
  April
• "Licklider Transmission Protocol - Motivation",
  4-Apr-07, ltdraft-irtf-dtnrg-ltp-motivation-04.txtgt
  
• "Licklider Transmission Protocol -
  Specification", 4-Apr-07, ltdraft-irtf-dtnrg-ltp-06
  .txtgt
• "Licklider Transmission Protocol - Extensions",
  5-Apr-07, ltdraft-irtf-dtnrg-ltp-extensions-05.txtgt
  

14
Implementations

• Stephen Farrells implementation in C
• Mani Ramadass implementation in Java
• Chris Krupiarzs 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.