Analisis perbandingan unjuk kerja TCP Reno dan TCP Vegas pada jaringan kabel

i

ANALISIS PERBANDINGAN UNJUK KERJA TCP RENO DAN TCP VEGAS PADA JARINGAN KABEL

SKRIPSI

Diajukan Untuk Memenuhi Salah Satu Syarat Memperoleh Gelar Sarjana Komputer Program Studi Teknik Informatika

DISUSUN OLEH :

Theo Mahardian Bangkit Sugiri 125314061

PROGRAM STUDI TEKNIK INFORMATIKA JURUSAN TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI

UNIVERSITAS SANATA DHARMA YOGYAKARTA

ii

PERFORMANCE EVALUATION BETWEEN TCP RENO AND TCP VEGAS IN WIRED NETWORK

A THESIS

Presented as Partial Fulfillment of Requirements to Obtain Sarjana Komputer Degree in Informatics Engineering Department

By:

Theo Mahardian Bangkit Sugiri 125314061

INFORMATICS ENGINEERING STUDY PROGRAM INFORMATICS ENGINEERING DEPARTMENT

FACULTY SCIENCE AND TECHNOLOGY SANATA DHARMA UNIVERSITY

YOGYAKARTA 2016

iii

HALAMAN PERSETUJUAN

SKRIPSI

ANALISIS PERBANDINGAN UNJUK KERJA TCP RENO DAN TCP VEGAS PADA JARINGAN KABEL

Oleh :

Theo Mahardian Bangkit Sugiri 125314061

Telah disetujui oleh :

Dosen Pembimbing,

iv SKRIPSI

ANALISIS PERBANDINGAN UNJUK KERJA TCP RENO DAN TCP VEGAS PADA JARINGAN KABEL

Dipersiapkan dan ditulis oleh: Theo Mahardian Bangkit Sugiri

NIM : 125314061

Telah dipertahankan di depan Panitia Penguji pada tanggal ……….

dan dinyatakan memenuhi syarat.

Susunan Panitia Penguji

Nama Lengkap Tanda Tangan

Ketua : Henricus Agung Hernawan, S.T., M.Kom. ... Sekretaris : Puspaningtyas Sanjoyo Adi, S.T., M.T. ... Anggota : Bambang Soelistijanto, S.T., M.Sc., Ph.D. ...

Yogyakarta, ... Fakultas Sains dan Teknologi

Universitas Sanata Dharma Dekan

v MOTTO

“Lebih baik bertempur dan kalah daripada tidak pernah bertempur sama sekali”. (Arthur Hugh Clough)

“Satu ons praktek lebih berharga daripada satu ton teori”

(Mahatma gandhi)

“Anda harus belajar dari pesaing Anda, tapi jangan pernah menirunya. Tiru dan Anda mati”

(Jack Ma)

“It’s a lie to think you’re not good enough. It’s a lie to think you’re not worth anything”

vi

PERNYATAAN KEASLIAN KARYA

Saya menyatakan dengan sesungguhnya bahwa skripsi yang saya tulis ini tidak memuat karya atau bagian karya orang lain, terkecuali yang sudah tertulis di dalam kutipan daftar pustaka, sebagaimana layaknya sebuah karya ilmiah.

Yogyakarta, ……… Penulis

vii

LEMBAR PERSETUJUAN PUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS

Yang bertanda tangan di bawah ini, saya mahasiswa Universitas Sanata Dharma: Nama : Theo Mahardian Bangkit Sugiri

NIM : 125314061

Demi pengembangan ilmu pengetahuan, saya memberikan kepada Perpustakaan Universitas Sanata Dharma karya ilmiah yang berjudul:

ANALISIS PERBANDINGAN UNJUK KERJA TCP VEGAS DAN TCP RENO PADA JARINGAN KABEL

Beserta perangkat yang diperlukan (bila ada). Dengan demikian saya memberikan kepada Perpustakaan Universitas Sanata Dharma hak untuk menyimpan, mengalihkan dalam bentuk media lain, mengelolanya dalam bentuk pangkalan data mendistribusikan secara terbatas, dan mempublikasikannya di Internet atau media lain untuk kepentingan akademis tanpa perlu meminta ijin dari saya maupun member

royalty kepada saya selama tetap mencantumkan nama saya sebagai penulis. Demikian pernyataan ini saya buat dengan sebenarnya.

Yogyakarta, ………. Penulis

viii ABSTRAK

Tugas akhir ini akan membahas tentang perbandingan unjuk kerja protokol TCP Reno dan TCP Vegas. Parameter jaringan yang diukur adalah averagethroughput, delay, dan packet drop. Parameter dan skenario berdasarkan topologi dan jenis trafik yang tetap dengan penambahan besar packet error probability dan penggunaan kapasitas buffer yang berbeda pada router.

.Hasil pengujian menunjukkan TCP Vegas dapat mengungguli TCP Reno ketika jaringan menyebabkan packet loss yang besar, hal ini dikarenakan packet loss

sangat berpengaruh terhadap unjuk kerja TCP Reno, hal tersebut dapat dilihat dari nilai

throughput. Sementara itu nilai end to end delay dan packet loss lebih tinggi ketika berada pada packet error karena pengaruh packet loss untuk TCP Vegas tidak sebesar TCP Reno menyebabkan jumlah paket yang dikirim lebih besar. Di sisi lain, end to end delay dan packet loss TCP Vegas lebih rendah daripada TCP Reno ketika berada pada jaringan link sharing, hal ini terjadi karena link sharing menghasilkan suatu kongesti yang menyebabkan TCP Vegas berhati-hati dalam pengiriman paket data. Tetapi TCP Vegas tidak cocok digunakan pada jaringan dengan buffer size yang besar dengan trafik padat karena menghasilkan nilai throughput yang kecil.

Kata Kunci : TCP Reno, TCP Vegas, simulator, throughput, delay, packet drop, congestion window, RTT

ix ABSTRACT

This final project will discuss about the comparison of the performance of TCP Reno and TCP Vegas. Network parameters measured is average throughput, delay and packet drop. Parameters and scenarios based on the topology and types of traffic are fixed with the addition of a large packet error probability and the use of different buffer capacity of the router.

The results of the testing indicate TCP Vegas can outperform TCP Reno when the networks are major causes packet loss, packet loss because it affects the performance of TCP Reno, it can be seen from the value of throughput. While the value of end to end delay and packet loss is higher when it is at packet error due to the effect of packet loss on TCP Vegas is not as big as TCP Reno cause the number of packets sent is greater. On the other hand, end to end delay and packet loss TCP Vegas is lower than TCP Reno when it is on a network link sharing, it’s occurs because link sharing produces a congestion causes TCP Vegas cautious in the delivery of data packets. But TCP Vegas is not suitable for use on a network with a large buffer size with heavy traffic because it produces a small throughput.

Keyword : TCP Reno, TCP Vegas, simulator, throughput, delay, packet drop, congestion window, RTT

x

KATA PENGANTAR

Puji dan syukur kepada Tuhan Yang Maha Esa, karena berkat dan karunia-Nya penulis

dapat e yelesaika tugas akhir ya g berjudul Analisis Perbandingan Unjuk Kerja TCP Vegas dan TCP Reno Pada Jaringan Kabel .

Penulis menyadari bahwa selama proses penelitian dan penyusunan laporan tugas akhir ini, banyak pihak yang telah memberikan bantuan baik berupa dukungan, motivasi, perhatian, semangat, kritik dan saran yang sangat penulis butuhkan, sehingga pada kesempatan ini penulis ingin mengucapkan terimakasih yang sebesar – besarnya, antara lain kepada :

1. Bapak Bambang Soelistijanto, S.T., M.Sc., Ph.D. selaku dosen pembimbing tugas akhir, yang tetap sabar membimbing penulis, meluangkan waktunya , memberi dukungan, motivasi, serta saran yang dibutuhkan penulis.

2. Paulina Heruningsih Prima Rosa S.Si.,M.Sc.,selaku Dekan Fakultas Sains dan Teknologi,atas bimbingan,kritik dan saran yang telah diberikan kepada penulis. 3. Romo Dr.Cyprianus Kuntoro Adi, S.J. M.A., M.Sc. selaku Dosen Pembimbing

Akademik, atas bimbingan dan nasehat yang diberikan kepada penulis

4. Sudi Mungkasi, Ph.D. selaku Dekan Fakultas Sains dan Teknologi, atas bimbingan, kritik dan saran yang telah diberikan kepada penulis.

5. Dr.Anastasia Rita Widiarti,M.Kom. selaku Ketua Program Studi Teknik Informatika,atas bimbingan,kritik dan saran yang telah diberikan kepada penulis. 6. Bapak saya Ig. Suparman dan ibu saya Veronika Rubiyati serta kakak-kakak saya

atas doa dan dukungan baik moril maupun finansial serta kasih sayang yang begitu besar untukku.

7. Teman – teman Teknik Informatika angkatan 2012 yang selalu memberikan semangat, dukungan dan bantuan hingga penulis menyelesaikan tugas akhir ini. 8. Teman seperjuangan TCP (Yoppi, Eca, Ari), dan teman-teman Lab tugas akhir

Jarkom yang memberikan dukungan dan semangat agar cepat menyelesaikan skripsi ini.

xi

9. Semua pihak yang telah membantu dan mendukung baik secara langsung dan tidak langsung, penulis mengucapkan banyak terimakasih.

Penulis menyadari bahwa masih banyak kekurangan dalam penyusunan tugas akhir ini. Saran dan kritik sangat diharapkan untuk perbaikan yang akan dating. Akhir kata, semoga tulisan ini dapat bermanfaat bagi kemajuan dan perkembangan ilmu pengetahuan.

Penulis,

xii DAFTAR ISI

ANALISIS PERBANDINGAN UNJUK KERJA TCP RENO DAN TCP VEGAS PADA

JARINGAN KABEL ... i

PERFORMANCE EVALUATION BETWEEN TCP RENO AND TCP VEGAS IN WIRED NETWORK ... i

HALAMAN PERSETUJUAN ... ii

SKRIPSI ... iv

MOTTO ... v

PERNYATAAN KEASLIAN KARYA ... vi

LEMBAR PERSETUJUAN PUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS ... vii

ABSTRAK ... viii

ABSTRACT... ix

KATA PENGANTAR ... x

DAFTAR ISI... xii

DAFTAR TABEL ... xv

DAFTAR GAMBAR ... xvi

BAB I ...1

PENDAHULUAN ...1

1.1 Latar Belakang ...1

1.2 Rumusan Masalah ...2

1.3 Tujuan Penelitian...3

1.4 Batasan Masalah ...3

1.5 Metodologi Penelitian ...3

1. Studi Literatur ...3

2. Rancangan ...3

3. Pembangunan Simulasi dan Pengumpulan Data ...4

4. Analisis Data Simulasi ...4

5. Penarikan Kesimpulan ...4

xiii

BAB II ...6

LANDASAN TEORI ...6

2.1. Jaringan Kabel (Wired) ...6

2.2. Congestion Control ...6

2.3. TCP RENO ...7

2.4. VEGAS ...10

2.5. Buffer Management ...14

2.6. Network Simulator (OMNET+ + ) ...15

BAB III ...17

RANCANGAN SIMULASI JARINGAN ...17

3.1. Skenario dan Topologi ...17

3.2. Parameter Kinerja...20

3.2.1. Throughput ...20

3.2.2. Loss paket ...20

3.2.3. Delay (End to End delay) ...20

BAB IV ...22

PENGUJIAN DAN ANALISIS ...22

4.1. Efek packet error probability ...22

4.1.1. Throughput ...22

4.1.2. Delay ...23

4.1.3. Packet loss ...25

4.1.4 Congestion Window ...26

4.2. Efek ukuran buffer queue ...30

4.2.1. Throughput ...30

4.2.2. Delay ...32

4.2.3. Packet loss ...33

4.2.4. RTT ...34

4.2.5.Congestion Window ...37

BAB V ...40

xiv

5.1. Kesimpulan ...40

5.2. Saran ...40

xv

DAFTAR TABEL

Tabel 3.1 Parameter tetap skenario 1 ... 18 Tabel 3.2 Parameter tetap pada skenario 2... 19 Tabel 4.1.1 Hasil pengujian throughput pada TCP dengan packet error probabability yang berbeda ... 22 Tabel 4.1.2 Hasil pengujian delay pada TCP dengan packet error probabability yang berbeda ... 24 Tabel 4.1.3 Hasil pengujian packet loss pada TCP dengan packet error probabability yang berbeda ... 25 Tabel 4.2 Hasil simulasi pada efek ukuran buffer size ... 30 Tabel 4.2.4 Rata-rata RTT pada buffer size yang berbeda ... 34

xvi

DAFTAR GAMBAR

Gambar 2.3.1 Slow Start ... 8

Gambar 2.3.2 Congestion Avoidance ... 8

Gambar 2.3.4 Fast Retransmit dan fast recovery ... 9

Gambar 2.4 TCP Vegas Behaviour ... 11

Gambar 2.4.2 Contoh mekanisme retransmisi ... 13

Gambar 3.1 Topologi skenario 1 ... 17

Gambar 3.2 Topologi skenario 2 ... 19

Gambar 4.1.1 Average throughput TCP pada penambahan packet error probabability ... 22

Gambar 4.1.2 Delay TCP pada penambahan packet error probabability... 24

Gambar 4.1.3 Packet loss TCP pada penambahan packet error probabability ... 25

Gambar 4.1.4 Congestion Window pada packet error probability yang berbeda ... 29

Gambar 4.2.1 Throughput pada TCP dengan buffer size yang berbeda ... 30

Gambar 4.2.2 Delay pada TCP dengan buffer size yang berbeda ... 32

Gambar 4.2.3 Packet loss pada TCP dengan buffer size yang berbeda ... 33

Gambar 4.2.4 RTT pada TCP dengan buffer size yang berbeda ... 36

1 BAB I PENDAHULUAN 1.1 Latar Belakang

Sekarang ini, berbagai aktivitas manusia tidak lepas dari jaringan Internet. Komunikasi dan pertukaran informasi pada saat ini sangat menuntut suatu kecepatan pengiriman, keamanan, serta jaminan terhadap informasi yang dikirim.

Penelitian dan pengembangan teknologi di bidang telekomunikasi khususnya Internet berkembang dengan pesat. Berbagai inovasi dilakukan oleh banyak peneliti untuk menciptakan suatu teknologi jaringan yang efisien dalam melakukan komunikasi. Pengembangan tidak berhenti pada suatu titik saja, tetapi dilakukan secara terus menerus untuk memenuhi kebutuhan informasi yang semakin besar dan juga cepat. Salah satu hal yang menjadi fokus pengembangan ini adalah algoritma TCP. TCP sendiri merupakan protokol yang digunakan dalam pengiriman data/informasi antar end-to-end host yang saling berkomunikasi dan memberikan jaminan terhadap data/informasi tersebut. Sudah banyak jenis algoritma TCP yang dikembangkan, dimulai dari TCP Tahoe, TCP Reno, TCP Vegas, TCP NewReno, TCP SACK dan versi lainnya. Pengembangan TCP ini tentu bertujuan untuk menghasilkan unjuk kerja TCP yang lebih baik pada kondisi jaringan tertentu.

Media transmisi saat ini terbagi menjadi dua bagian yaitu jaringan kabel dan jaringan wireless. Pada kedua jenis jaringan transmisi tersebut TCP memiliki tantangan tersendiri. Masalah yang terjadi pada transmisi kabel sangat kecil, hal tersebut dikarenakan kabel menyediakan bandwidth dan kecepatan yang stabil serta link yang selalu terhubung, hal inilah yang menyebabkan gangguan transmisi pada kabel sangat kecil atau bahkan tidak ada.

Meskipun packet error pada kabel sangat kecil , transmisi kabel memiliki masalah tersendiri, yaitu kapasitas buffer pada router dan juga

2

kongesti. Kedua hal tersebut akan menjadi masalah ketika router mengalami kelebihan beban (overload) data pada storage yang disebabkan oleh transmisi yang sangat besar dan juga cepat. Ketika ukuran buffer terlalu kecil dan transmisi yang terjadi sangat besar maka akan banyak paket drop yang terjadi, sedangkan ketika ukuran buffer terlalu besar akan memicu delay yang besar, kedua hal tersebut akan berpengaruh terhadap unjuk kerja TCP. Dalam kasus drop paket yang terjadi pada router juga dipengaruhi oleh jenis queue management yang digunakan. Dua queue management yang umum yaitu Drop Tail dan Random Early Drop (RED). Drop Tail akan melakukan drop paket ketika buffer sudah penuh, sedangkan RED akan melakukan drop paket secara acak tanpa harus menunggu buffer penuh.

Dari jenis algoritma TCP itu sendiri, mekanisme dalam menghadapi kongesti dan drop paket juga berbeda satu sama lain. Ada jenis TCP yang sangat terpengaruh oleh adanya loss paket yang terjadi karena packet error

maupun kongesti, sebagai contohnya adalah TCP Reno dan ada juga yang sangat terpengaruh oleh nilai RTT yang terjadi karena kongesti, sebagai contohnya adalah TCP Vegas. Dengan karakteristik dan mekanisme yang berbeda itu, suatu algoritma TCP dikembangkan untuk mengatasi keadaan jaringan tertentu. Dengan penggunaan mekanisme yang berbeda maka tingkat kesulitan yang dilakukan oleh algoritma TCP juga berbeda-beda, semakin luas algoritma yang digunaan maka pekerjaan TCP akan menjadi semakin berat.

1.2 Rumusan Masalah

Berdasarkan latar belakang masalah yang ada, rumusan masalah yang didapatkan adalah hasil antara TCP Vegas dan TCP Reno pada trafik jaringan yang mengalami kongestimaupun paket eror karena packet error.

3 1.3 Tujuan Penelitian

Tujuan dari penulisan tugas akhir ini adalah untuk mengetahui perbandingan unjuk kerja antara TCP Reno dan TCP Vegas pada jaringan kabel.

1.4 Batasan Masalah

Dalam pelaksanaan tugas akhir ini, masalah dibatasi sebagai berikut: 1. Penulis melakukan penelitian pada TCP Vegas dan TCP Reno.

2. Metrik unjuk kerja yang digunakan adalah throughput, delay, dan packet loss.

3. Pengujian dilakukan menggunakan simulator Omnet++. 4. Menggunakan trafik pengganggu berupaUDP.

5. Manajemen antrian yang digunakan adalah Drop tail. 6. _{Penelitian dilakukan pada jaringan kabel.}

1.5 Metodologi Penelitian

Metodologi dan langkah-langkah yang digunakan dalam penelitian ini adalah sebagai berikut :

1. Studi Literatur

Mengumpulkan informasi dari berbagai buku-buku atau jurnal-jurnal yang membahas tentang hal yang diperlukan dalam penelitian seperti :

a. Teori TCP Reno dan TCP Vegas

b. Teori throughput, delay, packet loss

c. Teori Omnet+ +

d. Tahap-tahap dalam membangun simulasi. 2. Rancangan

4

a. Penambahan besar packet error probability dalam persen (%) pada skenario 1

b. Menggunakan kapasitas buffer yang berbeda pada skenario 2 c. Kapasitas datarate dan delay pada link (tetap)

3. Pembangunan Simulasi dan Pengumpulan Data

Pada tahap ini dilaksanakan pemasangan perangkat-perangkat yang digunakan sesuai dengan skenario yang sudah dibuat sebelumnya. Pemasangan ini juga meliputi konfigurasi mekanisme drop pada router, TCP yang digunakan pada sender dan receiver dan juga pemasangan trafik penganggu (UDP) .

4. Analisis Data Simulasi

Pada tahap analisa, output hasil simulasi dan revisi-revisinya yang telah terkumpul digunakan untuk menghitung parameter yang akan diukur dalam penelitian ini.

5. Penarikan Kesimpulan

Penarikan kesimpulan dan saran didasarkan pada performance metric yang didapat dari proses simulasi dan analisis yang telah dilakukan.

1.6 Sistematika Penulisan

Sistematika penulisan tugas akhir ini dibagi menjadi beberapa bab dengan susunan sebagai berikut :

BAB I PENDAHULUAN

Pada Bab ini berisi latar belakang yang mendasari penulisan Tugas Akhir, rumusan masalah, batasan masalah, maksud dan tujuan penulisan, metodologi penelitian dan sistematika penelitian

5

Pada Bab ini menjelaskan tentang teori-teori yang menjadi landasan pada judul/topik Tugas Akhir

BAB III PERANCANGAN TUGAS AKHIR

Bab ini berisi tentang rancangan simulasi jaringan yang akan dijalankan serta parameter-parameter yang akan digunakan dalam penelitian.

BAB IV ANALISA HASIL PENGAMBILAN DATA

Bab ini berisi pelaksanaan simulasi dan analisis data hasil simulasi jaringan

BAB V KESIMPULAN DAN SARAN

Bab ini berisi tentang beberapa kesimpulan yang didapat berdasarkan hasil analisis dan juga saran untuk penelitian yang dapat dilakukan selanjutnya

6 BAB II

LANDASAN TEORI 2.1. Jaringan Kabel (Wired)

Jaringan kabel merupakan tipe jaringan yang dikembangkan pertama kali untuk membantu aktivitas transmisi data. Jaringan kabel melibatkan penggunaan beberapa router ataupun switch, kabel ethernet dan juga konektor untuk menghubungkan antar komputer. Jaringan kabel sendiri memiliki beberapa karakteristik seperti di bawah ini :

a. Bandwidth pada jaringan kabel sangat besar sehingga transfer data melalui kabel memiliki kecepatan yang tinggi.

b. Transmisi kabel memiliki packet error yang sangat kecil karena tidak terpengaruh oleh interferensi

Dalam prakteknya, kabel jaringan memiliki beberapa tipe yang disesuaikan dengan kebutuhan jaringan tertentu. Setiap tipe kabel ini memiliki karakteristik tersendiri seperti besar bandwidth dan kecepatan yang kemudian akan mempengaruhi proses transmisi yang dilakukan.

2.2.Congestion Control

kongesti terjadi karena adanya penggunaan kapasitas jaringan yang melebihi kapasitas yang tersedia, hal ini terjadi ketika buffer pada router mengalami kelebihan beban (overload). Dengan penuhnya buffer ini maka paket yang datang ketika terjadi kongestiakan di drop dan menyebabkan turunnya nilai dari throughputdan juga delay yang tidak terprediksi.

Mekanisme yang digunakan untuk mengatasi masalah kongestiini adalah sebagai berikut :

1. Congestion Avoidance

Congestion Avoidance merupakan mekanisme yang digunakan untuk mencegah terjadinya kongesti. Congestion Avoidance pada TCPmenggunakan

loss paket sebagai indikator adanya congesti, di sisi lain ada juga yang menggunakan perhitungan RTT sebagai indikator terjadinya kongesti.

7

Congestion control merupakan mekanisme yang digunakan ketika kongesti telah terjadi. Congestion control sendiri diimplemetasikan melalui dua sisi yaitu:

a. Congestion control pada host ujung di jaringan yang berpusat pada protokol transport (TCP)

b. Congestion control yang terjadi pada router di jaringan (mekanisme antrian) Meskipun sudah diimplementasikan dan berjalan, Congestion control

masih memiliki tantangan tersendiri. Dengan adanya pengiriman paket dari berbagai sisi host dan dengan waktu yang tidak teratur maka perubahan (seperti pengaturan kecepatan pengiriman paket) yang dilakukan melalui congestion control dalam penyesuaian dengan kapasitas jaringan yang tersedia menjadi tidak akurat.

2.3.TCP RENO

TCP Reno merupakan variasi TCP setelah TCP Tahoe. TCP Reno masih mengimplementasi mekanisme TCP Tahoeyaitu slow-start,congestion avoidance, fast retransmission dan menambahkan satu mekanisme fast recovery.

2.3.1. Slow-Start

Slow-start merupakan fase di mana TCP mencari tahu tentang kapasitas jaringan yang ada. Pertama TCP akan mengirimkan 1 paket dan menunggu ACK yang datang, jumlah paket akan terus ditingkatkan dari 1 paket, lalu 2 paket, lalu 4 paket dan seterusnya naik secara eksponensial. Kenaikan secara eksponensial ini akan berhenti ketika terdeteksi adanya packet loss

dengan tidak diterimanya ACK, pada titik ini berarti kenaikan CWND sudah mencapai titik ssthreshold. Setelah mencapai titik ssthreshold inilah kenaikan akan berubah menjadi kenaikan secara linier.

8

Gambar 2.3.1 Slow Start

2.3.2. Congestion Avoidance

Merupakan fase di mana TCP berusaha menghindari congestion. Dalam fase ini, CWND akan naik secara linear (bertambah 1) dan ketika terjadi 3 duplikasi ACK maka nilai sstreshold akan diturunkan setengah nilai CWND dan nilai CWND sendiri diturunkan sebesar nilai sstreshold.

Gambar 1.3.2 Congestion Avoidance

2.3.3. F ast Retransmit

Pada fase ini terjadi retransmisi pada paket yang hilang. Ketika menerima 3 duplikasi ACK maka akan dilakukan retransmisi pada paket yang hilang.

9 2.3.4. F ast recovery

Pada fase fast recovery, ketika terjadi 3 duplikasi ACK dan telah melakukan fast retransmission, TCP tidak masuk ke fase slow-start, tetapi langsung masuk pada fase congestion avoidance.

Algoritma fast recovery yang ada di dalam TCP Reno ketika mendeteksi packet loss melalui 3 duplikasi ACK adalah seperti berikut :

Gambar 2.2.4 Fast Retransmit dan fast recovery

1. Ssthresh = CWND/2 2. CWND = ssthresh

3. Melakukan fast retransmission 4. Melakukan fast recovery

5. Lalu masuki fase congestion avoidance

Berikut ini adalah algoritma ketika terjadi RTO pada paket : 1. Ssthresh = CWND/2

2. CWND = 1

3. Melakukan fast retransmission 4. Lalu masuki fase slow-start

Adanya 3 duplikasi ACK juga dijadikan sebagai indikator adanya congestion melalui terdeteksinya packet loss.

10

Ada kalanya TCP Reno akan mengalami timeout yang disebabkan oleh terjadinya multiple loss pada paket-paket yang dikirimkannya. Pengaruh jumlah dari multiple loss yang terjadi terhadap terjadinya timeout dapat dilihat seperti berikut :

a. Ketika ada dua packet loss, timeout terjadi kadang-kadang. b. Ketika ada tiga packet loss, timeout biasanya terjadi. c. Ketika ada empat packet loss, timeout dipastikan terjadi.

2.4.VEGAS

TCPVegas merupakan TCP yang berbasis pada modifikasi TCP Reno.

TCP Vegas dinilai dapat meningkatkan nilai throughput dibandingkan dengan TCP pendahulunya. Kenaikan throughput pada TCPVegasini tidak menggunakan strategi retransmisi agresif yang memungkinkan penggunaan bandwidth yang besar, TCPVegas lebih menekankan pada penggunaan bandwidth secara efisien. TCP Vegas memiliki mekanisme yang berfokus pada paket delay dibandingkan kehilangan paket. TCP Vegas menggunakan mekanisme-mekanisme baru yang berbeda dengan TCP pendahulunya. Kebanyakan TCP menggunakan mekanisme yang berfokus pada adanya packet loss (drop) yang disebabkan oleh link error atau

drop yang dilakukan oleh router, seperti TCP Tahoe, TCP Reno, TCP Newreno dan TCP SACK. Mekanisme yang menjadi fokus utama TCP Vegas adalah

congestion avoidance. Jika TCP Tahoe dan sejenisnya menggunakan packet drop

sebagai tanda kongesti, sedangkan TCP Vegas menggunakan nilai RTT variance

sebagai tanda terjadinya kongesti. Karakteristik TCP Tahoe dan sejenisnya yang agresif menghasilkan congestion window yang besar, sedangkan TCP Vegas memiliki congestion window yang cenderung datar karena dipengaruhi oleh mekanisme congestion avoidance yang dimilikinya. Seperti TCP lainnya, TCP Vegas juga masih menggunakan prinsip dasar slow-start, congestion avoidance

11

Gambar 2.3 TCP Vegas Behaviour

2.4.1.Mekanisme Congestion Avoidance

Congestion avoidance pada TCP Vegas berbasis pada perkiraan jumlah ekstra data yang ada di jaringan, tidak hanya berdasarkan drop segmen.

Langkah pertama adalah mendefinisikan BaseRTT yang merupakan nilai RTT terkecil dari semua RTT terhitung. Lalu dilakukan proses penghitungan nilai dari Expected throughput dengan nilai BaseRTT yang didapatkandengan rumus berikut :

Expected = �� � ���

Langkah kedua adalah menghitung nilai dari Actual throughput. Actual throughput didapat dengan merekam besar byte data yang dikirim ketika suatu segmen dikirim hingga acknowledgment-nya diterima lalu dibagi dengan nilai RTTnya. Actual throughput didapat melalui rumus berikut :

12

Actual = ���

rtt len merupakan jumlah bytes data yang dikirim ketika suatu segmen dikirim hingga ACK-nya sampai.

Langkah ketiga adalah dengan membandingkan nilai dari Expected dan

Actual lalu CWND akan diubah berdasarkan hasilnya. Sebutlah Diff = Expected – Actual, nilai Diff harus positif atau nol. Vegas juga mendefinisikan dua threshold yaitu α dan , nilai α akan menjadi pemicu penurunan nilai CWND dan akan menjadi pemicu penurunan nilai CWND. α memiliki nilai yang kecil namun tidak nol.

Jika Diff < α, CWND + 1 Jika Diff > , CWND - 1

Jika α ≤ Diff ≤ , maka CWND tidak berubah

Nilai baseRTT juga akan direset karena routing dan keadaan jaringan yang mengalami perubahan akan menyebabkan nilai RTT terkecil dapat berubah. Pembaharuan nilai baseRTT dapat dijelaskan seperti berikut :

Jika currentRTT < baseRTT baseRTT = currentRTT

2.4.2.Mekanisme retransmission

Dalam mekanisme retransmisi yang dilakukan oleh Vegas, hal pertama yang dilakukan adalah membaca dan merekam system clock setiap pengiriman segmen data. Ketika ACK diterima, Vegas akan membaca

system clock dan melakukan penghitungan RTT menggunakan waktu tersebut dan waktu yang telah dicatat sebelumnya untuk segmen yang

13

berkaitan. Lalu Vegas akan menggunakan perkiraan RTT yang ini untuk memutuskan melakukan retransmisi sesuai dengan dua situasi berikut :

Gambar 2.4.2 Contoh mekanisme retransmisi

1. Ketika menerima duplikat ACK, Vegas akan melakukan pengecekan untuk melihat perbedaan waktu terbaru dan waktu tercatat untuk segmen yang berkaitan lebih besar daripada nilai timeout. Jika benar maka Vegas akan melakukan retransmisi segmen tanpa menunggu adanya 3 duplikat ACK.

2. Ketika tidak ada duplikat ACK, merupakan ACK pertama atau kedua setelah retransmisi, TCP Vegas akan mengecek kembali untuk melihat jika interval waktu sejak segmen dikirim lebih besar dari timeout, TCP Vegas akan melakukan retransmisi segmen tersebut tanpa menunggu adanya duplikat ACK.

14

TCP Vegas hanya akan menurunkan CWND jika retransmisi segmen sudah dilakukan setelah penurunan CWND terakhir. Setiap packet loss yang terjadi sebelum penurunan CWND terakhir tidak dapat dijadikan pedoman bahwa jaringan mengalami congestion. TCP Vegas akan menurunkan ¼ CWND ketika terjadi retransmisi pada kondisi ini.

2.4.3.Mekanisme slow-start

Vegas menggunakan mekanisme slow-start yang dimodifikasi dengan menggabungkan mekanisme congestion detection ke dalam slow-start. Agar mampu untuk mendeteksi dan menghindari congestion selama slow-start,

Vegas hanya mengijinkan kenaikan secara exponensial hanya untuk setiap 2 RTT yang berbeda. Ketika actual rate berada di bawah expected rate dengan jumlah yang pasti, dapat disebut sebagai threshold, Vegas akan merubah mode slow-start ke mode linear.[3,6]

TCP Vegas juga masih mengimplementasikan karakteristik dari TCP Reno seperti

Coarse grained timer [5]ketika algoritma yang dimilikinya tidak dapat menangani keadaan jaringan yang ada.

2.5.Buffer Management

Meskipun jaringan kabel hampir tidak memiliki gangguan dalam transmisi, tetapi yang menjadi masalah tersendiri adalah kemampuan router sebagai penghubung antar network jaringan. Salah satu yang dihadapi oleh router dengan adanya paket besar yang datang melalui kabel menyebabkan antrian yang besar dan kapasitas buffer router akan mengalami kendala. Ketika terjadi packet flooding yang besar maka buffer pada router akan penuh sehingga menimbulkan adanya loss paket. Loss paket yang terjadi ini juga dipengaruhi oleh algoritma manajemen antrian yang berupa Drop Tail atau RED (Random Early Detect).

Drop tail dapat disebut sebagai algoritma manajemen antrian yang paling sederhana dan merupakan manajemen antrian yang bersifat pasif. Cara kerja drop

15

tail adalah ketika sebuah buffer penuh, paket yang tidak tertampung akan di drop.

Adanya paket dropini menyebabkan koneksi TCPyang terhubung dengan link ini akan dipaksa untuk melakukan slow-start ataupun fast recovery.

2.6.Network Simulator (OMNET++)

Omnet++ atau omnetpp adalah network simulation software discrete-event yang bersifat open source (sumber code terbuka). Discreate-event berarti simulasinya bertindak atas kejadian langsung didalam event . Secara analitis, jaringan komputer adalah sebuah rangkaian discrete-event. Komputer akan membuat sesi memulai, sesi mengirim dan sesi menutup. OMNet++ bersifat

object-oriented berarti setiap peristiwa yang terjadi di dalam simulator ini berhubungan dengan objek-objek tertentu. OMNet++ juga menyediakan infrastruktur dan tools untuk memrogram simulasi sendiri. Pemrograman OMNet++ bersifat object-oriented dan bersifat hirarki. Objek-objek yang besar dibuat dengan cara menyusun objek-objek yang lebih kecil. Objek yang paling kecil disebut simple module, akan memutuskan algoritma yang akan digunakan dalam simulasi tersebut. Omnet++ menyediakan arsitektur komponen untuk pemodelan simulasi. Komponen (modul) menggunakan bahasa programing C++ yang berekstensi “.h” dan “.cc”. Omnet++ memiliki dukungan GUI (Graphical User Interface) yang luas, karena arsitektur yang modular, simulasi kernel yang dapat dicompile dengan mudah di sistem anda..

Omnet juga mendukung beberapa framework yaitu : Inet, Inetmanet, Mixim, Castalica, Libara dan lain-lain. Framework tersebut yang akan membantu user untuk mampu mengembangkan sebuah simulasi jaringan. Pada skripsi ini Framework yang digunakan adalah Inet untuk protokol transport TCP Reno dan Vegas. [4]

Karena bersifat open-source maka Omnet++ mendukung multi platform

OS seperti ;Windows, Linux dan Mac.Adapun beberapa komponen dari Omnet++ adalah :

16

1. Simulation kernel library (library kernel) 2. NED(diskripsi topologi)

3. Omnet++ IDE yaitu Eclipse

4. GUI untuk simulator yang dieksekusi dengan coman Tkenv 5. Comand-line user interface yang menggunakan Cmdenv 6. Utilities seperti makefile pada tools

17 BAB III

RANCANGAN SIMULASI JARINGAN

3.1. Skenario dan Topologi

Simulasi ini terdiri dari dua skenario yaitu penggunaan packet error probability dan link sharing.

a. Skenario 1: Efek packet error

Pada skenario ini drop paket yang terjadi disebabkan oleh packet error probability (bukan kongesti).

Pada skenario pertama, simulasi yang dijalankan pada kedua protokol transport baik TCP Reno dan TCP Vegas yaitu dengan jaringan kabel yang menggunakan datarate pada link sebesar 2 Mbps, delay yang digunakan untuk semua link adalah 2 ms. Untuk setiap simulasi yang dijalankan akan digunakan packet error probability sebesar 5%, 10%, dan 15%.

1. Topologi

Gambar 3.1 Topologi skenario 1

18 2. Parameter tetap

Parameter Nilai

Jumlah Host 2 host

Waktu simulasi 200 s

Banyak Koneksi TCP 1 TCP

TCP packet size 1024 B

Delay 2 ms

Datarate 2 Mbps

Queue Droptail

Packet error probability 5, 10, 15(%) Tabel 3.1 Parameter tetap skenario 1

b. Skenario 2: Efek buffer size

Pada skenario ini drop paket yang terjadi karena adanya kongesti, dan kongesti yang terjadi akan berdampak pada delay.

Pada skenario kedua, simulasi yang dijalankan pada kedua protokol transport baik TCP Reno dan TCP Vegas yaitu skenario dengan jaringan kabel berbentuk topologi Dumbbell dengan datarate setiap link adalah 10 Mbps dan link bagian tengah adalah 1.5 Mbps, delay untuk link TCP dan bottleneck

adalah 2 ms sedangkan link UDP adalah 1 ms, untuk setiap simulasi yang dijalankan akan digunakan buffer size sebesar 20 dan 60 paket, lalu aliran data TCP akan saling ditabrakan dengan aliran data UDP. Hasil dari simulasi akan ditampilkan dalam suatu tabel dan grafik.

19 1. Topologi

Gambar 3.3 Topologi skenario 2

2. Parameter tetap

Parameter Nilai

Jumlah Host 4 host

Waktu simulasi 200 s

Banyak Koneksi TCP 1 TCP

TCP packet size 1024 B

Banyak Koneksi UDP 1 UDP

UDP packet size 2048 B

Traffic source TCP vs UDP

Delay 1 dan 2 ms

Datarate 10 Mbps dan 1.5 Mbps

Queue Droptail

Buffer size 20 dan 60 paket

20 3.2. Parameter Kinerja

Pada penelitian ini telah dipilih beberapa parameter kinerja yang dapat digunakan untuk mengukur unjuk kerja dari TCP Reno dan TCP Vegas. Parameter kinerjaini menjadi fokus dalam setiap pengujian yang dilakukan.

3.2.1. Throughput

Throughput merupakan jumlah bit data per satuan waktu yang dikirim ke suatu destinasi melalui jaringan. Semakin besar nilai throughput maka akan semakin baik. Kualitas protokol transport dapat terlihat melalui besarnya

throughput yang dihasilkan. Hal tersebut dapat menjadi tolak ukur performansi protokol transport yang diuji. Berikut adalah rumus untuk menghitung throughput :

Throughput = � � � � � �

�� � �� � � � �

3.2.2. Loss paket

Loss paket merupakan suatu kegagalan pada satu atau lebih paket yang sudah ditransmisikan untuk mencapai destinasi[2]. Semakin tinggi loss paket menunjukkan suatu keadaan jaringan yang memiliki masalah. Loss paket sendiri terjadi karena buffer overflow (congestion) dan juga bit error (pada jaringan wireless)[1].

Loss paket = jumlah paket dikirim – jumlah paket diterima

3.2.3. Delay (End to End delay)

End to End delay merupakan waktu yang ditempuh oleh paket dari ketika paket itu dikirim hingga mencapai destinasi. Nilai delay dapat dipengaruhi oleh cara kerja dari protokol transport, sehingga nilai delay dapat dijadikan parameter pembeda antar protokol transport. Rumus end to end delay

21 adalah sebagai berikut :

22

BAB IV

PENGUJIAN DAN ANALISIS

Untuk mendapatkan hasil pengujian perbandingan unjuk kerja TCP Vegas dan TCP Reno pada jaringan kabel maka dilakukan skenario simulasi yang telah direncanakan pada Bab 3.

4.1.Efek packet error probability 4.1.1. Throughput

Packet Error

probability (%) Reno Vegas

5 38.61232031 75.07881641

10 10.96741699 24.38298828

15 4.211444336 11.43839453

Tabel 4.1.1 Hasil pengujian throughput pada TCP dengan packet error probabability

yang berbeda

Gambar 4.1.1 Average throughput TCP pada penambahan packet error probabability

0 10 20 30 40 50 60 70 80

5 10 15

T h ro u g h p u t (k b p s)

Packet Error probability (%)

Throughput

23

Pada gambar 4.1.1 Penambahan packet error probability akan menurunkan

throughput dari kedua protokol karena semakin banyak paket yang hilang akan menyebabkan protokol TCP sering jatuh menyebabkan jumlah paket yang dikirimkan hanya berjumlah kecil sehingga nilai throughput menjadi semakin kecil. Meskipun sama-sama mengalami penurunan throughput, nilai throughput yang didapatkan oleh TCP Vegas lebih besar dibandingkan throughput TCP Reno. Hal tersebut karena cara kerja TCP Reno yang sangat terpengaruh oleh adanya packet drop menyebabkan TCP Reno sering jatuh yang kemudian mengakibatkan jumlah data yang dikirim hanya dalam jumlah yang kecil dan nilai throughput menjadi kecil, sedangkan TCP Vegas yang dapat menangani lebih banyak packet drop akan mendapatkan hasil yang sebaliknya.

4.1.2. Delay

Packet Error

probability (%) Reno Vegas

5 0.016032791 0.018831206

10 0.012508868 0.017349359

15 0.01145809 0.014427057

Tabel 4.1.2 Hasil pengujian delay pada TCP dengan packet error probabability yang berbeda

24

Gambar 4.1.2 Delay TCP pada penambahan packet error probabability

Pada gambar 4.1.2 Penambahan packet error probability menyebabkan drop semakin turun pada kedua prokol karena semakin besar packet error yang terjadi menyebabkan TCP menjadi semakin sering jatuh dan harus memulai dari awal (slow start) yang kemudian menyebabkan paket yang dikirim sangat kecil sehingga antrian yang terjadi pada buffer menjadi lebih kecil dan berdampak pada nilai delay yang semakin kecil. Dapat dilihat bahwa end to end delay pada TCP Vegas lebih besar daripada TCP Reno, hal tersebut dikarenakan TCP Vegas dapat menghadapi lebih banyak packet loss (drop) daripada TCP Reno, TCP Vegas tidak mudah jatuh jika terjadi paket hilang seperti yang terjadi pada TCP Reno sehingga TCP Vegas dapat mengirimkan paket yang lebih banyak, dengan banyaknya paket yang dikirim tersebut menyebabkan antrian yang lebih panjang sehingga nilai delay lebih besar.

0 0.005 0.01 0.015 0.02

5 10 15

d

e

lay

(

s)

Packet Error probability (%)

End to End delay

25 4.1.3. Packet loss

Packet Error

probability (%) Reno Vegas

5 791.8 1649.6

10 460.4 1109

15 273.4 808.6

Tabel 4.1.3 Hasil pengujian packet loss pada TCP dengan packet error probabability

yang berbeda

Gambar 4.1.3Packet loss TCP pada penambahan packet error probabability

Pada gambar 4.1.3 Penambahan packet error probability menyebabkan drop semakin turun pada kedua prokol karena semakin besar packet error yang terjadi menyebabkan unjuk kerja TCP menjadi semakin buruk dan harus memulai dari awal (slow start) yang kemudian menyebabkan paket yang dikirim sangat kecil sehingga paket yang loss akan semakin kecil. Dapat dilihat bahwa packet loss pada TCP Vegas lebih besar daripada TCP Reno, hal tersebut dikarenakan TCP Vegas dapat

0 200 400 600 800 1000 1200 1400 1600 1800

5 10 15

P ac k e t lo ss ( p k t)

Packet error probability (%)

Packet loss

26

menghadapi lebih banyak packet loss (drop) daripada TCP Reno, TCP Vegas tidak mudah jatuh jika terjadi paket hilang seperti yang terjadi pada TCP Reno sehingga TCP Vegas dapat mengirimkan paket yang lebih banyak, dengan banyaknya paket yang dikirim tersebut maka packet loss yang terjadi lebih besar.

4.1.4 Congestion Window

27

b) packet error probability 10%

28

c) packet error probability 15%

29

Gambar 4.1.4 Congestion Window pada packet error probability yang berbeda

Pada gambar a) hingga d) ditunjukkan bahwa congestion window TCP Reno lebih kecil dibandingkan TCP Vegas, hal ini dikarenakan cara kerja TCP Reno yang sangat dipengaruhi oleh adanya loss paket menyebabkan congestion window sering jatuh ketika terjadi single error ataupun mengalami timeout ketika terjadi multiple error (2 atau lebih paket eror dalam satu window) pada jaringan dengan packet error

menyebabkan congestion windows menjadi kecil. Di sisi lain congestion windows TCP Vegas lebih besar dibandingkan TCP Reno, hal tersebut congestion window TCP Vegas tidak selalu diturunkan ketika terjadi loss paket, ketika terjadi multiple error (2

loss paket dalam satu window) penurunan congestion window hanya dilakukan pada retransmisi paket yang pertama dan penurunan yang terjadi tidak sebesar TCP Reno (50% pada TCP Reno dan 25% pada TCP Vegas), karena mampu menangani adanya

multiple error menyebabkan congestion window pada TCP Vegas lebih besar dibandingkan TCP Reno.

30 4.2.Efek ukuran buffer queue

Parameter

Buffer 20 Buffer 60 Reno Vegas Reno Vegas Throughput _{50.02415625 54.94651563 52.73991504 50.12558594}

Delay _{0.181965114 0.16866472 0.418346728 0.266619286}

Packet loss _{254 140 43 14}

Tabel 4.2 Hasil simulasi pada efek ukuran buffer size

4.2.1. Throughput

Gambar 4.2.1Throughput pada TCP dengan buffer size yang berbeda

Pada grafik a) ditunjukkan bahwa nilai throughput TCP Vegas lebih besar daripada TCP Reno. Ketika ukuran buffer kecil maka cara kerja TCP Reno yang berusaha mengirim sebanyak mungkin data tidak mendapat dukungan buffer yang memadai menyebabkan paket-paket yang dikirimkannya banyak mengalami drop

50.02415 625 54.94651 563 47 48 49 50 51 52 53 54 55 56 Reno Vegas T h ro u g h p u t (k b p s)

Throughput

52.7399 1504 50.1255 8594 47 48 49 50 51 52 53 54 55 56 Reno Vegas T h ro u g h p u t (k b p s)

Throughput

31

sehingga TCP Reno sering jatuh dan paket yang dikirim hanya berjumlah kecil yang menyebabkan nilai throughput-nyakecil. Sedangkan TCP Vegas dapat unggul karena ukuran buffer yang kecil menghasilkan nilai dan RTT variance yang kecil, ketika nilai dan RTT variance kecil maka TCP Vegas menganggap jaringan sedang dalam keadaan yang stabil sehingga penurunan dalam pengiriman paket karena keadaan macet menjadi lebih sedikit dan menghasilkan nilai throughput yang besar.

Grafik b) menunjukkan throughput pada buffer size 60, pada grafik tersebut ditunjukkan bahwa nilai throughput TCP Vegas lebih kecil daripada TCP Reno, Ketika ukuran buffer besar maka cara kerja TCP Reno yang berusaha mengirim sebanyak mungkin data mendapat dukungan buffer yang memadai menyebabkan paket-paket yang dikirimkannya banyak yang dapat ditampung oleh buffer sehingga drop menjadi kecil, drop yang kecil menyebabkan TCP Reno dapat mengirimkan lebih banyak paket yang kemudian menghasilkan nilai throughput yang besar. Sedangkan TCP Vegas berada di bawah TCP Reno karena ukuran buffer yang besar menghasilkan nilai dan variasi RTT yang besar, ketika nilai dan variasi RTT besar maka TCP Vegas menganggap jaringan sedang dalam keadaan yang buruk sehingga penurunan dalam pengiriman paket karena keadaan macet menjadi lebih banyak dilakukan yang kemudian menyebabkan nilai throughput menjadi kecil.

32 4.2.2. Delay

Gambar 4.2.2Delay pada TCP dengan buffer size yang berbeda

Pada kedua grafik ditunjukkan bahwa nilai delay TCP Reno lebih besar daripada TCP Vegas, hal tersebut disebabkan oleh cara kerja TCP Reno yang berusaha mengirim sebanyak mungkin data menyebabkan antrian panjang yang kemudian menghasilkan waktu antri yang lebih besar dan mengakibatkan delay menjadi besar, sedangkan karakteristik TCP Vegas yang berusaha untuk mengurangi beban jaringan menyebabkan pengiriman paket hanya dalam jumlah yang kecil, dan dengan jumlah paket yang kecil ini maka antrian yang terjadi akan lebih pendek, antrian pendek akan menghasilkan delay yang kecil.

0.18196 5114 0.16866 472 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 Reno Vegas E to E d e lay ( s)

End to End delay

0.418346 728 0.266619 286 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 Reno Vegas E to E d e lay ( s)

End to End delay

33 4.2.3. Packet loss

Gambar 4.2.3 Packet loss pada TCP dengan buffer size yang berbeda

Pada kedua grafik tersebut ditunjukkan bahwa packet loss TCP Reno lebih besar daripada TCP Vegas, hal tersebut disebabkan oleh cara kerja TCP Reno yang berusaha mengirim sebanyak mungkin data menyebabkan banyak paket yang dikirimkannya tidak dapat ditampung oleh buffer yang ada dan mengakibatkan banyak paket mengalami drop , sedangkan karakteristik TCP Vegas yang berusaha untuk mengurangi beban jaringan menyebabkan pengiriman paket hanya dalam jumlah yang kecil, dan dengan jumlah paket yang kecil ini maka buffer mampu menampung sebagian besar paket yang dikirim dan drop yang terjadi karena buffer overload

menjadi kecil. 254 43 0 50 100 150 200 250 300

buffer 20 buffer 60

d ro p ( p k t)

Packet loss

43 14 0 50 100 150 200 250 300 Reno Vegas d ro p ( p k t)

Packet loss

34 4.2.4. RTT

Buffer size

Rata-rata RTT

Reno Vegas

20 0.09298952 0.06528966

60 0.22162661 0.10384049

Tabel 4.2.4 Rata-rata RTT pada buffer size yang berbeda

35

sampel buffer 20

36

Gambar 4.2.4RTT pada TCP dengan buffer size yang berbeda

Pada grafik a) ditunjukkan bahwa RTT TCP Reno dan TCP Vegas hampir terlihat sama namun jika dilihat pada rata-ratanya akan berbeda, hal tersebut karena kapasitas buffer yang kecil memiliki waktu antri terbesar yang sudah dicapai oleh kedua TCP sehingga nilai RTT yang didapatkan oleh kedua TCP tidak berbeda jauh. Sedangkan pada b) dapat dilihat bahwa secara keseluruhan RTT TCP Reno lebih besar daripada TCP Vegas, hal tersebut dikarenakan cara kerja TCP Reno yang berusaha mengirim sebanyak mungkin data menghasilkan antrian panjang dan hal ini menyebabkan nilai delay yang besar dan mengkibatkan nilai RTT yang juga besar, berbeda dengan TCP Vegas yang mengirimkan paket dengan jumlah yang kecil karena berusaha untuk tidak menyebabkan kemacetan jaringan yang lebih parah, paket dengan jumlah kecil menghasilkan antrian pendek yang menyebabkan nilai delay dan RTT

menjadi kecil.

37 4.2.5.Congestion Window

a) buffer 20

38

Gambar 4.2.5 Congestion Window pada buffer size yang berbeda b) buffer 60

39

Pada gambar a) ditunjukkan bahwa congestion window pada TCP Reno sering mengalami penurunan, hal ini disebabkan oleh ukuran buffer yang kecil. Cara kerja TCP Reno yang agresif dalam mengirim data serta adanya trafik lain menyebabkan

buffer sering mengalami kelebihan beban (overload) yang berakhir dengan banyaknya paket yang di drop oleh router, banyaknya loss paket inilah yang menyebabkan TCP Reno sering menjatuhkan congestion window-nya. Sedangkan penurunan yang terjadi pada TCP Vegas lebih disebabkan oleh nilai RTT yang dipengaruhi oleh delay yang dihasilkan oleh antrian pada router karena loss paket yang terjadi kecil. Buffer yang berukuran kecil menghasilkan delay dan RTT yang cenderung tidak berbeda jauh satu sama lain (RTT variance kecil), hal ini memberikan dampak baik bagi kinerja TCP Vegas karena perbedaan RTT yang tidak terlalu jauh mengindikasikan kongesti yang tidak parah dan penurunan congestion window tidak terlalu banyak terjadi.

Pada gambar b) ditunjukkan bahwa penurunan congestion window pada TCP Reno sangat jarang, hal ini disebabkan oleh ukuran buffer yang besar. Cara kerja TCP Reno yang agresif dalam mengirim data serta adanya trafik lain masih dapat di tangani oleh buffer yang tersedia dan kelebihan beban (overload) yang terjadi sangat kecil, kecilnya loss paket yang terjadi menyebabkan penurunan congestion window jarang terjadi . Sedangkan penurunan yang terjadi pada TCP Vegas lebih disebabkan oleh nilai RTT yang dipengaruhi oleh delay yang dihasilkan oleh antrian pada router karena loss

paket yang terjadi kecil. Buffer yang berukuran besar menghasilkan delay dan RTT

yang cenderung berbeda jauh satu sama lain (RTT variance besar), hal ini memberikan dampak baik bagi kinerja TCP Vegas karena perbedaan RTT yang berbeda jauh dapat memberikan indikasi bahwa sedang terjadi kongesti yang parah, hal ini menyebabkan TCP Vegas sering mengalami penurunan congestion window.

40 BAB V

KESIMPULAN DAN SARAN 5.1.Kesimpulan

Dari hasil pengujian dan juga analisis yang telah dilakukan dapat disimpulkan beberapa hal sebagai berikut :

a. Pada buffer size yang kecil dan packet error nilai throughput TCP Vegas lebih unggul dibandingkan TCP Reno dikarenakan packet loss yang terjadi menyebabkan TCP Reno sering menjatuhkan congestion

windows-nya dan berdampak pada pengiriman paket yang kecil dan menyebabkan nilai throughput menjadi kecil. Sedangkan pada buffer size yang besar,

throughput TCP Reno lebih tinggi dibandingkan TCP Vegas karena

packet loss yang terjadi kecil, ditambah lagi dengan besarnya buffer size

menyebabkan nilai RTT variance menjadi besar yang kemudian akan berdampak pada turunnya hasil unjuk kerja dari TCP Vegas.

b. Pada skenario buffer size, nilai packet loss dan end to end delay pada TCP Vegas lebih baik dibandingkan TCP Reno, hal tersebut dikarenakan cara kerja TCP Vegas yang berusaha mengurangi kongesti melalui pengiriman paket dalam jumlah yang kecil menghasilkan suatu antrian yang lebih pendek dan berdampak pada packet loss dan end to end delay yang lebih kecil, dan TCP Reno adalah sebaliknya. Sedangkan pada packet error,

nilai packet loss dan end to end delay TCP Vegas lebih besar karena pengaruh adanya packet loss pada TCP Vegas lebih kecil dibandingkan TCP Reno, hal tersebut menyebabkan TCP Vegas dapat mengirim lebih banyak paket dan berdampak pada packet loss dan end to end delay yang lebih besar.

5.2.Saran

a. Penelitian lebih lanjut yang dapat dilakukan adalah TCP Vegas pada

41

DAFTAR PUSTAKA

[1] Performance Measurements and metrics, n.d.Available at :

webstaff.itn.liu.se/~davgu/tnk087/Fo_8.pdf. [Accessed 03 December 2015] [2] Packet loss definition, (2007).Available at :

http://searchnetworking.techtarget.com/definition/packet-loss.[Accessed 03 December 2015]

[3] Brakmo, L. S., O’Malley,S.W., & Peterson, L. L. (1994), TCP Vegas:New Techniques for Congestion Detection and Avoidance. Department of Computer Science, University of Arizona.

[4] Andras Varga 2014 , Omnet+ + USER MANUAL , OpenSim LTD Copyright.. [5] Samios, C., Vernon M.K. n.d Modeling the Throughput of TCP Vegas.

Department of Computer Sciences, University of Wisconsin.

[6] Brakmo, L. S. Brakmo and Peterson, L. L. (1995), TCP Vegas: End to end congestion avoidance on a global internet. IEEE Journal on Selected Areas in Communications, 13(8).

LAMPIRAN

1. .ini Skenario packet error rate [Config inet-vegas]

**.tcpType = "TCP"

**.tcpAlgorithmClass = "TCPVegas" [Config inet-reno]

**.tcpType = "TCP"

**.tcpAlgorithmClass = "TCPReno"

[General]

network = test.Network record-eventlog = true sim-time-limit = 200s repeat = 51

#seed-0-mt = 7

**.scalar-recording = true **.vector-recording = true

**.endToEndDelay.scalar-recording = true **.endToEndDelay.vector-recording = true **.Mean endToEndDelay.vector-recording = true #record-eventlog = true

**.result-recording-modes = all

#tcp connection

#**.tcp.advertisedWindow = 16384

#**.tcp.advertisedWindow = 65535 # in bytes, corresponds with the maximal receiver buffer capacity (Note: normally, NIC queues should be at least this size) **.tcp.delayedAcksEnabled = false # delayed ACK algorithm (RFC 1122) enabled/disabled

**.tcp.nagleEnabled = true # Nagle's algorithm (RFC 896) enabled/disabled

**.tcp.limitedTransmitEnabled = false # Limited Transmit algorithm (RFC 3042) enabled/disabled (can be used for TCPReno/TCPTahoe/TCPNewReno/TCPNoCongestionControl)

**.tcp.increasedIWEnabled = false # Increased Initial Window (RFC 3390) enabled/disabled **.tcp.sackSupport = false # Selective Acknowledgment (RFC 2018, 2883, 3517) support

(header option) (SACK will be enabled for a connection if both endpoints support it)

**.tcp.windowScalingSupport = false # Window Scale (RFC 1323) support (header option) (WS will be enabled for a connection if both endpoints support it)

**.tcp.timestampSupport = true # Timestamps (RFC 1323) support (header option) (TS will be enabled for a connection if both endpoints support it) **.tcp.mss = 1024 # Maximum Segment Size (RFC 793) (header

**.tcp.recordStats = true #

recording of seqNum etc. into output vectors enabled/disabled #**.tcp.sendQueueClass = "TCPMsgBasedSendQueue"

#TCPVirtualDataSendQueue/TCPMsgBasedSendQueue #**.tcp.receiveQueueClass = "TCPMsgBasedRcvQueue" #TCPVirtualDataRcvQueue/TCPMsgBasedRcvQueue

##tcp tcp_source

**.TCPSource.numTcpApps = 1

**.TCPSource.tcpApp[*].typename = "TCPSessionApp" **.TCPSource.tcpApp[*].connectAddress = "TCPDest"

**.TCPSource.tcpApp[*].sendBytes = 10000MiB **.TCPSource.tcpApp[*].active = true

**.TCPSource.tcpApp[*].localAddress = "TCPSource" **.TCPSource.tcpApp[*].connectPort = 6789

**.TCPSource.tcpApp[*].localPort = 10020 **.TCPSource.tcpApp[*].tOpen = 0.1s **.TCPSource.tcpApp[*].tSend = 0s **.TCPSource.tcpApp[*].tClose = 200s #tcp tcp_sink

**.TCPDest.numTcpApps = 1

**.TCPDest.tcpApp[*].typename = "TCPSinkApp" **.TCPDest.tcpApp[*].localAddress = "TCPDest" **.TCPDest.tcpApp[*].localPort = 6789

**.configurator.networkConfiguratorModule = "iPv4NetworkConfigurator"

#[Config DroptailQueue] #NIC adapter

**.router.ppp[*].queueType = "DropTailQueue" **.router.ppp[*].queue.frameCapacity = 20 **.router.ppp[*].queue.vector-recording = true

**.router.ppp[*].queue.queueLength.result-recording-modes = true

**.router1.ppp[*].queueType = "DropTailQueue" **.router1.ppp[*].queue.frameCapacity = 20 **.router1.ppp[*].queue.vector-recording = true

**.router1.ppp[*].queue.queueLength.result-recording-modes = true

Pada source code nednya tambah dengan error rate pada link connections:

router.pppg++ <--> DatarateChannel { delay = 2ms; datarate = 2 Mbps; per = 0.2; } <--> router1.pppg++; #error rate 5,10,15

2. . ini Skenario efek buffer

[Config inet-vegas20] **.tcpType = "TCP"

**.tcpAlgorithmClass = "TCPVegas"

[Config inet-reno20] **.tcpType = "TCP"

**.tcpAlgorithmClass = "TCPReno"

[General]

network = jajal.Network record-eventlog = true sim-time-limit = 200s repeat = 51

#seed-0-mt = 6

**.scalar-recording = true **.vector-recording = true

**.endToEndDelay.scalar-recording = true **.endToEndDelay.vector-recording = true **.Mean endToEndDelay.vector-recording = true

#record-eventlog = true

**.result-recording-modes = all

#tcp connection

#**.tcp.advertisedWindow = 16384

#**.tcp.advertisedWindow = 65535 # in bytes, corresponds with the maximal receiver buffer capacity (Note: normally, NIC queues should be at least this size) **.tcp.delayedAcksEnabled = false # delayed ACK algorithm (RFC 1122) enabled/disabled

**.tcp.nagleEnabled = true # Nagle's algorithm (RFC 896) enabled/disabled

**.tcp.limitedTransmitEnabled = false # Limited Transmit algorithm (RFC 3042) enabled/disabled (can be used for TCPReno/TCPTahoe/TCPNewReno/TCPNoCongestionControl) **.tcp.increasedIWEnabled = false # Increased Initial Window (RFC 3390) enabled/disabled **.tcp.sackSupport = false # Selective Acknowledgment (RFC 2018, 2883, 3517) support

(header option) (SACK will be enabled for a connection if both endpoints support it)

**.tcp.windowScalingSupport = false # Window Scale (RFC 1323) support (header option) (WS will be enabled for a connection if both endpoints support it)

**.tcp.timestampSupport = true # Timestamps (RFC 1323) support (header option) (TS will be enabled for a connection if both endpoints support it) **.tcp.mss = 1460 # Maximum Segment Size (RFC 793) (header

**.tcp.recordStats = true #

recording of seqNum etc. into output vectors enabled/disabled #**.tcp.sendQueueClass = "TCPMsgBasedSendQueue"

#TCPVirtualDataSendQueue/TCPMsgBasedSendQueue #**.tcp.receiveQueueClass = "TCPMsgBasedRcvQueue" #TCPVirtualDataRcvQueue/TCPMsgBasedRcvQueue

##tcp tcp_source

**.TCPSource.numTcpApps = 1

**.TCPSource.tcpApp[*].typename = "TCPSessionApp" **.TCPSource.tcpApp[*].connectAddress = "TCPDest"

**.TCPSource.tcpApp[*].sendBytes = 10000MiB **.TCPSource.tcpApp[*].active = true

**.TCPSource.tcpApp[*].connectPort = 6789 **.TCPSource.tcpApp[*].localPort = 10020 **.TCPSource.tcpApp[*].tOpen = 0

**.TCPSource.tcpApp[*].tSend = 0s **.TCPSource.tcpApp[*].tClose = 200s #tcp tcp_sink

**.TCPDest.numTcpApps = 1

**.TCPDest.tcpApp[*].typename = "TCPSinkApp" **.TCPDest.tcpApp[*].localAddress = "TCPDest" **.TCPDest.tcpApp[*].localPort = 6789

**.configurator.networkConfiguratorModule = "iPv4NetworkConfigurator"

#[Config DroptailQueue] #NIC adapter

**.router.ppp[*].queueType = "DropTailQueue" **.router.ppp[*].queue.frameCapacity = 60 **.router.ppp[*].queue.vector-recording = true

**.router.ppp[*].queue.queueLength.result-recording-modes = true

**.router1.ppp[*].queueType = "DropTailQueue" **.router1.ppp[*].queue.frameCapacity = 60 **.router1.ppp[*].queue.vector-recording = true

**.router1.ppp[*].queue.queueLength.result-recording-modes = true

#UDP1

**.UDPStreamCli.numUdpApps = 2

**.UDPStreamCli.udpApp[0].typename = "SimpleVoIPSender" **.UDPStreamCli.udpApp[0].destAddress = "UDPStreamSer" **.UDPStreamCli.udpApp[0].destPort = 9911

**.UDPStreamCli.udpApp[0].talkPacketSize = 2048B **.UDPStreamCli.udpApp[0].stopTime = 200s

**.UDPStreamCli.udpApp[1].typename = "SimpleVoIPSender" **.UDPStreamCli.udpApp[1].destAddress = "UDPStreamSer" **.UDPStreamCli.udpApp[1].destPort = 9912

**.UDPStreamCli.udpApp[1].talkPacketSize = 2048B **.UDPStreamCli.udpApp[1].stopTime = 200s

#**.UDPStreamCli.udpApp[*].packetizationInterval = 1ms #**.UDPStreamCli.udpApp[*].silenceDuration = 0.3s #**.UDPStreamCli.udpApp[*].talkspurtDuration = 1ms #**.UDPStreamCli.udpApp[*].silenceDuration = 0.1s

41

DAFTAR PUSTAKA

[1]

Performance Measurements and metrics,

n.d.

Available at :

webstaff.itn.liu.se/~davgu/tnk087/Fo_8.pdf.

[Accessed 03 December 2015]

[2]

Packet loss definition,

(2007).

Available at :

http://searchnetworking.techtarget.com/definition/packet-loss.

[Accessed 03

December 2015]

[3] Brakmo, L.

S., O’Malley,S.W., & Peterson, L.

L. (1994),

TCP Vegas:New

Techniques for Congestion Detection and Avoidance

. Department of Computer

Science, University of Arizona.

[4] Andras Varga 2014 ,

Omnet+ + USER MANUAL

, OpenSim LTD Copyright..

[5] Samios, C., Vernon M.K. n.d

Modeling the Throughput of TCP Vegas.

Department of Computer Sciences, University of Wisconsin.

[6] Brakmo, L. S. Brakmo and Peterson, L. L. (1995),

TCP Vegas: End to end

congestion avoidance on a global internet

. IEEE Journal on Selected Areas in

Communications, 13(8).

LAMPIRAN

1. .ini Skenario packet error rate [Config inet-vegas]

**.tcpType = "TCP"

**.tcpAlgorithmClass = "TCPVegas" [Config inet-reno]

**.tcpType = "TCP"

**.tcpAlgorithmClass = "TCPReno"

[General]

network = test.Network record-eventlog = true sim-time-limit = 200s repeat = 51

#seed-0-mt = 7

**.scalar-recording = true **.vector-recording = true

**.endToEndDelay.scalar-recording = true **.endToEndDelay.vector-recording = true **.Mean endToEndDelay.vector-recording = true #record-eventlog = true

**.result-recording-modes = all

#tcp connection

#**.tcp.advertisedWindow = 16384

#**.tcp.advertisedWindow = 65535 # in bytes, corresponds with the maximal receiver buffer capacity (Note: normally, NIC queues should be at least this size) **.tcp.delayedAcksEnabled = false # delayed ACK algorithm (RFC 1122) enabled/disabled

**.tcp.nagleEnabled = true # Nagle's algorithm (RFC 896) enabled/disabled

**.tcp.limitedTransmitEnabled = false # Limited Transmit algorithm (RFC 3042) enabled/disabled (can be used for TCPReno/TCPTahoe/TCPNewReno/TCPNoCongestionControl)

**.tcp.increasedIWEnabled = false # Increased Initial Window (RFC 3390) enabled/disabled **.tcp.sackSupport = false # Selective Acknowledgment (RFC 2018, 2883, 3517) support

(header option) (SACK will be enabled for a connection if both endpoints support it)

**.tcp.windowScalingSupport = false # Window Scale (RFC 1323) support (header option) (WS will be enabled for a connection if both endpoints support it)

**.tcp.timestampSupport = true # Timestamps (RFC 1323) support (header option) (TS will be enabled for a connection if both endpoints support it) **.tcp.mss = 1024 # Maximum Segment Size (RFC 793) (header

**.tcp.recordStats = true #

recording of seqNum etc. into output vectors enabled/disabled #**.tcp.sendQueueClass = "TCPMsgBasedSendQueue"

#TCPVirtualDataSendQueue/TCPMsgBasedSendQueue #**.tcp.receiveQueueClass = "TCPMsgBasedRcvQueue" #TCPVirtualDataRcvQueue/TCPMsgBasedRcvQueue

##tcp tcp_source

**.TCPSource.numTcpApps = 1

**.TCPSource.tcpApp[*].typename = "TCPSessionApp" **.TCPSource.tcpApp[*].connectAddress = "TCPDest"

**.TCPSource.tcpApp[*].sendBytes = 10000MiB **.TCPSource.tcpApp[*].active = true

**.TCPSource.tcpApp[*].localAddress = "TCPSource" **.TCPSource.tcpApp[*].connectPort = 6789

**.TCPSource.tcpApp[*].localPort = 10020 **.TCPSource.tcpApp[*].tOpen = 0.1s **.TCPSource.tcpApp[*].tSend = 0s **.TCPSource.tcpApp[*].tClose = 200s #tcp tcp_sink

**.TCPDest.numTcpApps = 1

**.TCPDest.tcpApp[*].typename = "TCPSinkApp" **.TCPDest.tcpApp[*].localAddress = "TCPDest" **.TCPDest.tcpApp[*].localPort = 6789

**.configurator.networkConfiguratorModule = "iPv4NetworkConfigurator"

#[Config DroptailQueue] #NIC adapter

**.router.ppp[*].queueType = "DropTailQueue" **.router.ppp[*].queue.frameCapacity = 20 **.router.ppp[*].queue.vector-recording = true

**.router.ppp[*].queue.queueLength.result-recording-modes = true

**.router1.ppp[*].queueType = "DropTailQueue" **.router1.ppp[*].queue.frameCapacity = 20 **.router1.ppp[*].queue.vector-recording = true

**.router1.ppp[*].queue.queueLength.result-recording-modes = true

Pada source code nednya tambah dengan error rate pada link connections:

router.pppg++ <--> DatarateChannel { delay = 2ms; datarate = 2 Mbps; per = 0.2; } <--> router1.pppg++; #error rate 5,10,15

2. . ini Skenario efek buffer [Config inet-vegas20] **.tcpType = "TCP"

**.tcpAlgorithmClass = "TCPVegas"

[Config inet-reno20] **.tcpType = "TCP"

**.tcpAlgorithmClass = "TCPReno"

[General]

network = jajal.Network record-eventlog = true sim-time-limit = 200s repeat = 51

#seed-0-mt = 6

**.scalar-recording = true **.vector-recording = true

**.endToEndDelay.scalar-recording = true **.endToEndDelay.vector-recording = true **.Mean endToEndDelay.vector-recording = true

#record-eventlog = true

**.result-recording-modes = all

#tcp connection

#**.tcp.advertisedWindow = 16384

#**.tcp.advertisedWindow = 65535 # in bytes, corresponds with the maximal receiver buffer capacity (Note: normally, NIC queues should be at least this size) **.tcp.delayedAcksEnabled = false # delayed ACK algorithm (RFC 1122) enabled/disabled

**.tcp.nagleEnabled = true # Nagle's algorithm (RFC 896) enabled/disabled

**.tcp.limitedTransmitEnabled = false # Limited Transmit algorithm (RFC 3042) enabled/disabled (can be used for TCPReno/TCPTahoe/TCPNewReno/TCPNoCongestionControl) **.tcp.increasedIWEnabled = false # Increased Initial Window (RFC 3390) enabled/disabled **.tcp.sackSupport = false # Selective Acknowledgment (RFC 2018, 2883, 3517) support

(header option) (SACK will be enabled for a connection if both endpoints support it)

**.tcp.windowScalingSupport = false # Window Scale (RFC 1323) support (header option) (WS will be enabled for a connection if both endpoints support it)

**.tcp.timestampSupport = true # Timestamps (RFC 1323) support (header option) (TS will be enabled for a connection if both endpoints support it) **.tcp.mss = 1460 # Maximum Segment Size (RFC 793) (header

**.tcp.recordStats = true #

recording of seqNum etc. into output vectors enabled/disabled #**.tcp.sendQueueClass = "TCPMsgBasedSendQueue"

#TCPVirtualDataSendQueue/TCPMsgBasedSendQueue #**.tcp.receiveQueueClass = "TCPMsgBasedRcvQueue" #TCPVirtualDataRcvQueue/TCPMsgBasedRcvQueue

##tcp tcp_source

**.TCPSource.numTcpApps = 1

**.TCPSource.tcpApp[*].typename = "TCPSessionApp" **.TCPSource.tcpApp[*].connectAddress = "TCPDest"

**.TCPSource.tcpApp[*].sendBytes = 10000MiB **.TCPSource.tcpApp[*].active = true

**.TCPSource.tcpApp[*].connectPort = 6789 **.TCPSource.tcpApp[*].localPort = 10020 **.TCPSource.tcpApp[*].tOpen = 0

**.TCPSource.tcpApp[*].tSend = 0s **.TCPSource.tcpApp[*].tClose = 200s #tcp tcp_sink

**.TCPDest.numTcpApps = 1

**.TCPDest.tcpApp[*].typename = "TCPSinkApp" **.TCPDest.tcpApp[*].localAddress = "TCPDest" **.TCPDest.tcpApp[*].localPort = 6789

**.configurator.networkConfiguratorModule = "iPv4NetworkConfigurator"

#[Config DroptailQueue] #NIC adapter

**.router.ppp[*].queueType = "DropTailQueue" **.router.ppp[*].queue.frameCapacity = 60 **.router.ppp[*].queue.vector-recording = true

**.router.ppp[*].queue.queueLength.result-recording-modes = true

**.router1.ppp[*].queueType = "DropTailQueue" **.router1.ppp[*].queue.frameCapacity = 60 **.router1.ppp[*].queue.vector-recording = true

**.router1.ppp[*].queue.queueLength.result-recording-modes = true

#UDP1

**.UDPStreamCli.numUdpApps = 2

**.UDPStreamCli.udpApp[0].typename = "SimpleVoIPSender" **.UDPStreamCli.udpApp[0].destAddress = "UDPStreamSer" **.UDPStreamCli.udpApp[0].destPort = 9911

**.UDPStreamCli.udpApp[0].talkPacketSize = 2048B **.UDPStreamCli.udpApp[0].stopTime = 200s

**.UDPStreamCli.udpApp[1].typename = "SimpleVoIPSender" **.UDPStreamCli.udpApp[1].destAddress = "UDPStreamSer" **.UDPStreamCli.udpApp[1].destPort = 9912

**.UDPStreamCli.udpApp[1].talkPacketSize = 2048B **.UDPStreamCli.udpApp[1].stopTime = 200s

#**.UDPStreamCli.udpApp[*].packetizationInterval = 1ms #**.UDPStreamCli.udpApp[*].silenceDuration = 0.3s #**.UDPStreamCli.udpApp[*].talkspurtDuration = 1ms #**.UDPStreamCli.udpApp[*].silenceDuration = 0.1s