
Mục lục bài viết 10 phần
Một phép đo throughput trung bình không đủ kết luận QoS đúng. Policer có thể drop/remark phần vượt profile, còn shaper giữ packet trong queue và phát ra chậm hơn. Nếu traffic generator chỉ tạo tải đều, lỗi token bucket, burst tolerance, queue delay và tương tác nhiều class dễ bị bỏ qua.
Bài viết giúp bạn
- Câu hỏi kỹ thuật trước phép đo
- Topology và baseline
- Biến số phải kiểm soát
Câu hỏi kỹ thuật trước phép đo
#Trước khi phát traffic, cần xác định policy áp ở ingress hay egress, đo theo L2/L3 hay payload, rate là bit/s hay packet/s, token bucket có một hay hai rate, và hành động với packet green/yellow/red. RFC 2697 mô tả single-rate three-color marker; RFC 2698 dùng CIR/PIR với CBS/PBS; RFC 4115 dùng CIR/EIR với CBS/EBS. EIR là tốc độ vượt mức, không phải tốc độ đỉnh PIR và không được dùng thay nhau. Tên CLI giống nhau không đảm bảo thuật toán giống nhau.
Policer thực thi profile bằng pass, remark hoặc drop; shaper thường dùng buffer để trì hoãn traffic vượt tốc độ tức thời. Acceptance phải trả lời cả “đầu ra có đúng envelope” và “dịch vụ chịu thêm latency/jitter bao nhiêu”.
Topology và baseline
#Topology tối thiểu gồm traffic generator nhiều port/class, DUT, receiver đo timestamp và capture point trước/sau DUT. Nếu policy phân cấp, cần đủ luồng để kích cả child và parent. Đồng bộ thời gian, kiểm tra link speed/FEC/MTU và chạy line-rate baseline không QoS để loại lỗi vật lý hoặc generator.
Đo riêng một policy trước, sau đó mới ghép queue, scheduler, WRED/ECN và hierarchical QoS. Nếu thiết bị có hardware offload, lưu model, line card, interface mode và software vì counter granularity hoặc hành vi burst có thể thay đổi theo datapath.

Biến số phải kiểm soát
#Khóa CIR/PIR và CBS/PBS nếu dùng RFC 2698, hoặc CIR/EIR và CBS/EBS nếu dùng RFC 4115, packet size mix, IFG/preamble accounting, DSCP/CoS đầu vào, color mode, test duration và measurement interval. Với Ethernet, wire rate có overhead khác IP rate; nếu generator và DUT đếm khác lớp, sai số tưởng như policy sai.
Traffic profile phải có tải đều và burst có kiểm soát: on/off duration, peak rate, inter-burst gap và phase giữa nhiều flow. Random burst không có seed và timestamp khó tái lập. Thử cả packet nhỏ và lớn vì cùng bit rate nhưng packet rate, scheduler overhead và buffer consumption khác nhau.
KPI và bằng chứng
#Đo offered load, forwarded throughput theo color/class, remark/drop count, packet loss, one-way latency, jitter, queue depth, ECN mark, out-of-order và fairness. Báo cáo theo time series ngắn đủ thấy burst; trung bình 60 giây có thể che drop 100 ms gây mất giao dịch.
Pass/fail nên có tolerance gắn với timer/counter resolution. Không đặt “chính xác tuyệt đối CIR” nếu thiết bị và dụng cụ có clock, quantization hoặc accounting khác nhau.
- KPI: Rate envelope · Điểm đo: Receiver theo 1 ms/100 ms/1 s · Bằng chứng: Throughput ổn định theo cửa sổ công bố
- KPI: Burst tolerance · Điểm đo: Trước/sau DUT · Bằng chứng: Số byte/packet được pass trước remark/drop
- KPI: Color action · Điểm đo: DSCP/metadata + counter · Bằng chứng: Màu nội bộ và hành động đúng policy; DSCP chỉ phản ánh màu nếu đã cấu hình mapping
- KPI: Queue impact · Điểm đo: Timestamp + queue telemetry · Bằng chứng: Latency/jitter nằm trong budget
- KPI: Loss · Điểm đo: Sequence number · Bằng chứng: Vị trí và class mất xác định được
- KPI: Fairness · Điểm đo: Per-flow throughput · Bằng chứng: Không một flow chiếm ngoài policy
Ma trận quyết định policer–shaper
#Ma trận phải nêu color-aware hay color-blind. Với color-aware, marking đến từ upstream ảnh hưởng kết quả; cần hai bộ test: packet đã tô màu hợp lệ và packet cố tình gắn màu sai.
- Tình huống: Tải dưới CIR, token đủ, color-blind · Policer kỳ vọng: Green theo meter · Shaper kỳ vọng: Không thêm queue đáng kể nếu không có tranh chấp khác
- Tình huống: Burst ngắn trong CBS · Policer kỳ vọng: Pass theo token · Shaper kỳ vọng: Hấp thụ và phát theo rate
- Tình huống: RFC 2698: tải giữa CIR và PIR · Policer kỳ vọng: Màu tùy token của cả hai bucket và màu đầu vào · Shaper kỳ vọng: Queue/phát theo cấu hình shaper, không suy từ meter
- Tình huống: RFC 2698: tải vượt PIR kéo dài · Policer kỳ vọng: Khi peak token cạn: red; drop/remark theo policy · Shaper kỳ vọng: Nếu vượt tốc độ phát: queue tăng rồi có thể drop khi đầy
- Tình huống: Hai class cạnh tranh · Policer kỳ vọng: Hành động độc lập/theo parent · Shaper kỳ vọng: Scheduler chia bandwidth
- Tình huống: Link flap · Policer kỳ vọng: Token/state theo implementation · Shaper kỳ vọng: Queue flush/retain cần đo
- Tình huống: Policy update · Policer kỳ vọng: Không rò traffic ngoài envelope · Shaper kỳ vọng: Không reorder/loss ngoài budget
Test plan từng bước
#Khi đo burst, generator và analyzer phải dùng cùng định nghĩa timestamp/cửa sổ. Báo cả offered và received rate; chỉ báo received rate không cho biết packet bị policy loại hay generator chưa phát đủ.
- Bước 1: Xác minh baseline line rate, zero loss và timestamp trước khi bật policy.
- Bước 2: Phát tải 50%, 95%, 100%, 105% CIR đủ lâu để ổn định; đo nhiều cửa sổ.
- Bước 3: Tạo burst có peak cố định, tăng burst size quanh CBS để tìm transition.
- Bước 4: Với RFC 2698, quét quanh CIR và PIR; với RFC 4115, thử phần committed và excess theo CIR/EIR cùng CBS/EBS, không coi EIR là ngưỡng peak.
- Bước 5: Kiểm packet green/yellow/red, DSCP remark và counter tương ứng.
- Bước 6: Lặp với IMIX, packet nhỏ và jumbo hợp lệ.
- Bước 7: Thêm class nền để kích parent shaper/scheduler; đo fairness và latency.
- Bước 8: Thay đổi policy có kiểm soát khi traffic chạy; quan sát transient loss/reorder.
- Bước 9: Chụp config, counter trước/sau, pcap, generator result và telemetry queue.
- Bước 10: Lặp tối thiểu ba lần; báo median, tail và độ lệch.
Burst, nhiều class và failure case
#Một flow đều không đại diện workload thực. Dùng microburst đồng pha từ nhiều source, burst lệch pha và incast. Tăng session count nhưng giữ tổng rate để phát hiện hash/scheduler bias. Với hierarchical QoS, tạo child tổng nhỏ hơn parent, bằng parent và vượt parent để xác định enforcement order.
Failure case gồm interface flap, policy detach/attach, supervisor failover, line-card reload và counter rollover. Mục tiêu là đo thời gian policy thực sự được lập trình vào datapath, traffic có khoảng unpoliced hay blackhole, queue có bị flush và counter có tiếp tục nhất quán không.

Diễn giải kết quả và giới hạn
#Throughput bám CIR nhưng latency tăng không nhất thiết là lỗi nếu đang đo shaper; đó có thể là tác dụng của queue. Ngược lại, policer không tạo queue lớn nhưng làm application retry tăng. Kết luận phải nêu mục tiêu policy, điểm đo và ảnh hưởng dịch vụ.
RFC marker mô tả thuật toán đo/tô màu, không chuẩn hóa toàn bộ scheduler hay cấu trúc silicon của thiết bị. Kết quả một port, line card và version không tự áp dụng cho chassis khác. Nếu không biết accounting layer, chỉ có thể báo hành vi wire-observed chứ không xác nhận giá trị cấu hình nội bộ.
Checklist nghiệm thu
#- Ghi model, software, ASIC/line card, interface speed và topology.
- Xác nhận rate accounting, packet overhead và counter resolution.
- Chạy baseline không QoS và lưu sai số dụng cụ.
- Thử steady, burst, IMIX, nhiều class và hierarchical policy.
- Đối chiếu pcap, per-class counter, queue telemetry và application KPI.
- Định nghĩa tolerance, test duration, repeat count và pass/fail trước khi chạy.
- Regression sau nâng cấp, thay line card hoặc sửa policy compiler.
- Canary production và chuẩn bị rollback.
Khái niệm cần nhớ
#- CIR: committed information rate, tốc độ cam kết.
- PIR: peak information rate trong RFC 2698. EIR: excess information rate trong RFC 4115; hai đại lượng không tương đương.
- CBS/EBS/PBS: dung lượng token bucket cho burst cam kết, vượt mức hoặc peak.
- Policer: thực thi envelope bằng pass, remark hoặc drop.
- Shaper: trì hoãn packet trong queue để điều chỉnh tốc độ phát.
- Color-aware: meter xem xét màu đã gắn từ upstream.
- Wire rate: tốc độ gồm overhead trên đường truyền, khác payload/IP rate.
Khái niệm cần nhớ
- DUT / SUT
- Thiết bị hoặc toàn bộ hệ thống đang là đối tượng của bài kiểm thử.
- Steady state
- Giai đoạn tải đã ổn định và đủ điều kiện để lấy số liệu đại diện.
- Pass / fail
- Kết luận dựa trên ngưỡng đã thống nhất, luôn đi cùng topology, cấu hình và điều kiện đo.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo5 nguồn +
Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.
NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.
