5. Penarikan Kesimpulan
2.6. Random Early Drop (RED)
Pada antrian DropTail, router mengisi antriannya sebanyak mungkin sampai antriannya penuh, dan akan membuang paket baru yang tidak bisa mengantri. RED memonitoring rata-rata queue size dan paket drop berdasarkan probabilitas tertentu. Ketika antrian/buffer hampir kosong, semua paket yang datang akan diterima. Saat antriannya meningkat, probabilitas untuk membuang paket yang datang juga akan meningkat. Ketika buffer penuh, nilai probabilitasnya menjadi 1 dan semua paket yang datang akan didrop.
Gambar 2.7 Mekanisme Random Early Drop
RED bekerja dalam 3 fase. Ketika nilai rata-rata queue sizenya lebih kecil dari minimum treshold (minTresh), semua paket yang datang diterima di antrian; ketika nilai rata-rata queue sizenya diantara minTresh dan maximum treshold (maxTresh), RED membuang paket berdasarkan probabilitas yang dihitung berdasarkan rata-rata queue size dan jumlah paket yang ditransmisikan sejak paket terakhir yang didrop; ketika nilai rata-rata queue sizenya melebihi dari nilai
maxTresh, semua paket yang datang akan dibuang (gambar 2.6.2 dan 2.6.3).
Dengan demikian RED memonitor rata-rata queue size untuk mendeteksi
congestion dengan secara random membuang paket yang datang sehingga Congestion control TCP akan lebih sering terjadi untuk menyetabilkan flow.
15
Gambar 2.8 Algoritma Random Early Drop
16
BAB III
METODE PENELITIAN
3.1. Topologi Simulasi
Topologi yang digunakan adalah topologi dumb-bell, dengan 2 node pengirim, 2 node sebagai router, dan 2 node penerima. Topologi ini digunakan untuk mengamati dan mempelajari kinerja tcp melalui bottleneck pada node 2.
Gambar 3.1 Topologi Simulasi
3.2. Parameter Simulasi
Pada penelitian ini sudah ditentukan parameter-parameter jaringan. Parameter-parameter bersifat konstan atau tetap yang akan digunakan untuk simulasi TCP Sack dan TCP Reno menggunakan antrian DropTail dan RED adalah sebagai berikut:
Tabel 3.1 Parameter tetap dalam skenario RED Parameter Simulasi Nilai
Waktu simulas 300 detik
Jumlah host 4
Link Node n0-n2 Bandwidth : 15 Mb ; Delay : 20 ms Link Node n1-n2 Bandwidth : 5 Mb ; Delay : 20 ms Link Node n2-n3 Bandwidth : 1 Mb ; Delay : 50 ms Link Node n3-n4 Bandwidth : 5 Mb ; Delay : 10 ms
17
Link Node n3-n5 Bandwidth : 5 Mb ; Delay : 10 ms Protocol Transport TCP Sack & TCP Reno
Traffic source TCP vs UDP
Ukuran Buffer 40
Constant Bit Rate Paket Size : 210 ; Rate : 300kbps
TCP Windows 50
Min Tresh 10, 15, 20
Max Tresh 30
Tabel 3.2 Parameter tetap dalam skenario DropTail Parameter Simulasi Nilai
Waktu simulas 300 detik
Jumlah host 4
Link Node n0-n2 Bandwidth : 15 Mb ; Delay : 20 ms Link Node n1-n2 Bandwidth : 5 Mb ; Delay : 20 ms Link Node n2-n3 Bandwidth : 0.5 Mb ; Delay : 30 ms Link Node n3-n4 Bandwidth : 5 Mb ; Delay : 10 ms Link Node n3-n5 Bandwidth : 5 Mb ; Delay : 10 ms Protocol Transport TCP Sack & TCP Reno
TCP Window Size 40
Traffic source TCP vs UDP
Ukuran Buffer 20, 30, 40
Constant Bit Rate Paket Size : 500 ; Rate : 448kbps CBR start in 0,5s – 15s, 20s – 30s, 40s – 50s, 60s –
70s, 80s – 90s, 100s – 110s, 120s – 130s, 140s – 150s, 160s – 170s, 180s – 190s, 200s – 210s, 220s – 230s, 240s – 250s, 260s – 270s, 280s – 300s.
18 3.3. Skenario Simulasi 3.3.1. Skenario RED n0 n1 n2 n3 n4 n5 15 Mb ; 20ms 5 Mb ; 20ms 1 Mb ; 50ms 5 Mb ; 10ms 5 Mb ; 10ms TCP TCP Sink UDP Null RED Gateway
Gambar 3.2 Skenario Random Early Drop (RED)
Skenario RED ini akan menguji bagaimana Congestion Control pada TCP Reno dan TCP Sack mengatasi paket yang didrop secara random menggunakan topologi dumb-bell. Simulasi ini dimulai dengan menjalankan traffic FTP dari n0 menuju ke n4 dan traffic CBR dari n1 menuju ke n5 sebagai traffic pengganggu. Simulasi ini menggunakan nilai tetap dari
maxTresh = 30 dan queue size = 40 dari serta Bandwidth dan Delay yang
tetap dengan minTreshold RED yang berbeda-beda. Probabilitas paket yang didrop akan terus meningkat apabila rata-rata queue sizenya semakin mendekati maxTresh dari RED. Probabilitas paket yang didrop akan semakin meningkat pula apabila jarak antara minTresh dan maxTresh semakin dekat. Dengan paket drop yang random, maka drop paket yang bersebelahan akan lebih sedikit kemungkinan keluarnya sehingga TCP Reno dan Sack dapat menggunakan algoritma Congestion Control masing-masing TCP untuk mengatasi paket drop yang random.
19 3.3.2. Skenario DropTail n0 n1 n2 n3 n4 n5 15 Mb ; 20ms 5 Mb ; 20ms 0.5 Mb ; 30ms 5 Mb ; 10ms 5 Mb ; 10ms TCP TCP Sink UDP Null DropTail Gateway
Gambar 3.3 Skenario DropTail
Skenario DropTail ini akan menguji bagaimana Congestion Control & Congestion Avoidance TCP Reno dan TCP Sack mengatasi paket yang didrop secara burst (bersebelahan) menggunakan topologi dumb-bell. Simulasi ini dimulai dengan menjalankan traffic FTP dari n0 menuju ke n4 dan traffic CBR dari n1 menuju ke n5 sebagai traffic pengganggu. Simulasi ini menggunakan nilai tetap dari Bandwidth dan Delay dengan max queue
size DropTail yang berbeda-beda. Traffic CBR akan mengganggu flow
jaringan setiap 10 detik sekali agar paket dapat membanjiri antrian. Paket drop yang dihasilkan dari antrian DropTail akan bersebelahan karena semua paket yang datang akan didrop ketika antrian sudah mencapai kapasitas maksimalnya. Dengan paket drop yg bersebelahan, peneliti akan menguji
Congestion Control dari TCP Reno dan TCP Sack untuk melihat reaksi
20 3.4. Parameter Kinerja
3.4.1. Paket Loss
Packet loss didefinisikan sebagai kegagalan transmisi paket data mencapai tujuannya. Kegagalan paket tersebut mencapai tujuan, dapat disebabkan oleh beberapa kemungkinkan, di antaranya yaitu:
a) Terjadinya overload trafik didalam jaringan, b) Tabrakan (congestion) dalam jaringan, c) Error yang terjadi pada media fisik,
d) Kegagalan yang terjadi pada sisi penerima antara lain bisa disebabkan karena overflow yang terjadi pada buffer.
Di dalam implementasi jaringan IP, nilai packet loss ini diharapkan mempunyai nilai yang minimum. Secara umum biasanya terdapat pengkategorian performansi jaringan berdasarkan nilai packet loss yaitu sangat bagus, bagus, jelek, dan sedang.
3.4.2. Congestion Window
Congestion window adalah satuan dari jumlah paket yang dapat
dikirim oleh TCP. Setiap memulai pengiriman data dari suatu konesi, nilai
Congestion Window akan diset menjadi 1 sehingga Sender hanya bisa
mengirimkan 1 segment untuk sekali kirim. Pada fase Slow Start (ss) di TCP
Congestion Control, nilai cwnd akan naik secara exponensial ketika
mendapatkan Acknowledgement (ack), sehingga Sender dapat mengirimkan
segment lebih banyak dalam satu waktu.
3.4.3. Average Throughput
Rumus untuk menghitung Throughput adalah jumlah bit data per waktu unit yang dikirimkan ke terminal tertentu dalam suatu jaringan, dari node jaringan, atau dari satu node ke yang lain. Biasanya throughput selalu dikaitkan dengan bandwidth. Throughput adalah rata-rata data yang dikirim
21
dalam suatu jaringan, biasa diekspresikan dalam satuan bitpersecond (bps),
byte persecond (Bps) atau packet persecond (pps).
Throughput merujuk pada besar data yang dibawa oleh semua trafik
jaringan, tetapi dapat juga digunakan untuk keperluan yang lebih spesifik.Throughput akan semakin baik jika nilainya semakin besar. Besarnya throughput akan memperlihatkan kualitas dari kinerja protokol routing tersebut. Karena itu throughput dijadikan sebagai indikator untuk mengukur performansi dari sebuah protokol.
22 BAB IV
IMPLEMENTASI DAN ANALISIS
Penelitian ini menggunakan Simulator Network Simulator 2 (NS2), dengan menjalankan file dengan ekstensi .tcl yang merupakan konfigurasi dari skenario yang digunakan. Delay dan bandwidth pada link, dan jumlah node. Hasil dari menjalankan script tersebut berupa file trace dengan ekstensi .tr, dan .xg. File trace tersebut berisi semua data yang mengalir di skenario tersebut.
Data yang didapatkan dari file trace kemudian di oleh menggunakan script berekstensi .awk sehingga mendapatkan data rata-rata throughput dan paket drop. Dan file trace tersebut digunakan untuk menampilkan grafik congestion window dan grafik sequence number beserta paket drop.
Pada pengujian ini, penulis akan berfokus pada TCP 1 dengan UDP sebagai pengganggunya,
4.1. Hasil Simulasi
Setelah melakukan simulasi sesuai skenario yang telah ditentukan, didapatkan data berupa congestion control.
23 4.1.1.1. Congestion Window
Grafik 4.1 Skenario Red : Sack vs Reno cwnd : minTresh 10
24
Grafik 4.3 Skenario Red : Sack vs Reno cwnd : minTresh 20
Perbandingan Congestion window antara TCP Reno dan Sack pada skenario RED ini menunjukkan bahwa kinerja TCP Sack lebih baik dari TCP Reno dari segi pemulihan paket yang hilang. Percobaan pertama dengan nilai minTresh 10, TCP Sack kembali ke fase Slow Start sebanyak 3x, hal ini terjadi karena average queue TCP Sack untuk minTresh 10 lebih sering berada di nilai 10-18 (Grafik 4.5), meskipun berada di antara minTresh dan setengah dari nilai maxTresh yaitu 30, probabilitas paket drop yang kecil tetap dapat menghasilkan paket drop, dan probabilitas tersebut dapat membuang paket yang diretransmisi ulang sehingga membuat TCP Sack dipaksa kembali ke fase SlowStart (Grafik 4.12).
Sementara untuk TCP Reno sendiri lebih banyak jatuh karena setiap ada 2 atau lebih paket yang di drop dalam satu window, Reno akan mengulang lagi dari Slow Start. Percobaan 2 dan 3 juga menunjukkan secara garis besar bahwa kinerja TCP Sack lebih baik dari TCP Reno untuk mengatasi random packet drop.
25 4.1.1.2. Red Average Queue
Grafik 4.4 Skenario Red : TCP Reno average queue comparation
26
Perbandingan Average Queue dari kedua TCP terlihat berbeda. Dengan nilai maxTresh = 30, ketika TCP menaikkan nilai
minTreshnya dari 10 ke 15 dan ke 20, semakin dekat jarak diantara minTresh dan maxTresh, semakin cepat peningkatan probabilitas
paket dropnya. Namun, nilai minTresh yang tinggi menyebabkan antrian menjadi lebih cepat terisi karena average queue nya berada dibawah nilai minTresh sehingga paket yang akan masuk antrian tidak didrop.
4.1.1.3. Packet Loss
Grafik 4.6 Data Packet Loss Reno vs Sack : RED
Perbandingan packet loss antara TCP Reno dan TCP Sack pada skenario Red ini menunjukkan bahwa jumlah paket loss TCP Sack lebih tinggi daripada TCP Reno. Hal ini terjadi karena TCP Sack tidak sering jatuh ketika terjadi beberapa paket drop dalam satu RTT ketika rata-rata queue sizenya berada diantara minTresh dan
27
maxTresh, dan nilai cwndnya pun meningkat mulai dari setengah cwnd sebelumnya sehingga TCP Sender tetap dapat mengirim paket yang banyak. Pemulihan cwnd TCP Sack tersebut yang membuat rata-rata queue sizenya lebih cepat naik lagi sehingga probability Red untuk membuang paket juga meningkat dan hal tersebut menghasilkan jumlah paket drop yang lebih banyak dari TCP Reno yang lebih sering mengulangi dari fase Slow Start sehingga menyebabkan peningkatan probabilitas paket drop Red sedikit lebih lambat.
4.1.1.4. Average Throughput
Grafik 4.7 Data Average Throughput Reno vs Sack : RED Perbandingan rata-rata throughput antara TCP Reno dan TCP Sack pada skenario RED menunjukkan bahwa rata-rata throughput TCP Sack lebih tinggi daripada TCP Reno. Hal ini terjadi karena Congestion Control TCP Reno hanya dapat mengirim ulang
28
(meretransmit) 1 paket yang hilang per Round Trip Time (rtt) sehingga apabila beberapa paket dalam satu rtt di drop secara acak oleh algoritma RED, TCP Reno tentu akan jatuh dan mengulangi dari fase Slowstart lagi sehingga nilai throughputnya pun ikut turun. Sementara throughput TCP Sack lebih tinggi karena TCP Sack dapat merecovery paket yang hilang lebih dari 2 paket per RTT sehingga apabila ada beberapa paket yang didrop secara acak dalam satu RTT, TCP Sack dapat merecovery paket-paket tersebut, lalu akan mengubah nilai cwndnya menjadi setengah dari cwnd yang sebelumnya, dan melanjutkan pengiriman data.
Percobaan nilai minTresh 15 pada TCP Sack terlihat menghasilkan nilai rata-rata throughput yang lebih tinggi, karena pada percobaan ini TCP Sack tidak pernah jatuh sekalipun sehingga nilai throughput jadi lebih terjaga (Grafik 4.2), dan nilai rata-rata throughputnya berkurang di percobaan selanjutnya karena Sack lebih banyak mengalami fase Slow Start sehingga nilai throughputnya berkurang.
4.1.1.5. Sequence Number Graph 4.1.1.5.1. TCP Reno
29
Grafik 4.9 Skenario Red – TCP Reno multi drop reaction : 10
30
Grafik 4.11 Skenario Red – TCP Reno packet drop reaction : 20 TCP Reno dapat memulihkan 1 paket yang hilang pada satu window, pada Grafik 4.8 TCP Reno meretransmisikan 1 paket yang hilang pada detik ke 88,6 kemudian masuk ke fast recovery pada detik 88,9, dan 1 paket yang hilang berikutnya juga diretransmisikan dan masuk ke fase fast recovery. TCP Reno tidak dapat meretransmisi 2 paket sekaligus dalam satu rtt, pada Grafik 4.9 TCP Reno kembali ke fase slow start setelah paket kedua yang hilang terdeteksi lewat duplikat ack. Percobaan ke 3 untuk nilai minTresh 20, menghasilkan data congestion window (Grafik 4.3) yang nilai congestion windownya sering jatuh, jadi pada sequence graph terlihat bahwa banyaknya paket yang dikirim tidak stabil atau sering berkurang.
31 4.1.1.5.2. TCP Sack
Grafik 4.12 Skenario Red – TCP Sack retransmit packet drop : 10
32
Grafik 4.14 Skenario Red – TCP Sack Retransmit drop reaction : 20
TCP Sack akan mengalami pengulangan fase ke Slow Start apabila paket yang diretransmisikan juga didrop pada saat perjalanan ke Receiver (Grafik 4.12 dan Grafik 4.14). Ketiga grafik ini memperlihatkan tentang reaksi TCP Sack saat menghadapi random paket drop. TCP Sack mampu meretransmisikan 2 atau lebih paket yang hilang dalam satu RTT tanpa menunggu retransmission timer berakhir, untuk paket drop yang letaknya random/berjarak, TCP Sack mampu mengatasi dengan fase fast recoverynya (Grafik 4.13).
33 4.1.2. Skenario DropTail
4.1.2.1. Congestion Window
Grafik 4.15 DropTail – Cwnd Graph Sack vs Reno : 20
34
Grafik 4.17 DropTail – Cwnd Graph Sack vs Reno : 40
Ketiga percobaan antrian DropTail ini menunjukkan bahwa kedua TCP sama-sama jatuh ketika ada burst paket yang didrop bersebelahan. TCP Reno hanya mampu meretransmisi 1 paket yang hilang tiap satu rtt jadi ketika ada burst paket yang banyak, Reno akan mengulangi dari Slow Start dan mengirimkan semua paket tersebut termasuk paket yang sudah berhasil diterima oleh Receiver. Sementara TCP Sack, dapat memulihkan beberapa paket yang hilang apabila paket yang hilang tersebut tidak sering bersebelahan, jika sering bersebelahan dan banyak maka Sack juga akan jatuh ke Slow Start.
35 4.1.2.2. Packet Loss
Grafik 4.18 Droptail – Data Paket Loss
Paket drop yang bersebelahan membuat TCP Sack dan Reno mengalami penurunan nilai window. Dari data yang didapatkan, jumlah paket loss antara 2 TCP ini hampir sama, karena TCP Reno dan Sack sama2 jatuh ketika ada paket yang hilang bersebelahan/cluster sehingga drop paket yang dihasilkan kedua TCP pun relatif sama.
36 4.1.2.3. Average Throughput
Grafik 4.19 Droptail – Data Average Throughput
Perbandingan throughput antara TCP Reno dan Sack pada skenario Droptail ini menunjukkan bahwa antrian Droptail tidak membuat perbedaan performa yang signifikan diantara kedua TCP. Berbeda dari skenario RED yang menunjukan perbandingan
throughput yang jauh berbeda, skenario ini memperlihatkan bahwa
perbedaan throughputnya tipis. Karena pada antrian DropTail, setiap 10 detik, traffic CBR akan ikut membanjiri jaringan dengan jumlah paket yang banyak sehingga kedua TCP harus menerima kehilangan banyak paket yang bersebelahan, dan kedua TCP tidak dapat memulihkan paket bersebelahan yang hilang sekaligus dalam 1 rtt, sehingga keduanya lebih sering masuk ke fase Slow Start dan nilai
37
4.1.2.4. Sequence Number Graph 4.1.2.4.1. TCP Reno
Grafik 4.20 DropTail – TCP Reno sequence graph full : 20 packet
Grafik 4.21 DropTail – TCP Reno cluster drop reaction : 20 packet
Grafik diatas menunjukkan reaksi TCP Reno ketika ada cluster paket drop yang muncul, TCP Reno bereaksi dengan masuk ke fase Slow Start lagi setelah menerima semua
38
duplikat ack, sehingga semua paket yang hilang tersebut dapat diretransmisikan kembali, meskipun beberapa paket yang sudah diterimapun ikut diretransmisikan.
4.1.2.4.2. TCP Sack
Grafik 4.22 DropTail – TCP Sack cluster drop reaction 1: 20 packet
39
Grafik diatas menunjukan reaksi TCP Sack ketika terjadi burst paket yang menghasilkan paket drop yang bersebelahan, algoritma Sack Option TCP Sack tidak dapat menampung lebih dari 3 blok data sehingga Sack akan mengulang ke fase Slow Start untuk meretransmisikan paket yang hilang tersebut meskipun ada beberapa paket yang sudah diterima.
40 BAB V
KESIMPULAN DAN SARAN
5.1. KESIMPULAN
Dari hasil simulasi yang telah dilakukan, kesimpulan yang didapat diambil sebagai berikut:
1. Congestion Control TCP Sack yang dijalankan pada model antrian RED menunjukkan bahwa grafik congestion windownya lebih stabil daripada TCP Reno. Hal ini disebabkan karena antrian RED membuang satu atau beberapa paket secara acak tanpa menunggu antrian penuh sehingga TCP Reno yang hanya mampu meretransmisi 1 paket yang hilang per 1 rtt dapat jatuh sewaktu-waktu. TCP Sack mampu mengatasi random paket drop karena TCP Sack Receiver memberikan informasi berupa list paket mana saja yang berhasil dikirim, sehingga Sender hanya tinggal mengirimkan paket yang hilang saja dari list tersebut.
2. Pada model antrian DropTail, Congestion Control TCP Sack melalui grafik congestion window menunjukan bahwa nilai congestion windownya relatif lebih kecil pada saat terjadi paket drop secara bersebelahan saat burst paket dari CBR. Banyak paket hilang yang bersebelahan mengakibatkan Sack kehabisan ruang untuk mengisi list pada sack option sehingga TCP Sack harus kembali ke Slow Start untuk memperbaiki congestion windownya dan meretransmisi paket yang hilang tersebut. TCP Reno juga mengalami hal yang serupa, karena Reno hanya mampu meretransmisikan 1 paket per RTT, dan ketika ada beberapa paket yg bersebelahan hilang, maka TCP Reno akan langsung kembali ke Slow Start.
41 5.2. SARAN
Untuk pengembangan lebih lanjut, terdapat beberapa saran dari penulis antara lain :
1. Melakukan pengujian menggunakan TCP sebagai pengganggu jaringan
2. Mencoba menggunakan varian TCP yang berbeda untuk perbandingan (TCP NewReno, TCP Vegas, TCP CUBIC)
42
DAFTAR PUSTAKA
[1] K. Fall, dan S. Floyd. (1995), Simulation-based Comparisons of Tahoe,
Reno, and Sack TCP.
[2] Wirawan, Andi Bayu, dan Indarto Eka. (2004), Mudah Membangun Simulasi dengan Network Simulator 2 (NS2). Yogyakarta : Andi.
[3] S. Floyd. (1996), Issues of TCP with SACK.
[4] M. Mathis, J. Mahdavi, PSC, S. Floyd, LBNL, A. Romanow, dan Sun Microsystems. (1996), TCP Selective Acknowledgment Options.
[5] Prihmardoyo, Emanuel. (2016), Analisis Unjuk Kerja Tcp Tahoe Congestion
Control Pada Antrian Red dan DropTail.
[6] Flody, Sally. & V. Jacobson. (1993), Random Early Detection Gateways for
Congestion Avoidance.
[7] Jacobson, Van. & Michael J. Karels. (1988), Congestion Avoidance and
Control.
[8] Rastogi, Shubhangi & Samir Srivastava. (2014), Comparison Analysis of
Different Queuing Mechanisms Droptail, RED, and NLRED in Dumb-bell Topology.
[9] Torkey, Hanna A., Gamal M. Attiyay & I. Z. Morsiz. (2008), Performance
43
LAMPIRAN
LISTING PROGRAM 3. Skenario_1_red.tcl set ns [new Simulator]
$ns color 1 blue $ns color 2 red
set nm [open out-percobaan-red.nam w] $ns namtrace-all $nm
set nt [open out-percobaan-red.tr w] $ns trace-all $nt set n0 [$ns node] set n1 [$ns node] set n2 [$ns node] set n3 [$ns node] set n4 [$ns node] set n5 [$ns node] $ns duplex-link $n0 $n2 15Mb 10ms DropTail $ns duplex-link $n1 $n2 5Mb 20ms DropTail $ns duplex-link $n2 $n3 1Mb 50ms RED $ns duplex-link $n3 $n4 5Mb 10ms DropTail $ns duplex-link $n3 $n5 5Mb 10ms DropTail $ns queue-limit $n2 $n3 40
$ns duplex-link-op $n0 $n2 orient right-down $ns duplex-link-op $n1 $n2 orient right-up $ns duplex-link-op $n2 $n3 orient right $ns duplex-link-op $n3 $n4 orient right-up
44 $ns duplex-link-op $n3 $n5 orient right-down $ns duplex-link-op $n2 $n3 queuePos 0.5
#setting antrian RED
set redq [[$ns link $n2 $n3] queue] set tchan_ [open all.q w]
$redq set bytes_ false
$redq set queue_in_bytes_ false
$redq trace curq_ $redq trace ave_ $redq attach $tchan_
$redq set thresh_ 20 $redq set maxthresh_ 30 $redq set q_weight_ 0.002 $redq set linterm_ 10
#tcp
#set tcp [new Agent/TCP/Sack1] set tcp [new Agent/TCP/Reno] $tcp set class_ 1
$tcp set window_ 50 #default:20
#$tcp set packetSize_ 1000 #default:1000 #$tcp set ssthresh_ 64 #default:0
$ns attach-agent $n0 $tcp
#set sink [new Agent/TCPSink/Sack1] set sink [new Agent/TCPSink]
$ns attach-agent $n4 $sink $ns connect $tcp $sink
45 set ftp [new Application/FTP]
$ftp attach-agent $tcp
#set error rate
#set em [new ErrorModel] #$em set rate_ 0.2
#$em ranvar [new RandomVariable/Uniform] #$em drop-target [new Agent/Null]
#$ns link-lossmodel $em $n0 $n2
#trace cwnd in TCP $tcp attach $nt $tcp tracevar cwnd_ $tcp tracevar ssthresh_
#set UDP and Null and CBR Application set udp [new Agent/UDP]
$udp set class_ 2
$ns attach-agent $n1 $udp
set null [new Agent/Null] $ns attach-agent $n5 $null $ns connect $udp $null
set cbr [new Application/Traffic/CBR] $cbr attach-agent $udp
#$cbr set packetSize_ 1000 #default:210 $cbr set rate_ 300kb #default:448kb $cbr set random_ false
46 #Pengeplotan data cwnd dengan file akhir .xg proc cwnd_trace {tcpSource outfile} {
global ns
set now [$ns now]
set cwnd [$tcpSource set cwnd_]
puts $outfile "$now $cwnd"
$ns at [expr $now+0.1] "cwnd_trace $tcpSource $outfile" }
#set outfile [open "cwnd-percobaan-red.xg" w] set outfile [open "cwnd-percobaan-red-r.xg" w]
proc ssthresh_trace {tcpSource2 outfile2} { global ns
set now [$ns now]
set cwnd [$tcpSource2 set ssthresh_]
puts $outfile2 "$now $cwnd"
$ns at [expr $now+0.1] "ssthresh_trace $tcpSource2 $outfile2" }
set outfile2 [open "ssthresh-percobaan-red.xg" w] $ns at 0.0 "ssthresh_trace $tcp $outfile2"
puts $outfile "TitleText: TCP Sack vs TCP Reno - Cwnd Graph" puts $outfile "XUnitText: Time (second)"
puts $outfile "YUnitText: Cwdn (MSS)" #puts $outfile "0.Color: red"
#puts $outfile "1.Color: black"
47 proc finish {} { global ns nm nt $ns flush-trace set awkCode { { if ($6 == "cwnd_") { print $1, $6, $7 >> "winsize-percobaan-red.txt"; }
else if ($1 == "+" && $3 == 0 && $5 == "tcp") { print $2, $11 >> "enqueue-percobaan-red.txt";
print $2, $5, $11, "Enqueue" >> "winsize-percobaan-red.txt";
}
else if ($1 == "r" && $4 == 4 && $5 == "tcp") { print $2, $11 >> "arrival-percobaan-red.txt";
print $2, $5, $11, "Arrival" >> "winsize-percobaan-red.txt";