DEV Community: sujan khadka

Full Bars, Empty Promises: Why Your Wi-Fi Is Gaslighting You (and 5 Breakthroughs Fixing It)

sujan khadka — Tue, 11 Aug 2026 19:18:33 +0000

Have you ever looked at your device, seen “full bars” of Wi‑Fi strength, yet found yourself staring at a spinning loading icon? It is the digital equivalent of being gaslit. Your hardware is screaming that the connection is perfect, yet the actual performance feels like a dial‑up relic from 1995. We have been conditioned to believe that signal strength and raw gigabit ratings are the primary governors of our online experience, but the truth is far more structural. Your high‑speed Wi‑Fi is suffering from a deep‑seated identity crisis.

The root of this deception is the “Wired Network Assumption.” TCP, the internet’s foundational language, was architected for the predictable world of copper wires: a lost packet almost always meant a physically overcrowded link. But the wireless world is a chaotic theater of interference and signal noise. For decades, our devices have been mistaking these fleeting airwave hiccups for catastrophic traffic jams, needlessly triggering the sluggish “limp mode” we have all experienced.

Recent research and real‑world deployment of protocol variants like E‑Vegas, Snoop, and the BBR family are finally giving the internet the adaptive intelligence it has been missing. By moving away from the rigid logic of the 1980s, these technologies are teaching our networks how to handle the friction of the air.

Takeaway 1: Your Network is Mistaking Signal Noise for Traffic Jams

In a traditional wired network, data loss is a rare event caused by hardware failure or extreme congestion. In a Wi‑Fi environment, however, packet loss occurs for three distinct reasons: buffer overflow in routers, user mobility (like walking behind a wall), and high bit‑error‑rate (BER) caused by wireless interference.

Traditional TCP variants, such as Reno or CUBIC, are “loss‑based.” They operate on the flawed assumption that packet loss always equals congestion. When a Wi‑Fi signal encounters a momentary bit of noise or interference, these protocols reflexively slash their transmission speeds to “ease the traffic,” even if the network path is otherwise wide open. This misunderstanding forces the network to slow down unnecessarily, creating a bottleneck that exists only in the protocol’s mind.

Takeaway 2: The "Snoop" Effect: How Base Stations Became Local Heroes

To fix this misunderstanding, researchers developed the Snoop protocol, a masterclass in “cross‑layer design.” While modern protocols like BBR work at the Transport Layer (the end‑host), Snoop operates at the Link Layer (the base station).

Instead of forcing a server halfway across the world to re‑send a packet because your smartphone hit a patch of interference, the Snoop protocol empowers your local access point to take charge. The base station “snoops” on the data flow, caching packets as they pass through. If it detects a packet was lost specifically over the wireless link, it performs a local retransmission immediately. This hides the error from the distant sender, preventing the entire connection from slowing down. In environments plagued by high BER, this localized fix can achieve throughput speedups of up to 20 times over regular TCP.

Though the original Snoop agent from Berkeley’s 1995 research never shipped in your home router, its core idea hiding wireless loss from the sender via link‑layer retransmission lives on in today’s 802.11 MAC retry logic and cellular base station optimizations.

Takeaway 3: BBRv2 to BBRv3: Goodbye “Crash and Recover,” Hello “Perfect Pacing”

While older protocols use AIMD (Additive Increase Multiplicative Decrease) essentially “speed up until you crash, then slam on the brakes”—Google’s BBR (Bottleneck Bandwidth and Round‑trip Time) family introduced a more sophisticated, “rate‑based” approach.

BBRv2 was the public watershed, built on four signals: bottleneck bandwidth, RTprop, packet loss, and ECN. It addressed the notorious “RTT unfairness” of BBRv1, ensuring long‑haul and short‑hop flows could coexist more peacefully. But BBRv2 was just a step.

BBRv3, released in 2023 and in the process of being merged into the Linux kernel from version 6.5 onward, refines that model to near‑production perfection. It improves convergence fairness with traditional CUBIC flows, reduces aggressiveness under sustained loss, and tunes its control loop for the real, messy internet—not just simulation. Google already runs BBRv3 on its own backbone and YouTube servers, meaning a huge slice of global traffic already benefits from “perfect pacing” without the user ever knowing.

The core insight remains: instead of reacting blindly to packet loss, BBRv3 builds a dynamic model of the actual pipe and paces data accordingly. The result is less buffering, lower latency, and throughput that doesn’t nosedive the moment someone walks past a microwave.

Takeaway 4: The Bufferbloat Paradox: Why More Memory Isn't Always Better

In the 802.11n era, hardware manufacturers began equipping routers with massive memory buffers. While intended to prevent packet loss, this created “Bufferbloat.” The problem is particularly acute in 802.11n due to features like frame aggregation and HT‑Immediate BlockACK, which allow for high data rates (up to 300 Mbps) that can drop dynamically and drastically based on distance.

When your data rate drops, these massive buffers fill up with packets that “rot” in the queue, causing latency to spike from milliseconds to seconds. BBRv3, combined with Active Queue Management (AQM) like FQ‑CoDel, acts as a pressure valve. FQ‑CoDel uses sojourn time, which is the actual time a packet spends waiting in the queue to distinguish between a “good queue” (a transitory burst) and a “bad queue” (persistent bufferbloat). If the sojourn time stays high, the protocol drops packets early to signal the sender to slow down. Interestingly, BBRv3 actually performs better with smaller buffers because the reduced delay allows its control loop to react much faster to changing wireless conditions.

Takeaway 5: The "Directional King": Why E-Vegas and E-NewReno Rule Different Worlds

Not all traffic is created equal, and research proves that the “best” protocol depends on the direction of the data.

Unidirectional Champion (E‑Vegas): For tasks like streaming a movie (where data flows primarily to you), E‑Vegas—Vegas combined with Explicit Congestion Notification (ECN) is the clear winner. In a controlled simulation designed to stress‑test stability (not raw speed), E‑Vegas maintained a steady throughput of roughly 49–51 kbps, keeping a consistent flow where other protocols repeatedly reset their windows.

Bidirectional Superiority (E‑NewReno): For video conferencing or gaming, where heavy traffic flows in both directions, E‑NewReno takes the crown. While E‑Vegas “additively shrinks” its window too aggressively when it senses delay from reverse‑traffic interference, E‑NewReno uses robust recovery logic to handle the competition. In the same constrained testbed, NewReno achieved 180 kbps, while E‑NewReno (with Snoop) reached a dominant 208 kbps.

These differences highlight a deeper insight: ECN marking thresholds can be tuned independently at each network node, nearly eliminating buffer‑induced losses while preserving high utilization.

Conclusion: The Future of Frictionless Air

We are witnessing a fundamental shift from “blind” protocols that guess at the state of the air to “aware” protocols that use cross‑layer data and explicit feedback. With BBRv3 already deployed at global scale and Wi‑Fi 7 on the horizon, the intelligence of the software managing the connection is becoming more vital than the raw gigabit rating on the box.

The hardware is already fast enough. The real bottleneck is not a lack of spectrum, it’s the logic layer that manages it. We have to ask: are our current hardware‑focused upgrade cycles ignoring the very intelligence that makes the internet feel fast? Your Wi‑Fi will stop gaslighting you only when the protocol learns to stop lying to itself. The real “aha!” moment comes when we realize that the best connection isn’t just about more power, it is about more intelligent communication.

References
[1] H. Balakrishnan, S. Seshan, and R. H. Katz, “Improving TCP/IP performance over wireless networks,” in Proc. ACM MobiCom, 1995.
[2] C. Casetti, M. Gerla, S. Mascolo, M. Y. Sanadidi, and R. Wang, “TCP with Explicit Congestion Notification: The E‑Vegas Approach,” in Proc. IEEE ICC, 2002. (Simulation results for E‑Vegas and E‑NewReno throughput cited in context.)
[3] S. Floyd, “TCP and Explicit Congestion Notification,” ACM Comput. Commun. Rev., vol. 24, no. 5, 1994. (Foundational work on ECN; subsequent research demonstrated per‑node threshold tuning to nearly eliminate losses.)
[4] N. Cardwell, Y. Cheng, C. S. Gunn, S. H. Yeganeh, and V. Jacobson, “BBR Congestion Control,” IETF draft‑cardwell‑iccrg‑bbr‑congestion‑control‑02, work‑in‑progress, 2023.

The Silent Co-Pilot: How AI is redefining the Network and the Network Engineer

sujan khadka — Sun, 05 Oct 2025 15:17:15 +0000

The internet and networks have always been a complex and static beast. For decades, the network engineers armed with a command-line interface, deep knowledge, and a reactive mindset has worked to create an efficient path and implement efficient protocols, is always alert for unexpected failures, and sometimes bottlenecks due to expected traffic.

With the internet networks evolving and everyone wanting buffer-free and instant downlink/uplink, we definitely want it to grow smarter and become more dynamic, and we want the ability to maintain it. Can we invest in more research for more protocols? Can we have smart hardware and devices? The catalyst for the change? Artificial Intelligence.

As AI integrates into nearly every technological aspect, AI-controlled networking has become an imminent reality, not a sci-fi fantasy. It has already made significant inroads in our network operations centers (NOCs), and its role is set to expand dramatically in the near future. The question now is how it will reshape overall internet and networks with multiple aspects like privacy, hackers and ethicality on the line,

The Dawn of the Self-Driving Network: What to Expect

Can we expect an autonomous system with AI integration? Will network engineers be redefined same as a software developers? Will corresponding term in network same as ‘Vibe Coder’ will be introduce?

The Self-Optimizing Network
Say goodbye to the manual and static configurations that are perfect for Tuesday at 10 AM but useless during a Thursday afternoon video conference rush. AI might continuously analyze live traffic patterns, latency, jitter, and bandwidth usage. We can expect it to automatically adjust routing protocols, QoS policies, and load balancing in real-time. We can definitely expect a network will no longer just be a pipeline; it will be a dynamic, flowing system that adapts to the complexities faced.
Predictive Maintenance
Instead of reacting to a switch failure that takes down a critical application, AI could predict it. By analyzing subtle patterns in equipment behavior, traffic anomalies, and past data, the AI can flag a potential power supply failure or a degrading optic before it causes an outage. This moves us from a reactive "break-fix" model to a truly proactive and predictive approach to network management.
Intent-Based Networking (IBN): Speaking the Business Language
This is a need. Instead of manually configuring hundreds of access control lists (ACLs) and VLANs across dozens of devices, engineers will simply specify high-level business objectives. You will tell the network: "Prioritize live sports/meeting traffic above all else," or "Ensure 99.99% uptime for the CRM application." The AI will then translate these requirements into the thousands of specific, complex configurations needed across your entire infrastructure.
The Automated Security Sentinel
The speed of modern cyber threats outpaces human reaction time. AI-powered security can detect a DDoS attack, a ransomware pattern, or an anomalous lateral movement and respond in milliseconds. It can automatically isolate affected segments, reroute traffic, and deploy countermeasures, containing a threat before most humans have even registered the alert on a dashboard.

A Peek Under the Hood: How Does the AI Actually Work?

While it seems like magic, the AI relies on concrete technologies:

Machine Learning (ML) Models
These are trained on massive datasets of network telemetry—trillions of data points on packet loss, latency, and device health. They learn to recognize "normal" and can spot subtle anomalies that signal problems.

Reinforcement Learning
This is key for self-optimization. The AI tries different actions (e.g., changing a routing path) and receives "rewards" or "penalties" based on the outcome (e.g., lower latency is a reward, higher jitter is a penalty). Over time, it learns the optimal policies for any situation.

Natural Language Processing (NLP)
This allows the IBN system to understand high-level business intent, like "boost productivity app performance," and map it to technical parameters.

Navigating the Headwinds: Challenges and Limitations

While the future is bright, the path is not without obstacles. It is crucial to acknowledge the challenges:

The "Black Box" Problem
Sometimes, it is difficult to understand why an AI made a specific decision. This lack of transparency can be a major hurdle for troubleshooting and trust.

Data Bias and Garbage In, Garbage Out
An AI is at least as good as the data it is trained on. If the training data lacks diverse failure scenarios or contains hidden biases, the AI's recommendations will be flawed.

Integration Complexity
Weaving AI systems into legacy, multi-vendor environments is a significant technical challenge. The AI needs a unified view of the network to be effective.

Over-reliance and Skill Erosion
The risk is that engineers, trusting the AI too much, may lose the foundational skills needed to intervene when the system encounters a true edge case it cannot handle.

The Network Engineer of the Future From Pilot to Mission Control
This all leads to the big, pressing question: Will AI replace network engineers?

The answer is a big no. However, it will fundamentally—and irreversibly—transform their role. The hands-on CLI jockey will evolve into a strategic architect and AI overseer.

From Configuration to Strategy
Engineers will spend far less time on repetitive, device-level configuration. Their value will shift to designing robust network architectures, aligning technology with business goals, and strategic planning.

The Rise of the AI Supervisor
It is obvious that someone needs to train, validate, and oversee the AI. Engineers will become the co-pilots, ensuring the AI's decisions are sound and intervening when it encounters a novel situation it cannot handle. They will define the guardrails and policies within which the AI operates.

Master of Complex Problem-Solving
While AI handles the routine 95% of issues, human engineers will be freed up to tackle the novel 5%—the edge cases, the unprecedented failures, and the complex integrations that require true creativity and deep conceptual understanding.

A New Skill Set is required
The future belongs to the hybrid engineer. Deep traditional networking knowledge will need to be complemented by an understanding of AI/ML concepts, data analytics, and programming (especially Python and APIs). Knowing how to work with the AI will be as important as knowing how to work on the network.

Your Call to Action: Preparing for the AI-Augmented Era
The transition is already underway. The question is, how do you prepare?

Embrace Automation Now: Start learning Ansible, Python, or Terraform. Automate a simple task, like generating switch configurations. This is the foundational skill.

Get Data-Literate: Understand how to work with APIs to pull telemetry data from your network devices. Familiarize yourself with data visualization tools.

Dabble in AI Concepts: You do not need a PhD. Take an online introductory course on Machine Learning to understand the basic concepts of training, models, and inference. This demystifies the technology.

Focus on Business Alignment: Practice translating technical capabilities into business outcomes. Why does the sales team need a better VPN? How does network performance influences customer satisfaction? This is the language of Intent-Based Networking.

Within the next 5-10 years, AI involvement in networking will be the norm, not the exception. The network will become a silent, self-optimizing utility—much like the power grid, but infinitely more intelligent.

The relationship between the engineer and the network is being redefined. It's no longer about hands-on control, but about high-level guidance. The network engineer of the future will not be in the cockpit manually flying the plane; they will be in mission control, setting the destination and monitoring the systems, trusting a highly capable AI co-pilot to handle the journey.

Start building your mission control skills today. The future belongs to those who collaborate with the machine.

5 Python Automation Scripts to Supercharge Your Productivity

sujan khadka — Mon, 22 Sep 2025 19:20:39 +0000

With AI and automation taking over the world by storm, it is now essential for a normal person to work on basic skillset. Python is the perfect language to start for this as it popular for its lightweight, easy to read syntaxes, and it is packed with libraries that make automation painless.
In this post, we will explore beginner level of five Python mini-projects that you can use right away to improve your workflow.

1. 🗂 Auto-Organize Your Downloads Folder

Problem: Cluttered downloads folder with files everywhere
Solution: Automatically sort files into categorized folders

import os
import shutil
from pathlib import Path

# Path to your Downloads folder
downloads_path = Path.home() / "Downloads"

# File type categories
file_types = {
    "Images": [".jpg", ".jpeg", ".png", ".gif", ".svg"],
    "Documents": [".pdf", ".docx", ".txt", ".pptx", ".xlsx"],
    "Archives": [".zip", ".rar", ".7z", ".tar"],
    "Videos": [".mp4", ".mov", ".avi", ".mkv"],
    "Audio": [".mp3", ".wav", ".flac"],
    "Code": [".py", ".js", ".html", ".css", ".json"]
}

for file in downloads_path.iterdir():
    if file.is_file():
        file_moved = False
        for folder, extensions in file_types.items():
            if file.suffix.lower() in extensions:
                target_folder = downloads_path / folder
                target_folder.mkdir(exist_ok=True)
                shutil.move(str(file), str(target_folder / file.name))
                print(f"✅ Moved {file.name} to {folder}/")
                file_moved = True
                break

        # If file type doesn't match any category, put in "Other"
        if not file_moved:
            other_folder = downloads_path / "Other"
            other_folder.mkdir(exist_ok=True)
            shutil.move(str(file), str(other_folder / file.name))
            print(f"📁 Moved {file.name} to Other/")

🎯 How to use:

Save as organize_downloads.py
Run with python organize_downloads.py
Schedule to run daily with Task Scheduler/cron

2. ⏰ Daily Task Reminder in Terminal

Problem: Forgetting daily priorities
Solution: Get your task list automatically displayed when opening terminal

python

from datetime import datetime
import json
import os

# Define your daily tasks
tasks = [
    "🌅 Review yesterday's notes and plan today",
    "📧 Check and respond to urgent emails (15 min max)",
    "🎯 Work on top priority project (90 min focus)",
    "💧 Hydration break + stretch",
    "📊 Afternoon review and plan tomorrow"
]

# Customizable header
print("\n" + "="*50)
print(f"📅 TODAY'S PLAN - {datetime.today().strftime('%A, %B %d, %Y')}")
print("="*50)

for i, task in enumerate(tasks, 1):
    print(f"{i}. {task}")

print("\n💡 Tip: You've got this! One task at a time.")
print("="*50)

🎯 How to use:

Windows: Add to PowerShell profile
Mac/Linux: Add to ~/.bashrc or ~/.zshrc
VS Code: Add to terminal startup commands

3. 🧠 Quick Notes to Markdown

Problem: Ideas lost because note-taking is cumbersome
Solution: One-command note capture with automatic formatting

python

from datetime import datetime
import os

# Create notes directory if it doesn't exist
notes_dir = Path.home() / "QuickNotes"
notes_dir.mkdir(exist_ok=True)

print("📝 Quick Note Capture")
print("Type your note (press Enter twice to finish):")

lines = []
while True:
    try:
        line = input()
        if line == "" and lines and lines[-1] == "":
            break
        lines.append(line)
    except EOFError:
        break

note_content = "\n".join(lines[:-1])  # Remove the last empty line

if note_content.strip():
    # Create filename with timestamp
    timestamp = datetime.now().strftime("%Y-%m-%d_%H-%M-%S")
    filename = notes_dir / f"note_{timestamp}.md"

    # Write formatted markdown
    with open(filename, "w", encoding="utf-8") as f:
        f.write(f"# Note - {datetime.now().strftime('%A, %B %d, %Y at %H:%M')}\n\n")
        f.write(note_content)
        f.write(f"\n\n---\n*Captured automatically*")

    print(f"✅ Note saved to: {filename}")
else:
    print("❌ No content entered. Note not saved.")

🎯 How to use:

Save as quick_note.py
Create alias: alias note="python /path/to/quick_note.py"
Run note anytime to capture ideas

4. 📊 Instant CSV to Summary

Problem: Spending too much time opening spreadsheets for quick insights
Solution: Command-line data summary in seconds

python

import pandas as pd
import numpy as np
from pathlib import Path

def analyze_csv(filename):
    try:
        # Read CSV file
        df = pd.read_csv(filename)

        print("\n" + "="*60)
        print(f"📊 DATA ANALYSIS: {filename}")
        print("="*60)

        # Basic info
        print(f"📏 Shape: {df.shape[0]} rows × {df.shape[1]} columns")
        print(f"🔑 Columns: {', '.join(df.columns)}")

        # Data types
        print("\n📋 Data Types:")
        for col in df.columns:
            dtype = str(df[col].dtype)
            unique_count = df[col].nunique()
            print(f"  • {col}: {dtype} ({unique_count} unique values)")

        # Numerical summary
        numeric_cols = df.select_dtypes(include=[np.number]).columns
        if not numeric_cols.empty:
            print(f"\n🧮 Numerical Summary:")
            print(df[numeric_cols].describe().round(2))

        # Missing values
        missing = df.isnull().sum()
        if missing.sum() > 0:
            print(f"\n⚠️  Missing Values:")
            for col, count in missing.items():
                if count > 0:
                    print(f"  • {col}: {count} missing ({count/len(df)*100:.1f}%)")
        else:
            print(f"\n✅ No missing values found")

        print("="*60)

    except FileNotFoundError:
        print(f"❌ File '{filename}' not found!")
    except pd.errors.EmptyDataError:
        print("❌ File is empty!")
    except Exception as e:
        print(f"❌ Error reading file: {e}")

# Main execution
if __name__ == "__main__":
    filename = input("Enter CSV filename (or path): ").strip()
    analyze_csv(filename)

🎯 How to use:

bash

python csv_analyzer.py
Enter CSV filename: data/sales.csv

5. 🌐 Fast Website Status Checker

Problem: Manually checking if websites/services are online
Solution: Bulk status monitoring with one command

python

import requests
import time
from datetime import datetime

def check_website(url, timeout=5):
    """Check if a website is accessible"""
    try:
        start_time = time.time()
        response = requests.get(url, timeout=timeout, headers={
            'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'
        })
        response_time = round((time.time() - start_time) * 1000, 2)

        if response.status_code == 200:
            return "✅ UP", response.status_code, response_time
        else:
            return "⚠️  ISSUE", response.status_code, response_time
    except requests.exceptions.Timeout:
        return "⏰ TIMEOUT", "N/A", timeout*1000
    except requests.exceptions.ConnectionError:
        return "❌ DOWN", "N/A", "N/A"
    except Exception as e:
        return "🚫 ERROR", str(e), "N/A"

# Websites to monitor
websites = [
    "https://google.com",
    "https://github.com",
    "https://stackoverflow.com",
    "https://docs.python.org",
    "https://your-app.com",
    "https://api.yourservice.com"
]

print(f"\n🌐 WEBSITE STATUS CHECK - {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}")
print("="*70)

results = []
for url in websites:
    status, code, response_time = check_website(url)
    results.append((url, status, code, response_time))
    print(f"{status} {url}")
    print(f"   Status: {code} | Response Time: {response_time}ms")
    time.sleep(1)  # Be nice to servers

print("="*70)

# Summary
up_count = sum(1 for _, status, _, _ in results if status == "✅ UP")
print(f"📈 Summary: {up_count}/{len(websites)} websites operational")

# Save log
log_file = "website_status.log"
with open(log_file, "a") as f:
    f.write(f"\n{datetime.now().strftime('%Y-%m-%d %H:%M')} - {up_count}/{len(websites)} up\n")

print(f"📝 Log saved to: {log_file}")

🎯 How to use:

Customize the websites list with your URLs
Run with python status_checker.py
Schedule for automated monitoring

🚀 Taking It Further

Automate Execution:

bash

#Windows Task Scheduler
# Create daily task for organize_downloads.py
# Mac/Linux crontab (run every day at 9 AM)
0 9 * * * /usr/bin/python3 /path/to/organize_downloads.py
# Monitor websites every hour
0 * * * * /usr/bin/python3 /path/to/status_checker.py

Combine Scripts:

Create a master script that runs all automations:

python

# master_automation.py
import organize_downloads
import status_checker

def main():
    print("🚀 Running daily automations...")
    organize_downloads.main()
    status_checker.main()
    print("✅ All automations completed!")

if __name__ == "__main__":
    main()

💡 Final Thoughts
These scripts demonstrate how a few lines of Python can save hours of manual work each week. The real power comes from:

Customization: Adapt them to your specific needs
Integration: Combine them into workflows
Scheduling: Make them run automatically
Sharing: Help your team work smarter

Start small: Pick one script that solves your most annoying repetitive task. Run it manually for a week, then automate it. Build from there!

Which automation will you implement first? Share your experience or suggest other useful scripts in the comments below

What is in the Internet's Traffic Jam? A Story of TCP and UDP on a Shared Wireless Lane

sujan khadka — Tue, 16 Sep 2025 20:06:42 +0000

Have you ever been in a crowded coffee shop, trying to load a website while someone else is on a video call? Your web page loads slowly, stutteringly, while their video seems to flow just fine. This isn't just bad luck—it's a fundamental characteristic of how different types of internet traffic behave. Keeping all filters and priorities aside, what will happen if TCP and UDP is set to ahead-to-head in a battle for bandwidth on a shared wireless link.

The Protagonists: TCP vs. UDP

Before we dive into the basic introduction of the two protocols:

TCP (Transmission Control Protocol) : It is most influential at the transport layer. Before any data is sent, the TCP establishes a short connection between two network endpoints via a three-way handshake. The careful, reliable postal service of the internet. It's used for web browsing, email, and file downloads. TCP guarantees that every packet arrives, in order. If a packet gets lost, it stops, waits for an acknowledgment, and resends it. It's polite and plays well with others, constantly adjusting its sending rate to avoid congesting the network (a process called congestion control).

UDP (User Datagram Protocol) : Instead of the TCP’s lengthy handshake process, however, UDP sends small, independent packets known as datagrams, without cross-referencing a connection first. The relentless, high-speed courier. It's used for live video streaming, online gaming, and VoIP calls. UDP fires packets into the network as fast as it can, with no regard for whether they arrive or in what order. There are no acknowledgments, no retries. It's a "fire-and-forget" protocol that prioritizes speed over reliability.

To be more precise, TCP and UDP are transport protocols that run on top of the Internet Protocol (IP). If IP is the road, then TCP is a careful driver who follows the rules and checks their mirrors, while UDP is a speedster who weaves through traffic with no brakes.

The Foundation: It All Runs on IP

Before we see them in action, it's crucial to understand that both TCP and UDP are not standalone entities. They are transport layer protocols, and they both rely on a common foundation: the Internet Protocol (IP).

IP (The Postal Network): IP is the fundamental, low-level protocol responsible for addressing and routing packets across the internet. It defines how to get a packet from one computer to another. However, IP is "best-effort" and unreliable. It will try its best to deliver your packet, but if a router is overloaded, the packet might be silently dropped with no notification. It doesn't care about the order of packets or their content.

TCP and UDP (The Courier Services): This is where our two protagonists come in. They operate on top of IP, acting as different types of courier services that use the postal network (IP) to deliver their payloads (your data).

In the context of our simulation, this means both the TCP data segments and UDP datagrams are packaged into IP packets. They travel the same physical network path from the senders to the Access Point and on to the receiver. The AP, acting as a router, makes forwarding decisions based on the IP headers, largely unaware of whether the packet contains a TCP segment pleading for reliability or a UDP datagram rushing through. This shared foundation is what makes their competition so direct and inevitable. They are not on different tracks; they are different types of vehicles fighting for space on the exact same road.

This experiment models coexistence of TCP and UDP traffic over a shared wireless medium to study how transport-layer protocols interact under contention. The goal is to analyze performance metrics such as throughput, latency, jitter, packet loss, and fairness when a best-effort TCP flow and a rate-controlled UDP flow compete for a single bottleneck: a Wi-Fi access point.

==== SIMULATION PARAMETERS ====
Simulation Duration: 25 seconds
TCP Algorithm:

TcpNewReno
TcpCubic
TcpBbr

Bottleneck Bandwidth: 10 Mbps
Bottleneck Delay: 10 ms
Buffer Size: 1000 packets
UDP Rate: 6 Mbps

Output and Comparison

How TCP Managed Head-On with UDP ?

NewReno & Cubic (Loss-based TCP): They competed head-on with UDP by filling buffers and waiting for packet loss to signal congestion. This led to queue buildup, hurting latency-sensitive UDP traffic. TCP achieved decent throughput but at the cost of delay and packet loss for both flows.
BBR (Model-based TCP): Did not rely on buffer filling to probe bandwidth. Maintained low queue occupancy, allowing UDP to get a clean, low-latency path. Result: No packet loss, much lower delay, and still near-maximal throughput — making it much friendlier for real-time UDP.

Lets analyze a TCP BBR and UDP graphically based on simulation output:

The graph shows that UDP throughput (red) quickly ramps up to ~6 Mbps and stays stable, indicating that UDP gets its share of the bandwidth almost immediately.
TCP throughput (blue) ramps up more slowly (classic congestion window growth), then stabilizes around ~3.8–4.0 Mbps — meaning TCP backs off to avoid overwhelming UDP traffic.
In NewReno/Cubic, this stable point was reached after filling buffers, causing higher queueing delays (600+ ms).
In BBR, the same balance was achieved without filling the buffer, resulting in much lower delay (~54 ms) and zero packet loss.
The throughput split (~60% UDP / ~40% TCP) shows fair resource sharing — neither flow starved, and total link utilization was >100% (due to buffer effects and slight queue overfill).
This is good for real-world deployments where multiple traffic classes (bulk transfers + real-time) share the same bottleneck.

The results clearly show that BBR provides a much healthier coexistence between TCP and UDP by avoiding buffer bloat and keeping latency low. For networks carrying IPTV, VoIP, and bulk TCP traffic together, adopting BBR or AQM is a practical step toward ensuring fairness, efficiency, and end-user satisfaction.

Source Code : Github link