tcp/quic lab patched

network/tcpquiclab/README_LINUX.md

@@ -103,7 +103,38 @@ We use Linux `tc` (Traffic Control) with `netem` instead of `clumsy`.
    sudo tc qdisc del dev lo root
    ```
 
-### 3.3 & 3.4 Advanced Tests
+### 3.3 Advanced Test: Multiplexing vs Multi-Connection
 
-- **Multiplexing:** The current `quic_perf_client` uses a single stream (Stream ID 4). You can modify the code to launch multiple streams in parallel to test head-of-line blocking resilience.
-- **Network Recovery:** Use `tc` to drop 100% packets (`loss 100%`) for 30 seconds during a long transfer, then remove the rule (`del`) to see if the connection recovers.
+This task compares the performance of 5 parallel TCP connections against a single QUIC connection with 5 concurrent streams.
+
+**Scenario 1: TCP Multi-Connection**
+Establish 5 TCP connections simultaneously, each transferring 20MB (Total 100MB).
+
+1. Start TCP Multi-Connection Server:
+   ```bash
+   ./tcp_multi_server
+   ```
+2. Run TCP Multi-Connection Client:
+   ```bash
+   ./tcp_multi_client
+   ```
+3. Record total time and throughput from the server output.
+
+**Scenario 2: QUIC Single-Connection Multi-Streaming**
+Establish 1 QUIC connection and open 5 streams concurrently, each transferring 20MB (Total 100MB).
+
+1. Start QUIC Multi-Stream Server:
+   ```bash
+   ./quic_multi_server
+   ```
+2. Run QUIC Multi-Stream Client:
+   ```bash
+   ./quic_multi_client
+   ```
+3. Record the performance statistics.
+
+**Analysis Points:**
+- Compare completion times in a normal network.
+- Use `tc` to simulate packet loss (e.g., 5%). Observe how QUIC's multiplexing avoids TCP's Head-of-Line (HoL) blocking, where a single lost packet in one TCP connection doesn't stall the other streams in QUIC.
+
+### 3.4 Network Recovery