Simulation of a Client Server Video-on-Demand (VoD) System Using TCP Socket Factory | NS3 Project 21

Simulation of a Client Server Video-on-Demand (VoD) System Using TCP Socket Factory | NS3 Project

1. Aim

To simulate a client-server Video-on-Demand (VoD) system in NS-3 using the TCP Socket Factory for reliable video stream transport and the Flow Monitor module to measure and analyse key network performance metrics including throughput, end-to-end delay, jitter, and packet loss ratio across two simultaneous client streams.

2. Introduction

Video-on-Demand (VoD) is a media distribution paradigm that allows users to access video content at any time on demand. Services such as Netflix, YouTube, and Amazon Prime Video rely on robust network transport protocols to stream high-quality video to end users. Simulating such systems helps network engineers understand bottleneck behaviour, TCP fairness, and QoS characteristics under controlled conditions.

NS-3 (Network Simulator 3) is an open-source discrete-event network simulator widely used in academic research. It provides TCP/IP stack implementations, application helpers such as BulkSendApplication and PacketSinkApplication, and analysis tools including the Flow Monitor. In this exercise, NS-3 models a VoD streaming scenario with a server simultaneously streaming to two clients over point-to-point links with a bottleneck router in between.

3. Theory

3.1 TCP Socket Factory (TcpSocketFactory)

The TcpSocketFactory is an NS-3 abstraction that enables application-layer code to create TCP sockets without being tied to a specific TCP implementation. It uses the TypeId system, allowing easy switching between TCP variants such as TcpNewReno, TcpCubic, or TcpVegas at runtime without modifying application code. In this simulation, TcpNewReno is selected. The server calls TcpSocketFactory to open TCP connections to each client, and bulk data is sent once the three-way handshake completes.

3.2 Flow Monitor Module

The FlowMonitorHelper installs passive sniffers on every node. It classifies packets into flows using their 5-tuple (source IP, destination IP, source port, destination port, protocol) and records the following per-flow statistics:

• Throughput (Mbps): Total received bytes x 8 divided by flow duration.

• End-to-End Delay (ms): Mean packet delay from sender to receiver averaged over all packets.

• Jitter (ms): Mean variation in inter-packet arrival time — critical for video stream quality.

• Packet Loss (%): Ratio of lost packets to transmitted packets due to queue overflow.

4. Network Design & Topology

The simulated topology models a realistic VoD delivery network:

[VoD Server] ──10Mbps/2ms── [Router] ──5Mbps/5ms── [Client 0]

└──5Mbps/5ms── [Client 1]

• Nodes: 1 VoD Server (Node 0, 10.1.1.1), 1 Router (Node 1), Client 0 (Node 2, 10.1.2.2), Client 1 (Node 3, 10.1.3.2)

• Backbone: Server to Router — 10 Mbps, 2 ms delay, 100-packet DropTail queue

• Access Links: Router to each Client — 5 Mbps, 5 ms delay, 50-packet DropTail queue

• Transport: TCP NewReno, segment size 1448 bytes, 1 MB send/receive buffers

• Applications: BulkSendApplication (server) sending to PacketSinkApplication (each client)

• Simulation: 20 seconds total. Streaming starts at t=1s, stops at t=19s.

5. Prompt Used & LLM

LLM Used: Claude by Anthropic (claude.ai)

Prompt given to generate the NS-3 source code:

"Write a complete NS-3 C++ simulation (scratch/24bps1149cc) for a client-server VoD system. Use TcpSocketFactory with TcpNewReno, BulkSendApplication on server and PacketSinkApplication on two clients. Set backbone to 10 Mbps / 2 ms and access links to 5 Mbps / 5 ms. Install FlowMonitorHelper on all nodes. Output NetAnim XML, write per-flow throughput .dat files every 0.5s, and print a formatted flow statistics table to the terminal. Simulation time: 20 seconds.”

6. Source Code

* Run Command: ./ns3 run scratch/vod.cc

* * Topology:

* * [VoD Server] ----P2P (10Mbps, 2ms)---- [Router] ----P2P (5Mbps, 5ms)---- [VoD Client 0]

* \---P2P (5Mbps, 5ms)---- [VoD Client 1]

* Description:

* - Server streams bulk video data to two clients using TCP (NewReno)

* - BulkSendApplication simulates continuous video streaming on server

* - PacketSinkApplication receives data on each client

* - FlowMonitor captures throughput, delay, loss, jitter per flow

* - NetAnim XML generated for animation visualization

* - Gnuplot-compatible throughput data written to .dat files

#include "ns3/core-module.h"

#include "ns3/network-module.h"

#include "ns3/internet-module.h"

#include "ns3/point-to-point-module.h"

#include "ns3/applications-module.h"

#include "ns3/flow-monitor-module.h"

#include "ns3/netanim-module.h"

#include "ns3/traffic-control-module.h"

#include <fstream>

#include <iomanip>

#include <map>

using namespace ns3;

NS_LOG_COMPONENT_DEFINE("VoDSimulation");

// ─── Global throughput tracking ─────────────────────────────────────────────

std::map<uint32_t, std::ofstream*> g_throughputFiles;

std::map<uint32_t, uint64_t> g_lastRxBytes;

Ptr<FlowMonitor> g_monitor;

FlowMonitorHelper g_flowHelper;

// Called every 0.5s to record per-flow throughput

void RecordThroughput()

{

g_monitor->CheckForLostPackets();

auto stats = g_monitor->GetFlowStats();

for (auto& kv : stats)

{

uint32_t id = kv.first;

uint64_t rxNow = kv.second.rxBytes;

uint64_t prev = g_lastRxBytes[id];

double tput = (rxNow - prev) * 8.0 / 0.5 / 1e6; // Mbps over 0.5s window

g_lastRxBytes[id] = rxNow;

if (g_throughputFiles.count(id))

*g_throughputFiles[id] << Simulator::Now().GetSeconds()

<< "\t" << std::fixed << std::setprecision(4)

<< tput << "\n";

}

Simulator::Schedule(Seconds(0.5), &RecordThroughput);

}

// ─── Main ────────────────────────────────────────────────────────────────────

int main(int argc, char* argv[])

{

// ── Simulation parameters ──────────────────────────────────────────────

double simTime = 20.0; // seconds

uint32_t numClients = 2;

uint32_t serverPort = 9;

uint64_t maxBytes = 0; // 0 = unlimited (stream until simTime)

std::string tcpVariant = "ns3::TcpNewReno";

std::string backboneBw = "10Mbps";

std::string backboneDelay = "2ms";

std::string accessBw = "5Mbps";

std::string accessDelay = "5ms";

CommandLine cmd;

cmd.AddValue("simTime", "Simulation duration (s)", simTime);

cmd.AddValue("numClients", "Number of VoD clients", numClients);

cmd.AddValue("tcpVariant", "TCP congestion control type", tcpVariant);

cmd.Parse(argc, argv);

// ── TCP configuration ──────────────────────────────────────────────────

Config::SetDefault("ns3::TcpL4Protocol::SocketType",

StringValue(tcpVariant));

Config::SetDefault("ns3::TcpSocket::SegmentSize", UintegerValue(1448));

Config::SetDefault("ns3::TcpSocket::SndBufSize", UintegerValue(1 << 20)); // 1 MB

Config::SetDefault("ns3::TcpSocket::RcvBufSize", UintegerValue(1 << 20));

// ── Create nodes ───────────────────────────────────────────────────────

NodeContainer serverNode; serverNode.Create(1); // n0

NodeContainer routerNode; routerNode.Create(1); // n1

NodeContainer clientNodes; clientNodes.Create(numClients); // n2, n3, …

// ── Point-to-Point links ───────────────────────────────────────────────

PointToPointHelper backbone;

backbone.SetDeviceAttribute ("DataRate", StringValue(backboneBw));

backbone.SetChannelAttribute("Delay", StringValue(backboneDelay));

backbone.SetQueue("ns3::DropTailQueue",

"MaxSize", StringValue("100p"));

PointToPointHelper access;

access.SetDeviceAttribute ("DataRate", StringValue(accessBw));

access.SetChannelAttribute("Delay", StringValue(accessDelay));

access.SetQueue("ns3::DropTailQueue",

"MaxSize", StringValue("50p"));

// Server ↔ Router

NetDeviceContainer serverRouterDev =

backbone.Install(serverNode.Get(0), routerNode.Get(0));

// Router ↔ each Client

std::vector<NetDeviceContainer> clientDevs(numClients);

for (uint32_t i = 0; i < numClients; ++i)

clientDevs[i] = access.Install(routerNode.Get(0), clientNodes.Get(i));

// ── Internet stack ─────────────────────────────────────────────────────

InternetStackHelper internet;

internet.Install(serverNode);

internet.Install(routerNode);

internet.Install(clientNodes);

// ── IP addressing ──────────────────────────────────────────────────────

Ipv4AddressHelper ipv4;

// 10.1.1.0/30 — backbone

ipv4.SetBase("10.1.1.0", "255.255.255.252");

Ipv4InterfaceContainer serverRouterIf = ipv4.Assign(serverRouterDev);

// 10.1.2.0/30, 10.1.3.0/30, … — access links

std::vector<Ipv4InterfaceContainer> clientIf(numClients);

for (uint32_t i = 0; i < numClients; ++i)

{

std::ostringstream base;

base << "10.1." << (i + 2) << ".0";

ipv4.SetBase(base.str().c_str(), "255.255.255.252");

clientIf[i] = ipv4.Assign(clientDevs[i]);

}

Ipv4GlobalRoutingHelper::PopulateRoutingTables();

// ── Applications ───────────────────────────────────────────────────────

// PacketSink on every client

for (uint32_t i = 0; i < numClients; ++i)

{

PacketSinkHelper sink("ns3::TcpSocketFactory",

InetSocketAddress(Ipv4Address::GetAny(), serverPort + i));

ApplicationContainer sinkApp = sink.Install(clientNodes.Get(i));

sinkApp.Start(Seconds(0.0));

sinkApp.Stop(Seconds(simTime));

}

// BulkSend from server to each client (separate TCP connection per client)

for (uint32_t i = 0; i < numClients; ++i)

{

Ipv4Address clientAddr = clientIf[i].GetAddress(1); // right side of access link

BulkSendHelper bulk("ns3::TcpSocketFactory",

InetSocketAddress(clientAddr, serverPort + i));

bulk.SetAttribute("MaxBytes", UintegerValue(maxBytes));

bulk.SetAttribute("SendSize", UintegerValue(1448)); // ~1 video chunk

ApplicationContainer serverApp = bulk.Install(serverNode.Get(0));

serverApp.Start(Seconds(1.0)); // slight delay so sink is ready

serverApp.Stop(Seconds(simTime - 1.0));

} // ── Flow Monitor ───────────────────────────────────────────────────────

g_monitor = g_flowHelper.InstallAll();

// Open throughput output files (one per expected flow)

for (uint32_t i = 1; i <= numClients; ++i)

{

std::ostringstream fname;

fname << "vod_throughput_flow" << i << ".dat";

auto* f = new std::ofstream(fname.str());

*f << "# Time(s)\tThroughput(Mbps)\n";

g_throughputFiles[i] = f;

g_lastRxBytes[i] = 0;

}

Simulator::Schedule(Seconds(1.5), &RecordThroughput);

// ── NetAnim ────────────────────────────────────────────────────────────

AnimationInterface anim("vod_animation.xml");

// Server – left side

anim.SetConstantPosition(serverNode.Get(0), 10.0, 50.0);

anim.UpdateNodeDescription(serverNode.Get(0), "VoD Server");

anim.UpdateNodeColor(serverNode.Get(0), 255, 0, 0); // red

anim.UpdateNodeSize(serverNode.Get(0)->GetId(), 3.0, 3.0);

// Router – centre

anim.SetConstantPosition(routerNode.Get(0), 50.0, 50.0);

anim.UpdateNodeDescription(routerNode.Get(0), "Router");

anim.UpdateNodeColor(routerNode.Get(0), 0, 128, 0); // green

anim.UpdateNodeSize(routerNode.Get(0)->GetId(), 3.0, 3.0);

// Clients – right side, spread vertically

for (uint32_t i = 0; i < numClients; ++i)

{

double yPos = 30.0 + i * 40.0;

anim.SetConstantPosition(clientNodes.Get(i), 90.0, yPos);

std::ostringstream label;

label << "Client " << i;

anim.UpdateNodeDescription(clientNodes.Get(i), label.str());

anim.UpdateNodeColor(clientNodes.Get(i), 0, 0, 255); // blue

anim.UpdateNodeSize(clientNodes.Get(i)->GetId(), 3.0, 3.0);

}

// ── Run ────────────────────────────────────────────────────────────────

NS_LOG_UNCOND("=== VoD Simulation Starting ===");

NS_LOG_UNCOND(" TCP variant : " << tcpVariant);

NS_LOG_UNCOND(" Backbone : " << backboneBw << " / " << backboneDelay);

NS_LOG_UNCOND(" Access links : " << accessBw << " / " << accessDelay);

NS_LOG_UNCOND(" Clients : " << numClients);

NS_LOG_UNCOND(" Sim time : " << simTime << " s");

NS_LOG_UNCOND("================================");

Simulator::Stop(Seconds(simTime));

Simulator::Run();

// ── Flow Monitor Results ───────────────────────────────────────────────

g_monitor->CheckForLostPackets();

g_monitor->SerializeToXmlFile("vod_flowmon.xml", true, true);

Ptr<Ipv4FlowClassifier> classifier =

DynamicCast<Ipv4FlowClassifier>(g_flowHelper.GetClassifier());

auto stats = g_monitor->GetFlowStats();

NS_LOG_UNCOND("\n========= Flow Monitor Results =========");

NS_LOG_UNCOND(std::left

<< std::setw(8) << "FlowID"

<< std::setw(22) << "Src → Dst"

<< std::setw(14) << "Throughput"

<< std::setw(14) << "Mean Delay"

<< std::setw(14) << "Mean Jitter"

<< std::setw(10) << "Loss %");

for (auto& kv : stats)

{

Ipv4FlowClassifier::FiveTuple t = classifier->FindFlow(kv.first);

double duration = kv.second.timeLastRxPacket.GetSeconds()

- kv.second.timeFirstTxPacket.GetSeconds();

if (duration <= 0) continue;

double tput = kv.second.rxBytes * 8.0 / duration / 1e6; // Mbps

double delay = (kv.second.rxPackets > 0)

? kv.second.delaySum.GetSeconds() / kv.second.rxPackets * 1000.0

: 0.0; // ms

double jitter = (kv.second.rxPackets > 1)

? kv.second.jitterSum.GetSeconds() / (kv.second.rxPackets - 1) * 1000.0

: 0.0; // ms

double loss = (kv.second.txPackets > 0)

? 100.0 * (kv.second.txPackets - kv.second.rxPackets)

/ kv.second.txPackets

: 0.0;

std::ostringstream flow;

flow << t.sourceAddress << "→" << t.destinationAddress;

NS_LOG_UNCOND(std::left

<< std::setw(8) << kv.first

<< std::setw(22) << flow.str()

<< std::setw(14) << std::fixed << std::setprecision(3)

<< tput << " Mbps"

<< std::setw(14) << delay << " ms"

<< std::setw(14) << jitter << " ms"

<< std::setw(10) << loss << " %");

}

NS_LOG_UNCOND("========================================");

NS_LOG_UNCOND("NetAnim file : vod_animation.xml");

NS_LOG_UNCOND("FlowMonitor XML : vod_flowmon.xml");

NS_LOG_UNCOND("Throughput data : vod_throughput_flow*.dat");

// Close output files

for (auto& kv : g_throughputFiles)

{

kv.second->close();

delete kv.second;

}

Simulator::Destroy();

return 0;

}

7. NetAnim Animation Window

7.1 Animator View

The screenshot below shows the NetAnim Animator tab. The red node (left) is the VoD Server (10.1.1.1), the green node (centre) is the Router, and the two blue nodes (right) are Client 0 (10.1.2.2, upper) and Client 1 (10.1.3.2, lower). The simulation stat

netanim

us bar reads "Playing", confirming the animation is running through the 20-second simulation window.

Fig. 1: NetAnim Animator window — VoD Server (red), Router (green), Client 0 and Client 1 (blue). Packets travel from server through router to both clients. Status: "Playing" at Sim Time 1/102.

7.2 Stats View — IP/MAC Table

The Stats tab shows the IP and MAC address assignments for all nodes. Node 0 (Server) = 10.1.1.1. Node 1 (Router) has three interfaces (10.1.2.1, 10.1.3.1, 10.1.1.2). Node 2 (Client 0) = 10.1.2.2. Node 3 (Client 1)

netanim

= 10.1.3.2. This confirms correct IPv4 global routing across the topology.

Fig. 2: NetAnim Stats tab — IP-MAC mapping for all 4 nodes confirming correct address assignment. Node 1 (Router) shows 3 interfaces connecting to server and both clients.

8. Wireshark Packet Analysis

The pcap file (vod_capture-0-0.pcap) was captured on the backbone link and opened in Wireshark. It confirms the TCP three-way handshake (SYN at frame 1, port 49153→9), followed by sustained bulk data transfer. Frames labelled "DISCARD" (1502 bytes = 1448 B payload + headers) represent the continuous video stream. The total capture has 23,940 packets over 20 seconds, confirming heavy sustained data flow.

wireshark

Fig. 3: Wireshark capture (vod_capture-0-0.pcap) — 23,940 packets total. Frame 1 shows TCP SYN (port 49153→9). Frames 5+ show 1502-byte data segments from Server (10.1.1.1) to Client 0 (10.1.2.2). DISCARD frames are PPP-encapsulated NS-3 bulk video data.

9. Performance Graph — Throughput vs Time

The graph below was generated using Gnuplot from vod_throughput_flow1.dat and vod_throughput_flow2.dat. The x-axis shows simulation time (0–20s), y-axis shows TCP throughput (Mbps).

Fig. 4: TCP Throughput (Mbps) vs Time (s) — Flow 1 (Client 0, pink) and Flow 2 (Client 1, teal). Both flows start at ~4.75 Mbps after TCP slow-start (t=1.5s), then stabilise near 4.992 Mbps, saturating the 5 Mbps access link. A dip to ~4.65 Mbps at t=10.5s indicates a TCP NewReno retransmission event (packet loss detected, congestion window halved). Both flows recover quickly, demonstrating TCP fairness.

10. Flow Monitor Results

The FlowMonitor captured 4 flows — 2 downstream video streams (Flows 1 & 2: Server→Clients) and 2 upstream TCP ACK flows (Flows 3 & 4: Clients→Server). Key metrics are summarised below:

Flow ID	Source → Destination	Throughput	Mean Delay	Mean Jitter	Loss %
1	10.1.1.1 → 10.1.2.2	4.979 Mbps	113.909 ms	2.387 ms	0.905 %
2	10.1.1.1 → 10.1.3.2	4.984 Mbps	112.952 ms	2.389 ms	0.916 %
3 (ACK)	10.1.2.2 → 10.1.1.1	0.091 Mbps	7.132 ms	0.000 ms	0.049 %
4 (ACK)	10.1.3.2 → 10.1.1.1	0.091 Mbps	7.134 ms	0.000 ms	0.025 %

Table 1: FlowMonitor statistics. Flows 1 & 2 = VoD video streams. Flows 3 & 4 = TCP ACK returns (low throughput by design). All values from vod_flowmon.xml.

11. Trace File Analysis (vod_trace.tr)

The ASCII trace file records every enqueue (+), dequeue (-), and receive (r) event. Key observations:

• t=1.000s: Server enqueues TCP SYN to Client 0 (port 49153→9) and Client 1 (port 49154→10) simultaneously.

• t=1.002s: Router (Node 1) receives and forwards SYN packets to respective client access links.

• t=1.007s: Client 0 (Node 2) receives SYN, replies with SYN-ACK. Client 1 (Node 3) similarly responds.

• t=1.014s: Server completes 3-way handshake, immediately enqueues 10 data segments (1448 bytes each) — TCP slow-start begins with cwnd = 10 MSS.

• t=1.015s onwards: Bulk data segments flow at 10 Mbps backbone rate through router to both clients continuously.

Metric	Flow 1 (→Client 0)	Flow 2 (→Client 1)	Notes
Tx Packets	7,956	7,966	Near equal — fair sharing
Rx Packets	7,884	7,893	Less than 1% loss
Lost Packets	7	7	Tail-drop at router
Min Delay	7.13 ms	7.19 ms	Propagation only
Max Delay	259.6 ms	252.4 ms	Queue buildup at peak
Rx Bytes	11,823,108 B	11,836,608 B	~11.3 MB each received

Table 2: Per-flow packet statistics extracted from vod_flowmon.xml. Min delay = 7ms (2ms backbone + 5ms access). Max delay shows router queue buildup during peak congestion.

12. Result Analysis

12.1 Throughput Analysis

Both Flow 1 and Flow 2 achieve approximately 4.979 Mbps and 4.984 Mbps respectively, very close to the 5 Mbps access link capacity. This confirms that the bottleneck is the 5 Mbps access link, not the 10 Mbps backbone. TCP NewReno successfully discovers and utilises nearly all available bandwidth. The tiny difference of 0.005 Mbps between the two flows demonstrates near-perfect TCP fairness — a hallmark of TCP's AIMD (Additive Increase Multiplicative Decrease) algorithm when two flows share the same bottleneck link.

12.2 Delay Analysis

The mean end-to-end delay of approximately 113 ms is significantly higher than the minimum propagation delay of 7 ms (2ms backbone + 5ms access). This queuing delay is caused by the router's DropTail queue filling up as the server transmits at 10 Mbps while each access link drains at only 5 Mbps. Maximum delay of 259 ms corresponds to maximum queue occupancy. This bufferbloat effect is a known issue in VoD systems and would require AQM (Active Queue Management) such as CoDel or RED to mitigate in production networks.

12.3 Jitter Analysis

Mean jitter of approximately 2.387–2.389 ms is acceptably low for wired VoD streaming. Jitter arises from variable queuing delays as packets compete at the router queue. In real VoD systems, a client-side playback buffer of 2–5 seconds absorbs this jitter. For live or interactive video, jitter below 30 ms is required — this simulation comfortably meets that standard.

12.4 Packet Loss Analysis

Flows 1 and 2 each experience exactly 7 lost packets out of approximately 7,900 transmitted (loss ~0.905% and ~0.916%). Losses occur due to DropTail queue overflow at the router when both flows burst simultaneously. TCP NewReno detects losses via duplicate ACKs, halves the congestion window (multiplicative decrease), and retransmits — visible as the throughput dip at t=10.5s in the graph. The ACK return flows (3 and 4) show near-zero loss, confirming the upstream path is uncongested.

13. Conclusion

This exercise successfully demonstrated the simulation of a client-server Video-on-Demand system using NS-3 with TCP Socket Factory and Flow Monitor. TCP NewReno effectively utilised available bandwidth, achieving approximately 4.98 Mbps per client on a 5 Mbps access link, while maintaining near-perfect fairness between the two simultaneous streams. The FlowMonitor provided comprehensive per-flow metrics confirming system performance. The 113 ms mean delay revealed bufferbloat at the router queue, a key real-world network engineering consideration. NetAnim visually confirmed correct packet routing. Wireshark verified TCP handshake, segment sizes, and sustained bulk transfer behaviour. The tools and techniques used — NS-3, FlowMonitor, NetAnim, Wireshark, Gnuplot, and ASCII trace analysis — are directly applicable to real-world multimedia network design and performance evaluation.

Engineering Clinic

Search This Blog