Như ta đã biết, các giải thuật dựa trên chiều dài hàng đợi như RED, ARED, gặp phải một vấn đề là chiều dài hàng đợi cho biết rất ít thông tin như tính dữ dội của sự tắc nghẽn hay số lượng những kết nối cạnh tranh chia sẻ mối liên kết. Giải thuật RED cũng yêu cầu một lượng lớn các tham số để vận hành chính xác ở những trường hợp tắc nghẽn
khác nhau. RED chỉ đạt được sự làm việc lý tưởng khi nó có đủ không gian bộ đệm và các tham số của nó được cấu hình một cách chính xác.
Người ta đã đưa ra giải thuật BLUE, với mục đích sử dụng việc mất mát gói tin và những liên kết sử dụng để quản lý sự tắc nghẽn.
BLUE duy trì một xác suất và sử dụng xác suất này để đánh dấu hay loại bỏ những gói tin khi chúng xếp hàng trong hàng đợi. Nếu như hàng đợi liên tục loại bỏ những gói tin vì tràn bộ đệm, xác suất đánh dấu gói tin sẽ được tăng lên và qua đó thông báo tắc nghẽn trở lại hệ thống. Ngược lại, nếu hàng đợi rỗng hay các mối liên kết dừng lại, xác suất đánh
dấu gói tin sẽ được giảm xuống.[26][27][29]
3.7.2 Giải thuật:
Như đã nói ở trên, ý tưởng của BLUE là thực hiện quản lý hàng đợi bằng việc quản lý sự mất mát gói tin và sự sử dụng các mối liên kết hơn là dựa vào chiều dài hàng đợi tức thời hay chiều dài hàng đợi trung bình như các phương pháp mà ta đã đề cập ở các phần trên.
BLUE duy trì một xác suất đơn Pm dùng để đánh dấu hay loại bỏ những gói tin khi chúng xếp hàng trong hàng đợi. Nếu hàng đợi liên tục phải loại bỏ gói tin vì tràn bộ đệm, P sẽ tăng dần lên và qua đó tăng nhịp độ báo trở lại hệ thống sự tắc nghẽn. Ngược lại, nếu
những hàng đợi rỗng hay các mối liên kết ngừng lại, BLUE sẽ giảm bớt xác suất đánh dấu gói tin Pm.
Upon packet loss event:
if ( ( now - last_update ) > free_time ) then Pm = Pm + delta
last_update = now Upon link idle event:
if ( ( now - last_update ) > free_time ) then Pm = Pm - delta
last_update = now Hình 23 : Giải thuật BLUE
Ngoài tham số Pm , BLUE sử dụng hai tham số khác để điều khiển việc thay đổi xác suất Pm :
+ free_time: Tham số này xác định khoảng thời gian tối thiểu giữa hai lần cập nhật liên tiếp của Pm. Điều này cho phép những thay đổi trong xác suất đánh dấu Pm để tạo các hiệu ứng trước khi giá trị Pm này được cập nhật tiếp. Tham số này khi thực hiện ở thực tế phải là một giá trị ngẫu nhiên để tránh sự đồng bộ hóa ( global synchronization ). Tham số free_time cần phải đặt dựa vào một chu kỳ đi và về của những mối liên kết multiplex .
+ delta: Tham số này xác định số lần Pm tăng lên ( khi tràn hàng đợi ) hay giảm xuống ( khi mối liên kết dừng lại hoặc hàng đợi rỗng ).
Với hai tham số trên, sẽ có vô số cách để quản lý Pm. Người ta đã thực hiện nhiều thí nghiệm sử dụng nhiều cách thiết đặt tham số và nhiều sự biến đổi giải thuật để tìm cách nhanh nhất và tối ưu nhất để quản lý hàng đợi. Bằng những thực nghiệm, người ta đưa ra nhận xét: free_time nên để giá trị trong khoảng 10ms và 500ms, delta để sao cho Pm dao động trong khoảng 0 đến 1 trong khoảng thời gian 5 - 30 giây sẽ cho phép giải thuật BLUE vận hành thật hiệu quả.[26][27]
3.7.3 Sự so sánh những mức tổn thất gói khi sử dụng RED và BLUE:
Để đánh giá giải thuật BLUE, Wu-chang Feng (Đại học Michigan - Mỹ) đã làm một số thí nghiệm sử dụng môi trường NS-2 với một topo mạng như hình 24:[26]
Hình 24: Topo mạng được xử dụng trong mô phỏng giải thuật BLUE
Tất cả các luồng trong topo trên có sự hỗ trợ của ECN. Sự thống kê việc mất mát gói tin trong khoảng thời gian từ 10 giây đến 100 giây cho cả hai giải thuật RED và BLUE.
Ở hàng đợi RED, minth và maxth được đặt tương ứng 30% và 90% kích thước hàng đợi. maxp được đặt bằng 1. Với thí nghiệm này, cách thiết lập các thông số kia là lý tưởng nhất bởi nó hạn chế tối đa cả độ trễ hàng đợi và mức tổn thất gói cho giải thuật RED.
Ở thí nghiệm dành cho BLUE, delta được đặt bằng 0.01 và free_time được đặt bằng 10ms.
Kết quả mô phỏng trong chương trình NS-2 được thể hiện dưới hai hình 25 và hình 26:
Hình 25 : Mức tổn thất gói của RED và BLUE (1000 kết nối )
Hình 26: Mức tổn thất gói của RED và BLUE ( 4000 kết nối )
Ở hai hình trên cho thấy những mức tổn thất được quan sát qua những kích thước hàng đợi khác nhau sử dụng cả hai giải thuật RED và BLUE với 1000 và 4000 kết nối.
Ở hai thí nghiệm này, hàng đợi tại bottleneck link giữa A và B được cho cỡ từ 100 KB đến 1000 KB. Độ trễ hàng đợi từ 17.8 ms đến 178 ms như trên hình vẽ.
Hình a, với 1000 kết nối, BLUE duy trì mức tổn thất gói tin bằng 0 trên tất cả các kích thước hàng đợi và tất cả các độ lớn bộ đệm như trên hình . Ngược lại, RED có sự mất mát gói tin rất lớn. Với sự giảm xuống của không gian bộ đệm trong phạm vi đang xét thì mức mất gói tin của RED ở hai mức độ lớn max và min của bộ đệm là gần như gấp đôi nhau.
Hình b, khi số kết nối tăng lên 4000 kết nối, BLUE vẫn làm tốt hơn RED rất nhiều. Thậm trí, khi độ lớn bộ đệm tăng đến mức cao nhất trong giới hạn của thí nghiệm, mức độ mất mát gói tin của RED vẫn cao hơn mức độ mất gói tin của BLUE ở mức bộ đệm thấp nhất. (adsbygoogle = window.adsbygoogle || []).push({});
Ta có thể đưa ra kết luận, BLUE quản lý tắc nghẽn với một không gian bộ đệm cực tiểu. BLUE tốt hơn RED khi so sánh ngay cả trong trường hợp kích thước vùng đệm thấp nhất.
3.7.4 Kết luận:
BLUE có thể điều khiển tắc nghẽn với một lượng không gian bộ đệm cực tiểu. Với việc chỉ cần một bộ đệm nhỏ , BLUE cho phép dành nhiều bộ nhớ hơn để cấp phát đến những gói có quyền ưu tiên đặc biệt và giải phóng bộ nhớ cho những bộ định tuyến khác.
Mặc dù cơ chế BLUE rất đơn giản, nhưng nó cũng cần thiết đặt các tham số điều khiển chính xác và những tham số này phải được thay đổi một cách linh hoạt để giúp hàng đợi thích nghi linh hoạt với những sự thay đổi tải của mạng. Với những luồng "non-responsive" ( không đáp lại ) thì BLUE không hữu ích.
Với những điểm mạnh của mình là không phụ thuộc vào độ lớn hàng đợi trung bình cũng như độ lớn hàng đợi tức thời, giải thuật BLUE hứa hẹn sẽ được phát triển và sử dụng nhiều trong công tác quản lý tắc nghẽn trong tương lai.[26][27][29]
3.8 Tổng kết chương:
Chương này đi sâu vào nghiên cứu các phương pháp đang được bàn luận và sử dụng như : ECN, RED, WRED, ARED, DRED, BLUE,.Tìm hiểu về cơ chế, thuật toán, ưu điểm, nhược điểm, của các chế này.
Có thể nói các cơ chế như WRED, ARED, DRED hay SRED thực chất là phát triển dựa trên những thuật toán cơ sở của RED với mục đích khắc phục những điểm hạn chế của RED.
Việc đi tìm hiểu các cơ chế này nhằm đưa ra một sự khái quát, một sự thống kê một số trong số rất nhiều các phương pháp quản lý hàng đợi tích cực đang được bàn luận và sử dụng.
CHƯƠNG 4: MÔ PHỎNG GIẢI THUẬT RED.CÁC NHẬN XÉT VÀ ĐÁNH GIÁ.
4.1 Mục đích:
Chương này , tôi xin trình bày một số kết quả mô phỏng hệ thống mạng có sử dụng giải thuật RED ( Random Early Detection ) để phát hiện và quản lý tắc nghẽn với những mục đích sau:
Mô phỏng một topo mạng có sử dụng giải thuật RED để phát hiện và quản lý tắc nghẽn.
Thay đổi các tham số đầu vào để quan sát và nhận xét. Từ đó rút ra kết luận về những tham số có mức độ tối ưu cao của giải thuật.
So sánh sự hiệu quả của giải thuật RED với phương phương pháp quản lý hàng đợi bằng Drop Tail. Rút ra nhận xét về mức độ hiệu quả của RED so với Drop Tail.
Mô phỏng giải thuật RED trên mạng sử dụng luồng TCP và luồng UDP để nhận xét về sự hiệu quả của RED trên hai luồng dữ liệu này.
4.2 Môi trường mô phỏng:
4.2.1 Giới thiệu chương trình mô phỏng NS-2 :
NS-2 là một môi trường mô phỏng mạng khá mạnh. Nó có thể tương thích với hệ điều hành Linux và hệ điều hành Windows. NS-2 là công cụ mô phỏng sự kiện rời rạc dùng cho việc nghiên cứu về mạng. Nó có thể mô phỏng nhiều cấu trúc mạng khác nhau. NS-2 sử dụng các giao thức TCP/UDP; tạo các lưu lượng như : FPT, Telnet, Web, CBR,
VBR; quản lý định tuyến bằng DropTail, RED, CBQ; những giải thuật định tuyến như Dijstra ,. NS-2 còn có thể mô phỏng multicast và các giao thức lớp MAC cho LAN.
NS-2 hiện nay là một phần của dự án VINT , một dự án phát triển các công cụ mô phỏng, phân tích, chuyển đổi những mô hình mạng bằng cách phát triển dựa trên nền tảng chương trình NS-2.
NS-2 được viết trên nền ngỗn ngữ C++ và OTcl ( ngôn ngữ nguyên bản Tcl với những mở rộng hướng đối tượng ). OTcl là ngôn ngữ hướng đối tượng và cú pháp lệnh của nó rất đơn giản. Đó cũng chính là lý do mà các mã nguồn mở của NS-2 hiện nay hầu hết được viết bằng OTcl .
Để thiết lập và chạy một mô phỏng mạng trong NS-2, người dùng phải viết một tập lệnh OTcl Script và khởi động một lịch trình sự kiện, thiết lập cấu hình sử dụng các đối tượng mạng và các hàm chức năng trong thư viện, chỉ cho tài nguyên lưu lượng biết khi nào thì bắt đầu và kết thúc việc truyền gói thông qua lập biểu.
Hình 27 : Mô hình dữ liệu đầu vào và kết xuất của NS-2.
Hình 28: Kiến trúc cơ bản của NS. Hình 28 cho ta thấy một kiến trúc cơ bản của NS.
Trong sơ đồ này, vị trí của người sử dụng ở góc dưới cùng bên trái. Người sử dụng thiết kế và chạy các chương trình mô phỏng ở môi trường tcl bằng cách sử dụng các đối tượng mô phỏng ở thư viện OTcl . Bộ lịch trình sự kiện và hầu hết thành phần mạng được viết trong C++ và được nối với OTcl thông qua tclcl. Tất cả quá trình trên tạo thành NS.
Khi kết thúc một quá trình mô phỏng nào đó, NS sẽ xuất ra một hoặc nhiều file text chứa những dữ liệu mô phỏng chi tiết theo yêu cầu của người sử dụng khi người sử dụng yêu cầu chúng trong quá trình thiết kế mã nguồn Tcl ( hay OTcl ) nguyên bản. Những dữ liệu này có thể được sử dụng cho mục đích phân tích mô phỏng hay dùng làm dữ liệu đầu vào cho một chương trình mô phỏng trực quan gọi là NAM ( Network
Animator). Các số liệu kết quả mô phỏng cũng được dùng để vẽ các đồ thị phân tích bằng chương trình XGraph theo các yêu cầu nghiên cứu.[30][31][32]
4.2.2 Chuẩn bị chương trình mô phỏng NS-2
NS-2 được thiết kế để chạy trong môi trường Unix. Tuy nhiên, ta vẫn có thể cài đặt NS-2 trong Windows bằng cách dùng thêm chương trình Cygwin và đều cho kết quả tốt. (adsbygoogle = window.adsbygoogle || []).push({});
Tất cả các bài mô phỏng trong báo cáo này được thực hiện với chương trình NS-2 cài đặt trong môi trường hệ điều hành Linux, phiên bản SuSe Linux 9.3.
4.3 Nội dung và kết quả mô phỏng:
Để thuận tiện cho việc thực hiện mô phỏng và đánh giá, tất cả các bài mô phỏng trong đề tài này đều thống nhất sử dụng một topology mạng gồm 2 nút router (r1 và r2 ) và các host (s1, s2, s3, s4) như hình dưới đây:
Hình 29: Topology vật lý mạng dùng để thực hiện mô phỏng.
+ Liên kết giữa các host s1, s2 với router r1; s3, s4 với r2 sử dụng hàng đợi DropTail.
+ Các link giữa các nút đều là duplex với thời gian trễ và băng thông như biểu diễn trên hình vẽ ( Liên kết giữa hai router r1, r2 với các host s1, s2, s3, s4 có kiến trúc, băng thông, tốc độ tương đương mạng LAN. Còn liên kết giữa r1 với r2 có băng thông, tốc độ tương đương mạng WAN ).
Sau đây là nội dung và kết quả các bài mô phỏng mà sinh viên đã thực hiện. Mã nguồn OTcl Script của các bài mô phỏng này có trong phần phụ lục của bài báo cáo. 4.3.1 Mô phỏng tổng quan mạng có sử dụng giải thuật RED để quản lý tắc nghẽn: 4.3.1.a Mục đích:
Mục đích của bài mô phỏng này là quan sát mối tương quan giữa 2 giá trị độ dài hàng đợi tức thời và độ dài hàng đợi trung bình của giải thuật RED qua đó nhận xét về giải thuật.
Đánh giá việc quản lý hàng đợi tại một nút router sử dụng giải thuật RED.
4.3.1.b Mô hình:
Topo mạng như biểu diễn ở hình 29 . Liên kết giữa router r1 và r2 sử dụng giải thuật RED. Kích thước hàng đợi tối đa là 25 packet. Các tham số minth , maxth và wq của giải thuật RED ở bài này lần lượt là minth = 5 , maxth =12, wq = 0.002, maxp = 0.02.
Có 2 nguồn lưu lượng FTP ( fpt1 và fpt2 ) được gắn vào hai nút s1 và s2. Tương ứng có 2 đích nhận lưu lượng được gắn vào nút s3. Độ trễ và băng thông các mối liên kết như trên hình 29.
4.3.1.c Thực hiện và kết quả:
Thực hiện mô phỏng với lịch trình quy định trong script của chương trình: Thời điểm 0.0s : Luồng 1 ( luồng ftp1 từ nút s1 đến sink là nút s3 ) bắt đầu truyền.
Thời điểm 3.0s : Luồng 2 ( luồng ftp2 từ nút s2 đến sink là nút s3 ) bắt đầu truyền.
Thời điểm 30.0s : Cả 2 luồng ngưng truyền. Kết quả :
Sau khi chạy chương trình trên NS-2 ta có một đồ thị được vẽ trên Xgraph biểu thị 2 giá trị chiều dài hàng đợi tức thời và hàng đợi trung bình của topo mạng trong vòng 30 giây của quá trình mô phỏng như hình 30.
Ngoài đồ thị biểu diễn trên Xgraph, ta còn nhận được một hình mô phỏng trực quan sự rớt gói trong quá trình truyền dữ liệu của mạng như ở hình 32.
Hình 30. Kết quả biểu diễn giá trị độ dài hàng đợi tức thời (queue) và độ dài hàng đợi trung bình ( ave_queue) nhận được ở bài 1.
Hình 32: Quan sát trực quan việc thả gói trong mạng sử dụng RED. 4.3.1.d. nhận xét :
Qua kết quả mô phỏng trực quan một topo mạng xử dụng giải thuật RED để quản lý nghẽn giữa 2 router, ta đã thấy được những ưu điểm của giải thuật RED khi được áp dụng.
Hình 30 biểu diễn chiều dài hàng đợi hiện thời và chiều dài hàng đợi trung bình theo thời gian của hàng đợi tại gateway sử dụng giải thuật RED. Đường cong màu đỏ là kích thước hàng đợi hiện thời của router; đường cong mầu xanh lục biểu diễn kích thước
hàng đợi trung bình được tính bằng công thức:
Avgi = (1-wq )*avgi-1 + wq*q
Ở đây, avg là chiều dài hàng đợi trung bình; wq là trọng số dùng để tính toán và ở bài mô phỏng này được lấy bằng 0.002; q là kích thước hàng đợi tức thời. Giá trị minth = 5 và maxth = 12.
Nhìn vào đồ thị ở hình 30 ta thấy có những thời điểm độ lớn hàng đợi tức thời tăng một cách mạnh mẽ, thậm trí vượt qua cả ngưỡng maxth ( đoạn từ 3s đến khoảng 4.5s ). Nhưng giá trị độ lớn hàng đợi trung bình vẫn ở mức thấp hơn rất nhiều, thậm trí ở thời điểm đó nó còn chưa chạm tới ngưỡng tối thiểu minth. Và ta nhận thấy trong suốt khoảng thời gian thực hiện mô phỏng, chiều dài hàng đợi trung bình vẫn giữ ở mức rất thấp, gần như là nó chỉ dao động xung quanh giá trị minth. Mà theo lý thuyết, giải thuật RED loại bỏ gói tin chỉ dựa vào độ lớn của chiều dài hàng đợi trung bình chứ không dựa vào chiều dài hàng đợi tức thời.
Khi kích thước hàng đợi trung bình nhỏ hơn ngưỡng minth, RED hoàn toàn không loại bỏ hay đánh dấu (mark) gói tin; khi đó, xác suất loại bỏ gói của nó là 0 và mọi gói đến