TA : Analisis Perbandingan Unjuk Kerja Protokol TCP Vegas dan UDP Dengan Menggunakan Data Streaming.
DAN UDP DENGAN MENGGUNAKAN DATA STREAMING TUGAS AKHIR
Disusun Oleh :
Nama : Irene Rizky Andini NIM : 09.41020.0013 Program : S1 (Strata Satu) Jurusan : Sistem Komputer
SEKOLAH TINGGI
MANAJEMEN INFORMATIKA & TEKNIK KOMPUTER SURABAYA
(2)
iv `
Streaming adalah teknologi transmisi pengiriman data, video atau audio secara real time atau pre-recorded dari sender pada receiver. Kebutuhan akan akses data streaming yang semakin meningkat mendorong berbagai pihak untuk melakukan penelitian guna menghasilkan unjuk kerja protokol yang tepat dan ideal untuk data streaming, salah satunya dengan melakukan analisis terhadap protokol yang digunakan dalam data streaming.
Dalam tugas akhir ini menghasilkan perbandingan karakteristik utilisasi bandwidth, packet loss, latency dan jitter dari protokol TCP Vegas dan UDP berdasarkan kualitas layanan data streaming Voice over IP (VoIP) dan video streaming mengunakan network simulator 2.
Dari analisis perbandingan unjuk kerja protokol TCP Vegas dan UDP yang telah dilakukan, dengan parameter-parameter yang telah ditetapkan. Secara umum didapatkan bahwa prosentase utilisasi bandwidth pada protokol UDP lebih besar daripada TCP Vegas. Prosentase packet loss pada protokol TCP Vegas lebih tinggi daripada protokol UDP. Sedangkan nilai latency dan jitter pada protokol TCP Vegas memiliki nilai lebih tinggi daripada protokol UDP.
(3)
vii
Halaman
ABSTRAK ... iv
KATA PENGANTAR ... v
DAFTAR ISI ... vii
DAFTAR TABEL ... x
DAFTAR GAMBAR ... xi
DAFTAR LAMPIRAN ... xiii
BAB I PENDAHULUAN ... 1
1.1 Latar Belakang ... 1
1.2 Perumusan Masalah ... 2
1.3 Batasan Masalah ... 3
1.4 Tujuan ... 3
1.5 Kontribusi ... 4
1.6 Sistematika Penulisan ... 4
BAB II LANDASAN TEORI ... 6
2.1 Transmission Control Protokol (TCP) ... 6
2.2 TCP Vegas ... 8
2.3 User Datagram Protokol (UDP) ... 10
2.4 Data Streaming ... 12
2.4.1 VOIP ... 13
2.4.2 Video Streaming ... 13
2.5 Quality of Service (Qos) ... 14
(4)
viii
2.6.1 Konsep Dasar Network Simulator 2 ... 18
2.6.2 Cara Membuat dan Menjalankan Skrip NS-2 ... 19
2.6.3 Tahap-Tahap dalam Membangun Simulasi ... 19
2.6.4 Transport Agent ... 22
2.6.5 Output Simulasi Network Simulator 2 ... 23
BAB III Metode Penelitian ... 27
3.1. Desain Penelitian ... 27
3.2. Prosedur Penelitian ... 28
3.2.1 Parameter Penelitian ... 29
3.2.2 Desain Topologi ... 32
3.2.3 Pembuatan Script ... 33
3.2.4 Menjalankan Script di NS-2 ... 37
3.2.5 Pengolahan Data ... 37
3.2.6 Plotting ... 52
BAB IV Hasil dan Pembahasan ... 53
4.1. Kebutuhan Sistem ... 53
4.1.1 Kebutuhan Perangkat Keras ... 53
4.1.2 Kebutuhan Perangkat Lunak ... 54
4.2 Data Simulasi ... 54
4.3 Hasil dan Pembahasan ... 55
4.3.1 Utilisasi bandwidth ... 57
4.3.2 Packet loss ... 62
(5)
ix
BAB V PENUTUP ... 67
5.1. Kesimpulan ... 67
5.2. Saran ... 68
(6)
1 BAB I
PENDAHULUAN
1.1 Latar Belakang
Perkembangan teknologi yang semakin maju dan pesat mempengaruhi kehidupan masyarakat modern dalam menggunakan teknologi media komunikasi berbasis data streaming. Streaming adalah teknologi transmisi pengiriman data, video atau audio secara real time atau pre-recorded dari sender pada receiver. Pemanfaatan teknologi tersebut sangat beragam dalam berbagai kegiatan, sehingga data streaming membutuhkan suatu unjuk kerja protokol yang cepat dalam proses pengirimannya.
Salah satu protokol tersebut adalah protokol TCP Vegas dan UDP. TCP Vegas adalah algoritma yang menekankan pada keterlambatan paket daripada kehilangan paket (Arijasa, 2011), Sedangkan UDP merupakan protokol yang bersifat connectionless oriented. Artinya, saat melakukan pengiriman data tidak dilakukan proses handshaking, tidak ada sequencing datagram, dan tidak ada garansi bahwa paket data (datagram) yang dikirimakan tiba dengan selamat. UDP juga tidak menyediakan fitur koreksi kesalahan (Sofana, Cisco CCNA & Jaringan Komputer, 2009).
Ada Beberapa Jurnal yang berkaitan dengan perbandingan ini. Menurut Sean Boyden(2007) pada paper berjudul, “TCP Vegas Performance with Data streaming” yang berisi perbandingan TCP Vegas dan TCP New Reno didapatkan bahwa TCP Vegas lebih baik dari pada TCP New Reno untuk data streaming. Sedangkan menurut Mazhar B.Tayel (2008) pada paper berjudul “Effect of TCP
(7)
and UDP parameter on the quality of video streaming delivery over the internet” yang didapatkan bahwa pengaruh parameter UDP dan TCP pada penundaan jitter dan nilai paket loss yang digunakan meningkatkan efisiensi protokol UDP dan TCP untuk mencegah kemacetan jaringan.
Dalam tugas akhir ini penulis akan membandingkan karakteristik dari protokol TCP Vegas dan UDP berdasarkan pada kualitas layanan data streaming dengan parameter uji utilisasi bandwidth, packet loss, latency dan jitter. Alasan memakai protokol TCP Vegas, dikarenakan studi terdahulu (TCP Vegas Performance with Data streaming) yang membahas perbandingan TCP Vegas dan TCP varian lain menunjukkan bahwa TCP Vegas lebih unggul dalam hal keterlambatan paket untuk data streaming. Sementara itu secara umum diketahui bahwa protokol UDP sesuai dengan kateristiknya adalah protokol yang standar digunakan untuk data streaming. Karena itu dalam tugas akhir ini akan dianalisis unjuk kerja dari TCP Vegas dibandingkan dengan UDP untuk data streaming.
Perbandingan ini dilakukan menggukan Network Simulator 2. Network Simulator 2 merupakan sebuah perangkat lunak simulasi jaringan internet untuk kepentingan riset interaksi antar protokol dalam konteks pengembangan protokol internet pada saat ini dan masa yang akan datang (Indarto, 2004).
1.2 Perumusan Masalah
Dari latar belakang yang telah diuraikan diatas, dapat dirumuskan permasalahan yaitu:
1. Bagaimana mensimulasikan sistem dengan protokol TCP Vegas, dan UDP dengan menggunakan data streaming pada network simulator 2.
(8)
2. Bagaimana melakukan analisis perbandingan TCP Vegas, dan UDP pada data streaming dengan parameter uji utilisasi bandwidth, packet loss, latency dan jitter untuk ukuran paket data yang bervariasi.
1.3 Batasan Masalah
Batasan masalah dari sistem yang dibahas adalah sebagai berikut : 1. Protokol yang digunakan TCP Vegas, dan UDP.
2. Menggunakan data streaming berupa VOIP dan Video.
3. Perbandingan menggunakan parameter uji utilisasi bandwidth, packet loss, latency dan jitter dengan ukuran paket data yang bervariasi.
4. Menggunakan Network Simulator 2
1.4 Tujuan
Tujuan dari pembuatan sistem ini adalah:
1. Menghasilkan analisis perbandingan protokol TCP Vegas, dan UDP pada data streaming menggunakan network simulator 2.
2. Menghasilkan analisis perbandingan protokol TCP Vegas, dan UDP pada data streaming dengan parameter uji utilisasi bandwidth, packet loss, latency dan jitter dengan ukuran paket data yang bervariasi.
(9)
1.5 Kontribusi
Tugas akhir Analisis penbandingan unjuk kerja protokol TCP Vegas dan UDP pada data streaming ini diharapkan dapat menjadi pertimbangan dalam perkembangan layanan data streaming kedepan. Mengingat streaming sekarang ini digunakan oleh berbagai kalangan mulai dari dinas pemerintahan maupun masyarakat umum.
1.6 Sistematika Penulisan
Untuk memudahkan didalam memahami persoalan dan pembahasannya, maka penulisan laporan Tugas Akhir ini dibuat dengan sistematika sebagai berikut:
BAB I Pendahuluan
Pada bab ini dikemukakan hal-hal yang menjadi latar belakang, perumusan masalah, batasan masalah, kontribusi, tujuan yang ingin dicapai serta sistematika penulisan laporan tugas akhir ini.
BAB II Landasan Teori
Pada bab ini dibahas secara singkat teori-teori yang berhubungan dan mendukung dalam pembuatan tugas akhir ini. Adapun teori yang dibahas meliputi : TCP Vegas, UDP, data streaming, Quality of service, Network simulator 2.
BAB III Metode Penelitian
Pada bab ini dibahas tentang perancangan dan membuat simulasi jaringan pada algoritma TCP Vegas dan UDP serta alasan
(10)
penggunaan data streaming dalam penelitian. Perancangan jaringan dengan menggunakan NS-2.
BAB IV Hasil dan Pembahasan
Pada Bab ini akan melakukan simulasi, mengambil data, memplotting dan menganalisa berdasarkan parameter utilisasi bandwidth, packet loss, latency, jitter.
BAB V Penutup
Pada bab ini dibahas tentang kesimpulan dengan tujuan dan permasalah yang ada, serta saran untuk pengembangan sistem di masa mendatang.
(11)
6 BAB II
LANDASAN TEORI
2.1 Transmission Control Protokol (TCP)
TCP merupakan protokol yang bersifat connection oriented. Artinya sebelum proses transmisi data terjadi, dua aplikasi TCP harus melakukan pertukaran kontrol informasi (handshaking). TCP juga bersifat reliable karena menerapkan fitur deteksi kesalahan dan retransmisi apabila ada data yang rusak. Sehingga keutuhan data dapat terjamin. Sedangkan byte stream service artinya paket akan dikirimkan ke tujuan secara berurutan (sequencing).
Protokol TCP bertanggung jawab untuk pengiriman data dari sumber ke tujuan dengan benar. TCP dapat mendeteksi kesalahan atau hilangnya data dan melakukan pengiriman kembali sampai data diterima dengan lengkap. TCP selalu meminta konfirmasi setiap kali data dikirim, untuk memastikan apakah data telah sampai di tempat tujuan. Kemudian TCP akan mengirimkan data berikutnya atau melakukan retransmisi (pengiriman ulang) apabila data sebelumnya tidak sampai atau rusak. Data yang dikirim dan diterima kemudian diatur berdasarkan nomor urut. Pada Gambar 2.1 merupakan bagan segmen TCP.
Sumber: Sofana, 2009 Gambar 2.1. Bagan Segmen TCP
(12)
Berikut ini adalah keterangan dari Gambar 2.1 :
1. Source Port (16 bits) : Berisi informasi port pengirim 2. Destination Port (16 bits) : Berisi informasi port penerima
3. Sequence Number (32 bits) : Berupa sequence number yang terdiri atas dua kondisi berikut:
a. Jika flag SYN di-set (yang ada di bagian field Flags), maka field ini berisi awal (inisial) dari sequence number.
b. Jika flag SYN tidak di-set, maka nilai pada field ini merupakan sequence number.
4. Acknowledgement atau ACK (32 bits) : jika flag ACK di-set, maka nilai pada
field ini adalah nilai sequence number berikutnya yang di-“harapkan” oleh penerima.
5. Data offset (4 bits) : Menunjukan ukuran TCP header. Total header
sepanjang 32-bit words. Ukuran minimum header adalah 5 word. Data offset juga merupakan awal dari data.
6. Reserved (4 bits) : Untuk keperluan tertentu di masa akan datang. Nilai pada
field ini semestinya adalah zero (nol).
7. Flags (8 bit) : field untuk kontrol bit (masing-masing 1 bit), yaitu : a. CWR (Congestion Windows Reduced)
b. ECE (ECN-Echo) c. URG (URGent)
d. ACK (ACKnowledgement) e. PSH (Push function) f. RST (Reset)
(13)
g. SYN (Synchronize) h. FIN (Finish)
8. Window (16 bits) : menunjukan ukuran window penerima (receive window). Agar data dapat diterima dengan baik maka diperlukan pengaturan ukuran jumlah byte optimal yang ditentukan oleh field ini.
9. Checksum (16 bits) : digunakan untuk error-checking dari header dan data
10. Urgent pointer (16 bits) : digunakan untuk sequence number yang
menandakan urgent databyte terakhir.
11. Option (Variable bits) : Berisi berbagai opsi berupa angka sebagai berikut : a. 0-End of option list
b. 1-No operation list
c. 2-Maximum segment size
d. 3-Window scale
e. 4-Selective Acknowledgement
f. 5,6,7
g. 8-Timestamp
12. Data : Berisi data yang dikirim.
Protokol TCP sangat cocok digunakan untuk koneksi yang membutuhkan kehandalan tinggi, seperti aplikasi telnet, ssh, ftp, http, dan beberapa layanan lainnya (Sofana, Cisco CCNA & Jaringan Komputer, 2009).
2.2 TCP Vegas
TCP Vegas adalah sebuah algoritma yang menekankan pada keterlambatan paket daripada kehilangan paket, sebagai tanda untuk membantu
(14)
menentukan kadar saat paket akan dikirim. TCP Vegas merupakan pengembangan dari TCP Reno. TCP Vegas dikembangkan di University of Arizona oleh Lawrence Brakmo dan Larry L. Peterson (Arijasa, 2011).
Perbedaan antara TCP Vegas dengan TCP lainnya terletak pada fase
slowstart, pendeteksian bandwidth yang tersedia, serta mekanisme pendeteksian paket yang hilang. Pada TCP Reno congestion window akan terus bertambah sampai terdeteksi adanya packet loss yang diakibatkan oleh congestion. Jika
packet loss yang diakibatkan oleh kongesti terjadi, nilai congestion window akan diperkecil menjadi congestion window/2, yang mengakibatkan penurunan
throughput. Penambahan congestion window tidak dapat dihindari dikarenakan
mekanisme congestion control pada TCP Reno hanya dapat mendeteksi packet loss jika terjadi kongesti. Jadi jika ada packet loss yang bukan disebabkan oleh kongesti, maka congestion window akan terus bertambah sehingga ukuran
congestion window tidak dapat terkontrol dengan tepat yang dapat mengakibatkan
terjadinya packet loss semakin banyak.
Ide dasar dari TCP Vegas adalah mencegah terjadinya packet loss yang bukan hanya disebabkan oleh kongesti sehingga ukuran congestion window
menjadi tidak terlalu besar. Dengan terkontrolnya ukuran congestion window
dengan tepat, maka paket yang hilang dalam jaringan dapat dicegah, sehingga penurunan throughput akibat dari mengecilnya ukuran congestion window dapat dihindar.
Pada TCP Vegas dalam mengamati keadaan jaringan, tidak hanya
berdasarkan umpan balik ACK, tapi juga mengestimasi kondisi jaringan
(15)
dengan mengamati perubahan RTT (Round trip time) dari paket yang dikirimkan sebelumnya oleh pengirim kepada penerima. Jika RTT besar, maka jaringan mengalami kongesi dan memperkecil ukuran congestion window. Jika RTT kecil berarti jaringan dalam keadaan normal dan ukuran congestion window diperbesar. (Arijasa, 2011)
Dengan demikian jelaslah bahwa TCP Vegas jelas lebih baik daripada TCP Tahoe, Reno dan SACK dalam hal menghadapi paket yang hilang. TCP Vegas tidak perlu menunggu 3 detik untuk menduplikasi paket sehingga paket dapat dikirim kembali.
2.3 User Datagram Protokol (UDP)
UDP merupakan protokol yang bersifat connectionless oriented. Artinya, saat melakukan pengiriman data tidak dilakukan proses handshaking, tidak ada
sequencing datagram, dan tidak ada garansi bahwa paket data (datagram) yang dikirim akan tiba dengan selamat. UDP juga tidak menyediakan fitur koreksi kesalahan(Sofana, 2009).
UDP hanya menyediakan fasilitas multiplexing aplikasi (via nomor port) dan integritas verifikasi/deteksi kesalahan (via checksum) yang disediakan dalam
header dan payload. Deteksi kesalahan dalam UDP hanya bersifat optional. Untuk menghasilkan data yang reliable, haruslah dibantu dan dilakukan ditingkat aplikasi. Tidak bisa dikerjakan ditingkat protokol UDP. Pengiriman paket dilakukan berdasarkan “best effort basis”. Tabel 2.1 merupakan bagan dari segmen UDP.
(16)
Tabel 2.1. Segmen UDP
Bits 0-15 16-31
0 Source Port Destination Port
32 Length Checksum
64 Data
Sumber: Sofana, 2009
Berikut ini adalah keterangan dari Tabel 2.1:
1. Source port (16 bits) :Berisi informasi port pengirim.
2. Destination port (16 bits) :Berisi informasi port penerima.
3. Length (16 bits) :Menunjukkan panjang total dalam byte seluruh
datagram (header + data). Panjang minumum adalah 8 byte, sedangkan panjang maksimum 65,507 byte.
4. Checksum : Digunakan untuk error-checking header dan data.
Bidang checksum didalam UDP bersifat pilihan. Bila tidak digunakan, checksum di set ke nol. Namun, harus ditegaskan bahwa checksum IP hanya digunakan untuk header IP dan tidak untuk bidang data, dalam hal ini terdiri dari header UDP dan data pemakai. Jadi, bila tidak ada penghitungan checksum
yang ditampilkan oleh UDP, maka tidak ada pengecekan yang dibuat atas data pemakai.
(17)
Overhead yang diperlukan untuk mengirimkan datagram atau paket UDP sangatlah kecil. Sehingga UDP cocok untuk digunakan pada aplikasi yang membutuhkan query dan response cepat. Contoh layanan yang cocok untuk UDP yaitu transmisi audio/video, seperti: VoIP, audio/video streaming. UDP kurang baik jika digunakan untuk mengirimkan paket berukuran besar. Karena dapat memperbesar peluang jumlah packet loss atau hilang (Sofana, 2009)
2. 4 Data streaming
Streaming adalah teknologi transmisi pengiriman data, video atau audio secara real time /pre-recorded dari sender pada receiver. Ide dari streaming
adalah membagi data, encoding, mengirimkan melalui jaringan dan saat bagian data tiba pada client maka dilakukan decoding serta membaca data (Abdul Syarif, 2008). Pada streaming seorang pengguna akhir dapat mulai melihat suatu file multimedia hampir bersaman ketika file tersebut mulai diterima.
Penggunaan cara ini mengharuskan pengiriman suatu file multimedia ke
user dilakukan secara konstan. Hal ini bertujuan agar seorang user dapat menyaksikan video yang diterima secara langsung tanpa ada bagian yang hilang. Keuntungan utama dari penggunaan ini cara ini adalah seorang user tidak perlu menunggu hingga suatu file multimedia diterima secara lengkap. Dengan demikian, penggunaan cara ini memungkinkan sebuah user untuk melakukan pengiriman siaran langsung (live events) kepada user.
(18)
2.4.1 VOIP
Secara umum proses komunikasi VoIP meliputi pemaketan suara ”analog” dari headset telepon, di mana suara itu di digitalisasi, dimampatkan/dikompresi, dikirim dalam paket-paket pendek melalui jaringan, lalu di decode dan direkontruksi agar kembali menjadi sinyal suara di ujung sebelah sana.
Jaringan yang digunakan untuk mengirim paket suara tersebut dapat berbasis IP, berbasis ATM atau berbasis frame relay. Aneka infrastruktur tersebut sebetulnya menjadi dasar berbagai teknologi “voice over” termasuk VoIP, VoATM, VoDSL, dan VoP. Biasanya menggunakan istilah VoIP untuk semuanya.
IP phone biasanya akan melakukan proses digitalisasi, kompresi, dan pemaketan data secara internal di dalam pesat telepon dan menghasilkan aliran paket suara melalui jaringan LAN. Sementara IP gateway merupakan interface
antara telepon analog/telepon digital dan TDM trunk yang melakukan konversi terhadap setiap sinyal suara ke aliran paket VoIP. Sebuah IP PBX atau gateway
enterprise biasanya digunakan oleh sebuah perusahaan untuk menggabungkan IP
phone ke jaringan telepon konvensional. Sementara trunk gateway biasanya digunakan oleh sebuah perusahaan untuk menyambungkan banyak sambungan telepon”analog” ke VoIP.(Purbo, 2007)
2.4.2 Video Streaming
Video telah menjadi media yang sangat penting untuk komunikasi dan hiburan selama puluhan tahun. Pertama kali video diolah dan ditransmisikan dalam bentuk analog. Munculnya digital IC (Integrated Circuit) dan
(19)
berkembangnya komputer telah membantu terbentuknya video digital. Salah satu penerapan video digital yang digunakan dalam transmisi pada jaringan komputer adalah video streaming.
Video streaming adalah urutan dari “gambar yang bergerak” yang dikirimkan dalam bentuk yang telah dikompresi melalui jaringan internet dan ditampilkan oleh player ketika video tersebut telah diterima oleh user yang membutuhkan. Pengguna atau user memerlukan player, yaitu aplikasi khusus yang melakukan dekompresi dan mengirimkan data berupa video ke tampilan layar monitor dan data berupa suara ke speaker. Sebuah player dapat berupa bagian dari browser atau sebuah perangkat lunak.
Ada beberapa tipe video streaming, antara lain webcast, di mana tayangan yang ditampilkan merupakan siaran langsung (live), dan VOD (video on demand), di mana program yang ditampilkan sudah terlebih dahulu direkam atau disimpan dalam server.
Faktor-faktor yang berpengaruh dalam distribusi video streaming melalui jaringan antara lain besar bandwidth tersedia yang bervariansi (terhadap waktu),
delay (waktu tunda), dan lost packet, dan juga teknik mendistribusikan video tersebut ke beberapa tujuan secara merata dan efisien (Apostolopoulos,2002).
2.5 Quality of Service(Qos)
Quality of Service (QoS) merupakan metode pengukuran tentang
seberapa baik jaringan dan merupakan suatu usaha untuk mendefinisikan karakteristik dan sifat dari satu servis (Ferguson & Huston, 1998). Ada beberapa alasan mengapa perlu QoS, yaitu:
(20)
1. Untuk memberikan prioritas untuk aplikasi-aplikasi yang kritis pada jaringan.
2. Untuk memaksimalkan penggunaan investasi jaringan yang sudah ada. 3. Untuk meningkatkan performansi untuk aplikasi-aplikasi yang sensitif
terhadap delay, seperti Voice dan Video.
4. Untuk merespon terhadap adanya perubahan-perubahan pada aliran traffic
di jaringan.
2.5.1 Parameter Quality of Service(Qos) 1. Utilisasi bandwidth
Bandwidth, merupakan kapasitas atau daya tampung kabel Ethernet agar dapat dilewati trafik paket data dalam jumlah tertentu. Bandwidth juga biasa berarti jumlah konsumsi paket data per satuan waktu dinyatakan dengan satuan bit per second (bps) (Riadi & Wicaksono, 2011). Penggunaan bandwidth untuk multiuser dalam sebuah lingkungan institusi akan dipengaruhi banyak faktor: karakteristik situs yang diakses, jumlah user, delay (jeda) transmisi, dan
bandwidth tersedia. Faktor-faktor ini akan dianalisa dengan asumsi, utilisasi
sumber daya atau sering disebut sebagai utilisasi. Utilisasi adalah ukuran seberapa sibuk sumber daya yang ada. Dalam teori antrian, utilisasi direpresentasi sebagai waktu server melakukan layanan dan didefinisikan dengan persamaan (Riadi & Wicaksono, 2011):
Utilisasi = x100%...(2.1) dimana :
(21)
satu waktu
bandwidth = merupakan jumlah besaran bandwidth yang tersedia
2. Packet loss
Packet loss adalah jumlah paket yang hilang saat pengiriman paket data
ke tujuan, kualitas terbaik pada jaringan LAN/WAN jika jumlah losses paling kecil (Riadi & Wicaksono, 2011). Packet loss dianalisis berdasarkan berapa banyak paket yang hilang atau gagal mencapai tujuan pada waktu paket sedang berjalan. Kemudian dilakukan percobaan dengan memberikan ukuran paket yang bervariasi, dan dapat dihitung dengan persamaan 2.2 (Riadi & Wicaksono, 2011):
Packet loss= x 100%...(2.2) dimana :
Pd = Paket yang mengalami drop (paket) Ps = Paket yang dikirim (paket)
3. Latency
Latency adalah apabila mengirimkan data sebesar 3Mb pada saat jaringan
sepi waktunya 5 menit tetapi pada saat ramai sampai 15 menit, hal ini disebut
latency. Latency dianalisis berdasarkan berapa waktu tunda dari paket yang diterima sampai tujuan dari masing-masing protokol yang dibandingkan dengan data streaming, dan dihitung dengan persamaan (Khalid, 2010) dibawah ini:
Waktu tunda (t) = (Tr – Ts) detik...(2.3) dimana :
(22)
Ts = Waktu pengiriman paket (detik)
4. Jitter
Jitter, merupakan variasi delay antar paket yang terjadi pada jaringan berbasis IP. Besarnya nilai jitter akan sangat dipengaruhi oleh variasi beban trafik dan besarnya tumbukan antar-paket (congestion) yang ada dalam jaringan tersebut. Semakin besar beban trafik di dalam jaringan akan menyebabkan semakin besar pula peluang terjadinya congestion, dengan demikian nilai jitter -nya akan semakin besar. Semakin besar nilai jitter akan mengakibatkan nilai QoS
akan semakin turun.
Jitter dapat dianalisis berdasarkan keterlambatan transmisi data dari pengirim dan penerima dalam rentang waktu tertentu. Kemudian dilakukan percobaan dengan memberikan data inputan yang berbeda-beda, dan dapat dihitung dengan persamaan (Khalid, 2010) dibawah ini:
Jitter = delay (A) – delay (B)...(2.4) dimana:
delay (A) = delay of a current packet delay (B) = delay of a previous packet
2. 6 Network Simulator 2
Network simulator (NS) pertama kali di bangun sebagai varian dari REAL Network Simulator pada tahun 1989 di UCB (University of California Berkeley). Pada tahun 1995 pembangunan NS di sukung oleh DARPA (Defense Advance Research Project Agency) melalui VINT (Virtual Internet Testbed)
(23)
Project, yaitu sebuah tim riset gabungan yang beranggotakan tenaga ahli dari LBNL (Lawrence Berkeley of National Laboratory), Xerox PARC, UCB dan USC/ISI (University of Southern California School of Engineering/Information
Science Institute). Tim gabungan ini membangun sebuah perangkat lunak simulasi
jaringan internet untuk kepentingan riset interaksi antar protokol dalam konteks pengembangan protokol internet pada saat ini dan masa yang akan datang. (Indarto, 2004)
2.6.1 Konsep Dasar Network Simulator 2
Network Simulator dibangun dengan menggunakan 2 bahasa pemrograman, yaitu C++ dan Tcl/OTcl. C++ digunakan untuk library yang berisi
event scheduler, protokol dan network conmponent yang diimplementasikan pada
simulasi oleh user. Tcl/OTcl digunakan pada script simulasi yang ditulis oleh NS
user dan pada library sebagai simulator objek.
Bahasa C++ digunakan pada library karena C++ mampu mendukung runtime simulasi yang cepat, meskipun simulasi melibatkan simulasi jumlah paket dan sumber data dalam jumlah besar.
Bahasa Tcl memberikan respon runtime yang lebih lambat daripada C++, namun jika terdapat kesalahan, respon Tcl terhadap kesalahan syntax dan perubahan script berlangsung dengan cepat dan interaktif. User dapat mengetahui letak kesalahannya yang dijelaskan pada console, sehingga user dapat memperbaiki dengan cepat. Karena alasan itulah bahasa ini dipilih untuk digunakan pada skripsi simulasi
(24)
2.6.2 Cara Membuat dan Menjalankan Skrip Network Simulator 2
Dalam membuat skrip simulasi yaitu dengan menggunakan program teks editor yang terdapat pada linux,dan disimpan dalam sebuah folder dengan ekstensi .tcl. Contoh:
Simulasitcp.tcl
Untuk menjalankan simulasi yang telah dibuat, dapat dilakukan dengan masuk pada folder tersebut dan mengetikan NS serta nama file tcl simulasi yang ingin dijalankan. Contoh:
[root @accessnet your_folder]#ns Simulasitcp.tcl
2.6.3 Tahap-Tahap dalam Membangun Simulasi
Beberapa tahapan dalam membangun simulasi dapat di jelaskan sebagai berikut:
1. Inisialisasi Simulasi
Menurut Wirawan & Indarto (2004), untuk memulai pembuatan simulasi sederhana, dapat membuka salah satu teks editor yang ada pada Linux. Kemudian simpan file tersebut dalam folder sebagai contoh.tcl.
Simulasi NS dimulai dengan menuliskan skrip Tcl seperti di bawah ini. Skrip ini merupakan inisialisasi simulasi dan harus ada dalam setiap simulasi yang dibuat.
Ingatlah bahwa baris yang dimulai dengan tanda # dianggap sebagai komentar yang digunakan untuk menjelaskan masing-masing perintah.
#memanggil simulator object set ns [new Simulator]
(25)
set nf [open out.nam w] $ns namtrace-all $nf
#prosedur finish berguna untuk menyelesaikan simulasi, proc finish {} {
#menutup file dan memulai nam (network animator) global ns nf
$ns flush-trace close $ns
exec nam out.nam & exit 0
}
#mengeksekusi prosedur finish pada saat detik ke 5.0 $ns at 5.0 “finish”
#menjalankan simulasi $ns run
2. Pembuatan Topologi
Topologi dibangun oleh node dan link. Berikut ini dijelaskan pembuatan
node dan link yang membangun topologi simulasi. 1. Node
Sebuah objek node pada NS didefinisikan dengan command $ns node. Perintah pembuatan node pada NS adalah sebagai berikut:
set node [$ns node] 2. Link
Ada dua jenis link yang bisa digunakan pada NS, yaitu simplex link dan
duplex link. Berikut ini adalah perintah pembuatan link beserta parameternya: 1. Untuk simplex link:
$ns simplex-link<node1><node2><bw><delay><qtype>
(26)
2. Untuk duplex link:
$ns_ duplex-link<node1><node2><bw><delay><qtype>
Link dua arah dari <node1> ke <node2> dan sebaliknya.
3. Sending Data
Proses sending data pada NS dilakukan dengan membuat transport agent
dan aplikasi di atasnya. Transport agent dibuat berpasangan, satu berfungsi sebagai sumber data dan pasangannya sebagai tujuan. Pada simulasi ini, mencoba mengirim UDP paket dengan menggunakan traffic generator CBR antara kedua
node. Kita awali dengan membuat agent pengirim data.
#membuat objek simulator yang berupa UDP agent set udp0 [new Agent/UDP]
#attach-agent berfungsi untuk mengambil object agent yang sudah didefinisikan yaitu UDP0 sebagai pengirim pada node0 $ns attach-agent $n0 $udp0
Setelah kita mempunyai sumber data, sekarang coba Anda buat tujuan dari paket data yang kita kirimkan dan sekaligus Anda hubungkan keduanya.
#membuat object simulator berupa agent null set null0 [new Agent/Null]
#attach-agent berfungsi untuk mengambil object agent yang sudah didefinisikan yaitu null0 sebagai penerima pada node n1
$ns attach-agent $n1 $null0
#perintah untuk menghubungkan antara agent pengirim dengan penerima
$ns connect $udp0 $null0
Kemudian buat aplikasi yang berjalan di atas transport agent tersebut. Pada contoh ini, kita gunakan generator trafik dengan fungsi CBR (Constant Bit Rate).
(27)
#inisialisasi cbr0
set cbr0 [new Application/Traffic/CBR] #ukuran paket datanya 500 byte
$cbr0 set packetSize_ 500
#interval pengiriman antar paket 0.005 s $cbr0 set interval_ 0.005
#paket UDP 0 dikirim dengan fungsi CBR $cbr0 attach-agent $udp0
#mengatur proses sending data? $ns at 0.5 “$cbr0 start”
#sending data dimulai pada 0.5 detik $ns at 4.5 “$cbr0 stop”
Artinya bahwa data akan dikirim setelah 0.5 detik simulasi dari node n0 ke node n1 dan berakhir pada detik 4.5.
2.6.4 Transport Agent
Menurut Wirawan & Indarto (2004), protokol lapisan transport data yang didukung network simulator adalah TCP (Transport Control Protocol), UDP
(Universal Datagram Protocol), dan RTP (Real Time Transport Protocol). Dalam
network simulator 2 mendukung beberapa jenis TCP sender agent yaitu: 1. TCP Sender base (Tahoe TCP)
Agent/TCP
2. Reno TCP
Agent/TCP/Reno
3. New Reno TCP
Agent/TCP/NewReno
4. Vegas TCP
Agent/TCP/Vegas
(28)
Agent/TCP/SACK1 6. FACK (Forward ACK) TCP
Aget/TCP/Fack
Masing-masing sender memeiliki sender agent pada NS memiliki perilaku yang sama dengan implementasi masing-masing jenis TCP di dunia nyata.
2.6.5 Output Simulasi Network Simulator 2
Pada saat satu simulasi berakhir, NS membuat satu atau lebih file output text-based yang berisi detail simulasi jika dideklarasikan pada saat membangun simulasi. Ada dua jenis output NS, yaitu:
1. Network Animator (NAM)
Nam memiliki interface grafis yang mirip dengan CD player (play,
rewind, fast forward, pause, dan lain-lain) dan juga memiliki kontroler kecepatan
tampilan simulasi. Pada Gambar 2.2 merupakan NAM.
(29)
2. Trace file
2.1 Struktur dari trace file
Trace file merupakan isi dari out_voip.tr. trace file berisi data numerik yang akan digunakan untuk analisa simulasi. Gambar 2.3 merupakan contoh isi dari trace file sedangkan Gambar 2.4 adalah Field pada file trace.
Sumber : Jusak, 2012 Gambar 2.3. Contoh isi dari trace file
Sumber : Jusak, 2012 Gambar 2.4. Field pada file trace
Berikut adalah Fungsi dari setiap field pada Gambar 2.4:
1. Field pertama adalah event. Field event merupakan salah satu dari
kemungkinan symbol yang berasosiasi dengan 4 macam event, yaitu:
a. “r” merupakan simbol dari receive berarti bahwa paket telah sampai ke bagian output dari sebuah link.
b. “+” merupakan simbol bahwa paket masuk ke proses antrian. c. “-” merupakan simbol bahwa paket keluar dari proses antrian. d. “d” merupakan simbol bahwa paket tersebut dibuang (drop).
(30)
2. Field kedua menunjuk pada waktu saat sebuah event terjadi.
3. Field ketiga menunjuk pada node input dari sebuah link saat sebuah event
terjadi.
4. Field keempat menunjuk pada node output dari sebuah link saat sebuah event
terjadi.
5. Field kelima menunjuk pada tipe dari paket
6. Field keenam menunjuk pada ukuran dari paket.
7. Field ketujuh menunjuk pada beberapa flag yang akan dijelaskan di belakang.
8. Field kedepalan adalah flow id.
9. Field kesembilan adalah alamat sumber dalam bentuk “node.port”.
10. Field kesepuluh adalah alamat tujuan dalam bentuk “node.port”.
11. Field kesebelas adalah sequence number dari paket data.
12. Field keduabelas adalah id unik dari paket.
2.2 Pemrosesan file data dengan Perl
Menurut Jusak (2012), Perl singkatan dari Practical Extraction and
Report Language merupakan bahasa pemorgraman yang banyak digunakan untuk
pemrosesan data file ASCII pada sistem UNIX. Bahasa pemrograman ini dibuat oleh Larry Wall dengan tujuan untuk memudahkan tugas-tugas administrasi sistem UNIX. Namun perl saat ini telah berevolusi menjadi bahasa pemrograman dan merupakan salah satu alat yang dapat digunakan untuk pemrograman web.
Di bawah ini akan ditunjukkan skrip perl untuk penghitungan throughput
dari koneksi TCP.
$infile=$ARGV[0];
open (DATA,"<$infile") || die "Can't open $infile $!"; while (<DATA>)
(31)
{
$sum= $sum+ $x[5] }
Else {
$throughput=$sum/$granularity; Print STDOUT “ $x[1] throughput \n” $clock=$clock+$granularity;
$sum=0; }
close DATA; exit(0);
Selanjutnya, jalankan prosedur throughput.pl di atas dengan menggunakan file qm.out sebagai input, dan simpan hasil pengolahan ke dalam file bernama thp dengan cara:
perlthroughput.pl qm.out 4 1 > thp
Perintah di atas menunjukkan bahwa analisis queue akan dilakukan pada node 4 dengan nilai granularity sebesar 1s.
(32)
27 BAB III
METODE PENELITIAN
Metode penelitian yang digunakan dalam pengerjaan tugas akhir ini adalah studi kepustakaan, percobaan dan analisis. Dengan ini penulis berusaha untuk mengumpulkan data dan informasi-informasi, serta materi yang bersifat teoritis yang sesuai dengan permasalahan. Hal tersebut diperoleh dari buku-buku, materi perkualiahan, serta literatur dari internet, jurnal dan percobaan dengan bantuan Network Simulator 2.
3.1 Desain Penelitian
Analisis Perbandingan Unjuk Kerja Protokol TCP Vegas dan UDP dengan menggunakan data streaming ini dapat dijelaskan dengan lebih baik melalui blok diagram seperti yang terlihat pada Gambar 3.1:
Gambar 3.1. Blok Diagram
Pada Gambar 3.1 dapat dikelompokkan menjadi 3 bagian yaitu input data, proses dan output yang berupa hasil analisis perbandingan.
(33)
1. Input data
Data inputan yang digunakan adalah data streaming berupa VOIP dan Video. Pembanding kedua protokol didapat dengan melakukan generasi pembangkitan paket data pada NS-2 dengan ukuran packet size, bandwidth dan bit rate yang bervariasi.
2. Proses
Data inputan dijalankan diatas protokol TCP Vegas dan UDP dengan mengunakan pemograman TCL pada NS-2. Setelah didapatkan hasil trace file, hasil trace file diolah berdasarkan parameter uji utilisasi bandwidth, jitter, latency dan packet loss menggunakan libreoffice calc.
3. Output
Menunjukan analisis terhadap data yang dihasilkan berupa analisis perbandingan utilisasi bandwidth, analisis perbandingan latency, analisis perbandingan packet loss, analisis perbandingan jitter, dari protokol TCP Vegas dan UDP.
Analisis diatas disajikan dalam bentuk pembahasan berdasarkan studi literatur dan percobaan yang telah dilakukan pada bagian proses yang nantinya dapat dipaparkan melalui tampilan grafik.
3.2 Prosedur Penelitian
Pada Prosedur penelitian ini menjelaskan tentang langkah-langkah yang dilakukan dalam membuat analisis perbandingan unjuk kerja TCP Vegas dan UDP dengan menggunakan data streaming, seperti diagram alir pada Gambar 3.2:
(34)
Parameter Penelitian
Desain Topologi
Pembuatan Script
Menjalankan Script
Pengolahan Data
Plotting
Gambar 3.2. Skema Prosedur Penelitian
3.2.1 Parameter Penelitian
Dalam tahap ini dilakukan pengumpulan data yang akan digunakan untuk melakukan percobaan. Ada beberapa data yang dibutuhkan meliputi data
streaming yang akan digunakan berupa VOIP dan Video Streaming. Protokol yang akan digunakan adalah TCP Vegas dan UDP. Waktu percobaan yang akan dipakai selama 20 detik. Penentuan nilai paket size, bandwidth, delay dan bit rate
(35)
dalam membandingkan protokol berdasarkan kondisi-kondisi yang telah ditentukan.
Kateristik antrian yang digunakan yaitu drop tail dimana data terakhir yang datang akan dibuang apabila kapasitas dari memori telah penuh. Karena dianggap memiliki memori (buffer) maka perlu mendefinisikan kapasitas antrian sebesar 15.
Parameter pembanding yang digunakan untuk analisis masing-masing protokol yaitu utilisasi bandwidth, latency, packet loss dan jitter.
1. Analisis perbandingan utilisasi bandwidth.
Analisis perbandingan Utilisasi bandwidth pada TCP Vegas dan UDP merupakan hasil akhir yang ingin dicapai dalam penelitian ini. Utilisasi adalah ukuran seberapa sibuk sumber daya yang ada. Utilisasi bandwidth dianalisis berdasarkan seberapa besar prosentase bandwidth suatu link yang menghubungkan antara kedua sisi yaitu sisi pelanggan dan provider. Utilisasi bandwidth dapat dihitung dengan persamaan 2.1.
2. Analisis perbandingan packet loss.
Analisis perbandingan packet loss pada TCP Vegas dan UDP merupakan hasil akhir yang ingin dicapai dalam penelitian ini. Packet loss dianalisis berdasarkan berapa banyak paket yang hilang atau gagal mencapai tujuan pada waktu paket sedang berjalan.
Nilai dari Packet loss dapat dihitung dengan persamaan 2.2. Menurut versi TIPHON (Telecommunications and Internet Protocol Harmonization Over Networks) packet loss dikategorikan seperti pada Tabel 3.1:
(36)
Tabel 3.1. Kategori Packet loss
Kategori Packet loss
Sangat bagus 0%
Bagus 3%
Sedang 15%
Jelek 25%
3. Analisis perbandingan latency.
Analisis perbandingan lateny pada TCP Vegas dan UDPmerupakan hasil akhir yang ingin dicapai dalam penelitian ini. Latency dianalisis berdasarkan berapa waktu tunda dari paket yang diterima sampai tujuan dari masing-masing protokol yang dibandingkan dengan data streaming.
Nilai dari latency dapat dihitung dengan persamaan 2.3. Menurut versi
TIPHON latency dikategorikan seperti pada Tabel 3.2: Tabel 3.2. Kategori Latency
Kategori Latency
Sangat bagus < 150 ms
Bagus 150 s/d 300 ms
Sedang 300 s/d 450 ms
Jelek > 450 ms
4. Analisis perbandingan jitter.
Analisis perbandingan Jitter pada TCP Vegas dan UDP merupakan hasil akhir yang ingin dicapai dalam penelitian ini. Jitter merupakan variansi dari delay, jitter dianalisis berdasarkan keterlambatan transmisi data dari pengirim dan penerima dalam rentang waktu tertentu.
Nilai dari jitter dapat dihitung dengan persamaan 2.4. Menurut versi
(37)
Tabel 3.3. Kategori Jitter
Kategori Jitter
Sangat bagus 0 ms
Bagus 0 s/d 75 ms
Sedang 76 s/d 125 ms
Jelek 125 s/d 225 ms
3.2.2 Desain Topologi
Gambar 3.3. Topologi
Keterangan topologi pada Gambar 3.3 sebagai berikut: 1. Node yang akan di gunakan yaitu n0,n1,n2,n3,n4,n5.
2. Node n0-n2, n1-n2,n3-n4 dan n3-n5 terjadi hubungan duplex-link.
3. Node n2-n3 dan n3-n2 terjadi hubungan simplex-link. 4. Node n0 dialiri dengan data TCP Vegas menuju n4 5. Node n1 dialiri data UDP menuju n5
(38)
Model topologi yang digunakan pada Gambar 3.3 adalah dumb-bell topology. Penggunaan model ini dikarenakan dumb-bell topology mempunyai
single bottleneck link dengan jumlah dua sender dan dua receiver. Tetapi dengan algoritma bandwidth, bit rate dan packet size yang berbeda. Topologi yang digunakan dalam percobaan menggunakan bersifat unicast dimana proses pengiriman dilakukan satu sumber ke satu tujuan. Pada gambar diatas Node n0 dan n1 adalah sender, sedangkan node n4 dan n5 merupakan receiver. Untuk
bottleneck link terdapat pada n2 dan n3.
3.2.3 Pembuatan Script
Pembuatan script adalah pembuatan script .tcl yang disesuaikan dengan data yang sudah ditentukan. Ada 3 langkah dalam pembuatan script yaitu inisialisasi, pembuatan node dan link, penggabungan protokol TCP vegas dengan UDP, dan mengatur jalannya script.
1. Inisialisasi
Simulasi dengan NS selalu dimulai dengan mendefinisikan sebuah
variabel atau object sebagai instance dari kelas Simulator dengan cara sebagai berikut:
set ns [new Simulator]
Untuk menyimpan data keluaran hasil dari simulasi (trace files) dan juga sebuah file lagi untuk kebutuhan simulasi (nam files) akan dibuat dua buah file
dengan perintah “open” seperti berikut:
set tracefile1 [open out_voip.tr w] $ns trace-all $tracefile1
(39)
#Buka NAM trace files
set namfile [open out_voip.nam w] $ns namtrace-all $namfile
Skrip di atas akan membuat file out_voip.tr yang akan digunakan untuk menyimpan data hasil simulasi dan file out_voip.nam untuk menyimpan data hasil visualisasi. Deklarasi ‘w’ pada bagian akhir dari perintah open adalah perintah tulis.
Selanjutnya cara mendeklarasikan prosedur “finish” seperti di bawah ini:
proc finish {} {
global ns tracefile1 namfile $ns flush-trace
close $tracefile1 close $namfile exec nam out.nam & exit 0
}
Perhatikan bahwa prosedur tersebut menggunakan variabel global ns, tracefile1 dan namfile. Perintah flush-trace digunakan untuk menyimpan semua data hasil simulasi ke dalam tracefile1 dan namfile. Perintah exit akan mengakhiri aplikasi dan mengembalikan status dengan angka 0 ke sistem. Perintah exit 0 adalah perintah default untuk membersihkan memori dari sistem, nilai yang lain dapat digunakan misalnya untuk memberikan status gagal.
2. Membuat node dan link
Mendefinisikan sebuah node pada NS pada dasarnya adalah membuat sebuah variabel, sebagai berikut:
(40)
Selanjunya untuk menggunakan node n0 dilakukan dengan cara memanggil variabel $n0. Demikian pula node-node yang lain dapat dibuat dengan cara yang sama dengan kebutuhan dalam simulasi.
Setelah node terbuat, maka langkah selanjutnya adalah membuat link
yang akan membuat hubungan antar node. Sebuah link untuk menghubungkan node $n0 dan $n2 dengan bidirectional link berkapasitas 2Mb dan dengan waktu tunda akibat propagasi sebesar 10ms dapat dibuat dengan cara seperti di bawah ini, begitu pula pada link antar node lainnya.
$ns duplex-link $n0 $n2 2Mb 10ms DropTail $ns duplex-link $n1 $n2 2Mb 10ms DropTail
Apabila diinginkan sebuah link satu arah maka dapat digunakan perintah “simplex-link” untuk menggantikan “duplex-link”
Pada NS, antrian keluaran dari sebuah node didefinisikan sebagai bagian dari sebuah link. Karena itu kita perlu mendefinisikan karakteristik dari queue ini apabila terjadi lebihan data yang datang pada sebuah node. Opsi “DropTail” berarti bahwa data terakhir yang datang akan dibuang apabila kapasitas dari memori telah penuh. Karena link dianggap memiliki memori (buffer), maka kita perlu mendefinisikan kapasitas antrian dari link sebagai berikut:
$ns queue-limit $n2 $n3 15
3. Menggabungkan Aplikasi
Untuk mendefinisikan jenis protokol yang akan digunakan NS-2 menggunakan perintah
set ftp [new Application/FTP] set tcp [new Agent/TCP/Vegas]
(41)
set cbr [new Application/Traffic/CBR] Set udp [new Agent/UDP]
Selanjutnya untuk menggabungkan protokol ini pada sebuah node dari sumber yaitu n0 ke tujuan yaitu n4 dan dari n1 ke n5, menggunakan perintah di bawah ini:
$ns attach-agent $n0 $tcp $ns attach-agent $n4 $tcp $ns attach-agent $n1 $udp $ns attach-agent $n5 $udp
Langkah terakhir adalah menentukan jenis aplikasi dan menggabungkan dengan protokol TCP yang telah didefinisikan sebagai berikut:
$ftp attach-agent $tcp $cbr attach-agent $udp
4. Mengatur jadwal eksekusi pada skrip
Karena NS merupakan simulator kejadian diskrit, maka skrip yang telah dibuat dengan Tcl perlu mendefinisikan waktu eksekusi dari setiap kejadian. Setiap kejadian pada skrip Tcl dapat didefinisikan dengan perintah:
$ns at <waktu><kejadian>
Sehingga untuk menentukan kapan aplikasi FTP pada n0 dan CBR pada n1 mulai mengirimkan data dan kapan selesai mengirimkan data digunakan perintah berikut:
$ns at 0.1 "$cbr start" $ns at 0.1 "$ftp start" $ns at 19.0 "$cbr stop" $ns at 19.0 "$ftp stop"
Pada bagian akhir dari program, prosedur ‘finish’ harus dipanggil dengan indikasi waktu (dalam detik) terminasi dari program, misalnya:
(42)
$ns at 20.0 "finish"
Dengan menggunakan perintah tersebut, aplikasi TCP dan UDP akan mulai berjalan pada detik ke 0.1 dan berhenti pada detik 19.0. Pada detik ke 20 aplikasi selesai. Selanjutnya untuk memulai simulasi atau menjalankan program dapat dilakukan dengan menggunakan perintah:
$ns run
3.2.4 Menjalankan Script di NS-2
Setelah pembuatan script .tcl selesai script dijalankan diatas aplikasi
network simulator 2. Dengan cara mengetik ns voip.tcl pada terminal. Untuk pengujian script, apabila hasil yang ditampilkan berupa gambar visualisasi nam. Maka script yang dibuat sudah benar dan sesuai dengan konfigurasi pada script
.tcl.
Hasil output script .tcl adalah file out_voip.tr dan out_voip.nam. file out_voip.tr adalah tempat untuk menyimpan data hasil simulasi sedangkan file out_voip.nam adalah tempat untuk menyimpan hasil visualisasi.
3.2.5 Pengolahan Data
Setelah Script dijalankan didapat file out_voip.tr yang berisi trace file dari masing-masing parameter. Gambar 3.4 merupakan contoh trace file.
(43)
Gambar 3.4. trace file
Setelah didapatkan trace file (yaitu out.tr) pada Gambar 3.4, selanjutnya dilakukan pengolahan data dengan menggunakan pemrograman perl. Untuk memanggil pemograman perl dapat didefinisikan dengan perintah
perl <nama file>.pl <trace file> <required node>
<granularity> > output file
Selanjutnya dilakukan pengolahan data dengan LibreOffice calc untuk mendapatkan hasil yang diinginkan. Pengolahan data dengan perl dan LibreOffice calc dapat dijelaskan dalam bentuk flowchart sebagai berikut ini:
1. Utilisasi bandwidth
Untuk mendapatkan nilai utilisasi bandwidth, yang dicari lebih dahulu adalah nilai throughput dengan pemograman perl. Gambar 3.5 merupakan
(44)
Mulai
Inisialisasi variabel TCP = 0; UDP =0; clock =0
Cek Trace File
Waktu- clock <= granularity
Tipe_paket == tcp Event == r; Node_input == 2; Node_output == 3;
Jumlahkan ukuran paket tcp
Jumlahkan ukuran paket udp
Perhitungan throughput udp dan tcp
Cetak throughput udp dan tcp
Selesai
Perhitungan throughput udp dan tcp
Cetak throughput udp dan tcp
Clock=clock+granularity; udp=0; tcp=0 F F T T T F T
Gambar 3.5. Flowchart Throughput
Penjelasan flowchart pada Gambar 3.5: a. Mulai
(45)
c. Pengecekan data trace file, dimana trace file berisi data keluaran dari hasil simulasi. Jika masih ada data pada baris, maka proses dilanjutkan pada proses berikutnya. Jika tidak ada dilakukan perhitungan throughput. Dan hasilnya dicetak.
d. Jika waktu yang dimasukkan kurang dari sama dengan granularity maka dilanjutkan pada proses selanjutnya. Jika tidak sama dengan granularity maka dilanjutkan ke proses h.
e. Pengecekan kolom event yaitu x[0] (kolom ke-0) dengan status “r”, x[2] (kolom ke-2) adalah node sumber, dan x[3] (kolom ke-3) adalah node tujuan. Jika ketiga kondisi terpenuhi maka dilanjutkan ke proses berikutnya, jika tidak kembali ke proses c.
f. Jika kolom ke-4 sama dengan TCP maka dilanjutkan ke proses berikutnya jika bukan TCP maka dijumlahkan dan hasilnya disimpan dalam variabel UDP. Dan proses kembali ke c.
g. Menjumlahkan data TCP dan menyimpan hasilnya kedalam variabel TCP. Dilanjutkan dengan kembali ke c.
h. Dilakukan perhitungan throughput. i. Dicetak hasil perhitungan.
j. Proses dilanjukan dengan menambah variabelclock dengan nilai granularity
(46)
Setelah program throughput dijalankan, didapatkan nilai dari throughput
seperti Tabel 3.4.
Tabel 3.4. Hasil Throughput bandwidth 70Kb
Waktu Throughput TCP Vegas UDP 1,001783 1280 5920
2,0016 2080 6560 3,005566 160 8640 4,00064 640 8000 5,006354 960 7680 6,004423 800 7840 7,004354 800 8000 8,005211 960 7680 9,00328 800 7840 10,000583 800 8000 11,004069 800 7840 12,002137 800 7840 13,002069 800 8000 14,002926 800 7840 15,000994 800 7840 16,000926 480 8320 17,001783 960 7680 18,007497 640 8000 19,005566 800 7840 19,848114 640 2560
Setelah didapatkan nilai throughput selanjutnya dilakukan perhitungan menggunakan LibreOffice calc untuk mendapatkan nilai dari utilisasi bandwidth.
(47)
Mulai
Open Thp.ods
Utilisasi Bandwidth
Selesai
Gambar 3.6. FlowchartUtilisasi bandwidth
Penjelasan Gambar 3.6 flowchart utilisasi bandwidth: a. Mulai
b. Membuka file thp.ods. thp berisi file pemrosesan throughput dengan pemograman perl.
c. Utilisasi bandwidth dihitung dengan menggunakan persamaan 2.1. Sebagai contoh perhitungan utilisasi bandwidth pada detik pertama:
Bandwidth 70 Kb = = 8750 B
Utilisasi Bandwidth = x100%
= x 100% = 14,63 %
Perhitungan dilakukan sampai dengan detik ke-20 setelah itu di rata-rata untuk mendapatkan nilai utilisasi pada setiap percobaan.
(48)
d. Didapatkan nilai utilisasi bandwidth. e. Selesai
2. Packet loss
Mulai
Inisialisasi variabel TCP = 0; UDP =0; tcploss
=0; udploss =0;
Cek Trace File
Waktu <=20
Event == r; Node_input == 0; Node_output == 2; Tipe_paket == tcp;
Jumlahkan ukuran paket tcp Jumlahkan ukuran paket udp Perhitungan packet loss
udp dan tcp
Cetak udploss dan tcploss Selesai F F T T F T
Event == r; Node_input == 1; Node_output == 2; Tipe_paket == udp;
Event == d; Node_input == 2; Node_output == 3; Tipe_paket == tcp;
Event == d; Node_input == 2; Node_output == 3; Tipe_paket == udp;
Jumlahkan ukuran paket tcploss
Jumlahkan ukuran paket udploss
T
F
F
T T
(49)
Gambar 3.7 merupakan flowchart keseluruhan untuk mendapatkan nilai
packet loss dengan mengunakan pemrograman perl. Program ini digunakan untuk mencari nilai packet loss pada video dan voip.
Penjelasan Gambar 3.7 flowchart packet loss: a. Mulai
b. Inisialisasi variabel TCP, UDP, udploss, dan tcploss
c. Pengecekan data trace file dimana trace file berisi data keluaran dari hasil simulasi. Jika masih ada data pada baris, maka proses dilanjutkan pada proses berikutnya. Jika tidak ada dilakukan perhitungan packet loss. Dan hasilnya dicetak.
d. Jika waktu yang dimasukkan kurang dari sama dengan 20 maka dilanjutkan pada proses selanjutnya. Jika lebih dari 20 maka dilakukan perhitungan packet loss. Dan hasilnya dicetak.
e. Pengecekan kolom event yaitu x[0] (kolom ke-0) dengan status “r”, x[2] (kolom ke-2) adalah node sumber, x[3] (kolom ke-3) adalah node tujuan. x[4] (kolom ke-4) jenis protokol adalah TCP. Jika kondisi terpenuhi maka data TCP dijumlahkan dan disimpan hasilnya kedalam variabel sum1. Setelah itu dilanjutkan dengan kembali ke c.
f. Jika bukan TCP maka dilakukan pengecekan kolom event yaitu x[0] (kolom ke-0) dengan status “r”, x[2] (kolom ke-2) adalah node sumber, x[3] (kolom ke-3) adalah node tujuan. x[4] (kolom ke-4) jenis protokol adalah UDP, jika kondisi terpenuhi maka dijumlahkan dan hasilnya disimpan dalam variabel sum2. Dan proses kembali ke c.
(50)
g. Jika kondisi diatas tidak terpenuhi maka dilakukan pengecekan kolom
event yaitu x[0] (kolom ke-0) dengan status “d”, x[2] (kolom ke-2) adalah node sumber, x[3] (kolom ke-3) adalah node tujuan. x[4] (kolom ke-4) jenis protokol adalah UDP, jika kondisi terpenuhi maka dijumlahkan dan hasilnya disimpan dalam variabel drop2.
h. Jika kondisi diatas tidak terpenuhi maka dilakukan pengecekan kolom
event yaitu x[0] (kolom ke-0) dengan status “d”, x[2] (kolom ke-2) adalah node sumber, x[3] (kolom ke-3) adalah node tujuan. x[4] (kolom ke-4) jenis protokol adalah TCP, jika kondisi terpenuhi maka dijumlahkan dan hasilnya disimpan dalam variabel drop1. Dan proses dikembalikan ke langkah c.
Setelah program perl packet loss dijalankan, didapatkan nilai dari packet loss seperti pada Tabel 3.5:
Tabel 3.5. Hasil Packet Loss bandwidth 70 Kb
TCP Vegas UDP Packet Loss 6,25% 0,11%
3. Latency
Untuk mendapatkan nilai latency, yang dicari lebih dahulu adalah nilai paket terkirim dan paket diterima. Gambar 3.8 merupakan flowchart paket terkirim sedangkan Gambar 3.9 merupakan flowchart paket diterima pada pemrograman perl.
(51)
Mulai
Cek Trace File
Cetak waktu pengiriman tcp
Waktu <=20
Event == r; Node_input == 0; Node_output == 2; Tipe_paket == tcp;
Selesai
F
T F
T
T F
Gambar 3.8. Flowchart paket terkirim
Penjelasan Gambar 3.8 flowchart paket terkirim a. Mulai
b. Pengecekan data out.tr dimana out.tr berisi data keluaran dari hasil simulasi. Jika masih ada data pada baris, maka proses dilanjutkan pada proses berikutnya. Jika tidak ada proses selesai.
c. Jika waktu kurang dari sama dengan 20 maka dilanjutkan pada proses selanjutnya. Jika tidak lebih dari 20 maka kembali pada proses b.
d. Pengecekan kolom event yaitu x[0] (kolom ke-0) dengan status ”r”, x[2] (kolom ke-2) adalah node sumber, dan x[4] (kolom ke-4) adalah jenis
(52)
protokol. Jika ketiga kondisi terpenuhi maka dilanjutkan ke proses berikutnya, jika tidak kembali ke proses b.
e. Mencetak waktu dan id unik. Proses dilanjutkan ke langkah b.
Mulai
Cek Trace File
Cetak waktu pengiriman tcp
Waktu <=20
Event == r; Node_input == 0; Node_output == 2; Tipe_paket == tcp;
Selesai
F
T F
T
T F
Gambar 3.9. Flowchart paket diterima
Penjelasan Gambar 3.9 flowchart paket diterima: a. Mulai
b. Pengecekan data out.tr dimana out.tr berisi data keluaran dari hasil simulasi. Jika masih ada data pada baris, maka proses dilanjutkan pada proses berikutnya. Jika tidak ada proses selesai.
(53)
c. Jika waktu kurang dari sama dengan 20 maka dilanjutkan pada proses selanjutnya. Jika tidak lebih dari 20 maka kembali pada proses b.
d. Pengecekan kolom event yaitu x[0] (kolom ke-0) dengan status “r”, x[3] (kolom ke-3) adalah node tujuan, dan x[4] (kolom ke-4) adalah jenis protokol. Jika ketiga kondisi terpenuhi maka dilanjutkan ke proses berikutnya, jika tidak kembali ke proses b.
e. Mencetak waktu dan id unik. Proses dilanjutkan ke langkah b.
Setelah program dijalankan didapatkan hasil seperti Tabel 3.6 dan Tabel 3.7. Tabel 3.6 dan Tabel 3.7 merupaka sebagian data yang ada.
Tabel 3.6. Hasil Paket Diterima
Event Waktu From node To node Pkt Type Packet Size Packet Id r 0,207851 3 4 tcp 160 1 r 0,390709 3 4 tcp 160 12 r 0,573566 3 4 tcp 160 23 r 0,591851 3 4 tcp 160 24 r 0,610137 3 4 tcp 160 25 r 0,792994 3 4 tcp 160 38 r 0,829566 3 4 tcp 160 40 r 0,866137 3 4 tcp 160 42 r 1,048994 3 4 tcp 160 55 r 1,06728 3 4 tcp 160 56 r 1,122137 3 4 tcp 160 59 r 1,140423 3 4 tcp 160 60 r 1,19528 3 4 tcp 160 63 r 1,213566 3 4 tcp 160 64 r 1,396423 3 4 tcp 160 77 r 1,432994 3 4 tcp 160 80 r 1,487851 3 4 tcp 160 84 r 1,524423 3 4 tcp 160 87
(54)
Tabel 3.7. Hasil Paket Terkirim
Event Waktu From node
To node
Pkt Type
Pkt
Size Pkt Id r 0,11064 0 2 tcp 160 1 r 0,293383 0 2 tcp 160 12 r 0,47624 0 2 tcp 160 23 r 0,47688 0 2 tcp 160 24 r 0,47752 0 2 tcp 160 25 r 0,659097 0 2 tcp 160 38 r 0,677383 0 2 tcp 160 40 r 0,695669 0 2 tcp 160 42 r 0,878526 0 2 tcp 160 55 r 0,879166 0 2 tcp 160 56 r 0,915097 0 2 tcp 160 59 r 0,915737 0 2 tcp 160 60 r 0,951669 0 2 tcp 160 63 r 0,952309 0 2 tcp 160 64 r 1,134526 0 2 tcp 160 77 r 1,152811 0 2 tcp 160 80 r 1,207669 0 2 tcp 160 84 r 1,225954 0 2 tcp 160 87 r 1,280811 0 2 tcp 160 91 r 1,518526 0 2 tcp 160 108
Setelah didapatkan waktu terkirim dan waktu diterima selanjutnya dilakukan perhitungan menggunakan LibreOffice calc untuk mendapatkan nilai
latency. Perhitungan ini digunakan untuk mendapatkan nilai dari latency. Gambar 3.11 merupakan flowchart dari latency.
(55)
Mulai
Kolom2=kolom2 'sheet2’
Nilai latency
Selesai Kolom1-kolom1 'sheet2’
Cetak 0 F
T
Gambar 3.10. Flowchart Latency
Penjelasan Gambar 3.10 flowchart latency: a. Mulai
b. Jika nilai kolom2 pada sheet 1 sama dengan kolom2 pada sheet 2 maka dilanjutkan pada proses berikutnya, kolom2 adalan ID unik dari paket data. Tetapi jika nilai kolom 2 tidak sama dengan kolom2 pada sheet2 maka hasil dicetak 0 dan proses selesai .
c. Kolom1 pada sheet 1 – kolom1 pada sheet 2. Kolom1 pada sheet 1 adalah waktu dimana paket diterima. Sedangkan kolom1 pada sheet 2 adalah waktu dimana paket dikirim. Sebagai contoh perhitungan latency pada detik ke-0 seperti pada Gambar 3.11. Perhitungan ini dilakukan sampai pada detik ke-20
(56)
Gambar 3.11. Perhitungan Latency
d. Didapatkan nilai latency. e. Selesai.
4. Jitter
Setelah didapatkan nilai latency. Selanjutnya dilakukan perhitungan nilai
jitter. Gambar 3.12 merupakan flowchart dari jitter.
Mulai
Open Latency.ods
Jitter
Selesai Delay A – Delay B
(57)
Pada Gambar 3.12 perhitungan nilai jitter didapatkan dengan cara nilai
latency dari paket sekarang dikurangi dengan latency paket sebelumnya (persamaan 2.4).
3.2.6 Plotting
Setelah mendapatkan nilai utilisasi bandwidth, jitter, latency dan packet loss, selanjutnya adalah menggambarkan kedalam grafik dengan menggunakan
LibreOffice calc. LibreOffice calc digunakan untuk memudahkan dalam melakukan perbandingan.
(58)
53
BAB IV
HASIL DAN PEMBAHASAN
Pembahasan yang dilakukan merupakan hasil dari percobaan terhadap parameter-parameter yang telah ditentukan. Setelah itu dilakukan analisis untuk mendapat perbandingan unjuk kerja protokol TCP Vegas dan UDP dengan
menggunakan data streaming.
4.1 Kebutuhan Sistem
Sebelum dilakukan simulasi dan analisis perbandingan unjuk kerja
protokol TCP Vegas dan UDP dengan menggunakan data streaming dibutuhkan
perangkat keras dan perangkat lunak dengan kondisi tertentu agar simulasi dapat berjalan dengan baik. Adapun kebutuhan perangkat lunak dan perangkat keras sebagai berikut.
4.1.1 Kebutuhan Perangkat Keras
Syarat minimal perangkat keras yang digunakan untuk tugas akhir ini seperti pada Tabel 4.1:
Tabel 4.1. Kebutuhan Perangkat Keras
Perangkat Keras Spesifikasi
Processor Dual core
Memori 1GB RAM
(59)
4.1.2 Kebutuhan Perangkat Lunak
Pada Tabel 4.2 akan dijelaskan tentang beberapa kebutuhan perangkat lunak yang menunjang dalam tugas akhir ini.
Tabel 4.2. Kebutuhan Perangkat Lunak
Perangkat Lunak Uraian
Network Simulator 2 Aplikasi yang digunakan untuk menjalankan proses
simulasi
Perl Aplikasi yang digunakan untuk mengolah file .tr yang
merupakan data output dari simulasi.
Libreoffice Calc Aplikasi yang digunakan untuk mengolah hasil dari perl
dan membuat grafik dari data hasil simulasi.
4.2 Data Simulasi
Data simulasi ini digunakan untuk menjalankan percobaan dalam simulasi.
Data streaming yang akan dijalankan di atas TCP Vegas dan UDP adalah VOIP
dan Video. Waktu yang digunakan untuk menjalankan simulasi di bawah ini selama 20 detik. Untuk mendapatkan hasil yang lebih akurat percobaan dilakukan
sebanyak 5 kali di setiap data streaming. Tabel 4.3 dan Tabel 4.4 merupakan
data-data yang akan digunakan:
Tabel 4.3. Paket size dan bit rate
Data Streaming Data
Protokol
TCP Vegas UDP
VOIP Paket Size 160 Kb 160 Kb
Bit rate 64 Kb 64 Kb
VIDEO Paket Size 1400 Kb 1400 Kb
(60)
Tabel 4.4. Ukuran bandwidth
Percobaan Data
Streaming Bandwidth
1
VOIP
70 Kb
2 86 Kb
3 92 Kb
4 103 Kb
5 256 Kb
1
VIDEO
300 Kb
2 340 Kb
3 380 Kb
4 420 Kb
5 840 Kb
4.3 Hasil dan Pembahasan
Setelah melakukan percobaan sesuai dengan data pada Tabel 4.3 dan Tabel 4.4 didapatkan hasil seperti pada Tabel 4.5 dan Tabel 4.6:
Tabel 4.5. Hasil Perhitungan Utilisasi bandwidth dan Packet LossVOIP
Perc Bandwidth
Parameter
Utilisasi Bandwidth Packet Loss
TCP Vegas UDP TCP Vegas UDP
1 70 Kb 9,60% 85,67% 6,25% 0,11%
2 86 Kb 23,07% 69,80% 1,27% 0,21%
3 92 Kb 29,15% 65,39% 0,24% 0,32%
4 103 Kb 35,39% 58,78% 0,00% 0,00%
(61)
Tabel 4.6. Hasil Perhitungan Latency dan JitterVOIP
Perc Bandwidth
Parameter
Latency Jitter
TCP Vegas UDP TCP Vegas UDP
1 70 Kb 276,86 ms 288 ms 42,16 ms 36,11 ms
2 86 Kb 197,8 ms 184,54 ms 32,98 ms 29,94 ms
3 92 Kb 192,85 ms 188,73 ms 29,38 ms 29,12 ms
4 103 Kb 149,46 ms 147,71 ms 22,13 ms 20,02 ms
5 256 Kb 68,56 ms 67,98 ms 7,57 ms 6,99 ms
Pada tabel 4.5 dan 4.6 merupakan hasil perhitungan Utilisasi bandwidth,
packet loss, latency dan jitter pada data streaming VOIP dengan bandwidth 70 Kb, 86 Kb, 92 Kb, 103 Kb dan 256 Kb.
Tabel 4.7. Hasil Perhitungan Utilisasi bandwidth dan Packet Loss Video
Perc Bandwidth
Parameter
Utilisasi Bandwidth Packet Loss
TCP Vegas UDP TCP Vegas UDP
1 300 Kb 17,73% 77,12% 5,83% 3,79%
2 340 Kb 24,21% 70,12% 2,61% 0,47%
3 380 Kb 31,39% 62,86% 0,93% 0,33%
4 420 Kb 37,07% 57,33% 0,00% 0,00%
(62)
Tabel 4.8. Hasil Perhitungan Latency dan JitterVideo
Perc Bandwidth
Parameter
Latency Jitter
TCP Vegas UDP TCP Vegas UDP
1 300 Kb 341,33 ms 325,6 ms 57,81 ms 43,2 ms
2 340 Kb 296,13 ms 293,43 ms 40,94 ms 38,32 ms
3 380 Kb 273,51 ms 270,5 ms 37,02 ms 33,83 ms
4 420 Kb 245,5 ms 231,51 ms 27,22 ms 24,59 ms
5 840 Kb 106,15 ms 101,63 ms 12,41 ms 10,62 ms
Pada tabel 4.7 dan 4.8 merupakan hasil perhitungan Utilisasi bandwidth,
packet loss, latency dan jitter pada data streaming video dengan bandwidth 300 Kb, 340 Kb, 380 Kb, 420 Kb dan 840 Kb.
Di bawah ini adalah hasil percobaan data streaming VOIP berdasarkan
parameter uji Utilisasi bandwidth, packet loss, latency dan jitter yang disajikan
dalam bentuk grafik, untuk memudahkan dalam membandingkan kedua protokol.
4.3.1 Utilisasi bandwidth
Sebelum didapatkan nilai dari Utilisasi bandwidth terlebih dahulu dicari
nilai throughput, dibawah ini hasil dari nilai throughput.
(63)
(64)
Gambar 4.3. Throughput bandwidth 92Kb Gambar 4.4. Throughput bandwidth 103Kb
Gambar 4.5. Throughput bandwidth 256 Kb
Gambar 4.1-Gambar 4.5 adalah grafik nilai throughput dari TCP Vegas
dan UDP dengan data VOIP. Gambar 4.1 adalah nilai throughput dengan
bandwidth 70 Kb. Gambar 4.2 nilai throughput dengan bandwidth 86 Kb. Gambar
4.3 adalah nilai throughput dengan bandwidth 92 Kb, Gambar 4.4 nilai
throughput dengan bandwidth 103Kb. Sedangkan Gambar 4.5 nilai throughput
(65)
(66)
Gambar 4.6. Throughput bandwidth 300Kb Gambar 4.7. Throughput bandwidth 340Kb
Gambar 4.8. Throughput bandwidth 380Kb Gambar 4.9. Throughput bandwidth 420Kb
Gambar 4.10. Throughput bandwidth 840Kb
Gambar 4.6 – Gambar 4.10 adalah grafik nilai throughput dari TCP Vegas
dan UDP dengan data Video. Gambar 4.6 adalah nilai throughput dengan
bandwidth 300 Kb. Gambar 4.7 nilai throughput dengan bandwidth 340 Kb.
(67)
throughput dengan bandwidth 420 Kb sedangkan Gambar 4.10 merupakan nilai throughput dengan bandwidth 840 Kb.
Grafik throughput pada protokol UDP dan TCP Vegas menunjukkan
bahwa nilai throughput protokol UDP memiliki nilai konstan 8000 Bps untuk data
streaming VoIP dan 32000 Bps untuk data streaming video selama pengiriman
berlangsung. Throughput TCP Vegas pada percobaan pertama sampai keempat
pada data streaming VoIP (Gambar 4.1-Gambar 4.4) masing-masing bernilai
sekitar 750, 2750, 3500 dan 4875 Bps sedangkan untuk data streaming video
(Gambar 4.6-Gambar 4.9) masing-masing bernilai 5500, 10500, 15500 dan 20500 Bps.
Seperti terlihat pada Gambar 4.1 – Gambar 4.8, nilai karakteristik throughput pada TCP Vegas berbeda dengan karakteristik throughput pada UDP.
Pada TCP Vegas pertambahan nilai throughput berbanding lurus dengan kenaikan
bandwidth. Hal ini disebabkan karena aplikasi VOIP dan Video streaming pada
protokol UDP dalam simulasi digunakan constant bit rate (CBR) sehingga
throughput pada protokol UDP mengidentifikasi nilai yang konstan. Sedangkan
pada protokol TCP Vegas nilai throughput bertambah seiring dengan
pertambahan bandwidth, hal ini disebabkan adanya algoritma congestion control
pada TCP Vegas yang mana protokol berusaha menyelesaikan throughput dengan
kapasitas link (bandwidth) .
Setelah didapatkan nilai throughput selanjutnya dihitung dengan
persamaan 2.1 untuk mendapatkan nilai Utilisasi bandwidth. Rata-rata Utilisasi
(68)
Gambar 4.11. Grafik perbandingan Utilisasi bandwidth VOIP
Gambar 4.12. Grafik perbandingan Utilisasi bandwidth Video
Gambar 4.11 menunjukkan grafik perbandingan utilisasi bandwidth dari
protokol TCP Vegas dan UDP dengan menggunakan data streaming VOIP
sedangkan Gambar 4.12 nilai utilisasi bandwidth dengan menggunakan data
streaming Video. Pada saat bandwidth kecil utilisasi bandwidth UDP nampak lebih besar daripada utilisasi pada TCP Vegas. Namun pada saat bandwidth
0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00% 70.00% 80.00% 90.00%
1 2 3 4 5
U ti lis as i B an d w id th Bandwidth TCP VEGAS UDP 0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00% 70.00% 80.00% 90.00%
1 2 3 4 5
U til is as i b an d w id th Bandwidth TCP VEGAS UDP
(69)
bottleneck link semakin besar maka nampak utilisasi bandwidth TCP Vegas lebih besar daripada UDP.
Hal ini disebabkan karena UDP menggunakan menggunakan paket CBR yang punya kecepatan konstan sehingga ketika bandwidth pada bottleneck link
besar kecepatan bandwidth tetap konstan, dengan demikian utilisasi bandwidth
pada UDP akan semakin kecil ketika bandwidth bertambah. Karana UDP tidak memiliki mekanisme congestion control maka pengiriman data akan tetap konstan. Sementara itu TCP Vegas menggunakan congestion control dalam pengiriman data. Pada saat bandwidth bottleneck link diperbesar mekanisme congestion control mengatur kecepatan pengiriman data mengikuti besarnya bandwidth. Dengan demikian pada TCP Vegas saat bandwidth diperbesar maka utilisasi bandwidth akan semakin meningkat.
4.3.2 Packet loss
Gambar 4.13. Grafik Perbandingan Packet loss VOIP
0.00% 1.00% 2.00% 3.00% 4.00% 5.00% 6.00% 7.00%
1 2 3 4 5
P
ak
et
lo
ss
Bandwidth
TCP VEGAS UDP
(70)
Gambar 4.14. Grafik perbandingan Packet loss Video
Gambar 4.13 menunjukkan grafik perbandingan Packet loss dari protokol
TCP Vegas dan UDP dengan menggunakan data streaming VOIP sedangkan
Gambar 4.14 menunjukkan perbandingan packet loss dengan menggunakan data
streaming Video. Berdasarkan hasil pengujian didapatkan bahwa nilai packet loss
pada TCP Vegas lebih tinggi dibandingkan nilai packet loss pada UDP. Hal ini
dikarenakan kapasitas bandwidth pada bottleneck link banyak digunakan oleh
UDP selama proses pengiriman. Sehingga TCP Vegas hanya menempati sebagian
kecil total bandwidth yang tersedia. Misalnya untuk uji coba dengan bandwidth 70
Kb Utilisasi bandwidth TCP Vegas hanya 9,6% sedangkan utilisasi UDP mencapai 85,67%. Hal ini ditunjukkan pada Tabel 4.5.
Menurut Telecommunications and Internet Protocol Harmonization Over
Networks (TIPHON) nilai perbandingan packet loss pada VOIP dan Video masuk
pada kategori bagus karena besarnya packet loss pada VoIP masih dibawah 7 %.
Sedangkan untuk Video dibawah 6%.
0.00% 1.00% 2.00% 3.00% 4.00% 5.00% 6.00% 7.00%
1 2 3 4 5
P
ak
et
L
o
ss
Bandwidth
TCP VEGAS UDP
(71)
4.3.3 Latency
Gambar 4.15. Grafik perbandingan Latency VOIP
Gambar 4.16. Grafik perbandingan Latency Video
Gambar 4.15 menunjukkan grafik perbandingan latency dari protokol
TCP Vegas dan UDP dengan menggunakan data streaming VOIP. Sedangkan
Gambar 4.16 menunjukkan grafik perbandingan latency dengan mengunakan data
streaming Video. Berdasarkan hasil pengujian didapatkan nilai latency pada TCP
Vegas lebih tinggi dibandingkan nilai latency pada UDP. Gambar 4.1-Gambar 4.8
menunjukkan bahwa nilai throughput UDP lebih besar daripada TCP Vegas
0 50 100 150 200 250 300
1 2 3 4 5
L ate n cy ( m s) Bandwidth TCP VEGAS UDP 0 50 100 150 200 250 300 350
1 2 3 4 5
L ate n cy ( m s) Bandwidth TCP VEGAS UDP
(72)
sehingga secara keseluruhan latency TCP Vegas menjadi lebih tinggi karena paket
atau segmen TCP menunggu lama pada buffer node bottleneck link. (The VINT
Project, 2011) Paket data TCP akan dibuang ketika kapasitas buffer pada node
telah penuh sehingga menyebabkan packetloss TCP Vegas tinggi.
Menurut Telecommunications and Internet Protocol Harmonization Over
Networks (TIPHON) nilai perbandingan latency pada VOIP masuk pada kategori
bagus karena besarnya latency masih dibawah 300 ms. Sedangkan untuk Video
tergolong mempunyai kategori sedang karena nilai latency dibawah 350 ms.
4.3.4 Jitter
Gambar 4.17. Grafik perbandingan Jitter VOIP
0 10 20 30 40 50
1 2 3 4 5
Ji
tt
er
(
m
s)
Bandwidth
TCP VEGAS UDP
(1)
sehingga secara keseluruhan latency TCP Vegas menjadi lebih tinggi karena paket atau segmen TCP menunggu lama pada buffer node bottleneck link. (The VINT Project, 2011) Paket data TCP akan dibuang ketika kapasitas buffer pada node telah penuh sehingga menyebabkan packet loss TCP Vegas tinggi.
Menurut Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) nilai perbandingan latency pada VOIP masuk pada kategori bagus karena besarnya latency masih dibawah 300 ms. Sedangkan untuk Video tergolong mempunyai kategori sedang karena nilai latency dibawah 350 ms.
4.3.4 Jitter
Gambar 4.17. Grafik perbandingan Jitter VOIP 0
10 20 30 40 50
1 2 3 4 5
Ji
tt
er
(
m
s)
Bandwidth
TCP VEGAS UDP
(2)
66
Gambar 4.18. Grafik perbandingan Jitter Video
Gambar 4.17 menunjukkan grafik perbandingan jitter dari protokol TCP Vegas dan UDP dengan menggunakan data streaming VOIP. Sedangkan gambar 4.18 perbandingan jitter dengan mengunakan data streaming Video. Berdasarkan hasil pengujian didapatkan nilai jitter pada TCP Vegas lebih tinggi dibandingkan nilai jitter pada UDP. Hal ini dikarenakan besarnya interferensi yang terjadi dari protokol UDP sehingga delay TCP Vegas mengalami variasi yang tinggi. Delay paket sebelumnya kecil karena ada bandwidth yang bisa digunakan oleh TCP Vegas sedangkan paket selanjutnya harus menunggu lebih lama untuk proses pengiriman karena berada dalam antrian pada buffer. Hal inilah yang menyebabkan jitter TCP Vegas lebih tinggi daripada UDP.
Menurut Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) nilai perbandingan jitter pada VOIP dan Video masuk pada kategori bagus karena besarnya jitter masih dibawah 60ms.
0 10 20 30 40 50 60 70
1 2 3 4 5
Ji
tte
r
(m
s)
Bandwidth
TCP VEGAS UDP
(3)
67 BAB V PENUTUP
5.1 Kesimpulan
Berdasarkan hasil percobaan yang telah dilakukan, dapat disimpulkan sebagai berikut :
1. Simulasi sistem dengan protokol TCP Vegas dan UDP dengan menggunakan data streaming pada network simulator 2 telah dilakukan.
2. Kesimpulan analisis perbandingan TCP Vegas dan UDP pada data streaming
dengan parameter uji Utilisasi bandwidth, packet loss, latency dan jitter
untuk ukuran paket data yang bervariasi sebagai berikut a. Utilisasi bandwidth
Nilai prosentase Utilisasi bandwidth pada UDP lebih besar dibandingkan TCP Vegas untuk setiap percobaan nilai bandwidth 70Kb, 86Kb, 92Kb dan 63Kb. Sedangkan pada saat bandwidth bernilai diatas 256Kb prosentase utilisasi bandwidth pada TCP Vegas lebih besar dibanding UDP. Hal ini dikarenakan adanya congestion control pada TCP Vegas yang berfungsi untuk membatasi throughput, sedangkan UDP tidak memilik congestion control.
b. Packet loss
Prosentase nilai packet loss pada TCP Vegas lebih tinggi dibandingkan prosentase UDP, hal ini dikarenakan kapasitas bandwidth pada bottleneck link
banyak digunakan oleh UDP selama proses pengiriman. Sehingga TCP Vegas hanya menempati sebagian kecil total bandwidth yang tersedia
(4)
68
c. Latency
Nilai latency pada TCP Vegas lebih tinggi dibandingkan nilai latency
pada UDP. Gambar 4.1-Gambar 4.8 menunjukkan bahwa nilai throughput
UDP lebih besar daripada TCP Vegas sehingga secara keseluruhan latency
TCP Vegas menjadi lebih tinggi karena paket atau segmen TCP menunggu lama pada buffer node bottleneck link. (The VINT Project, 2011) Paket data TCP akan dibuang ketika kapasitas buffer pada node telah penuh sehingga menyebabkan packet loss TCP Vegas tinggi.
d. Jitter
Nilai jitter pada TCP Vegas lebih tinggi dibandingkan nilai jitter UDP, hal ini dikarenakan besarnya interferensi yang terjadi dari protokol UDP sehingga delay TCP Vegas mengalami variasi yang tinggi. Delay paket sebelumnya kecil karena ada bandwidth yang bisa digunakan oleh TCP Vegas sedangkan paket selanjutnya harus menunggu lebih lama untuk proses pengiriman karena berada dalam antrian pada buffer. Hal inilah yang menyebabkan jitter TCP Vegas lebih tinggi daripada UDP.
5.2. Saran
Sebagai pengembangan dari penelitian yang dilakukan, maka penulis memberikan saran sebagai berikut:
1. Perlu dilakukan analisis berdasarkan karakteristik antrian dari kedua protokol untuk memahami pola kedua protokol UDP dan TCP Vegas didalam konteks sistem antrian.
2. Protokol dijalankan dari dua sisi pengguna sehingga menyerupai interaksi yang terjadi secara real.
(5)
69
Abdul Syarif, A. S. (2008). Quality of Service (Qos) Teknologi Streaming untuk Aplikasi Surveillance. SNASTI.
Arijasa, R. S. (2011). Analisis Perbandingan Performansi TCP Vegas dan TCP Veno pada Jaringan Wireless.
Austerberry, D. (2005). The Technology of Video and Audio Streaming. USA: Focal Press.
Fatoni. (2011). Analisis Kualitas Layanan Jaringan Internet. Jurnal universitas Bima Darma .
Indarto, A. B. (2004). Mudah Membangun Simulasi dengan Network Simulator 2. Yogyakarta: Andi.
Jusak. (2012). Buku Panduan Kuliah: Desain dan Unjuk Kerja Jaringan Komputer STIKOM Surabaya.
Mazhar Tayel, A. A. (2008). Effect of TCP and UDP Parameters on the quality of video streaming delivery over the internet. Wseas Transaction on Communication, 653-662.
Riadi, I., & Wicaksono, W. P. (2011). Implementasi Quality of Service Menggunakan Metode Hierarchical Token Bucket. Yogyakarta: Universitas Ahmad Dahlan.
(6)
70
Sofana, I. (2009). Cisco CCNA & Jaringan Komputer. Bandung: Informatika.
The VINT Project. (2011, November 4). The ns Manual. formerly ns Notes and Documentation.