Kiểm thử QoS và bufferbloat: throughput cao nhưng ứng dụng vẫn chậm

QoS test không chỉ hỏi “policy có match đúng DSCP hay không”. Bài đo cần chứng minh packet được phân loại đúng, được đưa vào queue dự kiến, nhận tài nguyên theo thiết kế và duy trì chất lượng ứng dụng khi tổng offered load vượt năng lực của bottleneck.

Tách ba verdict: forwarding đúng class, scheduler/drop behavior đúng chính sách và chất lượng dịch vụ đạt mục tiêu. Một policy counter tăng không chứng minh latency hoặc packet loss của class đó đạt SLA.

Topology tối thiểu gồm traffic generator hai phía, DUT có QoS, một liên kết bottleneck và điểm thu telemetry. Bottleneck phải được tạo tại đúng interface/queue cần kiểm tra; nếu congestion xuất hiện ở switch hoặc hypervisor khác, counter trên DUT sẽ không giải thích được kết quả.

Đo offered/received traffic hai chiều, one-way latency và queue occupancy/drop. Đồng bộ clock giữa các điểm đo hoặc ghi rõ sai số. Với WAN/SD-WAN, thêm network emulator để tái tạo bandwidth, latency và loss nhưng chỉ thay một điều kiện mỗi vòng.

Tạo ít nhất ba class: real-time packet nhỏ, giao dịch có burst và bulk TCP/UDP tải nền. Ghi frame size, flow count, rate, burst, DSCP, VLAN PCP, hướng truyền và thời gian ramp. Kiểm tra DUT giữ hay remark marking ở mỗi trust boundary.

Khóa link speed, MTU, scheduler, queue depth, shaping/policing rate, ECN/AQM, offload và background control traffic. TCP congestion control, RTT và receive window ảnh hưởng mạnh tới throughput; không so sánh hai vòng nếu các biến này khác nhau.

Mỗi class cần throughput/goodput, packet loss, latency p50/p95/p99/max, jitter, reorder và burst loss. Ở DUT thu queue occupancy, tail/WRED drop, ECN marking, policer drop, scheduler counters và CPU. Với TCP bổ sung retransmission, time-to-complete; với thoại bổ sung gap và late packet.

Bufferbloat biểu hiện bằng latency tăng kéo dài khi queue đầy dù loss chưa cao. Báo “latency under load” so với idle baseline, không chỉ báo RTT trung bình. Pcap, sequence/timestamp, cấu hình policy và counter trước/sau là bộ bằng chứng tối thiểu.

• Tình huống: Dưới ngưỡng link · Kỳ vọng: Không drop, latency gần baseline · Bằng chứng: RX/TX, queue thấp
• Tình huống: Bulk chiếm link · Kỳ vọng: Real-time vẫn trong SLA · Bằng chứng: Per-class latency/loss
• Tình huống: Burst giao dịch · Kỳ vọng: Hấp thụ hoặc drop có kiểm soát · Bằng chứng: Queue depth, burst loss
• Tình huống: Sai DSCP · Kỳ vọng: Vào default/remark theo policy · Bằng chứng: Capture và class counter
• Tình huống: Shaper thấp hơn line rate · Kỳ vọng: Rate ổn định, queue có giới hạn · Bằng chứng: Rate time series
• Tình huống: Policer vượt CIR · Kỳ vọng: Drop/remark đúng thiết kế · Bằng chứng: Policer counters
• Tình huống: AQM/ECN bật · Kỳ vọng: Giảm queueing delay theo profile · Bằng chứng: ECN mark, latency, goodput

Chạy từng class riêng để xác nhận mapping và ceiling. Sau đó ghép traffic ở 50%, 80%, 100%, 110% và burst ngắn. Giữ mỗi bước đủ lâu để queue đạt steady state; lặp tối thiểu ba lần và lưu raw result.

Thử flow mới và flow dài, packet nhỏ/lớn, hai chiều và microburst. Tăng bulk trước, giữ real-time cố định để quan sát isolation. Pass/fail phải viết riêng cho từng class; tổng throughput đạt line rate không được che việc class ưu tiên bị starvation.

Shaping trì hoãn packet để giữ rate, còn policing thường drop hoặc remark khi vượt profile. Hai cơ chế có thể cho cùng throughput trung bình nhưng latency và loss hoàn toàn khác. Xác minh CIR/PIR, burst allowance và vị trí áp dụng ingress/egress.

Khi bật AQM hoặc ECN, so sánh A/B trên cùng profile: queue delay, goodput, loss và ECN marking. Không kết luận cơ chế tốt hơn chỉ từ một luồng TCP; cần nhiều RTT, flow count và congestion-control profile.

• Chốt SLA và class mapping.
• Xác nhận bottleneck, link speed và MTU.
• Lưu policy, scheduler, queue và counter baseline.
• Chạy từng class riêng rồi traffic hỗn hợp.
• Tăng tải theo bước và chèn burst.
• Đo latency/loss theo từng class.
• So sánh shaping, policing và AQM nếu có.
• Lặp lại, lưu pcap, telemetry và verdict.

Kết quả phụ thuộc NOS/firmware, ASIC, queue architecture, packet size, flow entropy và traffic profile. Queue counter do hãng công bố có thể có đơn vị hoặc chu kỳ lấy mẫu khác nhau; phải đối chiếu tài liệu đúng phiên bản.

Lab chứng minh hành vi trong điều kiện đã định, không tự động đại diện cho mọi ứng dụng hoặc đường WAN. Khi chuyển sang production, cần đối chiếu traffic distribution và peak burst thực tế.