Hieu Nang Mang.doc

Hieu Nang Mang

ĐÁNH GIÁ HIÊU NĂNG MẠNG

1.MÔ PHỎNG HỆ THỐNG MẠNG , SO SÁNH DROPTAIL – RED – DRR.

Toàn bộ quá trình mô phỏng được chia thành 3 trường hợp như sau: • Trường hợp 1: Queue DropTail

• Trường hợp 2: Queue Red • Trường hợp 3: Queue FQ Mục tiêu:

• Lần lượt thay đổi các kiểu hàng đợi để so sánh , đánh giá các giải pháp giải quyết tắc nghẽn khi tắc nghẽn đã xảy ra và tránh tắc nghẽn khi tắc nghẽn chưa xảy ra Mô hình tổng quan của bài mô phòng này như sau:

Hình 1: Mô hình tổng quát

Mô hình được thiết lập với 7 Node Bao gồm 3 nguồn phát 0-1-2 , 3 nguồn nhận 4-5-7 và 2 Node trung gian 3-6 tượng trưng cho các router trong hệ thống ngoài đời thật.

Nguồn phát 0-1-2 sử dụng giao thức TCP, chạy dịch vụ FTP (File Transfer

Protocol) Node 2 chạy luôn dịch vụ (Constant Bit Rate -Dịch vụ truyền gói tin theo dòng bit có cấu trúc) trên nền giao thức UDP.

Các liên kết giữa các Agent là liên kết Simplex Link Tại một thời điểm chỉ có 1 dòng tin được truyền qua.

Các mô phỏng được thực hiện trên hệ mô phỏng NS-2 trên nền hệ điều hành Windows XP Khi thực hiện chương trình mô phỏng, kết qua được lưu lại ở file lưu vết

Mbps = Mega bit per second; ms = mili second; window: cửa sổ cực đại

Trường hợp 1: Sử dụng hàng đợi DropTail

Nguyên lý hoạt động:

• Hoạt động theo nguyên tắc FIFO, gói tin vào trước được phục vụ trước, nếu các gói tin đến và hàng đợi đã đầy thì gói tin bị hủy bỏ, ta gọi là hủy bỏ phần đuôi

(DropTail) Mô hình mạng :

Hình 2: Hiện tượng drop gói tin dùng hàng đợi DropTail

Sau khi phân tích file lưu dấu bằng phần mềm TraceGraph thu được kết quả:

• Các gói tin bị drop ở giây thứ 0.8 vì xảy ra hiện tượng BottleNeck ( Thắt cổ chai) Hàng đợi có độ lớn 20 nên số lượng gói tin drop khá nhiều Khi đó mới chỉ có các nguồn phát là FTP1, FTP2 và FTP3 Sau đó nguồn phát UDP bắt đầu gửi gói tin ở

giây thứ 1, từ giây thứ 1 trở đi các gói tin bị drop liên tục do dịch vụ CBR gửi liên tục và do sự quá tải của hàng đợi.

Biểu đồ thông lượng khi sử dụng hàng đợi DropTail

Hình 3: Biểu đồ Thông lượng khi sử dụng queue DropTail

Nhận xét:

• Thông lượng của các gói tin gửi và nhận tương đương nhau • Thông lượng của các gói tin forward cao hơn nhiều so với biểu đồ.

Trường hợp 2: Sử dụng hàng đợi Red ( Random Early Detection)

Nguyên lý hoạt động:

Hàng đợi RED có chương trình quản lý độ dài hàng đợi Khi kiểm tra thấy sắp xảy ra hiện tượng tắc nghẽn thì thông báo cho trạm nguồn hiệu chỉnh của sổ tắc nghẽn bằng cách cho rơi sớm gói tin Như vậy trạm nguồn nhận biết thông qua “time out” hoặc “duplicate ACK” và trạm nguồn giảm tốc dộ phát với hy vọng không phải hủy bỏ nhiều

gói tin sau đó Xác suất rơi gói tin sớm phụ thuộc vào độ dài trung bình hàng đợi và hau ngưỡng minth, maxth[28].

Thay đổi hàng đợi Q từ DropTail thành Red, phân tích file lưu vết ta thấy:

• Các gói tin bị drop giảm hẳn so với trường hợp 1, dựa vào cơ chế phát hiện thấy hàng đợi sắp tràn nên nguồn phát đã giảm tốc độ phát do đó gói tin bị rơi giảm nhiều.

Thông lượng của mạng khi sử dụng hàng đợi RED

Hình 4: Biểu đồ Thông lượng khi sử dụng hàng đợi RED.

Nhận xét:

• Do số gói tin rớt ít nên không ảnh hưởng nhiều đến Thông lượng , do đó biểu đồ cho thấy Thông lượng được giữ ổn định ở mức cao từ giây thứ 3 trở đi cho đến khi kết thúc.

Trường hợp 3: Sử dụng hàng đợi DRR (Deficit Round Robin)

Nguyên lý hoạt động:

Hàng đợi DRR cung cấp ưu tiên cho lưu lượng thời gian thực như VoIP, các gói IP được ánh xạ sang các hàng đợi khác nhau căn cứ vào các bit ưu tiên Tất cả các hàng đợi đều phục vụ theo kiểu xoay vòng Round Robin Ngoại trừ một hàng đợi ưu tiên được dùng để kiểm soát lưu thoại DRR hỗ trợ tương tự như WFQ nhưng cho các giao tiếp tốc độ cao Thay đổi hàng đợi Q từ Red thành DRR, phân tích file lưu vết ta thấy:

Hình 5: Thông tin mô phỏng trường hợp 3

Nhận xét:

Số Node gửi 6 Số Node nhận 6 Số packet gửi 13913

Trong 3 giải pháp đã đưa ra so sánh, RED là tối ưu hơn cả trong mạng hữu tuyến mô phỏng như trên RED là giải pháp tránh tắc nghẽn, khi nhận thấy có tắc nghẽn, hoặc có thể xảy ra tắc nghẽn, RED sẽ thông báo cho trạm nguồn về tắc nghẽn bằng cách cho rơi sớm gói tin, như vậy trạm nguồn nhận biết thông qua “time out” hoặc “duplicate ACK” và trạm nguồn giảm tốc độ phát với hy vọng không phải hủy bỏ nhiều gói tin Sau khi so sánh ta nhận thấy RED rất hữu dụng trong các mạng TCP tốc độ cao để phòng tránh tắc nghẽn.

2.MÔ PHỎNG HỆ THỐNG MẠNG , SO SÁNH TCP VEGAS – TCP FACK – TCP SACK1

Mục tiêu: so sánh hiệu suất mạng khi sử dụng các giao thức TCP Vegas – TCP Fack – TCP Sack1

Ở đây chúng ta có tất cả 10 node Trong đó các node 0,1,2,8,9 là nguồn phát Các node 4,5,7 là nguồn nhận

Toàn bộ quá trình mô phỏng được chia thành 3 trường hợp như sau:

• Trường hợp 1: Các nguồn phát sử dụng giao thức TCP VEGAS chạy dịch vụ

FTP 1 (Node 2) 0.2 s: start , 5.2 s: stop FTP 2 (Node 1) 0.3 s: start , 5.3 s: stop FTP 3 (Node 0) 0.4 s: start , 5.4 s: stop FTP 4 (Node 8) 0.5 s: start , 5.5 s: stop FTP 5 (Node 9) 0.6 s: start , 5.6 s: stop Q DropTail, size = 20 Mbps = Mega bit per second; ms = mili second

Trường hợp 1: Các nguồn phát Node 0,Node1,Node 2,Node 8,Node 9 là TCP Vegas Sử dụng TraceGraph ta thu được thông tin mô phỏng:

Hình 7: Thông tin mô phỏng TCP Vegas

Trường hợp 2: Các nguồn phát Node 0,Node1,Node 2,Node 8,Node 9 là TCP Fack Sử dụng TraceGraph ta thu được thông tin mô phỏng:

Hình 8: Hệ thống mạng mô phỏng TCP Fack

Trường hợp 3: Các nguồn phát Node 0,Node1,Node 2,Node 8,Node 9 là TCP Sack1

TCP SACK: Phương pháp này cho phép TCP có thể báo nhận ACK các dữ liệu nhận được mà không theo thứ tự

Ưu điểm:

• Tăng hiệu quả của việc truyền lại TCP bằng cách giảm chu kỳ truyền lại và kỹ thuật SACK cho phép TCP truyền lại nhiều gói tin bị mất trong 1 chu kỳ Người ta đã chứng minh được TCP_SACK cho phép nâng cao hiệu năng của hệ thống trong trường hợp độ trễ lớn.

Nhược điểm:

• Đòi hỏi phải sửa đổi giao thức ở cả 2 phía thu và phát.

• Do TCP không phân biệt được lỗi do đường truyền, nên trong trường hợp lỗi lớn hiệu năng TCP giảm một cách đáng kể và bắt đầu giảm cửa sổ tắc nghẽn phía phát Sử dụng TraceGraph ta thu được thông tin mô phỏng:

Hình 9: Hệ thống mạng mô phỏng TCP Sack1

Sau khi mô phỏng hoàn thành 3 trường hợp tương đương với 3 giao thức là TCP Vegas, TCP Fack và TCP Sack1 Ta có bảng so sánh sau:

Giao thức sử dụng Số segments gửi Số segments rơi Số segments mất TCP Vegas 4695 23 23

TCP Fank 4240 18 18 TCP Sack1 4303 21 21 Nhận xét:

• Cùng một cấu hình như nhau, giữa hai giao thức TCP Vegas và TCP Fank có các chỉ số tương đương nhau TCP Vegas gửi 4695 segments rơi 23 , mất 23 TCP Fank gửi ít hơn một chút là 4240 segments rơi 18, mất 23.

3 MÔ PHỎNG HỆ THỐNG MẠNG

Yêu cầu:

• Xem xét các thông lượng, số gói tin rơi, mất và độ trễ trung bình, tỷ lệ gói truyền thành công.

• So sánh hiệu năng trong trường hợp liên kết 5-6, tăng tốc Đô từ 5 lên 50 mbps, thì độ trễ trung bình là bao nhiêu

• Tại node 5, hàng đợi thay Droptail = PQ, FSQ, RED so sánh số gói tin rơi • Thay TCP = TCP RENO, hãy đánh giá thông số như câu a và so sánh hiệu năng.

Hình 10 Mô hình tổng quan

Mô hình của chúng ta gồm 6 node 0,1,2,3,4,5 Trong đó các node 2,3,4,5 là nguồn gởi, node 0 là nguồn nhận Các node 2,3,4,5 sử dụng giao thức TCP và dịch vụ FTP.

Sử dụng TraceGraph ta thu được thông tin mô phỏng như sau:

Hình 11: Thông tin mô phỏng

Thông lượng của mô hình mô phỏng khi sử dụng giao thức TCP

Hình 12 : Thông tin thông lượng

Qua các thông tin thu thập được ta thấy : - Số gói tin drop: 0

- Số gói tin mất: 82 - Số gói tin gởi: 19414

- Tỉ lệ gởi gói tin thành công: 99,578% - Độ trễ trung bình: 0.041124474002s

- Thông lượng dần ổn định từ giây thứ 2 trở đi.

Trường hợp 2: Liên kết 5-6 tăng tốc độ từ 5->50Mbps.

Sử dụng TraceGraph ta thu được thông tin mô phỏng:

Hình 13: Thông tin mô phỏng

Thông lượng khi tăng bandwidth từ 50>50 Mbps.

Hình 14: Thông tin thông lượng

Qua các thông tin thu thập được ta thấy : - Số gói tin drop: 0

- Số gói tin mất: 82 - Số gói tin gởi: 19464

- Tỉ lệ gởi gói tin thành công: 99,579% - Độ trễ trung bình: 0.04091671953

- Thông lượng dần ổn định từ giây thứ 2 trở đi.

Nhận xét:

Khi tăng băng thông của Link 5-6 lên 50Mbps thì ta nhận thấy thời gian delay trung bình giảm đi và tỉ lệ gói truyền thành công tăng lên Vậy ta có thể kết luận rằng tỉ lệ thời gian delay và gói truyền thành công tỉ lệ thuận với băng thông đường truyền.

Trường hợp 3: Tại node 5, hàng đợi thay Droptail = PQ, FQ, RED.

Cơ chế hàng đợi DropTail:Các bộ định tuyến thực hiện nhiều hàng đợi FIFO, mỗi hàng

đợi có một độ ưu tiên riêng để đảm bảo các gói tin cần được ưu tiên xử lý trước, tránh khả năng bị hủy bỏ Các gói tin có độ ưu tiên cao được truyền trước các gói tin có độ ưu tiên thấp hơn.

Sau khi dùng TraceGraph ta thu được các thông tin mô phỏng như sau:

Hình 13: Thông tin mô phỏng

- Số gói tin drop: 0 - Số gói tin lost: 82

Hàng đợi FQ:

Trong hàng đợi FIFO có thể xảy ra vấn đề có hàng chờ mãi không được phục vụ và bị tràn gói tin đến Để khắc phục nhược điểm này trong hàng đợi FairQueue các gói tin bên trong mỗi hàng đợi được truyền theo nguyên tắc FIFO, còn các hàng đợi khác nhau sẽ được truyền theo quy tắc vòng tròn (Round Robin).

Hình 14: Thông tin chi tiết

Hình 15: Biểu đồ thông lượng dùng hàng đợi FQ

Hàng đợi RED:

Cơ chế hàng đợi RED (Random Early Detection) – Dò sớm ngẫu nhiên – Khi xảy ra tăt

nghẽn RED sẽ thông báo cho trạm nguồn về tắc nghẽn bằng cách cho rơi sớm gói tin, như vậy trạm nguồn nhận biết thông qua “time out” hoặc “duplicate ACK” và trạm nguồn giảm tốc độ phát với hi vọng không phải hủy bỏ nhiều gói tin sau đó Xác suất rơi gói tin sớm phụ thuộc độ dài trung bình hàng đợi và hai ngưỡng minth, maxth Vì vậy RED rất hữu dụng trong các mạng TCP tốc độ cao để tránh tắc nghẽn

Hình 16: Thông tin mô phỏng

Hình 17: Biểu đồ thông lượng dùng hàng đợi RED

Nhận xét: Sau khi thay đổi 3 kiểu hàng đợi khác nhau (PQ, RED, FairQueue), ta thu được kết quả: việc sử dụng hàng đợi dò sớm ngầu nhiên RED và hàng đợi cân bằng FairQueue làm chi hiệu năng mạng của hệ thông được nâng cao hơn (số gói tin rơi so với tổng số gói tin gửi có giảm hơn so với việc sử dụng hàng đợi PQ).