Difference between revisions of "GSOC2014LTP"

From Nsnam
Jump to: navigation, search
(Week 5)
Line 142: Line 142:
'''Working on Deliverables 1.3 and 2.3 '''
'''Working on Deliverables 1.3 and 2.3 '''
- Documentation: ltp-protocol.rst
*Documentation: ltp-protocol.rst
- Preparing the mid-term review.
*Preparing the mid-term review.
- Fixing issues in the LTP API class and small tweaks to auxiliary classes.
*Fixing issues in the LTP API class and small tweaks to auxiliary classes.
- Improving test-case class..
*Improving test-case class..

Revision as of 11:02, 23 June 2014

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.

Weekly Reports

Week 1

Finished - Deliverables 1.1 and 2.1

  • Providing SDNV [1] 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..