Project Objective:

Extending GSTAR to support inter-domain routing

Approach:

1. To understand the existing Generalized Storage Aware Routing Protocol(GSTAR)
   
2. Performance Analysis of GSTAR on various intra-domain network topologies
   
3. Extension of GSTAR to implement inter-domain routing

Results:

Work Log:

Week 1: Understanding the existing ns-3 based implementation

Week 2: Running sample MobilityFirst example scripts

Week 3: Simulation script for the following wireless ad-hoc network was written and performance analysis was done

The following results were obtained:

Week 4: Simulation script for a mixed topology with some wired nodes and two wireless destination nodes, was written and performance analysis was carried out

Week 5: This week's aim is to generate some mobility trace for the destination nodes, plug it into ns-3 and see how GSTAR performs when the destination nodes are randomly moving

Week 6: While last week's goal (parsing a mobility trace and plugging it into the simulation) worked fine, throughput as seen in the results, saturated at a value far lower than the expected throughput of the network. This week's goal would be look further into the code, as to what is the maximum throughput we could get from a wireless channel, between two nodes (a sender and a receiver)
Calculations showed, from a 54Mbps channel we could get only about 11Mbps of throughput. Further experiments were done to check, whether this is an ns-3 wireless module issue or gstar issue. Next, for a similar 54Mbps channel, between two nodes, sending udp packets, with global routing, a maximum thoughput of about 35Mbps was obtained. Thsi led us to conclude, its possibly an issue internal to the gstar code.

Week 7: This week's aim is to solve this throughput bottleneck. Further analysis was done, to check what is the control overhead for sending a chunk from a node to the next. As seen in the timing diagram, for every packet sent by gstar an 802.11 ack gets exchanged, other than the various gstar control messages getting exchanged in addition to data packets for the transmission of 1 chunk. The possible solution is to increase the data packet and the chunk size so as to transmit more data bytes for the same amount of control messages.

Week 8: Increasing the data packet posed another problem. The simulation started giving ns-3 buffer overflow errors. This week was spent mostly on looking at what could cause such an error, and it was observed, if the data packet size increases above 1500bytes, which is the Mtu for Ipv4, ns-3 crashes, as it lacks the ability to fragment the packets. Once the Mtu was increased above the data packet size, it started working fine.

Week 9: This week's main goals are to change the existing channel and traffic models to something more realistic. This has already been improved. Previously, the code could only support on-off channel model, in the sense, we could vary the link quality between two nodes, periodically (remaining good for some specific time instant, then going down for some specific time and again coming up). This was changed, so that the link quality could vary according to different in-built ns3 propagation loss models (for example: log-distance-loss-model,Friis-loss-model,ground-loss-model,etc), such that when a node moves away from an access point, the signal strength would automatically reduce according to the model. As for the traffic model, previously the code continuously pumped in chunks into the network till the end of the simulation. This was changed, so that the source could transmit a fixed number of chunks (specified by the application), then stop and wait for an exponentially random off time before starting to transmit again.
The rest of the week would be spent on trying to evaluate some realistic topologies and see how gstar performs in such scenarios compared to tcp/udp.