sarveshkapre / computer-networks Goto Github PK

Project-3: Comparison between different TCP Variants


Methodology for running experiments:


Given:
                         N1                      N4
                           \                    /
                            \                  /
                             N2--------------N3
                            /                  \
                           /                    \
                         N5                      N6

Bandwidth of each link: 10Mbps


Factors we considered:

Average Throughput
packet drop rate
Latency
properties associated with each TCP variant



Experiment 1:


Sarvesh created the TCL script using the above topology. He put one CBR source at N2 with sink at N3, and  then tested the results
for each TCP stream variant(Tahoe, Reno, NewReno, and Vegas)from N1 to a sink at N4.

  a. Incremented the CBR(from 1 to 10 Mbps) to plot the results
  
  b. Varied the  the packet size to determine the best settings for plotting results

After trace file results were generated, I(Manu) created the parsing script for experiment-1 in Python to compute the output -
i.e. throughput,packet drop rate, and latency (three of them on Y axis )as a function of CBR bandwidth(on X axis)



Me(Manu) and Sarvesh then plotted the output results in Excel sheets for each TCP Variant
   	


Experiment 2:


Sarvesh created the TCL script  by using  one CBR, and two TCP.He then added CBR source at N2 and a sink at N3,
then he added two TCP streams(from the below pairs) from N1 to N4 and N5 to N6, respectively.

* Reno/Reno
* NewReno/Reno
* Vegas/Vegas
* NewReno/Vegas

   a.Incremented the CBR(from 1 to 10 Mbps) to plot the results
   b.Varied the  the packet size to determine the best settings for plotting results


After trace file results were generated, I(Manu) created the parsing script for experiment-2 in Python to compute the output -
i.e. throughput, packet loss rate, and latency(three of them on Y axis) vs CBR bandwidth(on X axis) and
also analyzed how the protocols are implemented and why the different choices in different TCP variants can impact fairness

Me(Manu) and Sarvesh then plotted the output results in Excel sheets for each TCP Variant pairs.


Experiment 3: 18 graphs (6 graphs if we have both TCP variants and CBR source in one graph)

Sarvesh created the TCL script by adding one TCP flow (N1-N4) and one CBR/UDP (N5-N6) flow to the same topology as in
experiment-1 and then tested the influence of each queuing discipline(DropTail and Random Early Drop-RED) for each TCP
stream variant(TCP Reno and SACK) and CBR flow.

   a.Changed the size of the queue for best settings to plot the result

   b.Started CBR before the TCP stream or vice versa, to validate change in the results


After trace file results were generated, I(Manu) created the parsing script for experiment-3 in Python to compute the output -
throughput, and latency(both on y axis), vs time(on X axis).


Me(Manu) and Sarvesh then plotted the output results in Excel sheets for each queing algorithm.


Me(Manu) and Sarvesh created the report by using the above results and performing T-tests on the data sets for throughput to
come to a conclusion.



Project -5   :   Buildind CDN using AWS EC2 machines


HIGH LEVEL APPROACH

-> Code a DNS server, which will parse command line arguments and send the IP of nearest replica server.
-> Run http server with cache management on each of replica server.
-> Due to very less availability of cache space, cache management is used.
-> If the page is not there in the cache, the replcia server will request the origin for content, cache it and send it to client.


IMPLEMENTATION

-> We started by parsing command line arguments using getopt().
-> Derived a UDPServer class from BaseRequestHandler and redefined its method handle(). Reference: https://docs.python.org/2/library/socketserver.html
-> Understood the DNS packet structure such as Header, Question, Answer and Authority.
-> DNS Header contains important information needed for implementation of UDP packet.
-> If QR field is 0 it is a request, if it is 1 then it is a response.
-> Creating of packet and extracitng information was similiar to one in RawSockets.
-> For testing the code we followed the instructions mentioned on the site.
-> Used Scamper command to test the latency so that client can be forward to nearets replica server. If it failed, we use geolocation api.


CHALLENGES FACED

-> Understanding the project was the most difficult part. We watched youtube videos to refresh the concepts.
-> Handling DNS request and reply was difficult. We read DNS basic concepts from the following links.
http://www.ccs.neu.edu/home/amislove/teaching/cs3700/spring15/handouts/project3.pdf
http://www.ccs.neu.edu/home/amislove/teaching/cs3700/spring15/handouts/project3-primer.pdf
-> Understood the difference between Recursive name server and authoritative name server.
https://umbrella.cisco.com/blog/blog/2014/07/16/difference-authoritative-recursive-dns-nameservers/
->


STUDENT CONTRIBUTION
Manu worked on
-> HTTP server
-> Finding RTT
-> Testing the code

Sarvesh worked on
-> DNS server
-> Testing the code
-> Readme file