Trace là lớp đối tượng được sử dụng để ghi lại cỏc sự kiện trong chương trỡnh mụ phỏng ra một file hoặc đưa ra một hàm Tcl. Nú khụng cú biến trạng thỏi hay tham số cấu hỡnh mà chỉ cú ba phương thức :
$trace attach fileID: Gắn một file vào đối tượng trace để ghi lại cỏc sự kiện. fileID phải là một thẻ file được trả về bởi lệnh open của Tcl và phải được mở với chế độ cú thể ghi. File này được gọi là file trace (file theo dừi)
$trace detach : tỏch rời file khỏi đối tượng trace. Cỏc sự kiện sau này sẽ khụng được ghi vào file đú nữa.
$trace callback proc : Đặt chế độ để tự động gọi hàm proc (hàm Tcl) mỗi khi cú một sự kiện được ghi nhận bởi đối tượng trace. Cả fileID và proc
cựng cú thể hoạt động đồng thời. Việc gọi proc mỗi khi cú sự kiện được ghi nhận sẽ làm cho chương trỡnh mụ phỏng chạy chậm hơn.
Cỏc sự kiện được ghi vào file dưới dạng văn bản, mỗi dũng tương ứng với một sự kiện và cú cấu trỳc như sau :
<code><time><hsrc><hdst><packet>
Trong đú :
<code> là một trong cỏc kớ tự 'rd+-' tương ứng với cỏc sự kiện nhận được gúi tin (receive), loại bỏ gúi tin (drop), đưa vào hàng đợi (queue) và đưa ra khỏi hàng đợi (dequeue), tức là truyền đi.
<time> là thời điểm sự kiện xảy ra, tớnh theo giõy (s)
<hdst> là địa chỉ của nỳt mạng thứ hai của kết nối truyền gúi tin.
<packet> cú cấu trỳc:
<type><size><flag><class><src.sport><dst.dport><seqNum><pktID>
Trong đú:
<type> là loại gúi tin, bao gồm cỏc loại tcp,telnet,cbr,ack,...
<size> là kớch thước gúi tin tớnh theo byte
<flag> là cờ, bao gồm một số bit trạng thỏi như bit cảnh bỏo tắc nghẽn (C), bit đặt mức ưu tiờn (P),...
<class> là số nhận dạng (ID) của lớp
<scr.sport> là địa chỉ lớp giao vận của TCP nguồn, bao gồm địa chỉ TCP nguồn và địa chỉ cổng của TCP nguồn.
<dst.dport> là địa chỉ lớp giao vận của TCP đớch, cấu trỳc như địa chỉ TCP nguồn.
<seqNum> là số thứ tự của gúi tin
<pktID> là số nhận dạng của gúi tin.
Ngoài ra đối với gateway RED (và cỏc biến thể của RED) cũn cú file theo dừi hàng đợi với cấu trỳc mỗi hàng (mỗi sự kiện) như sau:
Trong đú :
<code> là mó sự kiện, [Q] là kớch thước hàng đợi tức thời, [a]là kớch thước hàng đợi trung bỡnh.
<time> là thời điểm ghi nhận sự kiện
<value> là giỏ trị tương ứng của a hoặc Q, tớnh theo byte nếu RED hoạt động ở chế độ byte và theo gúi tin nếu RED hoạt động ở chế độ gúi tin.
3.3 Cỏc bƣớc xõy dựng một chƣơng trỡnh mụ phỏng
Xõy dựng một chương trỡnh mụ phỏng mạng trờn NS-2 đầu tiờn cần tạo cỏc lớp đối tượng cũng như cỏc phương thức của nú trong C++, biờn dịch và đưa vào sử dụng với OTcl. Sau đú cần tạo một kịch bản trờn Tcl để diễn tả chương trỡnh mụ phỏng. Ở đõy chỉ đề cập đến giai đoạn tạo kịch bản Tcl, vỡ cỏc đối tượng sử dụng trong luận văn này đều đó được xõy dựng trờn NS-2. Tạo một kịch bản mụ phỏng trờn Tcl gồm cỏc bước chớnh sau:
1. Thiết lập topology mạng.
2. Thiết lập cỏc tham số cấu hỡnh cho cỏc đối tượng trong mạng 3. Sắp xếp, lờn lịch cỏc hoạt động của cỏc đối tượng.
Trong kịch bản sử dụng cỏc lệnh của NS-2 hoặc cỏc phương thức của cỏc đối tượng trong mạng. Cỏc lệnh hay dựng của NS-2 bao gồm :
$ns node: tạo một nỳt mạng
$ns link node1 node2 type : tạo kết nối giữa hai nỳt mạng node1, node2
với kiểu quản lớ hàng đợi type.
$ns at time proc : tại thời điểm time thực hiện hàm proc.
Ngoài ra cũn một số lệnh cơ bản khỏc của NS-2 như now, trace, random, run,... Cỏc phương thức của cỏc đối tượng tựy thuộc lớp của nú. Cú những cụng việc (lệnh) cú thể được diễn tả bằng lệnh của NS-2 hoặc phương thức của đối tượng đều được. Chỳng ta xem xột cụ thể cỏc bước này thụng qua một vớ dụ đơn giản trong trang kế tiếp. Cỏc vớ dụ phức tạp hơn chớnh là cỏc thớ nghiệm trong luận văn này, được liệt kờ trong phần phụ lục.
3.4 Khảo sỏt và đỏnh giỏ kết quả mụ phỏng
Kết quả mụ phỏng được ghi lại trong cỏc file trace. Cú nhiều cỏch xử lớ dữ liệu này như sử dụng chương trỡnh NAM trong bộ NS-2 để quan sỏt cỏc sự kiện được ghi lại này một cỏch trực quan. NAM khụng chỉ thể hiện cỏc sự kiện theo thời gian, mà cũn cho phộp thay đổi tốc độ chạy. Tuy nhiờn để cú thể xem được quỏ trỡnh mụ phỏng trờn NAM cần bổ xung một số lệnh vào kịch bản Tcl như cỏc lệnh đặt hướng của kết nối, màu của cỏc loại gúi tin, tạo file trace cho NAM... Ngoài ra cú thể sử dụng cỏc tiện ớch xgraph, gnuplot để vẽ đồ thị thể hiện một số thụng số. Để sử dụng cỏc tiện ớch này cần viết một đoạn mó lệnh chuyển file trace sang dạng file phự hợp với tiện ớch muốn sử dụng.
Phần quan trọng nhất của chương trỡnh mụ phỏng là tạo ra file kết quả, sau đú phõn tớch kết quả thỡ cú thể dựng bất cứ cỏch nào cũng được. Trong luận văn này em sử dụng Matlab làm cụng cụ phõn tớch kết quả. Lớ do là em cú thể làm tốt hơn trờn Matlab, và Matlab cú thể vẽ hỡnh đẹp hơn so với
Tạo một đối tượng NS mới
set ns [new Simulator]
Mở một file để ghi lại cỏc sự kiện
set f [open all.tr w]
Lệnh ghi cỏc sự kiện vào file đó mở
$ns trace-all $f Tạo ba nỳt mạng set s1 [$ns node] set s2 [$ns node] set s3 [$ns node] Tạo một gateway phỏt set G [$ns node]
Tạo một gateway thu
set r [$ns node]
Tạo cỏc kết nối để thiết lập topology mạng
$ns duplex-link $s1 $G 50Mb 5ms DropTail $ns dplex-link $s2 $G 55Mb 6ms DropTail $ns duplex-link $s3 $G 65Mb 7ms DropTail $ns duplex-link $G $r 2Mb 25ms DropTail Đặt một số tham số cấu hỡnh $ns queue-limit $G $r 15
Tạo một nguồn truyền tin và gắn vao nut mạng s1
set tcp1 [new Agent/TCP] $ns attach-agent $s1 $tcp1
Đặt một số tham số cấu hỡnh cho nguồn truyền tin này
$tcp1 set window_ 32 $tcp1 set fid_ 1
Tạo một đớch truyền tin và gắn vào nỳt r
set sink1 [new Agent/TCPSink] $ns attach-agent $r $sink1
Tạo một đường truyền tin
$ns connect $tcp1 $sink1
Tạo một ứng dụng phỏt dữ liệu và gắn vào TCP nguồn
set ftp1 [new Application/FTP] $ftp1 attach-agent $tcp1 Hàm kết thỳc proc finish {} { global ns $ns flush-trace exit 0 }
Lờn lịch cho ftp1 bắt đầu truyền tin từ 0.1s và kết thỳc lỳc 7.0s
$ns at 0.1 "$ftp1 start" $ns at 7.0 "$ftp1 stop" $ns at 7.25 "finish"
Ra lệnh chạy mụ phỏng
Chương này đó giới thiệu về NS-2 và sơ qua về cỏch thức hoạt động của nú, cũng như việc tạo ra một kịch bản để mụ phỏng. Như đó trỡnh bày bờn trờn, NS-2 là một phần mềm mụ phỏng mạng rất mạnh và mềm dẻo cả về cỏch viết chương trỡnh cũng như khả năng mở rộng thờm cỏc giao thức mới, cỏc thuật toỏn mới,... NS-2 cũng khỏ đơn giản để bắt đầu và khỏ phức tạp nếu muốn nắm thật vững về cỏc thành phần, lớp đối tượng của nú. Tuy nhiờn trong phậm vi của một chương luận văn khụng thể giới thiệu quỏ chi tiết về NS-2 được. Nếu muốn viết một giao thức mới, một thuật toỏn mới,... người dựng cần tỡm hiểu thờm về NS-2 thụng qua cỏc tài liệu hướng dẫn khỏc. Tỡm hiểu sõu về phần mềm này là một cụng việc rất hữu ớch trong việc nghiờn cứu về mạng. Nhờ nú mà cú thể hiểu thờm về cỏc giao thức, cỏc thuật toỏn đó cú, cũng như kiểm tra, đỏnh giỏ một ý tưởng mới để cú thể đi đến ỏp dụng vào thực tiễn.
CHƢƠNG 4
Mễ PHỎNG VÀ ĐÁNH GIÁ
CÁC THUẬT TOÁN ĐIỀU KHIỂN TẮC NGHẼN TRấN TCP
Trong chương I đó trỡnh bày lớ thuyết về cỏc thuật toỏn điều khiển tắc nghẽn mạng trờn TCP, bao gồm 4 thuật toỏn Tahoe, Reno, NewReno và Vegas. Nhằm làm rừ hơn những gỡ đó nờu trong chương I, chương này sẽ trỡnh bày cỏc kết quả mụ phỏng trờn NS-2, trong đú tập trung vào giải thớch cỏc bước, cỏc giai đoạn trong cỏc thuật toỏn và cố gắng chỉ ra được ưu nhược điểm của cỏc thuật toỏn.
Cỏc thớ nghiệm đều dựng topology mạng trong hỡnh 4.1. Hàng đợi trờn kết nối G-SINK là loại DropTail. Cỏc thớ nghiệm mụ tả cỏc bước trong cỏc thuật toỏn được tiến hành trong 5s, mục đớch là để số gúi tin ớt, dễ quan sỏt trờn hỡnh. Cỏc thớ nghiệm quan sỏt sự biến đổi của thụng lượng hay cwnd
được tiến hành trong 25s, quỏ trỡnh quan sỏt dài hơn dễ quan sỏt sự biến động của cỏc thụng số này hơn. Chương trỡnh nguồn của thớ nghiệm được liệt kờ trong phần phụ lục.
Hỡnh 4.1 : Topology mạng
4.1 Thuật toỏn Tahoe
Trong thớ nghiệm này, kớch thước hàng đợi được đặt là 20, kớch thước cửa sổ truyền cực đại là 47. Hỡnh 4.2 thể hiện quỏ trỡnh truyền tin của Tahoe. Trong hỡnh này mỗi ụ vuụng nhỏ thể hiện cho sự kiện TCP nguồn truyền một gúi tin, tọa độ của ụ vuụng thể hiện thời gian truyền trờn trục hoành, số thứ tự gúi tin trờn trục tung; mỗi ụ tam giỏc thể hiện sự kiện TCP nguồn nhận được một ACK với thời gian và số thứ tự gúi tin được ACK tương ứng với tọa độ; sự kiện gateway loại bỏ gúi tin được thể hiện bằng một dấu "X" với thời gian và số thứ tự gúi tin bị loại bỏ thể hiện qua tọa độ. Số thứ tự gúi tin được chia lấy dư cho 60 nhằm làm cho kết quả dễ quan sỏt hơn. Kiểu thể hiện này sẽ được dựng trong cỏc thớ nghiệm mụ tả hoạt động sau này. Sự biến đổi của
cwnd được thể hiện trong hỡnh 4.3 với hai kếtquả chạy 5s và 25s.
Trờn hỡnh 4.2 ta cú thể quan sỏt được cỏc giai đoạn slow-start, CA cũng như kĩ thuật fast retransmit của Tahoe. Giai đoạn slow-start thứ nhất bắt đầu từ 0.1 và kết thỳc ở khoảng 2s, khi Tahoe nhận được ACK lặp thứ 3 của gúi tin 91, lỳc này cwnd đang cú giỏ trị là 48. Ngay sau đú fast retransmit được kớch hoạt, gúi tin 91 được truyền đi và Tahoe bước vào giai đoạn slow-start
thứ hai với ngưỡng ssthresh=24. Sau khi cwnd đạt được giỏ trị 24 ở khoảng 3.35s, giai đoạn slow-start thứ 2 này được kết thỳc và Tahoe chuyển sang giai đoạn CA.
Ta cú thể thấy trong giai đoạn slow-start, cwnd được tăng gấp đụi sau mỗi RTT, khoảng 230ms. Trong khoảng thời gian 0-1.6s, với mỗi ACK nhận được Tahoe lập tức truyền liờn tiếp 2 gúi tin. Tốc độ truyền trờn kết nối TCP- G lớn khiến cho thời gian truyền của mỗi gúi tin khỏ nhỏ và hai gúi tin nhỡn trờn hỡnh gần như được truyền cựng thời gian. Sau 5 RTT (tới khoảng 1.3s),
giỏ trị của cwnd đó tăng từ 1 lờn đến 32. Trong RTT tiếp theo, cwnd được tăng thờm
Hỡnh 4.3 : Sự biến đổi của cwnd của Tahoe
2 mỗi khi nhận được một ACK, và đỏng ra cú thể tăng lờn 64. Tuy nhiờn sau khi nhận được ACK 45 ở 1.6s, Tahoe truyền hai gúi tin 91 và 92, sau đú cwnd
tăng lờn đến 47 thỡ đạt giỏ trị cực đại của cửa sổ, do đú sau này cwnd khụng tăng thờm 1 sau mỗi ACK nữa mà tăng thờm 1 sau mỗi RTT, và gúi tin 91 được sử dụng làm mốc để tớnh RTT. Từ đõy Tahoe chỉ truyền một gúi tin mới mỗi khi nhận được một ACK. Đến khoảng 1.96s, Tahoe nhận được ACK 91, bỏo hiệu đó hết một RTT và cwnd được tăng lờn 48, chỉ một gúi tin 138 được truyền đi mà khụng phải là 2 gúi tin. Nguyờn nhõn là do mặc dự cwnd tăng lờn 48 nhưng kớch thước cửa sổ tối đa (tương ứng với credit) là 47, nờn số gúi tin được phộp truyền mà khụng cần ACK bõy giờ được quyết định bởi giỏ trị 47 chứ khụng phải bởi cwnd.
Nhận được thờm 2 ACK lặp cho gúi tin 91 tiếp theo, nhưng Tahoe khụng thể truyền thờm một gúi tin nào nữa do đó sử dụng hết cửa sổ. Số gúi tin Tahoe được phộp truyền mà khụng phải đợi ACK là 47, và đó cú 47 gúi tin từ
92-138 chưa cú ACK. Khi nhận được ACK lặp thứ 3 của gúi tin 91 ở khoảng 1.99s, Tahoe coi như gúi tin 92 đó mất và khởi động fast retransmit, truyền lại gúi tin 92, đặt ssthresh=48/2=34, đồng thời hạ cwnd về 1. Trước khi nhận được ACK lũy tớch cho gúi tin 138, bao hàm ACK của gúi tin 92, Tahoe nhận được thờm 43 ACK lặp cho gúi tin 91 nữa, nhưng fast retransmit khụng được thiết kế để phản ứng với cỏc ACK lặp này, nờn Tahoe khụng làm gỡ khỏc ngoài việc đợi ACK cho gúi tin 92.
Ngay khi nhận được ACK 138 ở 2.35s, Tahoe bắt đầu một giai đoạn
slow-start mới với ngưỡng kết thỳc của cwnd là 24. Đến 3.32s, sau khi nhận ACK 159, cwnd tăng thờm 1 và đạt giỏ trị 24, giai đoạn slow-start được kết thỳc và Tahoe bước vào giai đoạn CA. Trong giai đoạn này, Tahoe truyền một gúi tin mới mỗi khi nhận được một ACK thường và cwnd khụng tăng thờm 1. Tuy nhiờn sau mỗi RTT, cwnd tăng thờm 1, và do cũn nhỏ hơn giỏ trị 47 của cửa sổ cực đại, nờn mỗi khi cwnd tăng thờm 1, Tahoe truyền liờn tiếp 2 gúi tin. Trờn hỡnh 4.4 ta cú thể quan sỏt rừ hơn điều này. Hai sự kiện truyền hai gúi tin liờn tiếp cỏch nhau chừng 230ms, tương ứng với 1 RTT.
Hỡnh 4.4 : Phúng to một vựng của hỡnh 4.2
Sự biến đổi cwnd trong hỡnh 4.3 và 4.4 thể hiện tương ứng với cỏc sự kiện trong hỡnh 4.2. cwnd tăng theo dạng hàm mũ từ 1 ở 0.1s và đạt 47 ở 1.6s. Sau đú khoảng 320ms, ở 1.92s, cwnd được tăng lờn 48. Giỏ trị RTT ở giai đoạn này được tăng lờn 320ms do sự tắc nghẽn tại G. Đến 2s cwnd bị giảm về 1 do fast retransmit. Sau đú cwnd tăng theo hàm mũ trong khoảng 2.35-3.32s. Sau 3.32s, cwnd tăng tuyến tớnh với độ dốc tương ứng với RTT - 1/230ms. RTT ở đõy đó trở lại giỏ trị gần đỳng hơn do hoạt động của mạng đó đi vào trạng thỏi ổn định. Cwnd tiếp tục tăng lờn trong 20s tiếp theo, nhưng thụng lượng khụng tăng lờn do vẫn bị hạn chế bởi kớch thước cửa sổ tối đa.
4.2 Thuật toỏn Reno
Reno hoạt động tốt trong trường hợp chỉ mất một gúi tin trong một cửa sổ. Ngoài ra trong fast recovery cũn cho phộp truyền thờm cỏc gúi tin mới mỗi khi nhận được ACK lặp mới. Tuy nhiờn cũng cú tỡnh huống do hạn chế bởi kớch thước cửa sổ tối đa nờn fast recovery khụng truyền được thờm gúi tin nào cho dự nhận thờm rất nhiều ACK lặp. Một tỡnh huống như vậy sẽ được minh họa trong thớ nghiệm này.
Reno hoạt động kộm hiệu quả trong trường hợp cú nhiều hơn 1 gúi tin bị mất trong cựng cửa sổ. Trong tỡnh huống này, thường là Reno sẽ phải đợi timeout rồi tiến hành khởi động lại slow-start, trong khi Tahoe khởi động lại
slow-start ngay nờn hiệu quả hơn. Sau khi truyền lại gúi tin bị mất và nhận được ACK cho gúi tin đú, fast recovery cho phộp Reno chuyển vào CA ngay với cwnd bằng một nửa mà khụng phải khởi động lại slow-start, cho phộp thụng lượng cao hơn. Tuy nhiờn điều này khụng hẳn đó tốt trong một số tỡnh huống. Vỡ truyền liờn tiếp với số lượng gúi tin lớn, Reno cú thể làm tràn hàng đợi tại nỳt mạng gần nú, khiến cho một số gúi tin cú thể bị mất, và hiệu quả khi đú thậm chớ cú thể kộm hơn so với việc khởi động lại slow-start ngay như trong Tahoe. Trong thớ nghiệm này cũng minh họa một tỡnh huống như vậy.
Trong phần này em sẽ trỡnh bày hai thớ nghiệm chớnh: một thớ nghiệm thể hiện sự thành cụng của Reno trong trường hợp mất một gúi tin và một thớ