Difference between revisions of "GSOC2014LTP"

From Nsnam
Jump to: navigation, search
(Protocol Validation)
Line 241: Line 241:
== Tests ==
== Tests ==
Test 1: 500 byte block, full red data, no losses. - Received and ACKed. (SUCCESS)
Nominal operation.
Test 2: 1000 byte block, red data and green data.
*Test 1: 500 byte block, full red data. - Received and ACKed. (SUCCESS)
*Test 2: 5000 bytes block, full red data. - Received and ACKed. (SUCCESS)
LTPLib block data: ltpd.in
ltpd -v -m C -D -S
./waf --run "scratch/ltp-emu"
*Test 3: 5000 byte block, red data and green data.
= Weekly Reports =
= Weekly Reports =

Revision as of 18:39, 5 January 2015

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers

Return to GSoC 2014 Accepted Projects page.

Project overview

  • Project name: Licklider Transmission Protocol (LTP).
  • Abstract: Licklider Transmission Protocol (LTP) is a point to point protocol for environments with long round-trip delays (such as deep space communications). This project will provide a RFC compliant implementation, it will consist of a ns-3 module with its corresponding testsuits, examples, helpers and documentation.


This protocol can be deployed at two different leves: on top of either the Data-Link-Layer or the Transport Layer (UDP). The best approach should be to start with an UDP implementation, this will ensure compliance with already existing implementations. A data-link-layer implementation can also be done depending on how the project advances, and will be be taken into consideration after the results of the mid-term review (see schedule section).

Development methodology

I will use an iterative-incremental development methodology, each iteration will include implementation, documentation (doxygen style comments, thorough the source code), and testing. Development will be divided on 3 main tasks:

  • Task 1: This task consist in developing the ltp-headers and a SDNV codec (Self-Delimiting Numeric Values) a type of data encoding used in DTN protocols. This task consist on defining several data-structures and their serialization/deserialization methods.
  • Task 2: This task will focus on developing the backbone of the protocol by defining the classes: ltp-packet-queues, ltp-session-records and the basic structure of the ltp-protocol. This will define the main data structures required in control logic used to handle: packets, sessions, protocol state, timers, etc.
  • Task 3: This task will focus on the Send() and Receive() methods of the ltp-protocol class, these methods implement the control logic of the protocol.

Testing approach

This project will have testing and cross-validation against existing implementations.

First, testing will we performed as part of the development cycle. It will use a test case based approach using the standard methods provided by the ns-3 API in the form of the TestSuite and TestCase classes. This project will have two kind of tests:

  • Unit Tests: each task will have a group of test vectors, those tests will ensure that the internal workings of each developed class works in isolation.
  • System tests: these tests will be provided mainly with examples, it will consist on using the developed module together with already tested ns-3 modules.

Lastly, the implementation will be cross-validated against existing implementations of the LTP, such as ION-DTN (JPL) or LTPlib (Trinity College Dublin). This cross-validation will be performed using a shared file descriptor to which both implementations can read or write traffic. The FdNetDevice class provided by the ns-3 API will be used to achieve this task.


Block Diagram


LTP Protocol Send Logic


LTP Protocol Receive Logic



The final product of the project will be a ns-3 module, so the main deliverables will be the several sections of this module:

  • Deliverable 1 - model and helper: will contain the main functionalities of the protocol and the helper classes to simplify its use.
Deliverable 1.1 - Packet Headers and SDNV codec.
Deliverable 1.2 - LTP-Protocol auxiliary structures (Data Queues and Session State Records).
Deliverable 1.3 - LTP-Protocol Core.
Deliverable 1.4 - LtpNetDevice.
Deliverable 1.5 - LtpStackHelper.
  • Deliverable 2 - test: this deliverable will contain the several testsuits used.
Deliverable 2.1 - Unit Tests. Packet Headers and SDNV codec: check correctness.
Deliverable 2.2 - Unit Tests, LTP-Protocol Auxiliary, check methods, timeouts and data handling correctness.
Deliverable 2.3 - Unit Tests, NetDevice implementation, check methods.
Deliverable 2.4 - Unit Tests: protocol implementation, communication between nodes, retransmissions, cancellation of communication.
  • Deliverable 3 - examples : this deliverable will contain several examples on how to install and use the protocol.
  • Deliverable 4 - Cross-Validation: This deliverable will contain several tests using FdNetDevices to perform cross-validation with existing implementations. (4.1 early tests basic protocol, 4.2 final validation).


  • Week 1 - May 19 - May 25. D-1.1. D-2.1.
  • Week 2 - May 26 - June 1.
  • Week 3 - June 2 - June 8. D-1.2. D-2.2.
  • week 4 - June 9 - June 15.
  • Week 5 - June 16 - June 22.
  • Week 6 - June 23 - June 29: Mid-Term Evaluation.
  • Week 7 - June 30 - July 6. D-1.3. D-2.3. D-4.1.
  • Week 8 - June 7 - July 13.
  • Week 9 - July 14 - July 20. D-1.4.
  • Week 10 - July 21 - July 27. D-1.5
  • Week 11 - July 28 - August 3. D-3, D-2.4
  • Week 12 - August 4 - August 10. D-4.2

Mid Term Review

The code is composed of 2 patches in Rietveld issues 97540043 [1] and 105340046 [2].

The first corresponds to the SDNV [3] encoding supportused in DTN protocols, from which I contributed the test-suite.

The second is a partial implementation of the LTP protocol containing: packet data structures, protocol management classes and basic API functions for communication with higher layer protocols.

To run test suites, the command is ./test.py -s ltp-protocol. Additionally the interested reader can look at the ltp-protocol.rst document, or the wiki page [4] for details on the purpose of each class and how they interact with each other.

Final Code Review

The final code review for the project can be found in [1], this review contains the final version of the model, including a helper, examples, tests and documentation.

The provided test-suites can be run as follows:

    ./test.py -s ltp-protocol
    ./test.py -s ltp-channel-loss

[1] https://codereview.appspot.com/123190043/

List of Features

Convergence Layer Adapter

  • Link state cues (callbacks in convergence layer adapter) : Link Up, Link Down, CP sent, RS sent, EOB dequeued, CX dequeued.

Ltp Core

  • Drop packet procedures: simple discard or Cancellation segment transmission.
  • Start Transmission procedure: Event triggered on reception of Link Up signal. Response: dequeue and tx all packets.
  • Start CP Timer: Event triggered on reception of CP received signal, Response: start CP timer.
  • Stop CP timer : Event triggered on reception of RS segments, response: stop CP timer.
  • Start RS Timer: Event triggered on reception of RS Timer signal, Response: start RS timer.
  • Stop RS Timer: Event triggered by reception of RA, response: stop RS timer.
  • Start Cancel Timer: Event triggered on reception of CX dequeued, response: start cancel timer.
  • Stop Cancel Timer: Event triggered on reception of CAX segment, response: stop cancel timer.
  • Stop Transmission procedure: Event triggered on reception of Link Down, Response: start dequeing of segments.
  • Suspend Timers: Event triggered on reception of Remote peer link Down, Response: suspend timers.
  • Resume Timers: Event triggered on reception of Remote peer link Up, Response: resume timers.
  • Retrans CP: Event triggered by expiration of CP timer, Response: Check Retransmission limit, enqueue new CP segment.
  • Retrans RS: Event triggered by expiration of RS timer, Response: Check Retransmission limit, enqueue new RS segment.
  • Signify Red Part: Reception of EORP and CP, response: Send notification to Client Service instance.
  • Signify Green Data Segment: Reception of GD segment, response: Send notification to Client Service instance.
  • Signify Transmission Completed: All data transmited (signal EOB dequeued) and RP ackd, response: send notification to client service instance and start Close session.
  • Send RP: Original reception of regular CP or asynchronous CP. Response: perform checks then: 1. drop and send CR OR 2. compute bounds of reception claim and send RP.
  • Retrans Data: triggered on reception of RS, response: Send RA segment, stop CP timer, if reception claim indicates incomplete data reception: check retransmission limit then send CS if exceeded or retransmit missed Data segment if not.
  • Retransmit Cancellation segment: triggered on expiration of Cancel timer. response: send copy of CX.
  • ACK cancellation: triggered on reception of CX, response: if received CS send CAS, if received CR sned CAR.
  • Cancel Session: triggered on reception of CAX, reponse: stop cancel timer and close session.
  • Handle Miscolored segments: reception of red-part with offset higher than green-part. response: discard.


  • Management Information Base: Database with times of operation of LTP engines, provides link state cues: Remote peer link Up, Remote peer link Down.
  • Handle System Error conditions.
  • Notifications to Client Service instance: session start, green-part segment arrival, red-part reception, transmission session completion, transmission-session cancellation, reception-session cancellation, initial-transmission completion.
  • Security Extensions.
  • Integrate SOCIS 2013 bundle protocol implementation with LTP in a separate repo (Tom)
  • Set up virtual machine environment with CORE network emulator to test interoperability against ns-3 implementation (Tom)

Features ordered by priority

1. Basic data transmission

  1. Link state cues. DONE
  2. Start Transmission procedure. DONE
  3. Drop packet procedures. DONE (No Cancellation sent for now)
  4. Handle Miscolored segments. DONE
  5. Notifications to Client Service instance. DONE
  6. Signify Red Part. DONE
  7. Signify Green Data Segment. DONE
  8. Signify Transmission Completed. DONE
  9. Stop Transmission procedure. DONE (Partially taking RPs into account)

2. Model validation

  1. Integrate SOCIS 2013 bundle protocol implementation with LTP in a separate repo (Tom)
  2. Set up virtual machine environment with CORE network emulator to test interoperability against ns-3 implementation (Tom)

3. Retransmission based reliability

  1. Send CP. DONE (Only syncronous checkpoints for now).
  2. Send RS. DONE
  3. Send RAS. DONE
  4. Start CP Timer. DONE
  5. Start RS Timer.DONE
  6. Retrams Data + Retrams CP. DONE (merged both cases together)
  7. Stop CP Timer. DONE
  8. Retrans RS: DONE
  9. Stop RS timer.DONE

4. Cancellation

  1. Cancel Session (Send CX)
  2. Start Cancel Timer
  3. Cancel ACK (Send CAX)
  4. Stop Cancel Timer
  5. Retransmit CX

5. Advanced kwnoledge about environment and other considerations

  1. Management Information Base
  2. Suspend Timers
  3. Resume Timers
  4. Handle System Error conditions.
  5. Authentication Extensions.
  6. Security Extensions.

Protocol Validation

The validation is performed using The Common Open Research Emulator (CORE). Ns-3 implementation is validated for interoperability against LTPLib [1]


Start core daemon.

sudo /etc/init.d/core-daemon start

Run core-gui.


Topology setup: two nodes connected with a point to point link <------------->

Notes on installation of LTPlib:

autoreconf --install
sudo apt-get install libssl-dev (required library not being checked by configure)
sudo make install

Node 2 (

Run LTPlib in 2 as server and specify as source (use ltp-deepspace IATA defined port in both sides).

ltpd -v -m S -L -S

Node 1 (

Set eth0 to prosmiscuous mode:

ifconfig eth0 promisc

cd into ns-3 directory and run:

./waf --run "scratch/ltp-emu"


Nominal operation.

  • Test 1: 500 byte block, full red data. - Received and ACKed. (SUCCESS)
  • Test 2: 5000 bytes block, full red data. - Received and ACKed. (SUCCESS)

LTPLib block data: ltpd.in

ltpd -v -m C -D -S


./waf --run "scratch/ltp-emu" 


  • Test 3: 5000 byte block, red data and green data.

Weekly Reports

Week 1

Finished - Deliverables 1.1 and 2.1

  • Providing SDNV [2] encoding support (this a numeric format commonly used on packet fields of DTN protocols). This encoding format was already implemented in Dizhi Zhou's BP wiki/SOCIS2013BundleProtocolProject project. I have expanded it with the corresponding test-suite and moved it to src/network/utils/, for use in both Bundle and LTP protocols. Currently under review in https://codereview.appspot.com/97540043/]
  • Implementation of all LTP packet structures, this includes: Segment Header, Segment Trailer, and Content Header (for all segment variants: data, reports, report acknowledgments, etc.). The implementation including the corresponding tests and documentation.

Week 2

Working on Deliverables 1.2 and 2.2

  • Implementation of the Ltp queue-set, this is a class containing the dual queue structure (internal operations and application data) used for LTP outbound traffic. The implementation and the corresponding test case can be found on the project repository.
  • Implementation of the session state record, this is a class to keep track of the state of an LTP transmission session, this class is basically a wrapper that handles several flags, counters, timers and lists. An early version can be found in the project repository.

Week 3

Working on Deliverables 1.2 and 2.2

  • Fixed several issues in the session state record.
  • Provided a test-case for the session state record.
  • Provided an early concept design for the LTP API.

Week 4

Working on Deliverables 1.3 and 2.3

  • Finished the design of the LTP API functions used for interaction with the upper layer.
  • Included all the required auxiliary structures inside the LTP core class.
  • Performed minor fixes to auxiliary structures.
  • Provided a test-case for the LTP API functions.

Week 5

Working on Deliverables 1.3 and 2.3

  • Documentation: ltp-protocol.rst
  • Preparing the mid-term review.
  • Fixing issues in the LTP API class and small tweaks to auxiliary classes.
  • Improving test-case class..