Các công cụ quản lý nghẽn trong router -

Tắc nghẽn (congestion) là khi một interface phải nhận quá nhiều traffic hơn khả năng xử lý. Lúc này, hàng đợi (queue) sẽ đầy, dẫn đến việc những ứng dụng nhạy cảm với độ trễ như voice, video, hay các ứng dụng tương tác real-time bị “nghẹt thở”. Nếu không có cơ chế quản lý, SLA gần như không thể đảm bảo.

• Scheduling (lập lịch): quyết định gói nào sẽ được gửi ra trước. Dù có hay không có congestion, scheduling luôn diễn ra.

• Queuing (xếp hàng): khi congestion xảy ra, các gói sẽ được đưa vào queue. Nếu đầy, chúng sẽ bị loại hoặc ưu tiên theo chính sách.

• Traffic scheduling theo trọng số: để duy trì sự công bằng hoặc ưu tiên cho một số loại traffic quan trọng hơn.

Các cơ chế lập lịch (Scheduling)

• Strict Priority (SP): Queue ưu tiên cao được xử lý trước hoàn toàn. Nhược điểm: dễ gây starvation cho traffic thấp.

• Round Robin (RR): xử lý tuần tự từng queue. Công bằng, nhưng có thể làm real-time traffic bị delay.

• Weighted Fair (WFQ): cho phép queue có trọng số, giảm starvation và ưu tiên tốt hơn cho traffic nhạy cảm, nhưng không bảo đảm băng thông tuyệt đối.

Các cơ chế xếp hàng (Queuing)

• FIFO: đến trước đi trước, rất đơn giản nhưng không phù hợp với mạng đa dịch vụ.

• PQ (Priority Queuing): 4 queue xử lý theo thứ tự ưu tiên nghiêm ngặt, dễ gây starvation.

• CQ (Custom Queuing): 16 queue với RR, đảm bảo tối thiểu cho các flow, nhưng thiếu strict priority.

• WFQ: chia băng thông đều cho từng flow, thích hợp với môi trường nhiều ứng dụng nhưng không có guarantee cho voice.

Các cơ chế nâng cao

• CBWFQ (Class-Based WFQ): cho phép định nghĩa class dựa trên ACL, protocol, interface,… và gán băng thông tối thiểu. Phù hợp cho data traffic, nhưng không đảm bảo latency cho voice.

• LLQ (Low Latency Queuing): CBWFQ + Strict Priority. Đây chính là “cứu tinh” cho voice và video vì vừa có bandwidth guarantee vừa có latency guarantee.

• Trong một mạng doanh nghiệp, anh em muốn vừa chạy video conference, vừa tải file. Nếu chỉ dùng CBWFQ, traffic voice có thể bị jitter. Nhưng nếu bật LLQ và gán một low-latency queue cho RTP/VoIP, gói thoại sẽ luôn được xử lý trước, trong khi file transfer vẫn có băng thông tối thiểu đảm bảo.