Cơ chế hàng đợi có độ trễ thấp LLQ (Low-Latency Queuing)

[danghoangkhanh]

Cơ chế hàng đợi có độ trễ thấp LLQ (Low-Latency Queuing)

Nếu chỉ căn cứ theo tên gọi, cơ chế hàng đợi LLQ có vẻ như là công cụ hàng đợi tốt nhất có thể. Những loại gói tin nào không muốn bị ảnh hưởng bởi độ trễ? Đối với những ứng dụng cần độ trễ thấp, LLQ là chọn lựa tốt. LLQ tìm kiếm và hành động giống như CBWFQ trên hầu hết mọi phương diện, ngoài trừ yếu tố là LLQ cho phép một số hàng đợi hoạt động như các hàng đợi có độ trễ thấp. LLQ định thời các hàng đợi này như là các hàng đợi có độ ưu tiên cao, giống như PQ. Nói cách khác, LLQ luôn cố gắng phục vụ các gói tin trong những hàng đợi này trước.

LLQ thỉnh thoảng có thể dùng trong một số hình thức khác nhau. Nếu một chính sách policy map có ít nhất một LLQ, chính sách policy map đó có thể xem như đang hiện thực LLQ, và hàng đợi đó được gọi là LLQ. Thỉnh thoảng, một hàng đợi LLQ còn được gọi là PQ vì đặc tính hoạt động giống PQ.

Khi LLQ thêm vào một hàng đợi có độ trễ thấp vào cơ chế CBWFQ, nó cũng giúp ngăn ngừa hiện tượng hàng đợi chết của PQ. LLQ thực sự khống chế hàng đợi dựa trên băng thông được cấu hình. Thực sự, mức băng thông cấp cho một hàng đợi LLQ sẽ vừa là mức băng thông đảm bảo tối thiểu, vừa là mức băng thông tối đa.
Kết quả là, các gói tin có thể được giải phóng khỏi hàng đợi để có độ trễ thấp nhưng sẽ có vài gói tin bị loại bỏ để ngăn ngừa các hàng đợi khác rơi vào trạng thái chết vì không được xử lý.

Hình dưới đây mô tả thuật toán hoạt động của LLQ. Chú ý rằng mặc dù có một thành phần chạy theo thuật toán PQ là được hiển thị, nhưng thành phần này cũng bị khống chế về băng thông.

Cấu hình LLQ đòi hỏi thêm vào một số lệnh bên cạnh các lệnh được dùng để cấu hình CBWFQ. Thay vì dùng câu lệnh bandwidth trong một class, lệnh priority sẽ được dùng.

priority { bandwidth-kbps | percent percentage} [ burst]

Lệnh này bật LLQ trong một lớp lưu lượng, cung cấp băng thông cho lớp đó và bật chức năng policing. Bạn cũng có thể cấu hình chỉ ra phần lưu lượng bùng nổ burst size đi kèm với tính năng khống chế băng thông policing. Ỏ chế độ mặc định, mức chỉ định 20% của băng thông được cấu hình là một chọn lựa hợp lý. Ví dụ dưới đây mô tả một cấu hình LLQ mẫu, dùng các tiêu chuẩn giống như ví dụ trước. Các chính sách LLQ được áp dụng vào cổng S0/0 của R3.

Băng thông của cổng S0/0 là 128 kbps.
Các gói tin đã được đánh dấu với giá trị DSCP tốt.
Tải của VoIP đã được đánh dấu giá trị DSCP EF và sẽ được đưa vào hàng đợi LLQ với băng thông là 58kbps.
Các lưu lượng có giá trị AF41, AF21 và AF23 sẽ được cấp phần băng thông tương ứng là 22, 20 và 8 kbps.
Tất cả những traffic còn lại sẽ được đặt vào hàng đợi mặc định, và sẽ dùng cơ chế WRED và WFQ.

Lệnh class map được dùng bởi hàng đợi queue-on-dscp không được mô tả nhưng cái tên này ngầm định rằng từng class map đã được cấu hình để so sánh. Chú ý câu lệnh priority 58 sẽ làm cho lớp dscp-ef là một LLQ.

policy-map queue-on-dscp
class dscp-ef
priority 58
class dscp-af41
bandwidth 22
class dscp-af21
bandwidth 20
random-detect dscp-based
class dscp-af23
bandwidth 8
random-detect dscp-based
class class-default
fair-queue
random-detect dscp-based
! max-res has to be raised or the policy map would be rejected.
interface Serial0/0
bandwidth 128
encapsulation frme-relay
load-interval 30
max-reserved-bandwidth 85
service-policy output queue-on-dscp

Dưới đây, đối với lớp dscp-ef, chú ý thuật ngữ “strict priority” cũng như việc tính toán ra giá trị bùng nổ dữ liệu ở mức 1450 bytes (là 20% của 58 kbps và chia cho 8 để chuyển thông số trên về đơn vị là số bytes).

R3# show policy-map queue-on-dscp
Policy Map queue-on-dscp
Class dscp-ef
Weighted Fair Queueing
Strict Priority
Bandwidth 58 (kbps) Burst 1450 (Bytes)
! lines omitted for brevity

Chú ý các thống kê dưới đây. Bất kỳ gói tin nào bị loại bỏ do policer sẽ hiển thị trong dòng cuối cùng dưới đây.

R3# show policy-map interface s 0/0 output class dscp-ef
Serial0/0
Service-policy output: queue-on-dscp
Class-map: dscp-ef (match-all)
227428 packets, 14555392 bytes
30 second offered rate 52000 bps, drop rate 0 bps
Match: ip dscp ef
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 58 (kbps) Burst 1450 (Bytes)
(pkts matched/bytes matched) 12194/780416
(total drops/bytes drops) 0/0

(còn tiếp)

[danghoangkhanh]

Định nghĩa và giới hạn băng thông trong LLQ

Lệnh priority trong LLQ có hai tuỳ chọn để định nghĩa băng thông cho LLQ. Một tùy chọn sẽ chỉ ra băng thông, tùy chọn còn lại là chỉ ra tỉ lệ phần trăm của băng thông (không có tùy chọn remaining bandwidth). Tuy nhiên không giống lệnh bandwidth, cả hai tùy chọn này đều có thể dùng trong cùng một policy. IOS vẫn giới hạn tổng số băng thông bên trong một chính sách LLQ policy map, với phần băng thông từ cả hai LLQ và những nhóm non-LLQ đều không được vượt quá giới hạn max-res*int-bw.

Mặc dù công thức trên là khá dễ, tuy nhiên các chi tiết có thể làm ta nhầm lẫn, đặc biệt là trong tình huống một policy map có một hàng đợi cấu hình với lệnh priority bw, một hàng đợi khác với lệnh priority percent bw và các hàng đợi khác với câu lệnh bandwidth. Hình dưới đây là một ví dụ với ba phiên bản của lệnh. Trong ví dụ có hai phiên bản của lệnh priority, class 3 có lệnh priority 32, dành ra 32 kbps. Class 2 có lệnh priority percent 25, nếu áp dụng vào băng thông của cổng (256Kbps) sẽ cấp cho class 2 một phần băng thông 64Kbps.

Phần thú vị của hình trên là cách mà hệ điều hành IOS tính khái niệm băng thông còn lại (remaining bandwidth) khi PQ được cấu hình. IOS sẽ trừ phần băng thông mà câu lệnh priority đã xin cấp. Kết quả là, một chính sách policy map có thể cấp cho những nhóm lưu lượng không được ưu tiên khác theo tỉ lệ phần trăm của phần băng thông còn lại, với tổng giá trị là 100.

Cấu hình LLQ với nhiều hơn một hàng đợi ưu tiên PQ

LLQ cho phép nhiều hàng đợi/class được cấu hình như PQ. Điều này dẫn đến câu hỏi “Hàng đợi nào sẽ được phục vụ trước?”. Thật ra, LLQ thực sự đặt các gói tin từ các hàng đợi LLQ vào một hàng đợi bên trong. Vì vậy, các gói tin trong các hàng đợi ưu tiên khác nhau vẫn được phục vụ trước những gói tin trong các hàng đợi không ưu tiên, nhưng nó sẽ được phục vụ dựa trên mà thời gian gói tin đến trong bất kỳ hàng đợi ưu tiên nào.

Vậy tại sao lại dùng nhiều hàng đợi ưu tiên? Câu trả lời là do công cụ khống chế băng thông policing. Khi khống chế băng thông của một lớp ở một mức nào đó và với lớp lưu lượng khác ở mức khác, ta sẽ có nhiều mức hiệu chỉnh khác nhau cho LLQ. Ví dụ nếu hoạch định cho dữ liệu video và voice, ta có thể đặt các loại dữ liệu này vào các hàng đợi LLQ riêng biệt và cả hai loại dữ liệu này sẽ có độ trễ thấp, đồng thời ngăn ngừa dữ liệu video chiếm băng thông của voice và ngược lại.