Làm thế nào để xếp hàng sớm ngẫu nhiên có trọng số và phát hiện sớm ngẫu nhiên có trọng số liên quan?

Tôi đang cố gắng hiểu các hệ thống QoS hoạt động như thế nào và tôi không chắc chính xác WFQ và WRED sẽ tương tác như thế nào.

Lúc đầu, tôi nghĩ rằng WFQ là một cơ chế xếp hàng và WRED là một cơ chế tránh tắc nghẽn. WFQ nên lên lịch các gói trong hàng đợi và WRED ở đó để thả chúng khi hàng đợi đầy. Nếu tôi đang thiết lập QoS trên một công tắc L3, tôi sẽ thiết lập một cơ chế xếp hàng và cơ chế tránh tắc nghẽn, vì vậy về mặt lý thuyết tôi có thể làm cho WFQ và WRD hoạt động cùng nhau. Ví dụ, tài liệu này dường như ngụ ý rằng tôi sẽ được thiết lập theo cách như vậy. Một số tài liệu khác của Cisco đề cập rằng tôi có thể sử dụng chúng một cách độc lập.

Sau đó, tôi muốn tìm hiểu thêm về cách họ làm việc và bắt đầu tìm kiếm trên Internet. Kết quả là bây giờ tôi không biết chúng là gì và chúng hoạt động như thế nào.

Một số trang web (ít nhất là theo hiểu biết của tôi về nội dung) cho rằng các thuật toán lập lịch gói và thuật toán tránh tắc nghẽn về cơ bản là giống nhau. Ví dụ ở đây bài viết trên Wikipedia, tất cả chúng đều được đặt trong một nhóm như vậy. Một số bài viết ngẫu nhiên đề cập rằng tôi có thể sử dụng WFQ XOR WRED.

Vì vậy, những gì tôi muốn hỏi là WFQ và WRED có liên quan như thế nào? Khi nào tôi sẽ sử dụng cái này hay cái khác và khi cả hai, nếu điều đó thậm chí có thể?

Xếp hàng công bằng có trọng số (WFQ) đúng như tên gọi của thuật toán xếp hàng. Xếp hàng được sử dụng khi có tắc nghẽn trên giao diện. Điều này thường được phát hiện thông qua đó Vòng truyền (TX-Ring) đã đầy. Điều này có nghĩa là giao diện đang bận gửi gói. Việc xếp hàng không diễn ra trừ khi có sự tắc nghẽn trên giao diện. Trong một số trường hợp, kích thước của vòng TX có thể được thao tác. Một vòng TX nhỏ cung cấp cho hàng đợi phần mềm nhiều năng lượng hơn để các gói được gửi đi trước nhưng nó không hiệu quả lắm. Một vòng TX quá lớn sẽ làm cho hàng đợi phần mềm gần như vô dụng và dẫn đến độ trễ và jitter cao hơn cho các gói quan trọng.

Thuật toán xếp hàng mặc định thường là First In First Out (FIFO). Điều này có nghĩa là các gói được phân phối chính xác theo thứ tự khi chúng đến trên đầu vào của giao diện. Điều này thường không được mong muốn vì một số gói nên được ưu tiên.

Một điều khá phổ biến là khách hàng mua một dịch vụ từ Nhà cung cấp dịch vụ Internet (ISP) khi đăng ký. Nghĩa là, khách hàng mua dịch vụ 50 Mbit / s nhưng giao diện vật lý đang chạy ở tốc độ 100 Mbit / s. Trong trường hợp này sẽ không có tắc nghẽn nhưng ISP sẽ giới hạn lưu lượng truy cập từ khách hàng. Để giới thiệu tắc nghẽn nhân tạo trong những trường hợp này, một máy ép có thể được áp dụng.

Vì vậy, bây giờ có tắc nghẽn, một thuật toán xếp hàng có thể được áp dụng. Lưu ý rằng các thuật toán xếp hàng không cung cấp thêm băng thông, chúng chỉ để chúng tôi quyết định gói nào quan trọng hơn đối với chúng tôi. WFQ là một thuật toán có một vài tham số và đưa ra quyết định dựa trên đó. Thuật toán khá phức tạp và sử dụng trọng số (IP Precedence), kích thước gói và thời gian lập lịch làm tham số. Có một lời giải thích rất chi tiết từ INE ở đây. WFQ là một lựa chọn tốt nếu người ta không muốn nghịch ngợm quá nhiều với việc xếp hàng vì nó cung cấp băng thông phù hợp cho các luồng có kích thước nhỏ như SSH, Telnet, thoại và điều đó có nghĩa là việc truyền tệp sẽ không lấy cắp toàn bộ băng thông.

Phát hiện sớm ngẫu nhiên có trọng số (WRED) là một cơ chế tránh tắc nghẽn. WRED đo kích thước của các hàng đợi tùy thuộc vào giá trị Ưu tiên và bắt đầu thả các gói khi hàng đợi nằm trong ngưỡng tối thiểu và ngưỡng tối đa. Cấu hình sẽ quyết định rằng 1 trong mỗi N gói được loại bỏ. WRED giúp ngăn chặn đồng bộ hóa TCP và bỏ đói TCP. Khi TCP mất các gói, nó sẽ đi vào khởi động chậm và nếu tất cả các phiên TCP mất các gói đồng thời chúng có thể được đồng bộ hóa, cung cấp một biểu đồ như thế này:

Như có thể thấy nếu WRED không được cấu hình, đồ thị sẽ nổ hoàn toàn, sau đó im lặng, rồi nổ hoàn toàn, v.v. WRED cung cấp tốc độ truyền trung bình hơn. Điều quan trọng cần lưu ý là UDP không bị ảnh hưởng khi bỏ các gói vì nó không có cơ chế xác nhận và cửa sổ trượt được triển khai như TCP. Do đó, WRED không nên được triển khai trên lớp dựa trên UDP như lớp xử lý SNMP, DNS hoặc các giao thức dựa trên UDP khác.

Cả WFQ và WRED đều có thể và nên được triển khai cùng nhau.

Trước hết, đừng tin tất cả những gì bạn đọc trên Internet ;-)

Đôi khi các thuật toán (hoặc cách chúng được thực hiện một cách vật lý) không phù hợp với một phạm trù lý thuyết. Những gì bạn gọi nó là ít quan trọng hơn là hiểu những gì nó làm.

Toàn bộ quan điểm của WFQ (hoặc bất kỳ thuật toán lập lịch nào khác) là chia sẻ băng thông liên kết giới hạn giữa các luồng khác nhau. WFQ cố gắng phân bổ băng thông theo tỷ lệ cho từng luồng. CBWFQ thực hiện tương tự với từng "lớp". Trong một thế giới hoàn hảo, với hàng đợi không giới hạn và bộ nhớ không giới hạn, đó sẽ là tất cả những gì bạn cần - bạn chia sẻ băng thông và mọi người đều hạnh phúc.

Nhưng vì các thiết bị không có hàng đợi và bộ nhớ không giới hạn, một số "phím tắt" phải được thực hiện. Bởi vì hàng đợi có kích thước hạn chế, có nguy cơ hàng đợi sẽ bị lấp đầy, gây ra sự sụt giảm đuôi và đồng bộ hóa lưu lượng. Về cơ bản, nếu hàng đợi của tôi bị tràn, tôi không còn kiểm soát băng thông nữa.

Để tránh hàng đợi của tôi tràn ra, tôi sử dụng Phát hiện sớm ngẫu nhiên. Thuật toán này thả ngẫu nhiên các gói từ hàng đợi theo mức độ đầy đủ của hàng đợi (độ sâu) - hàng đợi càng đầy đủ, càng nhiều gói sẽ bị loại bỏ. Mục tiêu là để giữ cho hàng đợi không bị tràn, để thuật toán lập lịch có thể hoạt động.

Sau đó, một số kỹ sư sáng giá của Cisco nhận thấy rằng người ta có thể sử dụng ít hàng đợi hơn (phần cứng đơn giản hơn) và giảm ngẫu nhiên các loại lưu lượng khác nhau ở các độ sâu hàng đợi khác nhau. WRED giảm lưu lượng từ hàng đợi ở các độ sâu khác nhau tùy thuộc vào loại lưu lượng. Mặc dù bạn có thể gọi WRED một cơ chế tránh ùn tắc, kể từ độ sâu nơi giao thông được giảm thay đổi theo loại giao thông, ảnh hưởng là các loại khác nhau được ít không gian trong hàng đợi và do đó ít băng thông. Vì vậy, nó cũng hoạt động như một thuật toán lập lịch. Bạn nói po-tay-to và tôi nói po-tah-toe.

Thêm một điểm khác biệt: FQ và WFQ hoạt động trên tất cả các loại lưu lượng, vì về cơ bản chúng đếm byte. RED và WRED chỉ hoạt động với TCP, vì chúng phụ thuộc vào cơ chế kiểm soát luồng của TCP để làm chậm lưu lượng và giữ cho hàng đợi không bị tràn.

(Lưu ý: để giải thích, tôi bỏ qua các hàng đợi ưu tiên và LLQ. Đó là một câu trả lời khác).

Tôi đồng ý với tất cả những gì Mike nói quá.

Dưới đây là một ví dụ về CBWFQ và WRED:

bản đồ chính sách OUT

lớp
Ưu tiên giọng nói phần trăm 20

lớp
Băng thông video phần trăm 30

lớp P1
băng thông phần trăm 10
phát hiện
ngẫu nhiên dscp dựa trên phát hiện ngẫu nhiên dscp af31 26 40 10

băng thông lớp P2 phần trăm 15
phát hiện
ngẫu nhiên dscp dựa trên phát hiện ngẫu nhiên dscp af21 24 40 10

lớp mặc định
hàng đợi công bằng hàng đợi
phát hiện ngẫu nhiên dựa trên dscp