Đánh Giá Hiệu Năng Truyền Thông Đa Phương Tiện Khi Sử Dụng Droptail Và Red

Hình 4.1 Cấu trúc mô phỏng

Hệ thống gồm 8 nút, trong đó R1, R2, CORE đóng vai trò là router trên đường đi, S1, S2, S3, S4 là nguồn phát và DEST là đích.

Với mục đích minh họa các chiến lược quản lý hàng đợi để chống tắc nghẽn, hệ thống được thiết kế như trên với nhiều nguồn phát tới đích, đi qua mạng có điểm nút cổ chai là đường truyền (link) nối nút CORE và nút R2 với băng thông thấp. Tất cả các đường truyền đều là song công với thời gian đáp ứng và băng thông như trên hình vẽ.

Mỗi nguồn S1, S2, S3 được gắn với 1 thực thể gửi (nguồn) của giao thức TCP, mỗi thực thể gửi TCP lại được gắn với một nguồn sinh lưu lượng của ứng dụng FTP, đó là: ftp(1,1) ; ftp(1,2); ftp(1,3); ftp(2,1).... Nguồn sinh lưu lượng trên nút S4 phát dữ liệu với tốc độ không đổi - CBR bằng giao thức UDP. Nguồn S3 và S4 nằm trên nút nỗi với các đường truyền có băng thông lớn nhằm mục đích tạo ra các thời điểm bùng phát, truyền nhiều dữ liệu làm ngập nút cổ chai.

Các thông số quan trọng khác: kích thước cửa sổ tối đa của các luồng TCP: 50; kích thước các gói tin: 100 byte.

Router ghi nhãn CORE là nơi sẽ xảy ra tắc nghẽn, ta sẽ triển khai các dịch vụ quản lý hàng đợi tại đó để so sánh đặc tính của các chiến lược quản lý hàng đợi.

4.3. Kịch bản mô phỏng

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

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

Trong các thí nghiệm mô phỏng DropTail, RED, WRED sử dụng chung 1 kịch bản mô phỏng (tô-pô mạng, các nguồn sinh lưu lượng, các thời điểm bắt đầu, kết thúc truyền, kích thước hàng đợi...). Mục tiêu của kịch bản là nhằm tạo ra ngữ cảnh thuận lợi cho việc quan sát trạng thái của hệ thống như: số gói tin trong hàng đợi, phục hồi tốc độ truyền giữa các nguồn, số gói tin bị mất… khi hệ thống trong trạng thái bình thường và khi có xảy ra tắc nghẽn.

Với mỗi một giao thức, ta có 3 kịch bản như sau:

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

 Giây 0.1, 10 và 20 lần lượt các nguồn S1, S2, S3 bắt đầu truyền 1 luồng ftp tương ứng.

 Tại giây 20, lúc S3 bắt đầu truyền thì tổng băng thông của 3 nguồn đã bắt đầu lớn hơn băng thông của nút cổ chai (3Mbps), nhưng do có hàng đợi nên vẫn trong phạm vi xử lý được của router CORE.

 Đến giây 30, tại nguồn S3 thì 2 luồng ftp(3,2) và ftp(3,3) cùng lúc truyền và chiếm hết băng thông 5Mbps của link S4-R1. Từ đó tạo nên thời điểm tắc nghẽn ở nút cổ chai.

 Đến giây 40, cả 3 luồng TCP tại S3 đều đột ngột dừng truyền, mô tả burst dữ liệu đã hết. Từ đó ta sẽ quan sát sự phục hồi về tốc độ truyền của S1 và S2.

 Code:

$ns at 0.1 "$ftp(1,1) start"

$ns at 10 "$ftp(2,1) start"

$ns at 20 "$ftp(3,1) start"

$ns at 30 "$ftp(3,2) start"

$ns at 30 "$ftp(3,3) start"

$ns at 40 "$ftp(3,1) stop"

$ns at 40 "$ftp(3,2) stop"

$ns at 40 "$ftp(3,3) stop"

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

 Thí nghiệm này có 2 phần: theo dõi, so sánh sự thay đổi khi có sự bùng phát về lưu lượng UDP trong 2 trường hợp UDP: khi các luồng TCP đang chạy ổn định và khi các luồng TCP cũng đang tắc nghẽn.

 Thí nghiệm thực hiện với thông lượng của luồng UDP là 5Mbps. Trong khi đó băng thông của nút cổ chai chỉ là 3Mbps. Tình trạng tắc nghẽn sẽ xảy ra tại link CORE-R2, các gói tin sẽ được cache trong queue của router Core.

 Code:

$ns at 0.1 "$ftp(1,1) start"

$ns at 0.1 "$ftp(2,1) start"

$ns at 10 "$ftp(3,1) start"

$ns at 20 "$cbr4 start"

$ns at 30 "$cbr4 stop"

$ns at 40 "$ftp(3,1) stop"

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

 Kịch bản này chỉ áp dụng với cơ chế WRED với chức năng đặt ưu tiên truyền dữ liệu theo nguồn phát.

 Khi mạng bị tắc nghẽn bởi nguồn CBR cbr4, các luồng dữ liệu TCP với độ ưu tiên khác nhau lần lượt được phát. Sau một thời gian thì luồng gây tắc

nghẽn CBR dừng truyền, từ đó ta sẽ quan sát được độ phục hồi của hệ thống.

 Code:

$ns at 0.1 "$cbr4 start"

$ns at 0.1 "$ftp(2,1) start"

$ns at 10 "$ftp(1,1) start"

$ns at 20 "$ftp(3,1) start"

$ns at 20 "$ftp(3,2) start"

$ns at 20 "$ftp(3,3) start"

$ns at 30 "$cbr4 stop"

$ns at 40 "$ftp(2,1) stop"

4.4. Đánh giá hiệu năng truyền thông đa phương tiện khi sử dụng DropTail và RED

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

a. Kết quả

Ta theo dõi 2 giải thuật DropTail và RED dựa trên 3 tham số: tỉ lệ packet mất, kích thước hàng đợi và thông lượng sử dụng.

Hình 4. 2 Tỉ lệ packet bị mất của DropTail và RED

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. 5 Kích thước hàng đợi của DropTail và RED

Hình 4. 6 Thông lượng của Droptail và RED khi CBR có throughput 3Mbps

Hình 4. 6.2. Thông lượng của Droptail và RED khi CBR có throughput 5Mbps

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.

4.5.1. Mô phỏng WRED TSW2CM và TSW3CM

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