Simulate a dumbbell topology (10 senders + 10 receivers) with bottleneck link and study queue drop | NS3 Project 19

 Simulate a dumbbell topology (10 senders + 10 receivers) with a bottleneck link and study the queue drop

Objective

To simulate a dumbbell network topology with 10 senders and 10 receivers connected via two central routers, creating a bottleneck link. The objective is to analyse network congestion and TCP traffic behaviour, and study packet drops resulting from queue overflow at the bottleneck link.

Introduction

A dumbbell topology describes a network structure consisting of two clusters of nodes connected by a single, shared link, resembling a dumbbell. This architecture is widely used in network simulations to study congestion control mechanisms. When multiple senders transmit data simultaneously across the shared 'bottleneck' link, the incoming aggregate bandwidth often exceeds the link's capacity. As the bottleneck router's queue fills up, any excess packets are dropped, demonstrating congestion and triggering TCP backoff algorithms.

Methodology

1. Initialise the NS-3 simulator and parse command-line arguments.
2. Create 10 sender nodes, 10 receiver nodes, and 2 router nodes.
3. Configure high-speed Point-to-Point access links (100 Mbps, 1ms delay) connecting senders to Router 1, and receivers to Router 2.
4. Establish a low-bandwidth bottleneck link (10 Mbps, 20ms delay) between Router 1 and Router 2, strictly limiting its queue capacity to force packet drops.
5. Install the Internet stack on all nodes and appropriately assign IP addresses.
6. Populate global routing tables so that nodes can reach each other.
7. Install PacketSink applications on receivers and BulkSend (TCP) applications on senders, staggering start times to simulate realistic traffic.
8. Integrate FlowMonitor for traffic analysis and NetAnim for XML animation generation.
9. Execute the simulation for 10 seconds and serialize output files.

Explanation of the Source Code

The code defines a structure containing senders, receivers, and routers. We define two types of links using PointToPointHelper: high-speed access links and a restrictive bottleneck link with a strict DropTailQueue limit. We assign distinct IPv4 subnets to every interface and leverage IPv4GlobalRoutingHelper to automatically route packets. BulkSendHelper initiates long-lived TCP flows from senders, while PacketSinkHelper catches them. NetAnim logs visual states, and FlowMonitor tracks metrics like throughput and queue drops into an XML output file.

Prompt Used

Generate a complete NS-3 script in C++ simulating a dumbbell topology with 10 senders and 10 receivers communicating over a bottleneck link via two routers. Include NS-3 flow-monitor and NetAnim setups, restrict the bottleneck queue size to induce network drops, and provide the methodology, objective, and a plotting script to visualize the congestion output.

LLM Used

ChatGPT (Anti-Gravity)

Full Source Code

#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/ipv4-global-routing-helper.h"
#include "ns3/flow-monitor-module.h"
#include "ns3/netanim-module.h"

using namespace ns3;

NS_LOG_COMPONENT_DEFINE ("DumbbellTopology");

int main (int argc, char *argv[])
{
  uint32_t nSenders = 10;
  uint32_t nReceivers = 10;

  CommandLine cmd;
  cmd.Parse (argc, argv);

  // Nodes
  NodeContainer senders;
  senders.Create (nSenders);

  NodeContainer receivers;
  receivers.Create (nReceivers);

  NodeContainer routers;
  routers.Create (2); // Two routers for dumbbell

  // Links
  PointToPointHelper p2pAccess;
  p2pAccess.SetDeviceAttribute ("DataRate", StringValue ("100Mbps"));
  p2pAccess.SetChannelAttribute ("Delay", StringValue ("1ms"));

  PointToPointHelper p2pBottleneck;
  p2pBottleneck.SetDeviceAttribute ("DataRate", StringValue ("10Mbps"));
  p2pBottleneck.SetChannelAttribute ("Delay", StringValue ("20ms"));
  // Queue limit to force drops
  p2pBottleneck.SetQueue ("ns3::DropTailQueue", "MaxSize", StringValue ("50p"));

  // Topology connections
  std::vector<NetDeviceContainer> senderDevices;
  for (uint32_t i = 0; i < nSenders; ++i)
    {
      senderDevices.push_back (p2pAccess.Install (senders.Get (i), routers.Get (0)));
    }

  NetDeviceContainer bottleneckDevices;
  bottleneckDevices = p2pBottleneck.Install (routers.Get (0), routers.Get (1));

  std::vector<NetDeviceContainer> receiverDevices;
  for (uint32_t i = 0; i < nReceivers; ++i)
    {
      receiverDevices.push_back (p2pAccess.Install (routers.Get (1), receivers.Get (i)));
    }

  // Internet Stack
  InternetStackHelper stack;
  stack.Install (senders);
  stack.Install (receivers);
  stack.Install (routers);

  // IP Assignments
  Ipv4AddressHelper address;
 
  std::vector<Ipv4InterfaceContainer> senderInterfaces;
  for (uint32_t i = 0; i < nSenders; ++i)
    {
      std::ostringstream subnet;
      subnet << "10.1." << i + 1 << ".0";
      address.SetBase (subnet.str ().c_str (), "255.255.255.0");
      senderInterfaces.push_back (address.Assign (senderDevices[i]));
    }

  address.SetBase ("10.2.1.0", "255.255.255.0");
  Ipv4InterfaceContainer bottleneckInterfaces = address.Assign (bottleneckDevices);

  std::vector<Ipv4InterfaceContainer> receiverInterfaces;
  for (uint32_t i = 0; i < nReceivers; ++i)
    {
      std::ostringstream subnet;
      subnet << "10.3." << i + 1 << ".0";
      address.SetBase (subnet.str ().c_str (), "255.255.255.0");
      receiverInterfaces.push_back (address.Assign (receiverDevices[i]));
    }

  Ipv4GlobalRoutingHelper::PopulateRoutingTables ();

  // Applications
  uint16_t port = 9;
  for (uint32_t i = 0; i < nReceivers; ++i)
    {
      PacketSinkHelper sink ("ns3::TcpSocketFactory",
                             InetSocketAddress (Ipv4Address::GetAny (), port));
      ApplicationContainer sinkApp = sink.Install (receivers.Get (i));
      sinkApp.Start (Seconds (0.0));
      sinkApp.Stop (Seconds (10.0));
    }

  for (uint32_t i = 0; i < nSenders; ++i)
    {
      BulkSendHelper source ("ns3::TcpSocketFactory",
                             InetSocketAddress (receiverInterfaces[i].GetAddress (1), port));
      source.SetAttribute ("MaxBytes", UintegerValue (0));
      ApplicationContainer sourceApp = source.Install (senders.Get (i));
      sourceApp.Start (Seconds (1.0 + i * 0.1)); // Stagger start times
      sourceApp.Stop (Seconds (10.0));
    }

  // Flow Monitor
  FlowMonitorHelper flowmon;
  Ptr<FlowMonitor> monitor = flowmon.InstallAll ();

  // NetAnim
  AnimationInterface anim ("dumbbell-animation.xml");
  for (uint32_t i = 0; i < nSenders; ++i)
    {
      anim.SetConstantPosition (senders.Get (i), 10.0, 10.0 + i * 5);
    }
  anim.SetConstantPosition (routers.Get (0), 30.0, 30.0);
  anim.SetConstantPosition (routers.Get (1), 60.0, 30.0);
  for (uint32_t i = 0; i < nReceivers; ++i)
    {
      anim.SetConstantPosition (receivers.Get (i), 80.0, 10.0 + i * 5);
    }

  Simulator::Stop (Seconds (10.0));
  Simulator::Run ();

  monitor->SerializeToXmlFile ("flowmon-results.xml", true, true);

  Simulator::Destroy ();
  return 0;
}

OUTPUTS

The following figures show the simulation animation and the corresponding congestion graph.

Figure 1: Dumbbell Topology Animation Showing Packet Flow

Figure 2: Graph Showing Packet Drop / Throughput Behavior Under Congestion

Explanation of Graph

The packet drops occur directly due to the strict buffer limitation (50 packets) configured at the bottleneck DropTail queue. Because the dumbbell topology channels ten high-speed (100 Mbps) connections into a single constrained bottleneck link (10 Mbps), the aggregate incoming bandwidth severely exceeds what the hardware can process. This extreme disparity forces the central router to hold packets in its queue until fully saturated. Upon reaching this threshold, the bottleneck link immediately discards any excess arriving packets, triggering simultaneous loss events per connection. The observed trend across the graph illustrates high-volume random drops varying per flow, confirming the chaotic nature of congestion and resulting TCP window backoffs.

Execution Command

./ns3 run scratch/23bps1xxx.cc

Explanation

- This command runs the NS-3 simulation.

- It generates animation and flow monitoring output files.

Screenshot Procedure

- Open NetAnim using the generated XML file.

- Capture animation screenshot.

- Capture graph screenshot.