Shannon Capacity Analysis Using Wireshark TCP Throughput Under Varying Traffic Loads

Shannon Capacity Analysis Using Wireshark TCP Throughput

1. Introduction

Modern communication networks operate within hard theoretical boundaries defined by Claude Shannon's channel capacity theorem. Originally formulated in 1948, Shannon's theorem establishes the maximum rate at which information can be reliably transmitted over a noisy channel. For any real-world network, understanding the gap between this theoretical maximum and observed throughput is critical for diagnosing bottlenecks, optimising configurations, and planning capacity.

This experiment leverages Wireshark's TCP Stream Graph feature to visually measure TCP throughput across four distinct traffic intensity levels, then compares the resulting slope-based throughput values against the Shannon capacity ceiling of approximately 120 Mbps computed for the test environment. Traffic was generated using a single curl.exe command per level — downloading files of increasing size (10 MB, 100 MB, 1 GB, 10 GB) from a public speed-test server — while tshark simultaneously captured all packets into .pcap files for post-analysis in Wireshark.

The most significant finding is that TCP throughput was not limited by the Shannon channel capacity but by TCP receive window scaling behaviour. Once the OS scaled the TCP window from near-zero to 8 MB in the medium and high traffic captures, throughput immediately jumped to ~100 Mbps — reaching 83.3% of the Shannon ceiling. The channel had available capacity throughout; the transport layer was the sole bottleneck.

2. Objectives

  • To compute the theoretical Shannon channel capacity (C = B · log₂(1 + S/N)) for the experimental network environment and establish it as an upper throughput bound for comparative analysis.
  • To capture and analyse TCP stream graphs in Wireshark across four curl-generated traffic intensities (low, normal, medium, high) and extract throughput values by measuring the slope of the time-versus-bytes-transferred curve.
  • To identify and explain the practical factors — including TCP receive window scaling, Bandwidth-Delay Product, and radio-layer SNR variation — that cause observed throughput to fall below the Shannon theoretical limit, and to recommend optimisations accordingly.

3. SharkFest Reference

Chappell, L. (2019). TCP Analysis Using Wireshark. Presented at SharkFest'19 US, Santa Clara, CA. Wireshark Developer and User Conference.

This SharkFest session by Laura Chappell is a foundational reference for TCP performance analysis using Wireshark. Chappell demonstrates how Wireshark's built-in TCP Stream Graphs — specifically the Time-Sequence (Stevens), Time-Sequence (tcptrace), Throughput, Window Scaling, and Round Trip Time views — can be used to diagnose real-world network problems. The session covers interpretation of the slope in throughput graphs as a direct measure of effective data transfer rate, explains the visual signatures of packet loss, retransmissions, and zero-window conditions, and introduces the concept of Bandwidth-Delay Product as a key limiting factor in long-fat network paths. The session also discusses TCP window scaling (RFC 7323) and SACK effects on observable throughput curves. This reference directly informed the five-graph-per-capture methodology used in this experiment to produce exactly 20 diagnostic observations.

4. Architecture Diagram

The following diagram shows the experimental topology. Two PowerShell windows ran simultaneously: Window 1 ran tshark to capture packets; Window 2 ran a single curl.exe command to generate traffic.

+------------------------------------------------------------------+
|                    TEST MACHINE (Client)                         |
|                      Windows 11 / PowerShell                     |
|                                                                  |
|  +---------------+   +----------------+   +------------------+  |
|  |  curl.exe     |-->|  NIC / TCP/IP  |-->|   Wireshark      |  |
|  | (single HTTP  |   |    Stack       |   |  (post-capture   |  |
|  |  DL command)  |   +-------+--------+   |   analysis)      |  |
|  +---------------+           |            +--------+---------+  |
|                               |  raw pkts           |           |
|  +---------------+            |                     v           |
|  |  tshark.exe   |<-----------+           TCP Stream Graphs:    |
|  | (Window 1,    |                         Stevens / tcptrace   |
|  |  captures)    |---- saves -->           Throughput           |
|  +---------------+  capture_X.pcap         Window Scaling       |
|                                            Round Trip Time       |
+------------------------------------------------------------------+
                          |
                  Mobile Hotspot
                  Bandwidth ~100 Mbps | SNR ~30 dB
                          |
                          v
            +------------------------------+
            |    speedtest.tele2.net       |
            |  10 MB / 100 MB / 1 GB /     |
            |          10 GB files         |
            +------------------------------+

Shannon: C = 100 x log2(1 + 1000) = ~120 Mbps  (theoretical ceiling)

Figure 1: Experimental topology — curl.exe generates single-command HTTP traffic, tshark captures into .pcap files, Wireshark TCP Stream Graphs extract throughput via slope measurement.

5. Procedure

5.1 Shannon Capacity Computation

Before running any captures, the theoretical channel ceiling was calculated:

C = B × log2(1 + S/N)
Given: B = 100 Mbps (mobile hotspot link speed)
SNR = 30 dB => linear SNR = 10^(30/10) = 1000

C = 100 x log2(1 + 1000)
= 100 x log2(1001)
= 100 x 9.967
= ~120 Mbps (Shannon ceiling used in all comparisons)

5.2 Traffic Generation Commands

Traffic was generated using one curl.exe HTTP download command per intensity level. File size was the control variable — larger files sustain higher throughput and produce richer graphs. This requires only a single command per capture.

Traffic Levelcurl.exe Command (Window 2)File SizePurpose
Lowcurl.exe -o NUL http://speedtest.tele2.net/10MB.zip10 MBBaseline, near-idle channel
Normalcurl.exe -o NUL http://speedtest.tele2.net/100MB.zip100 MBTypical download workload
Mediumcurl.exe -o NUL http://speedtest.tele2.net/1GB.zip1 GBSustained load, BDP saturation
Highcurl.exe -o NUL http://speedtest.tele2.net/10GB.zip10 GBMaximum stress, link saturation

5.3 tshark Capture Commands

tshark was started in Window 1 first, then curl was immediately run in Window 2. For large files, curl was stopped with Ctrl+C after 2–3 minutes, then tshark was stopped.

## WINDOW 1 — start tshark FIRST
# Run one of the following per session:
tshark -i "Wi-Fi" -w C:\Users\palla\capture_low.pcap
tshark -i "Wi-Fi" -w C:\Users\palla\capture_normal.pcap
tshark -i "Wi-Fi" -w C:\Users\palla\capture_medium.pcap
tshark -i "Wi-Fi" -w C:\Users\palla\capture_high.pcap

## WINDOW 2 — run curl immediately after starting tshark
curl.exe -o NUL http://speedtest.tele2.net/10MB.zip    # Low
curl.exe -o NUL http://speedtest.tele2.net/100MB.zip   # Normal
curl.exe -o NUL http://speedtest.tele2.net/1GB.zip     # Medium (Ctrl+C ~2 min)
curl.exe -o NUL http://speedtest.tele2.net/10GB.zip    # High   (Ctrl+C ~3 min)

## Stop order: Ctrl+C Window 2 first, then Ctrl+C Window 1

5.4 Wireshark Analysis Method

Each .pcap was opened in Wireshark. A TCP stream was selected via right-click → Follow → TCP Stream, then five graph types were opened under Statistics → TCP Stream Graphs: Stevens, tcptrace, Throughput, Window Scaling, and Round Trip Time. Throughput slope was measured as ΔBytes × 8 / Δtime(s) in the steady-state region.

6. Graph Inferences (20 Observations)

Formulae used throughout:  Slope (Mbps) = ΔBytes × 8 / Δt(s) / 106    BDP = Throughput(B/s) × RTT(s)    Shannon ceiling = 120 Mbps

▶ LOW TRAFFIC — low.pcap  (10 MB curl download)
Low traffic Stevens sequence number graph
Graph 1 — Sequence Numbers (Stevens) · low.pcap
Slope = 0.93 Mbps → 0.78% of Shannon limit. The Stevens graph rises from 0 to 11 MB over 95 seconds: slope = (11×106×8)/95 = 0.93 Mbps; utilisation = 0.93/120×100 = 0.78%. The curve is non-linear — a steep initial slow-start followed by a visible plateau at t≈35s (~5 MB mark), then gradual recovery. TCP's slow-start algorithm limits throughput far below the Shannon ceiling before any network constraint is encountered, because the 10 MB file is too small for TCP to complete slow-start and reach steady state.
Low traffic tcptrace graph
Graph 2 — Sequence Numbers (tcptrace) · low.pcap
Sparse retransmit markers confirm near-zero loss at low load. Orange and yellow event dots are sparse — fewer than 10 across 95 seconds. Shannon's theorem predicts near-zero bit error rate at 0.78% utilisation; the observed near-zero retransmission rate is fully consistent with this prediction. The channel is operating well within its noise tolerance margin at this load, confirming the theoretical model holds.
Low traffic throughput graph
Graph 3 — Throughput · low.pcap
Peak 2.5 Mbps, moving average ~1 Mbps → severe burstiness due to radio scheduling. The gold moving average oscillates between near-zero and 2.5 Mbps without stabilising. BDP = (1×106/8) × 0.050 = 6.25 KB — well within 64 KB default window, so the window is not the bottleneck. The bursty pattern is caused by the LTE/5G radio scheduler allocating resource blocks intermittently at low data rates, creating gaps in packet delivery that appear as throughput valleys.
Low traffic RTT graph
Graph 4 — Round Trip Time · low.pcap
Spikes to 800 ms despite low load; baseline ≈0–5 ms. BDP at spike = 100 KB > 64 KB window → stall confirmed. RTT spikes to 800 ms, 700 ms, and 600 ms at multiple points despite minimal network load. These are not queuing delays but LTE/5G resource block reallocation delays. At 800 ms: BDP_spike = (1×106/8) × 0.800 = 100 KB, exceeding the 64 KB default window. The sender ran out of window space and stalled — directly explaining the plateau in Graph 1 at t≈35s. This is a BDP bottleneck induced by radio scheduling latency.
Low traffic window scaling graph
Graph 5 — Window Scaling · low.pcap
Unacked bytes spike to 125 KB; confirms BDP = bandwidth × RTT at the stall point. Unacked outstanding bytes spike to 125 KB early in the transfer, corresponding precisely to the 800 ms RTT event. BDP = (1×106/8) × 0.800 = 100 KB ≈ 125 KB observed. The sender had exactly BDP-worth of data unacknowledged and could send no more. This validates Shannon's model: the channel had throughput capacity, but the transport layer could not utilise it due to the window constraint created by radio scheduling latency.
▶ NORMAL TRAFFIC — normal.pcap  (100 MB curl download)
Normal traffic Stevens graph
Graph 6 — Sequence Numbers (Stevens) · normal.pcap
Slope = 0.072 Mbps → 0.06% of Shannon limit; worst capture despite largest intended load. Only ~1 MB was transferred in 115 seconds: slope = (1×106×8)/115 = 69.6 kbps = 0.072 Mbps; utilisation = 0.072/120×100 = 0.06%. A visible stall at t≈50s (flat horizontal region) indicates a full TCP Retransmission Timeout (RTO) where the transfer froze completely before restarting. This is the lowest throughput of all four captures and demonstrates that mobile channel SNR can vary drastically, making Shannon capacity a dynamic rather than static value.
Normal traffic tcptrace graph
Graph 7 — Sequence Numbers (tcptrace) · normal.pcap
Dense retransmit clusters at t=10s, 20s, 35s, 45s confirm repeated severe loss events and RTO. At least 5 distinct clusters of red and yellow markers are visible, each representing fast retransmissions triggered by 3 duplicate ACKs. The trace flatlines at t=50s for ~5 seconds — a full RTO where TCP reset cwnd to 1 MSS and restarted slow-start from scratch. Shannon's theorem attributes this to a drop in effective SNR, which directly reduces C; here, interference reduced the practical capacity to near-zero Mbps.
Normal traffic window scaling graph
Graph 8 — Window Scaling · normal.pcap
Unacked bytes capped at 21 KB; congestion, not window, is the bottleneck here. Outstanding bytes oscillate between 0 and 21 KB throughout. BDP at 0.072 Mbps with RTT≈500 ms during loss recovery: BDP = (72,000/8) × 0.500 = 4.5 KB. The observed window (21 KB) is 4.7× larger than BDP, so the window is not limiting throughput. The bottleneck is purely packet loss resetting cwnd. This contrasts sharply with medium and high captures where window size was the primary constraint.
Normal traffic RTT graph
Graph 9 — Round Trip Time · normal.pcap
Spikes to 2.3 s confirm full RTO events and severely degraded effective channel SNR. Baseline RTT is already elevated at 100–300 ms (vs. near-zero for low traffic), with spikes to 2.3 s at t≈70s and 1.4 s at t≈60s and 75s. These multi-second RTT values correspond to TCP RTO timeouts. Shannon's formula C = B × log₂(1 + S/N) shows that lower SNR directly lowers C; the 2.3-second RTT spikes indicate the mobile channel's effective SNR dropped so severely that practical capacity fell to near-zero Mbps.
Normal traffic throughput graph
Graph 10 — Throughput · normal.pcap
Peak 200 kbps, average ~75 kbps; 99.94% of Shannon capacity wasted by radio interference. The gold moving average oscillates between 0 and 200 kbps with segment length dots clustering at 2.5–3 KB. Shannon gap = 120 Mbps − 0.075 Mbps = 119.925 Mbps unused. This capture demonstrates that Shannon capacity is an upper bound under ideal SNR; real-world radio interference can reduce the effective capacity to near-zero. The theoretical ceiling of 120 Mbps applies only when the channel noise is at the assumed 30 dB SNR level.
▶ MEDIUM TRAFFIC — med.pcap  (1 GB curl download, 403 MB / 180 s)
Medium traffic Stevens graph
Graph 11 — Sequence Numbers (Stevens) · med.pcap
Exponential curve: avg slope = 17.9 Mbps; end rate = 93.3 Mbps = 77.8% of Shannon limit. Average slope = (403×106×8)/180 = 17.9 Mbps. End-region slope (t=150–180s, ΔBytes ≈350 MB): (350×106×8)/30 = 93.3 Mbps; utilisation = 93.3/120 = 77.8%. The exponential shape is caused entirely by the TCP window scaling event in Graph 13. The channel had full capacity throughout; the window size was the only bottleneck for the first 120 seconds.
Medium traffic tcptrace graph
Graph 12 — Sequence Numbers (tcptrace) · med.pcap
Nearly clean trace with only 2–3 isolated markers; window-limited, not congestion-limited. The tcptrace graph is almost entirely clean — a smooth exponential curve with only 2–3 sparse event dots near t=110s. This is the critical evidence: near-zero throughput for the first 120 seconds was NOT caused by packet loss. Zero retransmissions during the slow phase proves the bottleneck was purely the TCP receive window. Once the window scaled (Graph 13), throughput exploded without any change in network quality.
Medium traffic window scaling graph
Graph 13 — Window Scaling · med.pcap
Stepwise expansion 0 → 1 MB → 4 MB → 8 MB directly proves RFC 7323 TCP window scaling is the throughput switch. The green receiver window line makes three step jumps: near-zero until t≈110s, then 1 MB at t=110s, 4 MB at t=135s, 8 MB at t=150s. BDP at 93 Mbps, RTT≈5 ms: BDP = (93×106/8) × 0.005 = 58 KB. Even the 1 MB window vastly exceeds BDP, so throughput was unconstrained from t=110s. The stepwise jumps represent the OS TCP buffer doubling its window advertisement as slow-start completed — directly causing the exponential increase in Graph 11.
Medium traffic RTT graph
Graph 14 — Round Trip Time · med.pcap
Stable 0–5 ms baseline; only two spikes (47 ms, 30 ms); confirms negligible queuing throughout. RTT stays at 0–5 ms for almost the entire 180-second capture. With RTT = 5 ms, a 1 MB window enables theoretical throughput of (1×106×8)/0.005 = 1,600 Mbps — far exceeding both the observed peak and the Shannon ceiling. This confirms the window was not the binding constraint after t=110s; the physical link itself became the final limit, validating that the channel's Shannon capacity was the true ceiling.
Medium traffic throughput graph
Graph 15 — Throughput · med.pcap
Near-zero for 120 s, then ramp to 100 Mbps; peak utilisation = 83.3% of Shannon limit; gap = 20 Mbps. The gold moving average hugs the bottom for 120 seconds, then rises sharply to peak at ~100 Mbps. Shannon utilisation = 100/120×100 = 83.3%. Shannon gap = 120 − 100 = 20 Mbps. This 20 Mbps deficit is attributable to TCP/IP header overhead (~3.5%), upstream ACK traffic (~2%), and the 1-second MA window smoothing the instantaneous peak. The gap is structural and consistent — not caused by congestion or loss.
▶ HIGH TRAFFIC — cap_high.pcap  (10 GB curl download, 524 MB / 360 s)
High traffic Stevens graph
Graph 16 — Sequence Numbers (Stevens) · cap_high.pcap
Avg slope = 11.6 Mbps; end rate = 90 Mbps = 75% of Shannon limit; slow phase extended to 250 s by RTT spike. Average slope = (524×106×8)/360 = 11.6 Mbps. End-region slope (t=320–360s): ≈90 Mbps; utilisation = 75%. The slow phase lasted 250 seconds vs. 120 s for medium, because the 315 ms RTT spike at t≈65s increased the effective BDP. BDP at 315 ms spike: (11.6×106/8) × 0.315 = 456 KB — any window smaller than 456 KB would stall this transfer, explaining the extended flat phase.
High traffic tcptrace graph
Graph 17 — Sequence Numbers (tcptrace) · cap_high.pcap
Cleanest trace of all four captures; near-zero retransmissions over 360 s; pure window-limited behaviour. The tcptrace graph is a smooth exponential curve with virtually no event markers across 6 minutes — only one tiny cluster near t≈200s. A 10 GB download over 6 minutes with essentially zero packet loss, yet throughput was near-zero for 250 seconds. The slowness was entirely window-limited, definitively distinguishing window-limited from congestion-limited behaviour and confirming the Shannon channel capacity was available throughout.
High traffic window scaling graph
Graph 18 — Window Scaling · cap_high.pcap
Flat near-zero for 300 s, then explosive jump to 3.5 MB at t≈350 s; window is 31× BDP at peak. Outstanding bytes near zero for 300 seconds, then a sharp vertical jump to 3.5 MB at t≈350s. BDP at 90 Mbps, RTT≈10 ms: BDP = (90×106/8) × 0.010 = 112.5 KB. The observed window (3.5 MB) is 31× larger than BDP, confirming the OS advertised a large receive buffer and the physical link — not the window — was the final constraint at t=350s. Channel utilisation at this point: 90/120 = 75%, within 25% of the Shannon ceiling.
High traffic RTT graph
Graph 19 — Round Trip Time · cap_high.pcap
Clean 5–10 ms baseline; spike to 315 ms at t≈65 s delayed window scaling; end cluster to 255 ms confirms brief buffer fill. Two disruptions: (a) spike to 315 ms at t≈65s (likely 5G radio handover), setting BDP = 456 KB and stalling the transfer for the extended slow phase; (b) cluster to 255 ms at t≈350s caused by the sudden 3.5 MB data burst when the window opened, transiently filling the hotspot buffer before stabilising. The 315 ms spike is the primary cause of the 250-second slow phase observed in Graph 16.
High traffic throughput graph
Graph 20 — Throughput · cap_high.pcap
Near-zero for 300 s, peak 100 Mbps at end; utilisation = 83.3% of Shannon ceiling; theorem empirically validated. The gold moving average stays near zero for 300 seconds, then rises sharply to ~100 Mbps. Peak utilisation = 100/120×100 = 83.3%. Remaining gap = 20 Mbps — identical to medium, confirming a systematic structural overhead of ~16.7%. Across all 360 seconds and all 20 graphs in this experiment, no measurement ever exceeded 120 Mbps. Shannon's theorem is empirically validated: the channel capacity ceiling is an absolute bound, never breached regardless of file size, duration, or TCP window state.

7. New Findings & Recommendations

Key Findings

  • TCP window scaling — not bandwidth — is the dominant throughput bottleneck: In both medium and high captures, throughput was near-zero for 120–300 seconds not because the channel lacked capacity, but because the TCP receive window was too small. The window scaling event (Graph 13: 0 → 8 MB) caused an immediate jump from near-zero to ~100 Mbps, proving the channel had capacity throughout the entire transfer.
  • Peak observed = 100 Mbps = 83.3% of Shannon limit; gap is structural at ~20 Mbps: The consistent 20 Mbps gap across both medium and high captures is attributable to TCP/IP header overhead (~3.5%), upstream ACK traffic (~2%), and throughput graph MA smoothing (~11%). It is not caused by congestion or retransmissions, as confirmed by the near-clean tcptrace graphs.
  • Normal traffic shows how mobile SNR variation directly reduces Shannon capacity: The 2.3-second RTT spikes in normal.pcap indicate the effective channel SNR dropped severely. Shannon's formula shows lower SNR directly lowers C — here, practical capacity fell to 0.072 Mbps due to radio interference while the theoretical ceiling remained 120 Mbps.
  • Low traffic BDP = 100 KB at 800 ms RTT spike > 64 KB default window → stall: This created a BDP bottleneck at minimal load due purely to radio scheduling latency, demonstrating that even very low throughput can be window-limited in mobile environments with high intermittent RTT.
  • Shannon's ceiling validated empirically across all 20 graphs: No measurement in any of the 20 Wireshark graphs exceeded 120 Mbps, confirming Shannon's capacity theorem as an empirical fact, not just a theoretical construct.

Recommendations

  • Force early TCP window scaling: Configure the OS to advertise a large initial receive window (e.g., 4 MB) at handshake time to eliminate the 120–300 second dead zone seen in medium and high captures.
  • Deploy FQ-CoDel AQM on the hotspot router: The 800 ms RTT spikes in low traffic and 2.3-second spikes in normal traffic indicate poor buffer management. FQ-CoDel would cap queuing delay to ~5 ms, preventing BDP inflation and window stalls.
  • Switch to BBR congestion control: BBR probes bandwidth and RTT directly rather than reacting to loss. It would detect available capacity much earlier than the 120–300 second slow-start observed with default CUBIC.
  • Monitor actual SNR alongside captures: Use netsh wlan show interfaces to log SNR at capture time, allowing Shannon capacity to be computed dynamically for more precise comparisons.

8. AI Usage Disclosure

Perplexity AI was used for the following purposes:

  • Clarifying the mathematical derivation of the Shannon-Hartley theorem and SNR dB-to-linear conversion.
  • Identifying the SharkFest reference for TCP stream graph methodology.
  • Cross-checking the relationship between TCP window scaling (RFC 7323) and the Bandwidth-Delay Product constraint.

All experimental commands, pcap captures, graph readings, slope calculations, and conclusions are original work. AI assistance was limited to conceptual clarification only.

9. Conclusion

This experiment empirically validated Shannon's channel capacity theorem across four traffic conditions using Wireshark TCP Stream Graphs. The Shannon ceiling was computed as C = 100 × log₂(1 + 1000) ≈ 120 Mbps. Across all 20 graphs from four pcap captures, this ceiling was never breached.

The most significant finding was that throughput was limited by TCP receive window scaling, not by bandwidth. In medium and high captures, throughput ran near-zero for 120–300 seconds before the OS scaled the window to 4–8 MB, at which point throughput jumped immediately to ~100 Mbps (83.3% of Shannon's ceiling). The channel had available capacity throughout; the transport layer was the sole bottleneck.

CaptureAvg SlopePeakShannon %Primary Bottleneck
low.pcap0.93 Mbps2.5 Mbps0.78% / 2.1%TCP slow-start + radio RTT spikes (800 ms)
normal.pcap0.072 Mbps200 kbps0.06% / 0.17%Packet loss, RTO events, radio interference (RTT 2.3 s)
med.pcap17.9 Mbps~100 Mbps14.9% / 83.3%TCP window too small for first 120 s; scaling resolved it
cap_high.pcap11.6 Mbps~100 Mbps9.7% / 83.3%TCP window too small for first 300 s; scaling resolved it

The consistent 20 Mbps gap between observed peak and Shannon ceiling is a structural protocol overhead (~16.7%), confirmed as non-congestion-related by near-clean tcptrace graphs. Shannon's theorem is validated as an absolute empirical bound.

10. Demo Video

A walkthrough of the tshark captures, Wireshark TCP Stream Graphs, and slope readings is available on YouTube:

📺 Video

11. GitHub Repository

All .pcap files, tshark commands, graph screenshots, and this report are available at:

🔗 https://github.com/po-creates/computer_networks

References

  1. Shannon, C. E. (1948). A mathematical theory of communication. Bell System Technical Journal, 27(3), 379–423.
  2. Chappell, L. (2019). TCP Analysis Using Wireshark. SharkFest'19 US. Wireshark Foundation.
  3. Jacobson, V., & Karels, M. (1988). Congestion avoidance and control. ACM SIGCOMM, 18(4), 314–329.
  4. Borman, D., Braden, B., Jacobson, V., & Scheffenegger, R. (2014). TCP Extensions for High Performance. RFC 7323. IETF.
  5. Cardwell, N. et al. (2016). BBR: Congestion-based congestion control. ACM Queue, 14(5), 20–53.
  6. Gettys, J., & Nichols, K. (2012). Bufferbloat: Dark buffers in the internet. Comm. of the ACM, 55(1), 57–65.
  7. Wireshark Foundation. (2024). Wireshark User's Guide v4.x. https://www.wireshark.org/docs/wsug_html_chunked/
  8. Tele2 AB. (2024). Tele2 Speed Test Files. http://speedtest.tele2.net/

Acknowledgements

I sincerely thank my parents and family for their constant support and encouragement throughout my academic journey at VIT. Their patience and motivation during late-night lab sessions made this work possible.

I am deeply grateful to Vellore Institute of Technology (VIT), Chennai — specifically the School of Computer Science and Engineering (SCOPE) — for providing the infrastructure, laboratory resources, and academic environment that enabled this experiment.

This Digital Assignment (DA3) was completed as part of the course BCSE308L & Computer Networks during Winter Semester 2025–26. I sincerely thank my course faculty for designing this hands-on activity in network analysis and information theory.

I also acknowledge the open-source communities behind Wireshark, tshark, and the SharkFest conference for making world-class network analysis tools and educational resources freely available.

Finally, I thank my peers for their time in reviewing this blog and providing the technical comments below.

Tech Comments — Peer Reviews

Peer 1 — Adithi

Good demonstration.

Peer 2 — Mrinalini

Clarity of inferences, good demonstration.

Additional tech comments are visible in the Blogger comments section below and in the YouTube video comments.

Written by: Pallavi Chimanchode  |  Reg. No.: 23BCE1732  |  Date: April 2026

© 2026 Shannon Capacity Analysis — DA3  |  VIT Chennai, SCOPE  |  Computer Networks

Comments

Post a Comment