Kiểm thử TCP BBR và CUBIC dưới latency, loss và bandwidth thay đổi

Mục tiêu không phải chọn thuật toán “nhanh nhất” nói chung. Cần xác định workload: file transfer, video, API hay replication; RTT thường gặp; băng thông; mức competing traffic; và SLO về goodput, latency hoặc fairness.

So sánh phải trả lời thời gian đạt steady state, phản ứng khi capacity giảm/tăng, ảnh hưởng tới flow khác và thời gian recovery sau packet loss. Một con số throughput trung bình che mất queue buildup và tail latency.

Đặt client/server trên host đã ghi rõ kernel, congestion-control module và NIC; network emulator ở giữa áp impairment hai chiều. Thu packet/counter ở client, emulator và server; đồng bộ thời gian đủ cho mục tiêu đo.

Chạy baseline không impairment để xác minh CPU, NIC, disk và generator không là bottleneck. Kiểm tra advertised window, MSS, offload và pacing. Dùng cùng application payload, flow count và duration cho mọi vòng.

Khóa kernel/version, initial congestion window, MSS/MTU, receive/send buffer, ECN, pacing, ACK behavior và NIC offload. Tách random loss khỏi burst loss; khai báo distribution của delay/jitter, queue size và shaping direction.

Flow ngắn chủ yếu phản ánh startup, flow dài phản ánh steady state. Cần cả single-flow và multi-flow; thử đồng thuật toán lẫn BBR cạnh tranh CUBIC. Randomize thứ tự chạy và lặp nhiều lần để giảm bias do trạng thái host.

Không dùng throughput layer 2 thay cho application goodput. Báo median, percentile và worst case; gắn kết quả với traffic profile và interval, không chỉ ảnh chụp dashboard.

• KPI: Goodput · Cách đo: Payload nhận/thời gian · Bằng chứng: App + packet counter
• KPI: RTT p50/p95/p99 · Cách đo: TCP timestamp/active probe · Bằng chứng: PCAP/raw metric
• KPI: Retransmission · Cách đo: Sequence analysis · Bằng chứng: PCAP + host counter
• KPI: Queue delay · Cách đo: RTT trừ propagation baseline · Bằng chứng: Emulator/telemetry
• KPI: Fairness · Cách đo: Share giữa flow · Bằng chứng: Per-flow result
• KPI: Recovery · Cách đo: Thời gian trở lại ngưỡng · Bằng chứng: Timeline impairment

• Kịch bản: RTT sweep · Biến chính: 5–200 ms · Mục đích: Độ nhạy BDP
• Kịch bản: Random loss · Biến chính: Nhiều mức nhỏ · Mục đích: Recovery/retransmission
• Kịch bản: Burst loss · Biến chính: Gilbert-Elliott hoặc profile rõ · Mục đích: Resilience thực tế hơn
• Kịch bản: Capacity step · Biến chính: Giảm/tăng bandwidth · Mục đích: Adaptation và queue
• Kịch bản: Buffer sweep · Biến chính: Nhỏ/vừa/lớn · Mục đích: Bufferbloat
• Kịch bản: Flow competition · Biến chính: 1/10/nhiều flow · Mục đích: Fairness
• Kịch bản: Reverse-path load · Biến chính: ACK path có tải · Mục đích: Bất đối xứng

Pha 1 xác minh baseline và calibration. Pha 2 chạy single-flow theo RTT/loss sweep. Pha 3 giữ impairment, tăng flow count và trộn thuật toán. Pha 4 thay đổi capacity giữa phiên để đo phản ứng động; pha 5 thêm reverse-path load.

Mỗi run cần warm-up, measurement window và cool-down cố định. Lưu sysctl, kernel, emulator profile, PCAP mẫu và raw CSV. Đặt kill condition khi queue, CPU hoặc loss vượt ngưỡng an toàn.

• Xác nhận thuật toán thực sự được áp cho từng socket.
• Hiệu chuẩn host/NIC/generator trước impairment.
• Ghi delay distribution, loss model, buffer và direction.
• Đo goodput, RTT, retransmission, fairness và recovery.
• Chạy flow ngắn/dài, đơn/đa luồng và cạnh tranh.
• Lặp, randomize thứ tự và lưu raw evidence.

Kết quả chỉ áp dụng cho kernel, implementation, NIC, impairment và workload đã kiểm tra. Không suy rộng một RTT/loss profile sang mọi WAN. Network emulator tạo điều kiện tái lập nhưng không thay thế đầy đủ routing churn, middlebox và cross traffic production.

• Congestion control: Cơ chế điều chỉnh tốc độ gửi khi mạng nghẽn.
• BDP: Bandwidth-delay product.
• Goodput: Dữ liệu ứng dụng hữu ích nhận thành công.
• Pacing: Dàn đều packet theo thời gian.
• Bufferbloat: Queue lớn làm tăng latency kéo dài.
• Fairness: Mức chia tài nguyên giữa các flow.