From Nsnam
Jump to: navigation, search

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 Summer 2014 Projects page.

Project overview

  • Project name: TCP Versions for Satellite communications.
  • Abstract: With regards to transport protocols, and with satellite links in mind, at the moment ns-3 has only few TCP congestion control algorithms (Reno, Tahoe, and NewReno) and no one is targeted for satellite systems. It also doesn't support required extensions to improve performance over satellite's link, like TCP Window Scaling or SACK/SNACK, making it not really suitable to simulate (or emulate) modern satellite-based networks. Anyway, thanks to its modular architecture and flexibility of the entire framework, it is possible to add such extensions and write satellite-focused TCP congestion control algorithms. The goal of this project is to add to ns-3 TCP codebase the required extensions (RFC2488) and various satellite-focused TCP versions, in order to improve the simulator in this field.


A list of possible TCP protocols designed for links with high bandwidth-delay product (e.g. satellite ones) to implement on ns-3 are TCP HighSpeed, TCP Hybla, and TCP Noordwijk. As these versions require TCP extensions named in the RFC 2488 (Enhancing TCP Over Satellite Channels using Standard Mechanisms). The approach is to add first such; there is already a pending patch for these features (namely TCP Window Scaling and TCP timestamps, used in RTT Measurement and Protection Against Wrapped Sequences, mandatory over a satellite link) with a series of comments by the community. The goal is to take these set of patches and implement the suggestions of the community, in order to be able to subsequently code the previously mentioned TCP variants. Each one has some distinctive points: TCP HighSpeed for example change the congestion avoidance phase with respect to standard TCP. To remove limitations of the high RTT, TCP Hybla try to perform like a NewReno connection would with a low reference RTT (for example 25ms). The last, TCP Noordwijk, completely change the paradigm of TCP, from window-based to burst-based. The testing of the code will be driven by DCE, as they are currently present in the Linux kernel (the only TCP to be developed kernel-side is Noordwijk).

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.

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.


As final deliverables, I'll present two set of patches which will cleanly apply over the last version of the ns-3 simulator: the first will regards the TCP extensions part, and the second the TCP congestion control algorithms for satellite communications.

  • Deliverable 1 - TCP Extensions
Deliverable 1.1 - General TCP extension support
Deliverable 1.2 - Timestamps
Deliverable 1.3 - Window scaling
Deliverable 1.4 - Test for the tcp options

Code review issue:

  • Deliverable 2 - TCP versions
Deliverable 2.1 - TCP Hybla
Deliverable 2.2 - TCP HighSpeed
Deliverable 2.3 - TCP Noordwijk
Deliverable 2.4 - Unit Tests

Code review issue:

  • Deliverable 3 - examples : this deliverable will contain several examples on how to install and use the various TCP protocols and options.


  • Week 1: Initial report over the status of the TCP extensions, and the possibile changes of original patches
  • Week 2: TCP extension implementations
  • Week 3: TCP extension test implementation
  • Week 4: TCP Hybla implementation
  • Week 5: TCP Hybla implementation
  • Week 6: TCP HS implementation
  • Week 7: TCP HS implementation
  • Week 8: TCP Noordwijk implementation
  • Week 9: TCP Noordwijk implementation
  • Week 10: Safety week: will use it if needed at some point of the plan
  • Week 11: Safety week: will use it if needed at some point of the plan
  • Week 12: Safety week: will use it if needed at some point of the plan

Weekly Reports

Week 1

Imported the patches, and made edit to respect the comments over that changeset (including, but not limited to, enum the TCP Options, clear a little the namespace).

Initial work for Timestamp and Window Scaling.

From a code point of view, each option is an attribute to the TcpSocketBase (for example "Timestamp") in order to enable/disable the options. Associated with it, there is another boolean value to represent if the option is active or not (the counterpart could not have it enabled). All the semantics is done in methods of TcpSocketBase.

Week 2

Let's start from the easy part:

  • Documented the existing code
  • Fixed a bug which could lead to a miscalculation of timestamp
  • Code refactoring on TcpOption (objectFactory, and a static lookup table).

Just a little word, for anyone, which doesn't want to look deep in the code. The solution I'm using is:

   9.24 +  struct kindToTid
   9.25      {
   9.26 -      return CreateObject<TcpOptionEnd> ();
   9.27 +      TcpOption::Kind kind;
   9.28 +      TypeId tid;
   9.29 +    };
   9.30 +
   9.31 +  static ObjectFactory objectFactory;
   9.32 +  static kindToTid toTid[] =
   9.33 +    {
   9.34 +      { TcpOption::END,       TcpOptionEnd::GetTypeId () },
   9.35 +      { TcpOption::MSS,       TcpOptionMSS::GetTypeId () },
   9.36 +      { TcpOption::NOP,       TcpOptionNOP::GetTypeId () },
   9.37 +      { TcpOption::SACK,      TcpOptionSack::GetTypeId () },
   9.38 +      { TcpOption::SACK_PERM, TcpOptionSackPermitted::GetTypeId () },
   9.39 +      { TcpOption::SNACK,     TcpOptionSnack::GetTypeId () },
   9.40 +      { TcpOption::TS,        TcpOptionTS::GetTypeId () },
   9.41 +      { TcpOption::WINSCALE,  TcpOptionWinScale::GetTypeId () }
   9.42 +    };
   9.43 +
   9.44 +  for (unsigned int i=0; i < sizeof(toTid)/sizeof(kindToTid); ++i)
   9.45 +    {
   9.46 +      if (toTid[i].kind == kind)
   9.47 +        {
   9.48 +          objectFactory.SetTypeId(toTid[i].tid);
   9.49 +          return objectFactory.Create<TcpOption> ();
   9.50 +        }
   9.51      }
   9.81    return 0;

I suspect that it is the same which gcc is doing by enabling -O2 (and -O3) flag, but anyway the code look really clean now.

And then, the two other part, which need some word.

1) Window scale

Implemented the window scale option; it depends on the buffer side. The main algorithm is (where snd_scale is the scaling factor we send):

  • snd_scale = log2(rxBuffer.Max())
  • adv_win = (rxBuffer.Max() - m_rxBuffer.Size ()) >> snd_scale

In the code, are present some other things to make it RFC-compliant.

2) Testing

I've made the testing cases for the window scaling. The approach I used is the #define one; the first lines of tcp-wscaling-test are

   #define private public
   #define protected public

Wow, that makes me free from encapsulation.. I'm flying free in the sky :-) Anyway, that let me to do things like:

  Ptr<TcpSocketBase> b = DynamicCast<TcpSocketBase> (sock);
  if (m_configuration == ENABLED)
      NS_TEST_EXPECT_MSG_EQ ((b->m_rWnd.Get ()), m_maxSourceBufferSize,
                             "Miscalculating source window");
      NS_TEST_EXPECT_MSG_LT_OR_EQ ((b->m_rWnd.Get () >> b->m_rcvScaleFactor),
                                   b->m_maxWinSize, "Violating maximum adv window");
      NS_TEST_EXPECT_MSG_LT_OR_EQ (b->m_rcvScaleFactor, 14,
                                   "Violating RFC for max value of the scale factor");

Going deep into TcpSocketBase details and see if all is working properly.

Week 3

This week I've coded the serialization/deseralization test and the Tcp HighSpeed proposal.For the upcoming week, I want to add the testing class to the Tcp HighSpeed, and start to work on Tcp Hybla.

Testing the serialization is specified for each option. For example, there is the code for the Timestamp option:

 TcpOptionTSTestCase::TestSerialize ()
   TcpOptionTS opt;
   opt.SetTimestamp (m_timestamp);
   opt.SetEcho (m_echo);
   NS_TEST_EXPECT_MSG_EQ (m_timestamp, opt.GetTimestamp (), "TS isn't saved correctly");
   NS_TEST_EXPECT_MSG_EQ (m_echo, opt.GetEcho (), "echo isn't saved correctly");
   m_buffer.AddAtStart (opt.GetSerializedSize ());
   opt.Serialize (m_buffer.Begin ());

The value saved on the TcpOptionTS class are then written into a buffer, which will be read in another method, called (with a great focus on fantasy) TestDeserialize.

 TcpOptionTSTestCase::TestDeserialize ()
   TcpOptionTS opt;
   Buffer::Iterator start = m_buffer.Begin ();
   uint8_t kind = start.ReadU8 ();
   NS_TEST_EXPECT_MSG_EQ (kind, TcpOption::TS, "Different kind found");
   opt.Deserialize (start);
   NS_TEST_EXPECT_MSG_EQ (m_timestamp, opt.GetTimestamp (), "Different TS found");
   NS_TEST_EXPECT_MSG_EQ (m_echo, opt.GetEcho (), "Different echo found");

Various test are been proposed in the test suite. The code for TCP HighSpeed has been written following the RFC 3649. It consist in an extension to TCP New Reno, which deal with great congestion window. So, in the implementation, a NewReno derived class is created, and the methods NewAck and DupAck have been reimplemented to follow the RFC specifications.

Week 4

Hi all!

In these days I worked on the HighSpeed implementation, spotting and (hopefully) fixing a problem.

Other works done:

  • Testing the Timestamp option, writing down tests
  • Using the timestamps to calculate RTTs for packets

Week 5

Hi all!

As for the things done, in this week I've produced the following thing:

  • Minor bug spotted in the TCP HighSpeed implementation
  • RTT test finished.. and the Timestamp class is working!
  • TCP Hybla implemented (but not committed yet.. see below)

Week 6

In this week I worked on the documentation part of TCP Hybla and HighSpeed. I've started to test the protocols with DCE, but it is a work-in-progress (few bug opened on the bugtracker).

Week 7

For personal issues, this week has delivered no code, but it has been interesting on the design point of view.

I tried solutions for the RttEstimator class, in order to be usable from other pieces of code (patch - with consequent review - is expected tomorrow).

I also have written down a test version of the Noordwijk TCP.

I've validated the TcpHighSpeed and TcpHybla code versus Linux DCE (spotting also two minor bugs in the installation of the DCE itself).

Week 8

The main point focused were TcpNoordwijk and Rtt Estimator.

For Rtt Estimator, a mail will follow with a proposal, in the right thread.

I've updated the code review for Tcp Option [1] (wrt to Tom's comment). I also prepared a code review for others tcp variants [2]. Actually, I have run some test with dce, and the models work well. A note about TcpNoordwijk: IMHO it isn't in a "ready-to-work" state. It is public now, so it can be tested, but it should be refined.