Kiểm thử packet reordering và duplication: TCP, QUIC phản ứng thế nào?

Reordering xảy ra khi packet đến không theo thứ tự phát; duplication là cùng dữ liệu xuất hiện nhiều lần. Receiver có thể hấp thụ một mức nhất định, nhưng transport thường dùng tín hiệu thứ tự và ACK để suy luận loss. Reordering sâu hoặc burst có thể kích hoạt retransmission không cần thiết, giảm congestion window và làm goodput sụt dù không mất packet vật lý.

Capture cũng có thể tạo “reordering giả” khi multi-queue NIC, offload, SPAN oversubscription hoặc timestamp không đồng bộ. Vì vậy cần sequence number tại generator/receiver và counter của emulator, không kết luận chỉ từ một pcap ở điểm giữa.

Đặt network emulator inline giữa client và server, cho phép cấu hình từng hướng. Thu capture trước và sau emulator với clock đủ chính xác; đồng thời lấy metric ứng dụng tại endpoint. Nếu đo QUIC, bảo đảm analyzer hiểu connection ID và packet number space tương ứng; với TLS 1.3, giải mã chỉ thực hiện khi được phép và quản lý key log an toàn.

Chạy baseline bypass impairment ở cùng throughput. Sau đó bật từng biến riêng: delay cố định, reordering, duplication; không trộn loss/jitter ngay từ đầu. Generator, emulator và receiver phải còn headroom về CPU, queue và NIC.

Một giá trị “1% reordering” chưa đủ. Cần ghi cơ chế chọn packet, khoảng trễ thêm, reordering depth, gap giữa các event, burst length, correlation, direction và seed ngẫu nhiên. Hai profile cùng tỷ lệ nhưng một profile phân tán đều, một profile tạo burst sẽ gây phản ứng transport khác nhau.

Duplication cũng cần nêu bản sao xuất hiện liền kề hay sau một delay, có giữ nguyên header/checksum và emulator thực hiện trước hay sau shaping. Nếu có bandwidth cap, queue discipline và buffer size trở thành biến cần khóa.

TCP dùng sequence number và ACK để tái lắp dữ liệu; duplicate ACK/SACK có thể dẫn đến phát lại. Hành vi thực tế phụ thuộc TCP stack, congestion control, RACK/TLP, offload và OS version. Do đó ghi rõ endpoint, kernel và thuật toán congestion control; không coi RFC là bằng chứng implementation cụ thể đạt cùng ngưỡng.

QUIC chạy trên UDP nhưng tự quản packet number, ACK range, loss detection và congestion control. Packet number không được tái sử dụng cho retransmission dữ liệu; recovery behavior khác TCP. QUIC còn có connection migration và nhiều packet number space, nên cần đo application goodput/latency cùng qlog khi implementation hỗ trợ.

Ở network/transport layer, theo dõi out-of-order depth, duplicate packet, retransmission/spurious retransmission, ACK pattern, RTT estimate, congestion window và bytes in flight. Ở application layer, đo goodput, transaction success, completion time, p50/p95/p99 latency và time-to-recover sau burst.

Chỉ số quan trọng là hiệu quả: offered load, wire throughput và useful application bytes không giống nhau. Một luồng giữ wire throughput cao nhưng phát lại nhiều có thể làm goodput thấp và chiếm tài nguyên mạng.

Traffic phải gồm luồng dài để quan sát congestion control và transaction ngắn để thấy tác động handshake/slow start. Với HTTP/3, ghi object size, concurrency, cache và 0-RTT; với TCP/TLS, ghi TLS version, session reuse và connection lifetime.

• Biến: Reordering depth · Mức baseline: 0 · Mức stress: 2, 4, 8… theo rủi ro · Bằng chứng: Sequence + ACK/qlog
• Biến: Event distribution · Mức baseline: Không · Mức stress: đều, burst, correlated · Bằng chứng: Emulator log
• Biến: Duplication · Mức baseline: 0 · Mức stress: tăng theo bước nhỏ · Bằng chứng: Receiver duplicate
• Biến: RTT · Mức baseline: LAN baseline · Mức stress: WAN/region profile · Bằng chứng: RTT hai chiều
• Biến: Flow count · Mức baseline: 1 flow · Mức stress: nhiều flow · Bằng chứng: Fairness/goodput
• Biến: Direction · Mức baseline: Không impairment · Mức stress: uplink/downlink/cả hai · Bằng chứng: Capture hai phía

Guardrail: dừng nếu emulator drop ngoài cấu hình, capture drop, endpoint CPU bão hòa hoặc clock drift vượt độ phân giải cần thiết. Reset connection và cache theo đúng mục tiêu giữa các run.

• 1. Calibration bypass: xác nhận zero unexpected reordering/loss ở mục tiêu tải.
• 2. Baseline qua emulator nhưng impairment bằng 0 để đo overhead.
• 3. Sweep reordering depth, giữ event rate và RTT cố định.
• 4. Sweep event rate/burst, giữ depth cố định.
• 5. Lặp lại với duplication riêng; sau đó mới kết hợp profile production hợp lý.
• 6. Chạy một flow và nhiều flow; kiểm tra fairness, tail latency.
• 7. Lặp lại TCP và QUIC với cùng application intent nhưng không ép cùng transport setting.
• 8. Chạy soak ở profile ngưỡng; lưu pcap mẫu, qlog, endpoint metric và seed.

Nếu pcap sau emulator reordered nhưng receiver không báo, stack có thể hấp thụ trong buffer; đây không phải lỗi. Nếu retransmission tăng nhưng emulator không drop, kiểm tra reordering vượt ngưỡng loss detection. Nếu chỉ capture trước emulator bị reordered, xem NIC/offload và pipeline capture.

Kết luận phải giới hạn theo OS/stack, transport implementation, congestion control, RTT, bandwidth, flow count và profile impairment. Không dùng một ngưỡng reordering chung cho mọi ứng dụng. Emulator tái tạo điều kiện đã mô tả, không tự chứng minh nguyên nhân production; cần dữ liệu thực tế để xây profile đại diện.

• Reordering depth: Khoảng cách thứ tự giữa vị trí mong đợi và vị trí packet thực đến.
• Spurious retransmission: Phát lại dù dữ liệu gốc không bị mất.
• Goodput: Dữ liệu ứng dụng hữu ích nhận được mỗi đơn vị thời gian.
• SACK/ACK range: Cơ chế báo các vùng dữ liệu/packet đã nhận.
• Congestion window: Giới hạn lượng dữ liệu được gửi khi chưa ACK.
• qlog: Định dạng log có cấu trúc phục vụ phân tích QUIC và giao thức liên quan.