NS-3 Packet-Level Trace Dataset of Network Congestion at a Bottleneck Link

1. Overview This dataset contains packet-level traces generated with the ns-3 discrete-event network simulator to study congestion at a single bottleneck link. A 50-node dumbbell topology carries 300 concurrent flows belonging to three traffic classes — Elephant (long-lived TCP), Sheep (medium-rate UDP On/Off) and Mice (sparse, small-packet UDP On/Off). Every flow is forced to cross the bottleneck. The same traffic scenario is run under seven queue management schemes at the bottleneck router (DropTail, CoDel, FQ-CoDel, PIE, CAKE-equivalent FQ-COBALT, RED, Adaptive RED), each repeated as independent replications with different RNG run numbers. For every run, one unified CSV file records: IPv4 transmit/receive events at every node (with IP, TCP/UDP header fields, ports, TCP sequence number and ACK flag), enqueue / dequeue / drop events of the bottleneck queue in both directions (with queue occupancy and per-packet queueing delay), TCP RTT estimator updates. The dataset was produced for doctoral research on traffic classification (Mice/Sheep/Elephant), federated reinforcement learning (FRL) and delay-based active queue management (CoDel and dynamic variants). The DropTail traces are intended as a neutral baseline on which other AQM algorithms can be re-implemented and evaluated offline (e.g. in Python). Possible uses: benchmarking AQM algorithms (offline trace-driven evaluation), flow classification / elephant-flow detection with ground-truth labels (derived from port numbers, see §5), training machine-learning / reinforcement-learning models for congestion control, teaching ns-3 tracing and congestion behaviour. 2. Simulation environment Item Value Simulator ns-3 version 3.42 OS Ubuntu 22.04 Simulation script simulation_la50_v6.cc Simulation time 180 s per run (applications start at 1.0–1.5 s) 3. Network topology and link parameters N1 ─┐ ┌─ N13 N2 ─┤ access 20 Mbps / 5 ms ├─ N14 ... ├──────── N11 ══════════════════ N12 ────────┤ ... N10─┘ (Router-1) bottleneck (Router-2) └─ N50 10 Mbps / 50 ms 10 client nodes 38 server nodes Parameter Value Number of nodes 50 (N1–N50, ns-3 node index 0–49) Access links 20 Mbps, 5 ms propagation delay, DropTail device queue (ns-3 default size), no traffic-control layer Bottleneck link (N11–N12) 10 Mbps, 50 ms propagation delay, full duplex Bottleneck buffer 300 packets for every queue discipline Base RTT (client ↔ server) ≈ 120 ms (2 × (5 + 50 + 5) ms) Routing Ipv4GlobalRoutingHelper::PopulateRoutingTables() Node and IP address mapping Node (1-based) ns-3 index Role IPv4 address N1–N10 0–9 Clients (senders) Nk → 10.1.k.1 (k = 1…10) N11 10 Router-1 (bottleneck ingress) 10.1.k.2 on access side, 10.1.100.1 on bottleneck N12 11 Router-2 (bottleneck egress) 10.1.100.2 on bottleneck, 10.1.m.2 on access side N13–N50 12–49 Servers (receivers) node index j → 10.1.(j−1).1 (N13 = 10.1.11.1 … N50 = 10.1.48.1) 4. Queue disciplines at the bottleneck Selected with the command-line argument --qdisc. All use a 300-packet limit. --qdisc ns-3 class Notes droptail DropTailQueue<Packet> (device queue) Baseline; traffic-control layer disabled (DisableFlowControl()) so no default FQ-CoDel is installed codel CoDelQueueDisc Target 5 ms, Interval 100 ms (RFC 8289) fqcodel FqCoDelQueueDisc ns-3 defaults pie PieQueueDisc ns-3 defaults cake FqCobaltQueueDisc CAKE-equivalent (COBALT AQM + flow queueing); ns-3 mainline has no full CAKE implementation red RedQueueDisc ns-3 defaults ared RedQueueDisc with ARED=true Adaptive RED 5. Traffic model (300 flows) For each index i = 0…99, three flows (one per class) are created on the same client/server pair but with different destination ports: client node = i mod 10 (N1–N10) server node = 12 + (i mod 38) (N13–N50) Class Count Transport / app Destination port Packet size Sending rate On / Off (exponential mean) Expected duty cycle Elephant 100 TCP BulkSend, unlimited bytes 20000 + i TCP segments up to MSS = 1400 B (app write size 1200 B) Elastic (TCP congestion control) always on > 0.9 Sheep 100 UDP OnOff 21000 + i 600 B payload (608 B IP payload) U(30, 80) kbps while On, fixed per flow 0.50 s / 0.15 s ≈ 0.77 Mice 100 UDP OnOff 22000 + i 150 B payload (158 B IP payload) U(40, 120) kbps while On, fixed per flow 0.03 s / 0.17 s ≈ 0.15 6. CSV schema (21 columns) Each row is one event. Columns that do not apply to an event type are empty; -1 means "not applicable / not parseable" for TCP/UDP-specific fields. # Column Unit / values Description 1 Timestamp s Simulation time of the event 2 event_type TX, RX, ENQUEUE, DEQUEUE, DROP, RTT_UPDATE Event type 3 direction 0 / 1 Bottleneck queue direction: 0 = N11→N12 (client→server), 1 = N12→N11 (server→client). Queue events only 4 src_ip IPv4 Source address 5 dst_ip IPv4 Destination address 6 protocol 6 = TCP, 17 = UDP IP protocol number 7 tos integer IP Type of Service 8 ttl integer IP TTL at the moment of the event (decreases per hop) 9 identification integer IP identification field 10 fragment_offset integer IP fragment offset 11 MF 0 / 1 More-Fragments flag 12 DF 0 / 1 Don't-Fragment flag 13 payload_size bytes IP payload size (transport header + data) 14 tcp_ack_flag 1 / 0 / −1 TCP ACK flag set; −1 for non-TCP 15 tcp_seq integer / −1 TCP sequence number; −1 for non-TCP 16 src_port integer / −1 TCP/UDP source port 17 dst_port integer / −1 TCP/UDP destination port 18 queue_size packets Bottleneck queue occupancy after the event (queue events only) 19 d_queue_ms ms Queueing delay of the packet (meaningful on DEQUEUE only; 0 on ENQUEUE/DROP) 20 rtt_context string ns-3 config path of the TCP socket (RTT_UPDATE only) 21 rtt_ms ms (integer) Most recent TCP RTT estimate observed anywhere in the network (global snapshot) Which columns are filled per event type Event type Filled columns TX, RX 1–2, 4–17, 21 ENQUEUE, DEQUEUE, DROP 1–5, 9, 13, 18–19, 21 RTT_UPDATE 1–2, 20–21 7. Important notes for users Multi-hop duplication. TX/RX are recorded at the IPv4 layer of every node, so one packet appears several times (client → N11 → N12 → server). Use ttl and the node implied by the context, or filter on the bottleneck queue events, to avoid double counting. A packet can be tracked across hops with the key (src_ip, dst_ip, identification). Flow identification must include ports. Elephant, Sheep and Mice flows with the same index share the same (src_ip, dst_ip) pair; use the 5-tuple (src_ip, dst_ip, protocol, src_port, dst_port). Queue events have no ports. ENQUEUE/DEQUEUE/DROP rows carry only IP fields; join them with TX rows on (src_ip, dst_ip, identification) to recover ports and the class label. rtt_ms is a global snapshot, not a per-flow RTT. For per-socket RTT use the RTT_UPDATE rows and rtt_context. RTT tracing starts at t = 1.05 s. queue_size is a packet counter maintained by the trace callbacks (incremented on enqueue, decremented on dequeue/drop). For FQ-based disciplines it is the total occupancy over all internal sub-queues. Retransmissions can be detected as repeated tcp_seq values within a TCP flow, excluding pure ACKs (payload_size equal to the TCP header length). Warm-up. Applications start between 1.0 and 1.5 s; excluding the first few seconds is recommended for steady-state statistics. 8. Known limitations Packet size is constant within each On/Off flow (an OnOffHelper limitation), so the within-flow packet-size coefficient of variation is close to 0 for Sheep and Mice. Sheep and Mice are both non-responsive UDP; only Elephant flows react to congestion. Only the 50-node scenario is included in this version. 9. How to cite Vuong Xuan Chi (2026). NS-3 Packet-Level Trace Dataset of Network Congestion at a Bottleneck Link . Dataset, Zenodo. https://doi.org/10.5281/zenodo.23831638