Theo giải thuật, mỗi khi có một gói tin đến, sẽ tính kích thƣớc hàng đợi trung bình – avg bằng bộ lọc thông thấp:
Trong đó: q là kích thƣớc hàng đợi hiện thời; wq là trọng số hàng đợi, nhận giá trị trong miền 0..1, wq còn đƣợc gọi là hệ số làm trơn, wq càng nhỏ thì mức độ làm trơn càng cao, wq càng lớn thì avg càng bám sát giá trị tức thời của q. Nhƣ vậy wq quyết định độ lớn và độ kéo dài cho phép của sự bùng nổ lƣu lƣợng.
Khi avg chạy từ minth đến maxth thì xác suất pb thay đổi tuyến tính từ 0 đến maxp:
Xác suất đánh dấu gói tin pa tăng chậm khi số gói tin từ gói cuối cùng đƣợc đánh dấu count tăng lên: pa ← pb / (1 – count.pb), điều này đảm bảo cho gateway không phải đợi quá lâu trƣớc khi đánh dấu một gói tin. RED gateway đánh dấu tất cả các gói tin đến nếu nhƣ avg vƣợt quá maxth.
RED có một tuỳ chọn: để đảm bảo xác suất một gói bị loại bỏ tỉ lệ với thông lƣợng tính bằng bit/s chứ không phải packet/s, pb đƣợc tính nhƣ sau:
Trong trƣờng hợp này, một gói tin lớn dễ bị loại bỏ hơn là một gói tin nhỏ.
3.2.3 Thiết lập các tham số
Theo thuật toán chi tiết chúng ta thấy có bốn tham số cố định cần đƣợc đặt trƣớc. Vấn đề thiết lập các tham số cố định cho giải thuật RED là rất quan trọng, quyết định tới chất lƣợng của thuật toán. Phần này chúng tôi sẽ trình bày song song hai cách thiết lập các tham số: định tính (bằng lý luận) và định lƣợng (bằng mô phỏng) để có thể chọn đƣợc một bộ tham số hợp lý nhất, mang lại hiệu quả cao nhất cho thuật toán. Phần mô phỏng đã đƣợc các tác giả [4] nghiên cứu rất kỹ bằng NS-2, tôi đã thực hiện lại các mô phỏng đó và thấy rằng các kết quả mà họ đƣa ra là hoàn toàn chính xác. Vì vậy ở đây chúng tôi chỉ xin trích dẫn các kết quả đó kèm theo bình luận riêng mà không trình bày lại các mô phỏng.
a. Trọng số hàng đợi wq
RED gateway sử dụng bộ lọc thông thấp để tính kích thƣớc hàng đợi trung bình. Theo đó, sự tăng ngắn hạn của kích thƣớc hàng đợi hiện tại do một lƣu lƣợng bùng nổ, hoặc một sự tắc nghẽn thoáng qua sẽ không ảnh hƣởng lớn đến kích thƣớc hàng đợi trung bình: avg ← (1 – wq) * avg + wq * q, trong đó, trọng số hàng đợi wq đóng vai trò quyết định đến giá trị của avg. Sau đây chúng ta sẽ thiết lập cận trên và cận dƣới cho wq.
Cận trên cho wq
Chúng ta thấy rằng, nếu wq quá lớn, kích thƣớc trung bình luôn bám sát kích thƣớc hàng đợi hiện tại, dẫn đến RED gateway không lọc đƣợc tắc nghẽn tạm thời tại gateway, nghĩa là không hấp thu đƣợc các lƣu lƣợng tăng đột biến, dẫn đến hàng đợi bị tràn và mất gói tin. Giả sử hàng đợi đƣợc khởi tạo rỗng, với kích thƣớc trung bình bằng không, sau đó kích thƣớc hàng đợi tăng từ 0 đến L ứng với L gói tin đến. Sau khi gói tin thứ L đến gateway, kích thƣớc trung bình avgL là:
Cho trƣớc ngƣỡng dƣới minth, giả sử chúng ta muốn cho phép hấp thu bùng nổ đến L gói tin, wq phải đƣợc chọn thoả mãn bất phƣơng trình avgL < minth:
Cho minth = 5, L = 50 chẳng hạn, khi đó wq ≤ 0.0042 [18, p.9-10]
Cận dưới cho wq
RED gateway đƣợc thiết kế để giữ cho kích thƣớc hàng đợi trung bình avg dƣới một ngƣỡng nào đó. Tuy nhiên sẽ không đạt đƣợc mục đích nếu nhƣ avg không phản ánh đƣợc một cách hợp lý kích thƣớc hàng đợi trung bình hiện tại. Nếu wq đƣợc thiết lập quá thấp, thì avg phản ứng rất chậm với sự thay đổi kích thƣớc hàng đợi thực. Trong trƣờng hợp này, gateway không phát hiện thấy sự bắt đầu của tắc nghẽn. Theo các kết quả tính toán của các nghiên cứu về RED, ngƣời ta khuyến cáo wq ≥ 0.001. Giá trị tối ƣu cho wq là 0.002, ngoài ra, tuỳ theo điều kiện của mạng, ta có thể chọn wq trong khoảng (0.002, 0.003).
b. Thiết lập minth và maxth
Giá trị tối ƣu cho minth và maxth phụ thuộc vào một số yếu tố, trong đó có kích thƣớc trung bình mong muốn của hàng đợi, hay cũng chính là mức tắc nghẽn đƣợc phép tại hàng đợi. Theo nguyên lý hoạt động của RED:
− Nếu lƣu lƣợng trên mạng ít có các đột biến, minth và maxth nên đƣợc thiết lập giá trị cao để tận dụng tối đa đƣờng truyền.
− Nếu lƣu lƣợng trên mạng thƣờng xảy ra đột biến, minth và maxth nên đƣợc thiết lập giá trị nhỏ để có thể hấp thu các đột biến lƣu lƣợng. Tuy nhiên, các giá trị quá nhỏ sẽ dẫn đến lãng phí dải thông, vì số gói tin bị loại bỏ không cần thiết sẽ cao hơn.
− Khoảng ngƣỡng (maxth - minth) ảnh hƣởng mạnh đến thăng giáng độ trễ, thông lƣợng và khả năng hấp thu các đột biến tạm thời tại hàng đợi. Để tránh đƣợc hiện tƣợng đồng bộ toàn cầu thì không nên để giá trị khoảng này quá thấp, avg
sẽ nhanh chóng đạt tới ngƣỡng trên. RED gateway sẽ làm việc hiệu quả nhất khi (maxth – minth) bằng mức gia tăng điển hình của kích thƣớc hàng đợi trung bình trong một khoảng thời gian khứ hồi RTT. Quy tắc nên tuân theo là thiết lập maxth ít nhất gấp đôi minth.
Sau khi kiểm nghiệm các mô phỏng trong [4], chúng tôi khuyến nghị rằng minth ≥ 5 và maxth = 3 minth.
c. Thiết lập xác suất loại bỏ tối đa maxp
Giá trị maxp sẽ quyết định tần số loại bỏ gói là lớn hay nhỏ, nó quyết định avg sẽ nằm ở mức nào trong khoảng từ minth đến maxth. Vì vậy tùy từng yêu cầu mà có thể thiết lập maxp cho phù hợp. Thí dụ, để avg nằm trong khoảng giữa minth và maxth, giá trị maxp phù hợp là 0.02. Tuy nhiên nếu tắc nghẽn thƣờng xuyên xảy ra, cần chọn maxp lớn hơn, thí dụ bằng 0.1. Về tham số này, chúng tôi cũng đồng ý với các tác giả trong [1] rằng nên chọn maxp = 0.1.
3.2.4 Một số đánh giá về RED
RED là một điển hình của các chiến lƣợc quản lý hàng đợi động AQM, ngoài những ƣu điểm chung của AQM, RED còn có một số tính chất (ƣu điểm) riêng biệt khác nữa:
− Tránh tắc nghẽn: Nếu RED gateway thực sự loại bỏ gói tin đến khi kích thƣớc hàng đợi trung bình đạt đến ngƣỡng trên, thì RED gateway đảm bảo kích thƣớc hàng đợi trung bình tính theo lý thuyết không vƣợt quá ngƣỡng trên. Nếu trọng số hàng đợi wq đƣợc thiết lập một cách hợp lý thì RED gateway hoàn toàn có thể điều khiển đƣợc kích thƣớc hàng đợi trung bình thực sự. Nếu RED gateway đánh dấu một bit trong header của gói tin đến khi kích thƣớc hàng đợi trung bình vƣợt quá ngƣỡng trên, thay vì loại bỏ nó, thì hiệu quả hoạt động của RED gateway còn phụ thuộc vào sự hợp tác của các cặp nguồn/đích để điều khiển kích thƣớc hàng đợi trung bình.
− Tránh đồng bộ toàn cục: Tỷ lệ đánh dấu gói tin của RED gateway phụ thuộc vào mức độ tắc nghẽn. Ở giai đoạn tắc nghẽn thấp, RED gateway đánh dấu gói tin với một xác suất thấp, và khi tắc nghẽn tăng lên thì xác suất đánh dấu cũng tăng lên. Mặt khác, RED gateway chọn ngẫu nhiên các gói tin đến để đánh dấu; với phƣơng pháp này xác suất đánh dấu một gói tin từ một kết nối cụ thể tỉ lệ với phần băng thông đƣợc chia sẻ của kết nối đó tại gateway. Nhƣ vậy, RED gateway tránh hiện tƣợng đồng bộ toàn cục bằng cách đánh dấu gói tin theo một tỷ lệ thấp nhất có thể và việc đánh dấu các gói tin một cách ngẫu nhiên.
− Đơn giản: Thuật toán RED có thể đƣợc cài đặt với một chi phí vừa phải, không yêu cầu phải cài đặt đồng loạt cho tất cả các gateway trong mạng mà có thể triển khai dần.
− Cực đại hoá công suất toàn cục: Công suất nói ở đây đƣợc định nghĩa bằng tỷ lệ giữa thông lƣợng và độ trễ. Vì RED gateway điều khiển cho kích thƣớc hàng đợi nhỏ, dẫn tới độ trễ nhỏ, mặt khác nhƣ các mô phỏng chúng tôi trình bày dƣới đây, hệ số sử dụng đƣờng truyền với RED và DropTail là xấp xỉ nhau, vì vậy công suất đƣờng truyền cao hơn rất nhiều so với DropTail (điều này đƣợc khẳng định bằng các mô phỏng dƣới đây).
− Tính công bằng: một trong những mục tiêu quan trọng của một thuật toán quản lý hàng đợi là sự công bằng trong việc cấp phát đƣờng truyền cho các kết nối chia sẻ. Về điểm này thì RED gateway có phần hạn chế. RED gateway không phân biệt các kết nối hay các lớp kết nối khác nhau. Đối với RED gateway, tỷ lệ các gói tin bị đánh dấu tỷ lệ với phần băng thông chia sẻ của kết nối đó tại gateway. Tuy nhiên nó không cố gắng đảm bảo tất cả các kết nối nhận đƣợc cùng một tỷ lệ dải thông, mặt khác nó không điều khiển đƣợc hiện tƣợng misbehaving users - hiện tƣợng một kết nối nào đó nhận đƣợc tỷ lệ băng thông lớn hơn rất nhiều so với các kết nối khác đi qua gateway.
3.3 Phương pháp loại bỏ ngẫu nhiên theo trọng số - WRED
Thuật toán RED không phải lúc nào cũng đảm bảo cho các luồng chia sẻ băng thông một cách cân đối nhau. Trong thực tế, RED không ƣu tiên đối với các luồng TCP tốc độ thấp vì RED loại bỏ ngẫu nhiên các gói khi ngƣỡng bị vƣợt quá. WRED (Weighted RED) là phƣơng pháp tránh tắc nghẽn dựa trên việc các thuộc tính của thuật toán RED và ƣu tiên IP. WRED có thể lựa chọn loại bỏ lƣu lƣợng có mức ƣu tiên thấp khi trên giao diện bắt đầu xảy ra quá trình tắc nghẽn và cung cấp các đặc tính tiêu chuẩn khác nhau cho các lớp dịch vụ khác nhau.
Với các giao diện mạng đƣợc cấu hình sử dụng đặc tính giao thức dành sẵn tài nguyên (RSVP), khi quá trình nghẽn xảy ra WRED ƣu tiên các luồng RSVP hơn là các luồng dữ liệu khác trong quá trình loại bỏ gói để tránh tắc nghẽn. Cũng giống nhƣ RED trong cơ chế của mình WRED loại bỏ gói một cách ngẫu nhiên, từ đó thông báo tới trạm gốc giảm tốc độ truyền gói tin vào mạng. Nếu trạm gốc sử dụng TCP, nó sẽ làm giảm tốc độ của chính các gói đó cho tới khi tất cả các gói có thể đến đƣợc đích.
WRED loại gói dựa trên giá trị ƣu tiên IP đƣợc gán cho mỗi gói. Các gói có giá trị ƣu tiên thấp hơn có khả năng bị làm rớt cao. WRED khắc phục các điểm yếu của cơ chế DropTail khi đầu ra giao diện có nguy cơ bị tắc nghẽn nó sẽ thực hiện lựa chọn làm mất một số gói thay vì chờ cho tới khi các hàng đợi bị đầy rồi mới thực hiện việc loại bỏ gói.
WRED tránh việc làm mất một lƣợng lớn các gói trong một khoảng thời gian ngắn, từ đó nó cho phép các đƣờng truyền đƣợc sử dụng hữu ích tại mọi thời điểm. WRED tránh đƣợc các vấn đề đồng bộ toàn cục xảy ra khi sử dụng DropTail để tránh tắc
nghẽn. WRED chỉ hữu ích khi phần lớn lƣu lƣợng là dữ liệu của giao thức TCP, khi đó các gói bị loại sẽ phát sinh thông báo (gián tiếp) về sự nghẽn mạch để từ đó trạm phát giảm tốc độ truyền dẫn của mình. Đối với các gói tin đƣợc đóng gói theo một giao thức khác có thể trạm gửi không phát hiện quá trình mất gói xảy ra, nhƣ vậy có thể không ngăn chặn đƣợc quá trình nghẽn mạch. Với các dữ liệu mà không thuộc dạng gói TCP, WRED coi đó nhƣ là dữ liệu có mức ƣu tiên thấp nhất (Precedence = 0), bởi vậy khả năng bị loại của nó là cao hơn các dữ liệu TCP.
Hình 3. 3 Cơ chế làm việc của WRED được minh hoạ trong hình vẽ trên
Router sẽ tự động tính toán các thông số của WRED để xác định cỡ hàng đợi trung bình. Cỡ hàng đợi trung bình đƣợc tính trên cơ sở cỡ hàng đợi trung bình trƣớc và cỡ hàng đợi hiện tại. Giá trị của nó đƣợc tính theo công thức sau:
average = (old_average * (1 – 1/2n )) + (current_queue_size * 1/2n ) Trong đó:
n: là hệ số trọng số và có thể cấu hình đƣợc. average: Cỡ hàng đợi trung bình
old_average: Cỡ hàng đợi trung bình trƣớc đó current_queue_size: Kích thƣớc hàng đợi hiện tại
Chúng ta nên chọn hệ số trọng số cho phù hợp nếu n quá lớn WRED sẽ không tác động để chống tắc nghẽn, các gói tin sẽ đƣợc gửi hoặc bị loại vì vậy việc áp dụng WRED là vô ích, tuy nhiên việc lựa chọn n quá nhỏ WRED sẽ phản ứng mãnh liệt với sự bùng nổ lƣu lƣợng tạm thời dẫn đến làm mất gói trong khi không thực sự cần thiết. Chúng tôi sẽ sử dụng NS2 để mô phỏng thuật toán này và đƣa ra các nhận xét trong chƣơng 4.
Nhƣ đã trình bày trong chƣơng 2, DiffServ đi theo hƣớng đảm bảo chất lƣợng dựa trên nguyên lý hành vi theo từng chặng căn cứ vào mức ƣu tiên của các gói tin đã đƣợc đánh dấu. Việc đƣa ra chính sách với các loại lƣu lƣợng khác nhau là do ngƣời quản trị quyết định và có thể thay đổi theo thực tế nên nó rất mềm dẻo. DiffServ tận dụng tốt tài nguyên mạng hơn, tránh đƣợc tình trạng nhàn rỗi băng thông và năng lực xử lý trên
router, ngoài ra mô hình DifServ có thể triển khai trên nhiều miền độc lập do vậy khả năng mở rộng mạng trở nên dễ dàng. Dƣới đây, là các đặc tính của WRED đƣợc sử dụng trong kiến trúc DiffServ.
a. Cấu trúc của DiffServ
DiffServ cung cấp dịch vụ QoS bằng việc chia traffic ra làm nhiều nhóm (lớp) khác nhau, mỗi một packet sẽ đƣợc đánh dấu bằng 1 mã (Code Point) để xác định nhóm. Module DiffServ trong NS2 có thể hỗ trợ 4 lớp traffic, mỗi lớp lại có 3 loại quyền ƣu tiên loại bỏ (dropping precedences) cho phép ta xử lý các lớp traffic theo nhiều cách khác nhau. Các packet trong một lớp đơn sẽ đƣợc đƣa vào trong 1 hàng đợi RED vật lý (physical queue), trong đó chứa tối đa 3 hàng đợi ảo (virtual queue). Tại các hàng đợi ảo này ta có thể cấu hình để ƣu tiên với các loại gói tin theo ý muốn.
Những tham số khác nhau của RED có thể đƣợc cấu hình cho các virtual queue, từ đó có thể dẫn đến 1 virtual queue có thể drop gói tin thƣờng xuyên hơn những virtual queue khác. Mỗi packet sẽ đƣợc gắn với 1 giá trị Code Point và các tham số của RED, trong đó có trị số drop (dropping precedences), nếu trị số này thấp thì sẽ packet đƣợc ƣu tiên hơn, sẽ ít bị drop khi xảy ra tắc nghẽn.
Module DiffServ trong NS2 có 3 thành phần chính nhƣ sau:
- Policy: là bộ luật, nó đƣợc thiết lập bởi ngƣời quản trị mạng, nói về các cấp độ
của dịch vụ mà của 1 lớp traffic nhận đƣợc trên mạng
- Edge router: các router biên có nhiệm vụ đánh dấu mã Code Point vào packet.
Giá trị Code Point tƣơng ứng với policy đã đƣợc thiết lập ở trên.
- Core router: các router lõi có nhiệm vụ thực thi policy dựa theo code point của
gói tin.
Tất cả những thủ tục và chức năng của DiffServ có thể tìm thấy trong bộ code/thƣ viện của NS2: ~ns/diffserv/dsred, dsredq, dsEdge, dsCore, dsPolicy.{cc, h}
b. Hàng đợi RED trong module DiffServ
Hàng đợi RED trong DiffServ khác với hàng đợi RED sẵn có của NS2 trong REDQueue, nó đƣợc định nghĩa trong lớp dsREDQueue, thừa kế từ lớp Queue, nó có những chức năng nhƣ sau:
- Triển khai nhiều hàng đợi vật lý RED qua cùng 1 liên kết đơn
- Triển khai nhiều hàng đợi ảo trong 1 hàng đợi vật lý, với những tham số riêng biệt cho mỗi hàng đợi ảo
- Xác định 1 packet thuộc hàng đợi vật lý và hàng đợi ảo nào dựa vào giá trị Code Point của nó
Lớp dsREDQueue bao gồm tối đa 4 hàng đợi RED vật lý, mỗi cái lại chứa tối đa 4 hàng đợi ảo. Số hàng đợi vật lý và ảo đƣợc sử dụng có thể đƣợc thiết lập thông qua