Đánh giá hiệu quả đảm bảo QoS cho truyền thông đa phương tiện của chiến lược quản lý hàng đợi Wred

ứng. Ta sử dụng file mới này để vẽ đường trung bình. Chi tiết code của file calculate_average_point.sh được cung cấp trong phụ lục của luận văn.

− Độ trễ

Để tính độ trễ của các gói tin khi qua các node thì ta phải phân tích tệp vết của file

tcl.

Tệp vết sẽ sử dụng 2 chương trình awk để phân tích :

 calculate-queue-delay.awk : tính độ trễ trung bình khi các gói tin đi qua 1 link (thường bị chậm do lưu trong queue).

 calculate-flow-delay.awk: tính độ trễ trung bình của 1 flow từ nguồn đến đích. Do các tệp vết ghi đầy đủ thông tin về tất cả các gói tin qua mạng nên dung lượng

thường khá lớn. Với 45s mô phỏng của mỗi kịch bản thì tệp vết sẽ có xấp xỉ khoảng 3 triệu record và dung lượng khoảng 120MB. Trong luận văn ứng với mỗi kịch bản mô phỏng và cơ chế quản lý hàng đợi thì đều có 1 tệp vết tương ứng. Vì vậy, có tất cả 3x3=9 tệp vết được phân tích.

c. Kết quả

Ta xem xét kích thước hàng đợi và băng thông qua Core router khi sử dụng các kĩ thuật RED, TSW2CM, TSW3CM

- Kịch bản 1: Tăng cường độ tắc nghẽn với nguồn phát TCP

Hình 4. 8. Kích thước hàng đợi RED, WRED-TSW2CM , WRED-TSW3CM

[

Hình 4. 9 Kết quả so sánh thông lượng của RED với hai chính sách của WRED

Hình 4. 10 Đường thông lượng trung bình của RED, tsw2cm và tsw3cm

Giao thức quản lý hàng đợi

Thời gian trễ trung bình của link R1 - Core (s)	Thời gian trễ trung bình của link Core – R2 (s)	Thời gian trễ trung bình của link R2 – Dest (s)	Thời gian trễ trung bình từ nguồn S1 đến đích (s)
RED	0.00512952	0.00950826	0.005112	0.00859365
WRED tsw2cm	0.0101001	0.0182467	0.005112	0.00976031
WRED tsw3cm	0.0100821	0.024623	0.00508321	0.0092573

Có thể bạn quan tâm!

Xem toàn bộ 88 trang tài liệu này.

Bảng 4.1. Kết quả so sánh thời gian trễ của RED, tsw2cm và ts3cm ở kịch bản 1

- Kịch bản 2: Tăng cường độ tắc nghẽn với nguồn phát UDP

Hình 4. 11 Kích thước hàng đợi của RED, tsw2cm và tsw3cm (Kịch bản 2)

Hình 4. 12 Kết quả so sánh thông lượng của RED với ba chính sách của WRED

Hình 4. 13 Kết quả so sánh đường thông lượng trung bình của RED với ba chính sách của WRED

Giao thức quản lý hàng đợi

Thời gian trễ trung bình của link R1 - Core (s)	Thời gian trễ trung bình của link Core – R2 (s)	Thời gian trễ trung bình của link R2 – Dest (s)	Thời gian trễ trung bình từ nguồn S1 đến đích (s)
RED	0.00510018	0.0310101	0.00510062	0.00852365
WRED tsw2cm	0.0101055	0.0154239	0.005112	0.00920217
WRED tsw3cm	0.0100949	0.0196376	0.00509856	0.00922524

Bảng 4.2. Kết quả so sánh thời gian trễ của RED, tsw2cm và ts3cm ở kịch bản 2

- Kịch bản 3: Luồng ưu tiên bắt đầu chạy khi đang có tắc nghẽn

Hình 4. 14 Kích thước hàng đợi của RED, tsw2cm và tsw3cm (Kịch bản 3)

Hình 4. 15 Kết quả so sánh thông lượng của RED với ba chính sách của WRED

Hình 4. 16 Kết quả so sánh thông lượng trung bình của RED với ba chính sách của WRED

Giao thức quản lý hàng đợi

Thời gian trễ trung bình của link R1 - Core (s)	Thời gian trễ trung bình của link Core – R2 (s)	Thời gian trễ trung bình của link R2 – Dest (s)	Thời gian trễ trung bình từ nguồn S1 đến đích (s)
RED	0.00508605	0.0606333	0.00508553	0.00850128
WRED tsw2cm	0.0101001	0.0182467	0.005112	0.00976031
WRED tsw3cm	0.0100821	0.024623	0.00508321	0.0092573

Bảng 4.3. Kết quả so sánh thời gian trễ của RED, tsw2cm và ts3cm ở kịch bản 3

d. Nhận xét

Kịch bản 1: bùng phát TCP, ta có thể thấy 1 sự khác biệt đáng kể giữa 3 chính sách: RED, TSW2CM và TSW3CM:

− RED tận dụng được nhiều băng thông nhất, tuy nhiên không có cơ chế QoS để ưu tiên luồng dữ liệu từ S1 và S3. Khi có tắc nghẽn (từ giây 20 đến giây 40) thì loại bỏ gói tin ngẫu nhiên trong hàng đợi. Sau khi nguồn S3 ngập băng thông ngừng truyền, thì thông lượng qua router cũng bị giảm đột ngột, dữ liệu từ S1 và S2 phải mất 2 giây để phục hồi từ tốc độ 1Mbps lên 2Mbps

− TSW2CM theo cấu hình luôn ưu tiên S1 vào hàng đợi (0,0) ưu tiên còn S2 vào hàng đợi (0,1) có xác suất loại bỏ rất cao. Theo cấu hình tại configQ thì các traffic của S2 đã vượt ngưỡng maxth 20 nên trong kịch bản này bị drop toàn bộ. Biên độ dao động tốc độ truyền là khá lớn, nhưng đến khi dữ liệu ưu tiên từ nguồn S3 làm ngập mạng, thì router tận dụng hết throughput để phục vụ S3 và đường throughput trở nên “mịn”. Đặc biệt, sau khi S3 dừng truyền ở giây 40 thì ngay lập tức S1 vẫn có tốc độ truyền tối đa (1Mbps) chứ không bị mất 2 giây

phục hồi như RED. Điều này chứng tỏ sau khi S1 được ổn định tốc độ tối đa, dù có xảy ra tắc nghẽn nhưng do được ưu tiên nên không có gói tin nào của S1 bị mất. Từ đó tốc độ S1 không bị ảnh hưởng.

− TSW3CM được cấu hình với các luồng dữ liệu từ S2, S4 ban đầu sẽ được cho vào hàng đợi (0,1), nói cách khác traffic được màu vàng, chỉ hạn chế phần nào tốc độ truyền chứ không cấm chặt chẽ như màu đỏ ở hàng đợi (0,2).Vì vậy khi tới giây 10, nguồn S2 với tốc độ 1Mbps bắt đầu truyền nhưng chỉ được đi qua 55%, từ giây 10 đến giây 20, băng thông đi qua router core dao động trong khoảng 1,55 Mbps. Khi bùng phát xảy ra ở giây 30, do nguồn gây bùng phát là S3 và cũng là 1 nguồn được ưu tiên, vì thế dữ liệu bùng phát nhanh chóng chiếm đầy hàng đợi mà không bị drop. Từ đó gây nên hiện tược lockout và sau đó băng thông của router tụt xuống về gần 0. Sau đó quá trình truyền dữ liệu khi quá tải của CORE router hết sức bất thường với sự tăng giảm đột ngột, liên tục của tốc độ truyền. Khi nguồn bùng phát S3 dừng truyền dữ liệu thì giống như TSW2CM, ngay lập tức S1 và S2 vẫn giữ được tốc độ lý tưởng (1,55Mbps) như trước khi xảy ra tắc nghẽn. Điều này chứng tỏ khả năng phục hồi của hệ thống là rất tốt.

− Về độ trễ trung bình, giao thức RED cho thời gian trễ là nhỏ nhất. Nguyên nhân là khi chạy giao thức WRED tsw2cmm tsw3cm, các gói tin cần mất thêm thời gian tại link R1-CORE để đánh dấu và router core ở link CORE-R2 cũng mất nhiều thời gian phân loại, ưu tiên gói tin theo hàng đợi hơn.

Kịch bản 2: bùng phát UDP

− RED: kết quả của thí nghiệm không khác với những gì đã làm trong phần trên. Băng thông được tận dụng nhiều nhưng khi bùng phát xảy ra, dữ liệu truyền lại chủ yếu là UDP, và sau đó các luồng tcp phải mất đến 6 giây mới phục hồi được tốc độ 3Mbps như ban đầu.

− TSW2CP: Do cấu hình đã đánh dấu traffic từ S2 và S4 bằng màu đỏ, đặt vào hàng đợi (0,1) với tham số loại bỏ rất cao. Vì thế ngay từ khi bắt đầu S2 và S4 đã vi phạm ngưỡng truyền CIR và bị drop sớm. Dữ liệu bùng phát không được truyền qua router CORE, không làm ngập băng thông và các traffic TCP từ S1, S3 được bảo đảm hoàn toàn, không gặp phải tắc nghẽn.

− TSW3CP: Dữ liệu từ nguồn bùng phát S4 được đánh dấu màu vàng, cho vào hàng đợi (0,1) với các tham số loại bỏ vừa phải. Tuy nhiên do traffic UDP bùng phát sinh ra là quá lớn nên trong khoảng thời gian từ 20s đến 30s đã chiếm toàn bộ băng thông của router CORE. Kết quả là hệ thống cũng mất đến 6s để phục hồi lại tốc độ truyền TCP như trước khi tắc nghẽn, TSW3CP trong trường hợp này không đạt hiệu quả nào đáng kể trong việc chống bùng phát.

− Về thời gian trễ trung bình, RED vẫn chỉ bằng 1 nửa so với tsw2cm và tsw3cm trong link R1-CORE vì không phải đánh dấu gói tin. Tuy nhiên tại link CORE- R2 thì thời gian trễ của RED là 0,0310101 giây, nhiều hơn gấp đôi so với 0.0154239 và 0.0196376 của tsw2cm và tsw3cm. Nguyên nhân vì lưu lượng CBR phát ra là rất lớn, giao thức RED drop gói tin sớm không hiệu quả bằng WRED nên trong thời gian hàng đợi bị tràn nhiều hơn hẳn. Vì thế gói tin bị giữ trong hàng đợi lâu hơn và tổng hợp lại làm thời gian trễ trung bình của gói tin RED trong kết nối CORE-R2 nhiều lên.

Kịch bản 3: Luồng ưu tiên bắt đầu chạy khi đang có tắc nghẽn

− RED: do traffic từ S2, S4 truyền quá mạnh, và không có cơ chế ưu tiên nên traffic từ S1, S3 truyền vào trong thời gian tắc nghẽn không gây được hiệu quả nào. Sau khi hết tắc nghẽn, băng thông được giải phóng thì S1, S3 mới bắt đầu tăng window size từ 0 lên và mới truyền được dữ liệu

− TSW2CM: traffic từ S2, S4 bị đánh màu Đỏ và nhanh chóng bị drop, vì thế khi S1 và S3 bắt đầu truyền vào giây 10 và giây 20, chúng không gặp cản trở gì và nhanh chóng đạt tốc độ tối đa.

− TSW3CM: Dữ liệu từ S2, S4 bị đánh màu Vàng, có khả năng bị drop nhiều hơn nhưng do lưu lượng bùng phát là quá lớn, nên cho dù traffic ưu tiên từ S1, S3 cũng không thể truyền qua được. Sau khi nguồn S2, S4 dừng truyền thì traffic của S1, S3 dần dần chiếm được băng thông nhưng với tốc độ chậm hơn RED

− Thời gian trễ trung bình của RED và WRED trong link R1-CORE không có gì thay đổi so với kịch bản 1 và 2. Tuy nhiên tại nút cổ chai CORE-R2 thì có sự khác biệt rõ rệt. Ta có thể quan sát tương ứng với biểu đồ thông lượng, thì giải thuật nào có thời gian truyền với full throughput lâu hơn thì sẽ có nhiều packet lưu trong hàng đợi hơn, theo đó thì độ trễ của gói tin sẽ lớn theo. Theo bảng dữ liệu thì RED với cơ chế quản lý hàng đợi kém hơn có thời gian trễ lớn nhất ở nút cổ chai là 0.0606333, so với 0.0182467 và 0.024623 của tsw2cm và tsw3cm.

4.5 So sánh và kết luận chung

Qua việc lập mô phỏng WRED với phương pháp TSW2CM và TSW3CM, so với RED, DropTail thì ta thấy có 1 số ưu điểm như sau:

− Ta có thể định nghĩa chính xác ưu tiên cho những luồng dữ liệu nào, và có thể chặn hoặc giới hạn traffic từ những nguồn không mong muốn. Điều này có ý nghĩa quyết định trong việc triển khai mô hình QoS bảo đảm chất lượng dịch vụ truyền tin.

Xem toàn bộ nội dung bài viết ᛨ