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

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 Để 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).

M C L C ỤC LỤC ỤC LỤC

I GIỚI THIỆU 2

II NỀN TẢNG 4

1 Thuật toán 8

2 Tỉ lệ mất gói tin khi sử dụng RED và BLUE 10

3 Hiểu BLUE 14

III KẾT QUẢ MÔ PHỎNG 19

IV KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 21

V TÀI LIỆU THAM KHẢO 22

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 (minth), 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

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

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 maxp 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

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ỏ

1 Thuật toán

Ý 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, pm, 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 pm, 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,

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, minth và maxth đã đượ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 maxp đế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 maxp 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ự

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

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 maxth 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 maxth 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 maxth Đâ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

2. 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

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

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ả:

R1 R2 R3 R4

Bảng 2-1: Kết quả thực hiện mô phỏng sử dụng RED

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:

RED BLUE

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

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