In this lab, we will implement application layer packet forwarding/routing that can be used to build infrastructure services such as overlay networks where a logical topology is embedded over a physical topology. It is a short lab where coding is minimal. Most of the effort entails performing benchmark experiments that re-use network software from previous labs. Problem 1.2 is a bonus problem that extends the experiments.
We will re-use the VPN client/server from lab4 to set up a multi-hop network
that is configured to perform load balancing of ingress traffic over two egress
links. The following describes a specific test topology:
src (amber09) -> hop1 (amber01) -> hop2 (amber02) -> hop4 (amber04)
-> dst (amber10)
-> hop3 (amber03) ->
where hop1 may forward traffic arriving from src on two outgoing links
to hop2 and hop3. hop2 and hop3 forward traffic coming in from hop1 to
hop4.
The source host, src, will run the UDP ping client from Problem 2, lab2,
and the destination host, dst, will run the corresponding UDP ping server. The
specific names of the amber lab machines is arbitrary but for needing
to be distinct. The above configuration serves as an example.
The forwarding actions at hop1, hop2, hop3, hop4 are configured by running the tunneling server, tunneld, from Problem 2, lab4, on the four machines. The tunneling client, tunnelcli, may be executed at src or any other lab machine but for hop1, hop2, hop3, hop4. After running tunneld on hop4, tunnelcli is executed (say at host src) so that it commands hop4 to forward traffic arriving on the child's UDP ingress port from hop2 or hop3 to dst where the UDP ping server runs. After running tunneld on hop2, a second instance of tunnelcli is executed which configures hop2's forwarding table so that UDP traffic arriving at its child's UDP ingress port is forwarded to hop4's UDP ingress port. Analogously for hop3. In the final step, after running tunneld on hop1, a fourth instance of tunnelcli is executed which configures hop1 to forward UDP packets arriving at its child's ingress port to hop2. A fifth instance of tunnelcli is executed at src which configures hop1 to forward UDP packets arriving at its ingress UDP port to hop3. Thus hop1 will have two entries in its table for UDP packets arriving on its ingress UDP port, one entry that specifies hop2 as the next hop, another that denotes hop3.
Copy relevant source code from lab4 and lab2 to new directory v1/ under lab6/. Modify the code of tunneling server, tunneld, so that if the source IPv4 address communicated by tunnelcli is already present in the forwarding table, the previously spawned child's forwarding table is updated with a new entry. Do not fork another child. Hardcode the constant 5 using #define in tunneld so that up to 5 consecutive UDP packets arriving on the UDP ingress port from the same source are forwarded to hop2. The next 5 UDP packets arriving on the UDP ingress port are forwarded to hop3. This load balancing action that alternates forwarding on two egress links every 5 packets continues until a session is terminated. When performing forwarding actions, tunneld counts how many packets were forwarded per entry in its routing table which are output to stdout when a session is terminated.
Use the UDP ping app to send out 50 packets at src. If all goes well and there are no packet losses, output at hop1 should show an even split 25/25 of forwarded egress traffic. hop2 and hop3 should show 25 packets each, hop4 should output 50. Compare the observed RTT values to a run where src transmits 50 UDP ping packets directly to dst without application layer routing affecting multi-path forwarding. Discuss your findings in lab6ans.pdf.
Re-use the benchmark set-up of 1.1 but with the UDP-based file transport app from Problem 2, lab3, in place of the UDP ping app. Perform reduced benchmark experiments compared to lab3 where a medium sized file (e.g., several hundred thousand bytes) is transported under the forwarding actions of application layer routing. Fix block size to 1400 bytes and use a packet spacing value from lab3 that yielded fast performance. Compare the results to those from lab3. Discuss your findings in lab6ans.pdf.
Electronic turn-in instructions:
i) For problems that require answering/explaining questions, submit a write-up as a pdf file called lab6ans.pdf. Place lab6ans.pdf in your directory lab6/. You can use your favorite editor subject to that it is able to export pdf files which several freeware editors do. Files submitted in any other format will not be graded.
ii) We will use turnin to manage lab assignment submissions. Please check that relevant source code including Makefile are included in the relevant subdirectories of lab6. In the parent directory of lab6, run the command
turnin -c cs422 -p lab6 lab6
You can check/list the submitted files using
turnin -c cs422 -p lab6 -v