Hình 4. 3 – Kích thước hàng đợi của DropTail và RED
Hình 4. 4 Thông lượng của DropTail và RED
b. Nhận xét
− Trong vòng 20 giây đầu, chƣa có sự quá tải băng thông xảy ra, vì thế trong cả 2 giao thức thì luồng dữ liệu đều đi qua thông suốt, gần nhƣ không có packet nào phải ở trong hàng đợi. Tốc độ truyền của các luồng TCP qua link giữa 2 router CORE – R2 đạt tốc độ tối đa.
− 20s – 30s: bắt đầu xuất hiện tắc nghẽn, các gói tin đƣợc lƣu lại ở trong hàng đợi. Với giao thức DropTail thì đạt ổn định khoảng 38 packet thƣờng xuyên trong
queue, dƣới ngƣỡng tối đa 50 packet của link, và vì thế không có packet nào bị drop, dù băng thông đã bị đầy. Nhƣng giao thức RED lại khác, do có cơ chế drop sớm các gói tin trong hàng đợi nên đã xuất hiện các packet bị mất, từ đó lƣu lƣợng truyền dao động, không liên tục đạt ngƣỡng tối đa 3Mbps, nhƣng bù lại số gói tin trong hàng đợi giảm hẳn, dao động mạnh trong khoảng từ 0 đến 36 packet.
− 30s - 40s: lƣu lƣợng truyền tăng cƣờng TCP, tại giây 30 đột ngột tăng làm tràn đầy queue (hiện tƣợng lock out) ở cả 2 giao thức. Với DropTail, do đặc tính của nó nên băng thông lúc nào cũng đƣợc sử dụng tối đa, tuy nhiên số gói tin trong hàng đợi dao động hết sức thất thƣờng, từ 0-50 packet, rất thƣờng xuyên đạt ngƣỡng 50 packet và drop mọi gói tin đến (hiện tƣợng lockout). Với RED, do có khả năng drop sớm nên không bị hiện tƣợng này, và số gói tin trong hàng đợi vẫn dao động ổn định quanh ngƣỡng từ 5 đến 35 packet.
− 40s – 50s: quá trình bùng phát dữ liệu kết thúc, hàng đợi đƣợc giải phóng, không có gói tin nào bị mất. Trong thí nghiệm này thì giao thức DropTail tỏ ra tốt hơn khi gần nhƣ ngay lập tức tốc độ truyền của S1 và S2 đã duy trì ở mức tối đa. Trong khi đó, dựa vào biểu đồ băng thông, ta thấy với giao thức RED thì S1 và S2 phải mất 2 giây để từ từ tăng window size lên để truyền với tốc độ cao nhất. Nguyên nhân của việc này là do trong quá trình trƣớc đó, RED đã drop nhiều gói tin hơn hẳn so với DropTail, trong đó vì tính ngẫu nhiên, nhiều gói tin từ nguồn S1, S2 cũng bị drop theo, vì thế trƣờng window size từ 2 nguồn này đã giảm thấp và cần thời gian để phục hồi.
4.4.2. Thí nghiệm 2: Tăng cường độ tắc nghẽn với nguồn phát UDP a. Kết quả
Ta theo dõi sự thay đổi của thông lƣợng - throughput sử dụng trên link CORE – R2 với 2 lần thay đổi mức độ bùng phát UDP nhƣ kịch bản đã phát biểu ở trên.
Hình 4. 6 Thông lượng của Droptail và RED khi CBR có throughput 3Mbps
Hình 4.7. Tỉ lệ packet bị mất của Droptail và RED
b. Nhận xét:
Giao thức UDP truyền tin không tin cậy, nó không sử dụng trƣờng window size hay 1 cơ chế nào khác để tự giảm tốc độ truyền mà chỉ đơn thuần là làm ngập băng thông, khác với giao thức TCP có thể tự giảm tốc độ truyền khi gặp tắc nghẽn. Trong thí nghiệm 2, ta có thể thấy tại giây 30, sau khi dừng phát UDP, chỉ còn luồng TCP đang hoạt động, thì có sự khác biệt giữa tốc độ phục hồi của luồng TCP giữa giao thức DropTail và RED.
Trong trƣờng hợp mức độ bùng phát tại nguồn UDP chƣa thật sự lớn (3Mbps, bằng với băng thông nút cổ chai) thì kết quả thu đƣợc cho thấy 2 nguồn TCP khi sử dụng giao thức RED có thể phục hồi nhanh hơn hẳn so với DropTail. Cụ thể tại các giây 30, 3 luồng TCP ở RED với tổng thông lƣợng 100Kbps chỉ mất 2s để đạt đƣợc thông lƣợng tối đa 3Mbps. Trong khi đó với Droptail thì từ 0 Kbps và phải mất đến 5s mới phục hồi hoàn toàn, lâu hơn 2,5 lần.
Tuy nhiên khi mức độ bùng phát tại nguồn UDP nghiêm trọng (5Mbps) thì kết quả thu đƣợc giữa 2 giao thức là không có sự khác biệt rõ ràng. Với lƣợng dữ liệu lớn, ngập tràn thì thuật toán loại bỏ sớm ngẫu nhiên của RED không còn tỏ ra hiệu quả, và tốc độ phục hồi ở giây 30 nhƣ trong thí nghiệm trên không có nhiều sự khác biệt so với giải thuật DropTail.
4.5. Đánh giá hiệu năng truyền thông đa phương tiện khi sử dụng WRED
Topô mạng và kịch bản đƣợc xây dựng chung nhƣ đã trình bày trong phần trên. WRED có nhiều loại khác nhau, tùy theo mục đích cần minh họa cho Policier Type nào mà ta sẽ có kịch bản tùy chỉnh các tham số tƣơng ứng. Chi tiết sẽ đƣợc trình bày trong mô phỏng cụ thể tiếp theo.
a. Cấu hình mô phỏng
Theo mô phỏng, ta sẽ ƣu tiên các gói tin từ nguồn S1 và S3, và sẽ hạn chế thông lƣợng từ S2 và S4. Ngƣỡng CIR của S1, S3 đặt max băng thông của nó và lần lƣợt là 1Mbps và 3Mbps. Ngƣỡng CIR của 2 luồng cần giới hạn S2, S4 sẽ đặt lần lƣợt là 0.5Mbps và 1Mbps.
Tham số PIR của TSW3CM sẽ đƣợc thiết lập gấp đôi so với CIR.
TSW2CM sử dụng 2 hàng đợi ảo, trong đó hàng đợi (0,0) màu green sẽ đƣợc ƣu tiên hơn, hàng đợi (0,1) màu đỏ sẽ có xác suất drop cao hơn. Cụ thể trong cấu hình configQ nhƣ sau:
$qCR2 configQ 0 0 20 80 0.02 $qCR2 configQ 0 1 20 40 0.10
TSW3CM sử dụng 3 hàng đợi ảo, trong đó hàng đợi (0,0) màu green sẽ đƣợc ƣu tiên nhất, tiếp đó hàng đợi (0,1) màu vàng sẽ có xác suất drop cao hơn., và cuối cùng hàng đợi (0,2) màu đỏ kém ƣu tiên sẽ bị drop nhiều nhất. Cụ thể trong cấu hình configQ nhƣ sau:
$qCR2 configQ 0 0 20 80 0.02 $qCR2 configQ 0 1 20 40 0.10 $qCR2 configQ 0 2 10 20 0.30
b. Phương thức thu thập kết quả
− Lấy dữ liệu từ NS2:
Với mục đích nghiên cứu về các cơ chế quản lý hàng đợi nên kết quả thu thập đƣợc sẽ chủ yếu đƣợc lấy từ hàng đợi Core-R2, là nơi có băng thông thấp và xảy ra hiện tƣợng nút cổ chai.
Thông số thu thập bao gồm kích cỡ, thông lƣợng và số gói tin bị mất. Các giá trị này đƣợc tính toán và ghi vào file bằng việc phân tích dữ liệu ở qFile – đối tƣợng thuộc dạng monitor-queue. Từ các giá trị thu đƣợc ta dùng xgraph để vẽ biểu đồ so sánh tƣơng ứng.
− Đường trung bình
Do dữ liệu thô có biên độ dao động lớn, để trực quan hơn ta sử dụng giá trị trung bình. Ta tính giá trị này theo thuật toán:
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
File shell script: calculate_average_point.sh lấy đầu vào là file dữ liệu kích cỡ, thông lƣợng hoặc số gói tin bị mất, từ đó sinh ra file ghi các giá trị trung bình tƣơng
ứ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
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. 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
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. 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à