5. Cấu trúc của luận văn
2.3.3.Giai đoạn tránh tắc nghẽn
TCP Vegas cập nhật cửa sổ tắc nghẽn của tuyến tính trong giai đoạn chống nghẽn mạng, nó là quá chậm cho một mạng có độ trễ băng thông lớn.
Tùy thuộc vào các thông tin được đưa ra bởi các dữ liệu thêm ước tính, nó là giá trị để thử một chiến lược tích cực hơn.
Đối với mỗi bước tăng cửa sổ tắc nghẽn, Quick Vegas có nguyên tắc để thay đổi kích thước cửa sổ.
- Nếu Δ <α :
CWnd = CWnd + (β - Δ) × succ. (3)
Như vậy kích thước cửa sổ tắc nghẽn sẽ được tăng (β-Δ) vào phiên đầu tiên và (β-Δ) × 2 tại phiên tiếp theo của Δ <α, và như vậy. Ý tưởng là nếu tăng thành công, nó có thể là trường hợp có đủ băng thông. Tuy nhiên, để đảm bảo rằng các cửa sổ tắc nghẽn sẽ không được tăng quá nhanh, Quick Vegas có thể tăng nhiều nhất là gấp đôi cửa sổ tắc nghẽn.
- Nếu Δ> β, Quick Vegas giảm cửa sổ tắc nghẽn:
CWnd = CWnd – (4)
- Nếu α < Δ < β: Quick Vegas sẽ xét đến giá trị (α + β)/2. + Nếu : CWnd = CWnd – 1
+ Nếu : CWnd = CWnd –
Thuật toán điều chỉnh cửa sổ của Quick Vegas có thể được trình bày với mã giả sau:
if (Δ> β)
CWnd = CWnd –
else if (Δ <α) succ = succ + 1
if ((β - Δ) × succ> CWnd)
incr = 1
else incr = × succ
else if ( ) CWnd = CWnd - 1; incr = 0; succ = 0 else if ( ) incr = ; succ = 0 else /* ( ) */ incr = 0; succ = 0
Để giảm hiệu ứng việc tăng truyền hàng loạt, biến incr được xem như số lượng tăng của cửa sổ tắc nghẽn sau mỗi ACK được nhận bởi một nguồn Quick Vegas.
2.4. Kết luận chương 2
Trong chương này, tôi đã đi sâu phân tích cơ chế hoạt động của giao thức TCP Westwood, RoVegas và Quick Vegas. Giao thức TCP Westwood cải tiến ở giai đoạn phục hồi nhanh, phân tích giao thức RoVegas cải tiến so với giao thức TCP Vegas trong trường hợp tổng quát mạng đối xứng và mạng bất đối xứng, và giao thức Quick Vegas cải tiến ở giai đoạn khởi động chậm và tránh tắc nghẽn trong môi trường có độ trễ băng thông lớn.
CHƯƠNG 3
MÔ PHỎNG VÀ ĐÁNH GIÁ HIỆU NĂNG MỘT SỐ GIAO THỨC
Để đánh giá hiệu suất hoạt động của các giao thức thông thường người ta có thể dùng các phương pháp như: Phương pháp giải tích, phương pháp thử nghiệm hoặc phương pháp mô phỏng. Trong luận văn này, tôi chọn phương pháp mô phỏng dựa trên phần mềm OMNet++ để đánh giá hiệu năng của giao thức TCP Westwood.
3.1. Đánh giá mô phỏng
3.1.1. Giả thiết và thiết lập thông số ban đầu cho quá trình mô phỏng
Kịch bản gồm 4 nút gửi client1, client2, client3, client4 cùng gửi tới server, và qua hàng đợi router với thông số truyền như sau:
- Số gói tin truyền: 10MiB
- Tốc độ truyền từ mỗi client tới router: 100Mbps, độ trễ: 2ms - Tốc độ truyền từ router tới server: 5Mbps, độ trẽ: 10ms - Hàng đợi ở router: DropTail, kích thước: 100 gói
- Độ lớn tối đa gói tin gửi : 400 gói
Kịch bản 1:
- Client1, client2, client3 truyền với giao thức TCP Westwood - Client4 truyền với giao thức UDP
Kịch bản 2:
- Client1, client2, client3 truyền với giao thức TCP Westwood - Client4 truyền với giao thức TCP Reno
Hình 3.1: Mô hình phân tích mô phỏng TCP Westwood
3.1.2. Phân tích kết quả TCP Westwood
3.1.2.1. Kịch bản 1
Quá trình mô phỏng và kết thúc được thực hiện như hình 3.2 và hình 3.3:
Hình 3.3: Kết thúc quá trình mô phỏng kịch bản 1
Như vậy, với thời gian mô phỏng T = 1s, số message được tạo ra là 5656 (message) và số message tôi sẽ tiến hành phân tích trong khoảng thời gian này là 65 (message).
Hình 3.5: Biểu đồ đo thời gian RTT
Với kịch bản này thì nút client4 chiếm hậu hết đường truyền do dùng giao thức UDP.
Bảng 3.1: Số gói tin nhận ở kịch bản 1
Số gói tin nhận
Tổng gói gửi Westwood 1 Westwood 2 Westwood 3 UDP
10485760 113604 67844 57284 10280
1.083% 0.647% 0.546% 0.098%
Bảng 3.2: Mất gói tin ở hàng đợi
Mất gói ở hàng đợi
Westwood 1 Westwood 2 Westwood 3 UDP
0 0 0 136
Bảng 3.3: Số gói tin còn ở hàng đợi sau thời gian giả lập 1s
Số gói tin còn ở hàng đợi sau thời gian giả lập 1s
Tổng gói gửi Westwood 1 Westwood 2 Westwood 3 UDP
10485760 4644 3964 560 249012
0.044% 0.038% 0.005% 2.375%
Từ bảng 3.3 tôi nhận thấy rằng trong thời gian giả lập 1s, những gói tin truyền với giao thức UDP chiếm hầu hết đường truyền và chiếm tới 2,375%
tổng gói tin ở trong hàng đợi. Tuy nhiên ở bảng 3.1 cho thấy giao thức UDP mặc dù chiếm đường truyền nhưng UDP là giao thức truyền thông không tin cậy, nó không quan tâm tới bên nhận đã nhận được gói tin hay chưa và tôi nhận thấy tỉ lệ gói tin nhận thành công thấp hơn rất nhiều so với giao thức Westwood.
Ngoài ra, trong thời gian mô phỏng đó, số gói tin bị mất vẫn xảy ra trên giao thức UDP
3.1.2.2. Kịch bản 2
Kịch bản này khác với kịch bản ở trên là client 4 sẽ được truyền với giao thức TCP Reno, client1, client2, client3 vẫn truyền với giao thức TCP Westwood.
Quá trình mô phỏng và kết thúc được thực hiện như hình 3.6 và hình 3.7:
Hình 3.7: Kết thúc quá trình mô phỏng kịch bản 2
Như vậy, với thời gian mô phỏng T = 1s, số message được tạo ra là 5622 (message) và số message tôi sẽ tiến hành phân tích trong khoảng thời gian này là 77 (message).
Hình 3.9: Biểu đồ đo thời gian RTT Bảng 3.4: Số gói tin nhận ở kịch bản 1
Số gói tin nhận
Tổng gói gửi Westwood 1 Westwood 2 Westwood 3 Reno
10485760 67844 57284 57284 57284
0.65% 0.55% 0.55% 0.55%
Bảng 3.5: Mất gói tin ở hàng đợi
Mất gói ở hàng đợi
Westwood 1 Westwood 2 Westwood 3 Reno
0 0 0 135
Bảng 3.6: Số gói tin còn ở hàng đợi sau thời gian giả lập 1s
Số gói tin còn ở hàng đợi sau thời gian giả lập 1s
Tổng gói gửi Westwood 1 Westwood 2 Westwood 3 Reno
10485760 3964 3964 3964 239696
0.038% 0.038% 0.038% 2.29%
Với mô phỏng này, từ bảng 3.6 tôi nhận thấy rằng trong thời gian giả lập 1s, những gói tin truyền với giao thức TCP Reno chiếm đường truyền hơn giao thức TCP Westwood và chiếm tới 2,29% tổng gói tin ở trong hàng đợi.
Tuy nhiên ở bảng 3.5 cho thấy giao thức TCP Reno mặc dù chiếm đường truyền và phát nhiều hơn TCP Westwood nhưng kết quả từ bảng 3.5 cho thấy tỉ lệ gói tin nhận thành công của giao thức Westwood (0,65%) hơn TCP Reno (0,55%).
Ngoài ra, trong thời gian mô phỏng đó, số gói tin bị mất vẫn xảy ra đối với giao thức TCP Reno (135 gói).
3.2. Kết luận chương 3
Trong nội dung chương này, tôi đã tiến hành mô phỏng hai kịch bản giao thức TCP Westwood hoạt động cùng giao thức UDP và giao thức TCP Westwood hoạt động cùng giao thức TCP Reno. Kết quá cho thấy giao thức UDP cũng như giao thức TCP Reno mặc dù đều chiếm đường truyền so với giao thức TCP Westwood nhưng có số gói tin nhận thành công vẫn thấp hơn TCP Westwood, tỉ lệ mất gói tin đối với giao thức UDP và TCP Reno vẫn nhiều hơn so với TCP Westwood
Phân tích mô phỏng vẫn còn hạn chế là chưa đánh giá sâu về thông lượng trên đường truyền, đánh giá về giá trị ước tính băng thông BWE của TCP Westwood để làm sáng tỏ bản chất hoạt động của TCP Westwood.
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN
Những cải tiến của giao thức TCP hiện đang là một thách thức của các nhà nghiên cứu trong việc tìm ra những cải tiến mới, giao thức mới với mục đích cuối cùng là đạt được một hệ thống mạng ổn định và hiệu suất khai thác cao trên các dịch vụ truyền thông đa phương tiện.
Qua thời gian 6 tháng nghiên cứu, tìm hiểu một số giao thức định tuyến điều khiển của TCP, luận văn đã đạt được một số kết quả:
1. Kết quả đạt được:
-Trình bày một cách tổng thể về mạng Internet, các hạn chế của TCP từ đó tìm hiểu hoạt động các giao thức cơ bản như TCP Tahoe, TCP Reno, TCP Vegas.
-Tìm hiểu, phân tích cơ chế hoạt động của giao thức TCP Westwood cải tiến ở giai đoạn phục hồi nhanh, RoVegas trong trường hợp mạng đối xứng và bất đối xứng, Quick Vegas cải tiến ở giai đoạn khởi động chậm và tránh tắc nghẽn trong môi trường có độ trễ băng thông lớn.
-Thiết kế một số mô hình mạng trên công cụ mô phỏng mạng OMNET. Cài đặt, mô phỏng giao thức TCP Westwood để minh họa cách thức hoạt động.
2. Hướng phát triển:
-Tiếp tục nghiên cứu mở rộng của một số giao thức TCP Westwood+, QuickVegas, RoVegas trên môi trường di động tốc độ cao.
TÀI LIỆU THAM KHẢO Tiếng Việt:
1. Võ Thanh Tú, (2012), Giáo trình sau Đại Học Mạng và truyền dữ liệu
nâng cao, Nhà xuất bản Đại Học Huế.
2. Võ Thanh Tú, Hoàng Hữu Hạnh, (2003), Giáo trình mạng máy tính, Đại học khoa học Huế.
Tiếng Anh:
3. C. Casetti, S. Mascolo, M. Gerla, S. S. Lee, M. Sanadidi, (2000), “TCP Westwood: congestion control with faster recovery”, Computer Science
Department – UCLA Los Angeles, CA, 90024.
4. Claudio Casetti, Mario Gerla, Saverio Masscolo, M.Y.Sanadidi and Ren Wang, (2002), “TCP Westwood: End-to-End Congestion Control for Wired/Wireless Networks”, Kluwer Academic Publishers. Manufactured
in The Netherlands
5. Chia-Tai Chanb, Yi-Cheng Chana, Yaw-Chung Chena, (2004), “RoVegas: a router-based congestion avoidance mechanism for TCP Vegas”,
Computer Communications 27 (2004) 1624–1636.
6. Chia-Liang Lin, Yi-Cheng Chan, Cheng-Yuan Ho, (2008), “Quick Vegas: Improving Performance of TCP Vegas for High Bandwidth-Delay Product Networks”, IEICE Trans. Commun., Vol.E91–B, No.4 April 2008.
7. OpenSim and András Varga OpenSim Ltd, (2011), “OMNeT++ User Guide Version 4.3”, (2011), available at http://www.omnetpp.org/. 8. “INET Framework for OMNeT++”, http://www.omnetpp.org/
9. Jeroen Idserda, (2004), “TCP/IP modelling in OMNeT++”.
10. Travis Andelin, Randy Buck, Rich Lee, “Using OMNET++ to Simulate TCP”, Department of Computer Science Brigham Young University Provo, UT 84602.
1. Giới thiệu chung về OMNeT++
OMNeT++ là viết tắt của cụm từ Objective Modular Network Testbed in C++.OMNeT++ là một ứng dụng cung cấp cho người sử dụng môi trường để tiến hành mô phỏng hoạt động của mạng. Mục đích chính của ứng dụng là mô phỏng hoạt động mạng thông tin, tuy nhiên do tính phổ cập và linh hoạt của nó, OMNeT++ còn được sử dụng trong nhiều lĩnh vực khác như mô phỏng các hệ thống thông tin phức tạp, các mạng kiểu hàng đợi (queueing networks) hay các kiến trúc phần cứng.
OMNeT++ cung cấp sẵn các thành phần tương ứng với các mô hình thực tế. Các thành phần này (còn được gọi là các module) được lập trình theo ngôn ngữ C++, sau đó được tập hợp lại thành những thành phần hay những mô hình lớn hơn bằng một ngôn ngữ bậc cao (NED).
OMNeT++ hỗ trợ giao diện đồ hoạ tương ứng với các mô hình cấu trúc của nó đồng thời phần nhân mô phỏng (simulation kernel) và các module của OMNeT++ cũng rất dễ dàng nhúng vào trong các ứng dụng khác.
Một mô hình trong OMNeT++ bao gồm các module lồng nhau có cấu trúc phân cấp. Độ sâu của của các module lồng nhau là không giới hạn, điều này cho phép người sử dụng có thể biểu diễn các cấu trúc logic của các hệ thống trong thực tế bằng các cấu trúc mô hình. Các module trao đổi thông tin với nhau thông qua việc gửi các message. Các message này có thể có cấu trúc phức tạp tuỳ ý. Các module có thể gửi các message này theo hai cách, một là gửi trực tiếp tới địa chỉ nhận, hai là gửi đi theo một đường dẫn được định sẵn, thông qua các cổng và các kết nối.
topology của mô
hình. Các module ở mức thấp nhất trong cấu trúc phân cấp đóng gói các thuộc tính. Các module này được coi là các module đơn giản, và chúng được lập trình trong ngôn ngữ C++ bằng cách sử dụng các thư viện mô phỏng.
Cấu trúc phân cấp của các module
Một mô hình trong OMNeT++ chứa các module lồng nhau có cấu trúc phân cấp, trao đổi thông tin với nhau bằng cách gửi các message. Cấu trúc của mô hình có thể được mô tả bằng ngôn ngữ NED của OMNeT++.
Cấu trúc phân cấp module trong OMNeT++
Các module có thể chứa nhiều module con và được gọi là module kết hợp. Các module đơn giản là các module có cấp thấp nhất trong cấu trúc phân cấp. Các module đơn giản chứa các thuật toán của mô hình. Người sử dụng triển khai các module đơn giản bằng ngôn ngữ C++, sử dụng các thư viện mô phỏng của OMNeT++.
Message, cổng, liên kết
Các module trao đổi thông tin bằng việc gửi các message. Trong thực tế, message có dạng khung (frame) hoặc là các gói tin (packet) được truyền đi trong mạng. Các message có thể có cấu trúc phức tạp tuỳ ý. Các module đơn
“Thời gian mô phỏng địa phương” (local simulation time) của một module tăng lên khi module nhận được một message. Message có thể đến từ một module khác hoặc đến từ cùng một module (message của chính bản thân module - self-message được dùng để thực hiện bộ định thời). Cổng (gate) là các giao tiếp vào ra của module. Message được gửi đi qua các cổng ra và được nhận vào thông qua các cổng vào. Mỗi kết nối (connection) hay còn gọi là liên kết (link) được tạo bên trong mức đơn trong cấu trúc phân cấp của các module: bên trong một module kết hợp, một kết nối có thể được tạo ra giữa các cổng tương ứng của hai module con, hoặc giữa cổng của module con với cổng của module kết hợp.
Các kết nối trong OMNeT++
Mô hình truyền gói tin:
Một kết nối có thể có ba tham số đặc trưng. Những tham số này rất thuận tiện cho các mô hình mô phỏng mạng thông tin nhưng không hữu dụng lắm cho các kiểu
mô hình khác. Ba tham số này bao gồm:
• Độ trễ đường truyền (propagation delay) tính bằng s - giây. • Tỉ số lỗi bit, được tính bằng số lỗi/bit.
kênh truyền - channel
type). Độ trễ đường truyền là tổng thời gian đến của message bị trễ đi khi truyền qua kênh. Tỉ số lỗi bit ảnh hưởng đến quá trình truyền message qua kênh. Tỉ số này là xác suất các bit bị truyền sai. Do đó xác suất để một message độ dài n bit truyền đi chính xác là: P (message gửi đi được nhận chính xác) = (1 - ber)n, trong đó ber là tỉ số lỗi bit và n là số bit của message.
Các message truyền đi đều có một cờ lỗi, cờ này sẽ được thiết lập khi việc truyền message có lỗi. Tỉ số dữ liệu được tính theo đơn vị bit/s, và nó được sử dụng để tính thời gian để truyền một gói tin. Khi tỉ số này được sử dụng, quá trình gửi message đi trong mô hình sẽ tương ứng với việc truyền bit đầu tiên và message được tính là đến nơi sau khi bên nhận đã nhận được bit cuối cùng.
Xây dựng và chạy thử các mô hình mô phỏng
Một mô hình OMNeT++ bao gồm những phần sau:
• Ngôn ngữ mô tả topology - NED (file có phần mở rộng .ned): mô tả cấu trúc của module với các tham số, các cổng... Các file .ned có thể được viết bằng bất kỳ bộ soạn thảo hoặc sử dụng chương trình GNED có trong OMNeT++.
• Định nghĩa cấu trúc của các message (các file có phần mở rộng .msg): Người sử dụng có thể định nghĩa rất nhiều kiểu messsage và thêm các trường dữ liệu cho chúng. OMNeT++ sẽ dịch những định nghĩa này sang các lớp C++ đầy đủ.
• Mã nguồn của các module khá đơn giản. Đây là các file C++ với phần mở rộng là .h hoặc .cc.
• Trong Windows: các file .cpp lien kết thành file .obj.
Sau đó, tất cả các file trên sẽ được liên kết (link) với các thư viện cần thiết để tạo thành file .exe.
Chạy các ứng dụng mô phỏng bằng OMNeT++:
Ta thực hiện đánh hai lệnh sau:
opp_nmakemake để tạo ra Makefile.vc Để tạo file chạy ta gõ: nmake -f Makefile.vc.
2.Cài đặt TCP Westwood, TCP Vegas
- Điều kiện để cài đặt và sử dụng TCP Westwood trong OMNet++