Tiểu luận mạng máy tính nâng cao Tìm hiểu thuật toán quản lý hàng đợi tích cực BLUE

Tìm hiểu thuật toán quản lý hàng đợi tích cực BLUE
MỤC LỤC
MỤC LỤC 1
1
Tìm hiểu thuật toán quản lý hàng đợi tích cực BLUE
I GIỚI THIỆU
Để ngăn chặn tỷ lệ mất gói tin ngày càng tăng do sự gia tăng hàm mũ trong lưu lượng
mạng, IETF đã xem xét và triển khai thông báo tắc nghẽn mà không rơi gói (ECN) cùng
với các kỹ thuật quản lý hoạt động hàng đợi như RED (Random Early Detection).
Trong khi ECN (Explicit Congestion Notification) là cần thiết để loại bỏ mất gói tin
trong mạng Internet, chúng tôi chỉ ra rằng RED, ngay cả khi sử dụng kết hợp với ECN, là
không hiệu quả trong việc ngăn ngừa mất gói tin.
Ý tưởng cơ bản của quản lý hàng đợi RED là để phát hiện sớm tắc nghẽn để chuyển tải
thông báo tắc nghẽn đến các trạm cuối, cho phép giảm tỷ lệ truyền trước khi tràn hàng đợi
trong mạng và các gói dữ liệu bị rơi.
Để làm điều này, RED duy trì một mức độ thay đổi chiều dài trung bình của hàng đợi -
mà nó sử dụng để nhận ra sự tắc nghẽn - có trọng số theo hàm mũ(exponentially-
weighted).
Khi chiều dài hàng đợi trung bình vượt quá một ngưỡng tối thiểu (min
th
), các gói được
ngẫu nhiên bị bỏ rơi hoặc đánh dấu bằng một thông báo tắc nghẽn mạng (ECN). Khi chiều
dài hàng đợi trung bình vượt quá một ngưỡng tối đa, tất cả các gói dữ liệu bị rơi hoặc được
đánh dấu.
Một trong những vấn đề cơ bản với kỹ thuật quản lý RED và các hoạt động hàng đợi
là dựa vào chiều dài hàng đợi như là một ước tính của tắc nghẽn. Trong khi sự có mặt của
một hàng đợi là đòi hỏi của tắc nghẽn, chiều dài của nó cho phép thông tin rất ít dẫn đến
mức độ nghiêm trọng của tắc nghẽn, nghĩa là, số lượng kết nối cạnh tranh đang chia sẻ liên
kết. Từ kết quả nổi tiếng trong lý thuyết xếp hàng, đó là các gói tin xung đột tuân theo mô
hình phân phối Poisson, độ dài hàng đợi liên quan trực tiếp tới số lượng các nguồn hoạt
động, và mức độ của tắc nghẽn.

Với những nhận xét của các quan sát ở trên, tác giả đề xuất một giải thuật quản lý hàng
đợi tích cực khác đó là BLUE, nó sử dụng việc mất gói tin và lịch sử sử dụng liên kết (link
utilization history) để quản lý việc tắt nghẽn. BLUE duy trì một xác suất duy nhất, mà nó
sử dụng để đánh dấu (hoặc làm rơi) các gói dữ liệu khi nó đang xếp hàng đợi. Nếu tại
hàng đợi các gói dữ liệu liên tục giảm do tràn bộ nhớ đệm, BLUE đánh dấu số gia có
thể, như vậy làm tăng tỷ lệ mà tại đó nó sẽ gửi thông báo về tắc nghẽn. Ngược lại, nếu
2
Tìm hiểu thuật toán quản lý hàng đợi tích cực BLUE
hàng đợi trở thành trống rỗng, hoặc nếu có liên kết là nhàn rỗi, BLUE giảm xác suất của nó
đánh dấu
II. NỀN TẢNG
Một trong những vấn đề lớn nhất với các thuật toán điều khiển tắc nghẽn của TCP là
tràn hàng đợi Drop-tail, làm giảm tỉ lệ vận chuyển chỉ sau khi phát hiện đúng gói tin bị mất
do tràn hàng đợi. RED làm giảm bớt vấn đề này bằng cách phát hiện sớm và tắc nghẽn đưa
ra thông báo tắc nghẽn đến cuối-host, cho phép làm giảm tỷ lệ truyền của nó trước khi xảy
ra tràn hàng đợi. Để được hiệu quả, một hàng đợi RED phải có cấu hình với một số lượng
không gian đệm vừa đủ để chứa một tải lớn hơn khả năng liên kết, từ khi tắc nghẽn được
phát hiện bằng cách sử dụng kích hoạt chiều dài hàng đợi, đến khi các áp dụng giảm tải tại
các liên kết nút cổ chai để trả lời lại thông báo tắc nghẽn.
Kịch bản tắc nghẽn trình bày trong hình 1 (a) xảy ra khi một số lượng lớn các nguồn
TCP đang hoạt động, và khi một số lượng nhỏ không gian đệm được sử dụng tại nút cổ
chai. Theo các con số cho thấy, tại t = 1, một sự thay đổi đầy đủ trong tải TCP tổng hợp
(do TCP mở cửa sổ tắc nghẽn) gây ra tỷ lệ truyền dẫn của các nguồn TCP vượt quá khả
năng của liên kết tại nút cổ chai. Tại t = 2, sự không phù hợp giữa tải và khả năng là lý do
để xây dựng hàng đợi tại các nút cổ chai. Tại t = 3, chiều dài hàng đợi trung bình vượt quá
minth và tắc nghẽn các cơ chế kiểm soát được kích hoạt. Tại thời điểm này, thông báo tắc
nghẽn được đưa trở lại máy chủ với tỷ lệ phụ thuộc vào độ dài hàng đợi và đánh dấu xác
suất max
p
. Tại t = 4, người nhận TCP, hoặc phát hiện mất gói hoặc quan sát các gói tin với

bit ECN của họ thiết lập. Đáp lại, dupliCate acknowlegdements và / hoặc TCP dựa trên
ECN tín hiệu được đưa trở lại các nguồn. Tại t = 5, các duplicate acknowlegements và /
hoặc ECN tín hiệu thực hiện theo cách của nó là trở về nguồn để báo hiệu tắc nghẽn.
Tại t = 6, các nguồn cuối cùng đã phát hiện tắc nghẽn và điều chỉnh tỷ lệ truyền dẫn
của. Cuối cùng, tại t = 7, một giảm tải được cung cấp tại liên kết nút cổ chai đã được Quan
sát.
3
Tìm hiểu thuật toán quản lý hàng đợi tích cực BLUE
Hình 1: Ví dụ về RED
I. BLUE
Để khắc phục những thiếu sót của RED, chúng ta đề xuất, thực hiện và đánh giá một
thuật toán quản lý hàng đợi cơ bản khác, đó là BLUE.
Sử dụng cả mô phỏng và thử nghiệm, cho thấy BLUE vượt qua nhiều thiếu sót của RED.
RED đã được thiết kế với mục tiêu (1) giảm thiểu mất gói tin và độ trễ của hàng đợi, (2)
tránh đồng bộ hóa toàn cầu về nguồn, (3) duy trì sử dụng liên kết cao, và (4) loại bỏ xu
hướng chống lại quá tải nguồn. Phần này cho thấy cách BLUE kết hợp cải thiện hiệu suất
của RED trong tất cả các khía cạnh. Các kết quả cũng cho thấy rằng BLUE hội tụ thuật
toán lý tưởng thể hiện trong hình 1 (b) ở hầu hết các kịch bản, ngay cả khi được sử dụng
với bộ đệm rất nhỏ.
Thuật toán
4
Tìm hiểu thuật toán quản lý hàng đợi tích cực BLUE
Ý tưởng chính đằng sau thuật toán quản lý hàng đợi BLUE là dựa trực tiếp trên sự mất
gói tin và việc sử dụng các liên kết hơn là trên các độ dài trung bình hàng đợi tức thời.
Điều này tương phản sắc nét với tất cả các kỹ thuật quản lý hàng đợi đã được sử dụng
trong điều khiển tắc nghẽn trước đó. BLUE duy trì một xác suất duy nhất, p
m
, mà nó sử
dụng để đánh dấu (hoặc làm rơi) các gói dữ liệu khi chúng được cho vào hàng. Nếu hàng
đợi liên tực rơi gói tin do tràn bộ nhớ đệm, BLUE tăng xác suất đánh dấu p

m
, do đó tăng tỷ
lệ mà tại đó nó sẽ gửi thông báo về tắc nghẽn. Ngược lại, nếu hàng đợi sẽ trở thành trống
rỗng, hoặc nếu có liên kết là nhàn rỗi, BLUE giảm xác suất của nó đánh dấu. Điều này có
hiệu quả cho phép BLUE biết tỷ lệ chính xác nó cần phải gửi lại thông báo tắc nghẽn. Hình
3 cho thấy thuật toán BLUE.

Hình 3: Thuật toán BLUE
Tham số đầu tiên,
freeze-time
, nên được thiết lập dựa trên hiệu quả thời gian vòng đi
của các kết nối qua liên kết để cho phép bất kỳ thay đổi trong xác suất đánh dấu để phản
ánh trở lại vào nút gửi trước khi thay đổi mới được đưa ra. Đối với các đường truyền có độ
trễ lớn như các liên kết vệ tinh,
freeze-time
nên được tăng lên để phù hợp với thời gian dài
hơn của vòng đi. Tham số tiếp theo là
δ1
và
δ2
được thiết lập để cung cấp cho các liên
kết có khả năng thích ứng hiệu quả với những thay đổi vĩ mô trong tải qua các liên kết ở
các mức kết nối. Tỉ lệ mất gói tin khi sử dụng RED và BLUE
Để đánh giá hiệu suất của BLUE, một số mô phỏng các thí nghiệm đã chạy bằng cách
sử dụng NS2 trên một mạng nhỏ được hiển thị trong hình 4. Sử dụng mạng này, các nguồn
Pareto bật / tắt nguồn với thời gian bật là 2 second và thời gian tắt là 3 giây được chạy từ
một trong các nút tận cùng bên trái (n0, n1, n2, n3, n4) đến một trong các nút bìa phải (n5,
5
Tìm hiểu thuật toán quản lý hàng đợi tích cực BLUE
n6, n7, N8, n9). Ngoài ra, tất cả các nguồn đã được kích hoạt với sự hỗ trợ ECN, ngẫu

nhiên đã được bắt đầu trong vòng 1 giây đầu tiên của mô phỏng, và được sử dụng 1kB gói
dữ liệu. Gói dữ liệu thống kê thiệt hại sau đó đã được đo sau 100 giây của mô phỏng.
Thống kê mất gói dữ liệu cũng được đo cho RED bằng cách sử dụng mạng tương tự với
điều kiện giống hệt nhau. Đối với hàng đợi RED, min
th
và max
th
đã được thiết lập tới 20%
và 80% kích thước hàng đợi tương ứng. Kỹ thuật thông báo tắc nghẽn của RED đã được
thực hiện như là tích cực nhất có thể bằng cách thiết lập max
p
đến 1.
Hình 4: Kiến trúc mạng
Đối với những thí nghiệm này, điều lý tưởng của max
p
là nó giảm thiểu cả độ trễ của
hàng đợi và tỷ lệ mất gói cho RED [9]. Đưa ra các cài đặt này, một loạt các cấu hình RED
được nghiên cứu trong đó thay đổi giá trị của w
q
, là kích thước hàng đợi trung bình của
RED. Đáng lưu ý rằng, khi w
q
được thiết lập tương đối nhỏ, ảnh hưởng của chiều dài hàng
đợi đối với thuật toán quản lý hàng đợi RED cũng trở nên nhỏ hơn. Đối với các giá trị vô
cùng nhỏ của w
q
, thuật toán RED trở nên tách biệt khỏi chiều dài hàng đợi (không phụ
thuộc vào chiều dài hàng đợi) và do đó nó hoạt động gần giống với BLUE.
Bảng 1 cho thấy các cấu hình được sử dụng cho RED. Đối với những thí nghiệm
BLUE, δ1 và δ2 được thiết lập sao cho δ1 lớn hơn δ2 rất nhiều. Sử dụng các giá trị này,

freeze-time biến đổi trong khoảng thời gian từ 10ms và 100ms. Các mô phỏng sử dụng một
phạm vi rộng hơn các giá trị cũng đã được thực hiện và cho thấy kết quả tương tự.
6
Tìm hiểu thuật toán quản lý hàng đợi tích cực BLUE
Bảng 1
Bảng 2
Hình 5 cho thấy tỷ lệ tổn thất quan sát trên các kích cỡ khác nhau của hàng đợi bằng
cách sử dụng cả hai thuật toán BLUE và RED với 1000 và 4.000 kết nối hiện nay. Trong
các thí nghiệm, hàng đợi tại nút cổ chai liên kết giữa A và B là có kích thước từ 100K B
đến 1000K B. Điều này tương ứng với độ trễ của hàng đợi thay đổi trong phạm vi từ
17.8ms và 178ms như đã chỉ ra trong hình.
7
Tìm hiểu thuật toán quản lý hàng đợi tích cực BLUE
Hình 5: Tỷ lệ rơi gói tin của RED và BLUE
Trong tất cả các thí nghiệm, liên kết vẫn còn hơn 99,9% sử dụng. Như Hình 5(a) cho
thấy, với 1.000 kết nối, BLUE duy trì tỷ lệ mất gói là 0 trên tất cả các kích thước hàng đợi
ngay cả với những băng thông có độ trễ thấp hơn của mạng. Điều này trái ngược với RED,
khi mà không gian đệm giảm xuống thì tỉ lệ mất gói tin ở RED là 2 chữ số. Một điểm thú
vị trong các đồ thị mất gói tin của RED thể hiện trong hình 5 (a) là nó cho thấy một sự
giảm sút đáng kể trong tỷ lệ tổn thất ở một sự chậm trễ của bộ đệm khoảng 80ms. Điều này
xảy ra là do một điểm hoạt động đặc biệt của RED khi chiều dài hàng đợi trung bình vẫn
lớn hơn max
th
trong toàn bộ thời gian. Tại một số điểm trong quá trình thử nghiệm này đặc
biệt, độ trễ của bộ đệm và sự cung cấp tải hoàn toàn phù hợp dẫn đến chiều dài trung bình
hàng đợi lớn hơn max
th
. Trong vùng này hoạt động, hàng đợi RED đánh dấu mỗi gói,
nhưng tải được cung cấp là tích cực, nên vẫn có thể làm cho hàng đợi đầy. Trường hợp này
cho phép RED thực hiện tại những thời điểm giống như BLUE với một xác suất đánh dấu

là 1 và độ trễ của hàng đợi tương đương với max
th
. Đây là trạng thái duy nhất của hoạt
động ngay lập tức bị gián đoạn bởi bất kỳ thay đổi trong tải hoặc round-trip-time. Khi độ
trễ của bộ đệm tăng lên, round-trip-time tương ứng tăng và gây ra giao thức TCP ít linh
hoạt hơn.
Hiểu BLUE
Hình 6: Biểu đồ hàng đợi của RED và BLUE
Để hoàn toàn hiểu sự khác biệt giữa các thuật toán RED và BLUE, hình 6 so sánh
chiều dài hàng đợi của chúng trong một thử nghiệm bổ sung bằng cách sử dụng các cấu
hình B4 của BLUE và cấu hình R2 của RED.
8
Tìm hiểu thuật toán quản lý hàng đợi tích cực BLUE
Trong thử nghiệm này, lưu lượng của các nguồn được thay đổi bằng cách tăng số
lượng kết nối lên 200 cứ sau mỗi 20 giây. Như Hình 6 (a) cho thấy, RED mất gói liên tục
trong suốt thử nghiệm. Ngoài ra, ở tải thấp hơn, thời gian mất gói thường kéo theo là thời
gian sử dụng đường truyền với hiệu quả thấp như xác định gói dữ liệu đánh dấu và loại bỏ
chúng, để các nguồn gửi giảm tốc độ truyền các gói tin. Ngược lại, như hình 6 (b) cho
thấy, khi BLUE quản lý mức độ đánh dấu của nó thông minh hơn, đồ thị chiều dài hàng
đợi của nó là ổn định hơn. Thông báo tắc nghẽn được gửi với một tốc độ mà ở đó không
gây ra thời gian mất gói kéo dài thời gian sử dụng đường truyền hiệu quả liên tục hơn. Chỉ
khi tải cung cấp tăng lên đến 800 kết nối, thì mới xảy ra hiện tượng mất gói tin ở BLUE.
II. KẾT QUẢ MÔ PHỎNG
Dựa trên những nghiên cứu về giải thuật quản lý hàng đợi tích cực Blue, nhóm chúng
tôi đã tiến hành mô phỏng bằng phần mềm NS2 version: 2.34 trên hệ điều hành Ubuntu
9.10 và được một số kết quả ban đầu như sau:
a) Cấu trúc mạng:
Số lượng nút: 28
9
Tìm hiểu thuật toán quản lý hàng đợi tích cực BLUE

Có 2 nút cổ chai (bottleneck)
Các thông số mạng:
Từ các nút nguồn (đích) đến nút cổ chai: 10ms / 10Mbs / DropTail
Giữa 2 nút cổ chai:
Chiều nút gửi: Blue/Red
Chiều gửi Ack: Droptail
b) Kết quả so sánh về số lượng gói tin rơi
Bảng 1-1: Tham số thiết đặt cho RED
Bảng 1-2: Tham số thiết đặt cho BLUE
•
Kết quả:
10
Tìm hiểu thuật toán quản lý hàng đợi tích cực BLUE
R1 R2 R3 R4
Số lượng gói tin rơi 504 603 619 596
Số lượng gói tin mất 574 630 648 625
Bảng 2-1: Kết quả thực hiện mô phỏng sử dụng RED
B1 B2 B3 B4
Số lượng gói tin rơi
(Có /Không có ECN)
55
490
67
260
44
403
44
441
Số lượng gói tin mất
(Có /Không có ECN)

93
525
119
310
76
448
78
488
Bảng 2-2: Kết quả thực hiện mô phỏng sử dụng BLUE
(có hoặc không sử dụng ECN)
c) Nhận xét:
Bằng việc thực hiện mô phỏng nói trên nhóm chúng tôi nhận thấy rằng: BLUE là
một giải thuật quản lý hàng đợi tích cực mạnh hơn RED về việc giảm tỷ lệ rơi và mất gói
tin. Trong trường hợp số lượng nút trong mạng rất lớn thì BLUE càng thể hiện sự vượt
trội so với RED. Ví dụ: với mạng được thiết kế gồm 2002 nút (2 nút cổ chai) thì số lượng
mất và rơi gói tin được thể hiện trong bảng sau:
11
Tìm hiểu thuật toán quản lý hàng đợi tích cực BLUE
RED BLUE
Số lượng gói tin rơi 10470 6470
Số lượng gói tin mất 10507 6542
III.KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN
Chúng tôi đã chỉ ra sự yếu kém vốn có của thuật toán quản lý hàng đợi hiện nay đang
hoạt động. Mục đích của vấn đề này, chúng tôi đã thiết kế và đánh giá một quy tắc cơ bản
khác của thuật toán quản lý hàng đợi đó là BLUE. BLUE sử dụng mất gói và lịch sử sử
dụng liên kết của hàng đợi tắc nghẽn, thay vì độ dài hàng đợi để quản lý tắc nghẽn.
Trong tương lai, nhóm cũng mong muốn mở rộngviệc nghiên cứu, đánh giá một cách
toàn diện về BLUE và hiệu quả của nó so với các giải thuật quản lý hàng đợi khác để có
thể áp dụng BLUE trong thực tế.
Đồng thời nhóm cũng muốn nghiên cứu giải thuật quản lý hàng đợi SFB (Stochastic

Fair Blue) một giải thuật quản lý hàng đợi được phát triển dựa trên BLUE.
12
Tìm hiểu thuật toán quản lý hàng đợi tích cực BLUE
IV.TÀI LIỆU THAM KHẢO
[1] Wu-chang Feng, Kang Shin, Dilip Kandlur, Debanjan Saha, “The Blue Active Queue
Management Algorithms”, IEEE/ACM Transactions on Networking, Vol. 10, No. 4,
August 2002.
[2] W. Feng, D. Kandlur, D. Saha, and K. G. Shin. Blue: A New Class of Active Queue
Management Algorithms. In UM CSE-TR-387-99, April 1999.
[3] Sunitha Burri, BLUE: Active Queue Management.
[4] S. Floyd and V. Jacobson, “Random Early Detection Gateways for Congestion
Avoidance”, IEEE/ACM Transactions on Networking, Vol. 1, pp 397-413, August 1993.
13