To study the impact of channel error rate on Stop-and-Wait vs. GBN efficiency in a point-to-point link | NS3 Project 27

To study the impact of channel error rate on Stop-and-Wait vs. GBN efficiency in a point-to-point link.

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/error-model.h"

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

 

using namespace ns3;

 

NS_LOG_COMPONENT_DEFINE ("StopWaitVsGBN");

 

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

{

    double errorRate = 0.00001; // change this for experiment

    uint32_t packetSize = 1024;

    std::string dataRate = "5Mbps";

 

    CommandLine cmd;

    cmd.AddValue ("errorRate", "Bit error rate", errorRate);

    cmd.Parse (argc, argv);

 

    NodeContainer nodes;

    nodes.Create (2);

 

    PointToPointHelper p2p;

    p2p.SetDeviceAttribute ("DataRate", StringValue (dataRate));

    p2p.SetChannelAttribute ("Delay", StringValue ("2ms"));

 

    NetDeviceContainer devices = p2p.Install (nodes);

 

    // Error model

    Ptr<RateErrorModel> em = CreateObject<RateErrorModel> ();

    em->SetAttribute ("ErrorRate", DoubleValue (errorRate));

    devices.Get (1)->SetAttribute ("ReceiveErrorModel", PointerValue (em));

 

    InternetStackHelper stack;

    stack.Install (nodes);

 

    Ipv4AddressHelper address;

    address.SetBase ("10.1.1.0", "255.255.255.0");

    Ipv4InterfaceContainer interfaces = address.Assign (devices);

 

    uint16_t port = 8080;

 

    // Receiver

    PacketSinkHelper sink ("ns3::TcpSocketFactory",

                           InetSocketAddress (Ipv4Address::GetAny (), port));

    ApplicationContainer sinkApp = sink.Install (nodes.Get (1));

    sinkApp.Start (Seconds (0.0));

    sinkApp.Stop (Seconds (20.0));

 

    // Sender

    OnOffHelper client ("ns3::TcpSocketFactory",

                        InetSocketAddress (interfaces.GetAddress (1), port));

 

    client.SetAttribute ("PacketSize", UintegerValue (packetSize));

    client.SetAttribute ("DataRate", StringValue ("10Mbps"));

    client.SetAttribute ("OnTime", StringValue ("ns3::ConstantRandomVariable[Constant=1]"));

    client.SetAttribute ("OffTime", StringValue ("ns3::ConstantRandomVariable[Constant=0]"));

 

    ApplicationContainer clientApp = client.Install (nodes.Get (0));

    clientApp.Start (Seconds (1.0));

    clientApp.Stop (Seconds (20.0));

 

    // ---- SWITCH BETWEEN STOP-WAIT AND GBN ----

    // Stop-and-Wait → window = 1

    Config::SetDefault ("ns3::TcpSocket::SndBufSize", UintegerValue (1024));

    Config::SetDefault ("ns3::TcpSocket::RcvBufSize", UintegerValue (1024));

 

    // For GBN → increase buffer (comment above and use below)

    // Config::SetDefault ("ns3::TcpSocket::SndBufSize", UintegerValue (65535));

    // Config::SetDefault ("ns3::TcpSocket::RcvBufSize", UintegerValue (65535));

 

    // Flow Monitor

    FlowMonitorHelper flowmon;

    Ptr<FlowMonitor> monitor = flowmon.InstallAll ();

 

    Simulator::Stop (Seconds (20.0));

    Simulator::Run ();

 

    monitor->CheckForLostPackets ();

    Ptr<Ipv4FlowClassifier> classifier =

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

    std::map<FlowId, FlowMonitor::FlowStats> stats = monitor->GetFlowStats ();

 

    for (auto &flow : stats)

    {

        double throughput = flow.second.rxBytes * 8.0 / 20.0 / 1024 / 1024;

        std::cout << "Throughput: " << throughput << " Mbps\n";

        std::cout << "Packet Loss: " << flow.second.lostPackets << "\n";

    }

 

    Simulator::Destroy ();

    return 0;

}

TRACEMETRICS:

RESULT:

 

 

GRAPH:

WIRESHARK:

NETANIM:

 

THEORY BEHIND THIS BEHAVIOUR:

Stop-and-Wait and Go-Back-N are flow control protocols that differ in how they utilise the communication channel. In Stop-and-Wait, the sender transmits one packet and waits for an acknowledgement before sending the next. This results in significant idle time, especially when delay or errors occur, leading to low throughput and poor efficiency. In contrast, Go-Back-N uses a sliding window mechanism that allows multiple packets to be sent consecutively without waiting for individual acknowledgements. If an error occurs, the receiver discards the erroneous packet and all subsequent packets, and the sender retransmits from the lost packet onward. Although this may increase the number of retransmissions, Go-Back-N maintains better channel utilisation due to pipelining. As channel error rate increases, throughput decreases in both protocols, but the decline is much steeper in Stop-and-Wait, while Go-Back-N sustains comparatively higher performance.

CONCLUSION:

The simulation shows that Go-Back-N achieves significantly higher throughput than Stop-and-Wait due to its ability to transmit multiple packets without waiting for acknowledgements, resulting in better link utilisation. Stop-and-Wait suffers from low efficiency because the sender remains idle after each transmission, causing throughput to drop rapidly as the error rate increases. In Go-Back-N, although multiple packets may be retransmitted when an error occurs, the overall performance remains superior due to pipelining. An important observation is the effect of TCP behaviour in the simulation. As packet loss increases, TCP interprets it as congestion and reduces its sending rate by shrinking the congestion window, a mechanism known as congestion control. This leads to a slowdown in transmission at higher error rates, sometimes reducing the number of packets sent and thus affecting observed packet loss. Overall, Go-Back-N performs better than Stop-and-Wait despite higher retransmissions, especially under moderate error conditions.