Đo SLA bằng TWAMP và STAMP: one-way hay round-trip mới đủ?

SLA phải nói rõ dịch vụ, điểm đầu/cuối, hướng, thời gian quan sát, KPI, ngưỡng và cách xử lý maintenance window. “Latency dưới 30 ms” là chưa đủ: đó là RTT hay one-way, percentile hay average, trên class nào và từ probe nào tới đâu?

Phép đo chủ động tạo packet tổng hợp ngay cả khi người dùng không phát traffic. Nó phù hợp để baseline, phát hiện suy giảm và đối chiếu SLA, nhưng không tự đại diện cho mọi ứng dụng. Cần ánh xạ DSCP, packet size, route và policy của probe với traffic thật.

TWAMP trong RFC 5357 xây trên kiến trúc OWAMP, gồm control và test protocol; sender trao đổi với reflector để đo metric hai chiều. STAMP trong RFC 8762 đơn giản hóa mô hình, tập trung Session-Sender và Session-Reflector, hỗ trợ đo delay, delay variation và loss một chiều hoặc round-trip.

Không nên kết luận STAMP luôn “tốt hơn” TWAMP. Lựa chọn phụ thuộc thiết bị hỗ trợ, authentication, telemetry, scale, control model và khả năng tích hợp orchestration. Phải xác nhận exact feature theo firmware/license; tên menu không chứng minh implementation đầy đủ RFC.

Đặt sender/reflector tại ranh giới cần phân định: chi nhánh–DC, CPE–PE, cloud–on-prem hoặc hai region. Vẽ cả forward và return path, VRF, tunnel, NAT, ECMP và QoS. Nếu reflector nằm sau firewall/load balancer, policy/state có thể thay đổi kết quả.

Chọn nhiều cặp điểm đo để tách miền trách nhiệm. Một probe ở LAN người dùng đo cả access/WAN; probe tại CPE loại bớt access. Khi hai phép cùng suy giảm, có thể khoanh vùng WAN; khi chỉ LAN probe xấu, xem lại access.

RTT có thể đo bằng clock tại sender, nên ít phụ thuộc đồng bộ tuyệt đối giữa hai đầu. One-way delay cần timestamp hai phía trên cùng time basis và uncertainty nhỏ hơn hiện tượng cần đo. Trạng thái “NTP synchronized” không đủ; phải ghi offset, jitter, timestamp source và độ chính xác đã kiểm chứng.

Nếu clock uncertainty là ±5 ms, chênh lệch one-way 3 ms không đủ để kết luận. Với PTP/hardware timestamp, vẫn phải kiểm soát asymmetry, grandmaster, domain, NIC/driver và load. Lưu timestamp UTC có timezone/precision rõ ràng.

Packet size, packet rate, DSCP, ECN, IP version, UDP port, authentication mode, test duration và schedule đều có thể đổi đường đi hoặc queue. Một probe DSCP 0 không chứng minh SLA cho voice EF. Packet nhỏ định kỳ cũng không đại diện microburst hoặc throughput application.

Chạy nhiều profile có mục đích: low-rate continuity; voice-like packet/DSCP; packet size đại diện application; burst giới hạn để đánh giá queue. Tránh tạo tải active measurement đủ lớn làm ảnh hưởng production. Ghi randomization và maintenance window.

KPI gồm availability, packet loss ratio, RTT/one-way delay percentile, delay variation, consecutive loss burst và time-to-recover. Không chỉ báo average; p95/p99 và worst credible window giúp phát hiện tail degradation. Bằng chứng cần raw sample, cấu hình session, time health, route/path và event log.

• Câu hỏi: Reachability/SLA tổng quát · Phép đo phù hợp: RTT + loss · Điều kiện: Sender clock ổn định · Bằng chứng: Raw samples, route
• Câu hỏi: Bất đối xứng hai chiều · Phép đo phù hợp: One-way delay/loss · Điều kiện: Clock hai đầu đủ chính xác · Bằng chứng: Offset/uncertainty
• Câu hỏi: QoS theo class · Phép đo phù hợp: Nhiều DSCP profile · Điều kiện: Policy giữ marking · Bằng chứng: DSCP capture, queue
• Câu hỏi: Brownout ngắn · Phép đo phù hợp: Sampling dày có kiểm soát · Điều kiện: Probe/reflector đủ scale · Bằng chứng: Burst timeline
• Câu hỏi: Trend dài hạn · Phép đo phù hợp: Lịch chạy định kỳ · Điều kiện: Version/topology tracked · Bằng chứng: Time series, change log

Pass/fail phải định nghĩa sample invalid, missing result, clock unhealthy và maintenance exclusion. Nếu probe lỗi, không tự động coi network pass hoặc fail; đánh dấu dữ liệu không hợp lệ.

• 1. Xác định SLA, cặp điểm đo, hướng và traffic class.
• 2. Kiểm tra clock, source timestamp và uncertainty budget.
• 3. Chạy calibration qua đường ngắn/loopback để biết baseline probe.
• 4. Xác nhận DSCP không bị remark và forward/return path đúng.
• 5. Chạy baseline nhiều khung giờ; tính percentile và loss burst.
• 6. Gây impairment trong lab hoặc maintenance window được phê duyệt để kiểm tra alert.
• 7. Thử route failover, QoS congestion và reflector restart riêng biệt.
• 8. Đối chiếu active test với interface counter, routing và application KPI.
• 9. Lưu version/config; đặt regression sau mọi thay đổi lớn.

RTT tốt không chứng minh hai chiều đều tốt. One-way xấu có thể do clock, không chỉ network. Loss tại probe có thể xuất phát từ CPU/queue của reflector. ECMP có thể khiến packet active đi path khác application nếu 5-tuple khác. DSCP có thể bị remark ở tunnel hoặc provider boundary.

Kết quả chỉ áp dụng cho điểm đo, profile, thời gian và topology đã quan sát. Active measurement không thay packet/application telemetry; nó tạo tín hiệu chuẩn hóa để tương quan. Không công bố SLA end-to-end nếu phép đo chỉ bao phủ một đoạn.

• Session-Sender/Reflector: Hai vai trò phát packet test và phản hồi trong STAMP.
• RTT: Thời gian khứ hồi đo từ cùng điểm phát.
• One-way delay: Độ trễ một chiều, cần time basis phù hợp giữa hai đầu.
• Delay variation: Mức biến thiên delay giữa các packet/mẫu.
• Clock uncertainty: Khoảng sai số của timestamp so với thời gian tham chiếu.
• Synthetic traffic: Traffic được tạo chủ động để đo dịch vụ.