IP

Analisa Perbandingan Class Based Queuing (CBQ) dan Hierarchical Token Bucket (HTB) Untuk Manajemen Bandwidth Pada Jaringan TCP/IP Nyoman Bogi AK, Ir, MSEE1, Andi Ardiansyah2 , Eka Pratania3 1,3 Jurusan Teknik Elektro Sekolah Tinggi Teknologi Telkom 2 PT. Comnet Indonesia 1 [email protected], [email protected], [email protected] ABSTRAK Manajemen bandwidth menjadi hal yang mutlak diperlukan bagi jaringan multi layanan, semakin banyak dan bervariasinya aplikasi yang dapat dilayani oleh suatu jaringan berpengaruh pada penggunaan link dalam jaringan tersebut. Link-link yang ada harus mampu menangani kebutuhan user akan aplikasi tesebut bahkan dalam keadaan kongesti sekalipun, harus ada suatu jaminan bahwa link tetap dapat berfungsi sebagaimana mestinya walaupun terjadi ledakan permintaan aplikasi. Manajemen bandwidth memegang perananan penting dalam mengatur jenis aplikasi yang bisa mengakses link yang ada selain itu manajemen bandwidth mampu memberikan garansi kepada aplikasi yang mendapat alokasi bandwidth untuk terus mengirimkan data sesuai dengan alokasinya sekalipun terjadi kemacetan dalam jaringan bahkan dalam keadaan tertentu ketika alokasi bandwidth yang dimiliki oleh suatu aplikasi/layanan tidak digunakan maka oleh Bandwidth Manager alokasi bandwidth yang idle tersebut dapat dialihkan sementara waktu kepada kelas yang sedang mengalami backlog/timbunan antrian, hal ini memberikan keuntungan mempercepat hilangnya backlog suatu kelas sekaligus mengoptimalkan penggunaan link yang ada. Class Based Queuing (CBQ) dan Hierarchical Token Bucket (HTB) sebagai implementator manajemen bandwidth yang tersedia secara gratis dan dapat dijalankan diatas platform sistem Operasi LINUX merupakan Bandwidth Manager yang layak dianalisa keunggulan dan kelemahannya, diharapkan penggunaannya yang tepat dan akurat akan membuat jaringan yang menerapkan Bandwidth Manager ini bekerja secara optimal. kata kunci : Bandwidth Manager, CBQ, HTB, link sharing ABSTRACT Bandwidth management absolutely is needed for multiservice network, variant applications which can be served influence to the use of link in that network. Links must be able to handle user need even in congestion condition. It must be a guarantee that link still be alive properly eventhough network experiences heavy request services. Bandwidth management holds important role in order to manage kind of application which can access remain link beside that it can give us warrant to application which has bandwidth allocation to keep sending data although there is congestion in network. Moreover in particular situation, if other application does not use their bandwidth allocation, Bandwidth Manager will shift that idle bandwidth to class which is experiencing backlog. The benefit is not only reducing the packet queue but also optimalizing the use of link. Class Based Queuing (CBQ) and Hierarchical Token Bucket (HTB), as Bandwidth Manager, which can be got freely and can be used over Linux platform are suitable to analyze the pros and cons. It is expected that Bandwidth Manager can be implemented accurately and appropriately so that network will work optimally. keyword : Bandwidth Manager, CBQ, HTB, link sharing 1. PENDAHULUAN Perkembangan komunikasi data telah mencapai kemajuan yang sangat pesat, ditandai oleh pemakaiannya yang begitu meluas tidak hanya oleh perusahaanperusahaan berskala besar tetapi juga oleh individuindividu yang membutuhkan informasi yang cepat dan terbarukan melalui jaringan komunikasi data terutama melalui Internet. Internet telah memberikan pengaruh yang sangat besar pada penyebaran informasi berupa data, dengan demikian akan semakin banyak individu yang mengakses data melalui internet. Hal ini akan berakibat pada meningkatnya trafik data yang dapat menyebabkan penurunan performansi jaringan terutama pada jaringan yang memiliki bandwidth terbatas dan

yang tidak berkeinginan untuk menambah kapasitas bandwidthnya (bandwidth WAN berbanding lurus dengan biaya), untuk mengurangi penurunan performansi jaringan tanpa menambah biaya (atau bandwidth) salah satunya dengan menerapkan manajemen bandwidth dengan menerapkan disiplin antrian pada gateway berbasis LINUX. Dalam penelitian tugas akhir ini, penulis mencoba mengimplementasikan serta membandingkan Bandwidth Manager yaitu Class Based Queuing (CBQ) dan Hierarchical Token Bucket (HTB) berdasarkan parameter waktu proses, jitter dan respon time serta throughput dengan pembedaan pada pembagian kapasitas bandwidth, nomor port dan alamat IP Address,

sehingga diharapkan didapat jenis Bandwidth Manager yang lebih baik dan optimal diantara keduannya yang bisa secara langsung diimplementasikan pada PC gateway berbasis sistem operasi LINUX II. DASAR TEORI II.1 Class-Based Queuing (CBQ) Class-Based Queuing (CBQ) adalah suatu mekanisme penjadwalan, bertujuan menyediakan Link sharing antar agensi yang menggunakan jalur fisik yang sama, dan sebagai acuan untuk membedakan trafik yang memiliki prioritas-prioritas yang berlainan. Dengan CBQ, setiap agensi dapat mengalokasikan bandwidth miliknya untuk berbagai jenis trafik yang berbeda, sesuai dengan pembagiannya yang tepat untuk masing-masing trafik. CBQ berinteraksi dengan Link sharing memberikan keunggulan yaitu pemberian bandwidth yang tak terpakai bagi leaf classnya sebelum diberikan kepada agensi-agensi lain. Blok-blok utama Class-Based Queuing adalah sebagai berikut : 1. Classifier, bekerja dengan cara yang sama dengan pemfilter paket yaitu mengekstrak aliran informasi dari suatu paket (untuk IP misalnya Ipsrc, Ipdest, PROTO, PORTsrc, PORTdesc) kemudian menempatkannya pada kelas yang sesuai 2. General Scheduler, merupakan mekanisme penjadwalan bertujuan untuk membagi bandwidth saat seluruh kelas memiliki antrian paket. General Scheduler menjamin hak kuantitas layanan untuk tiap cabang kelas (leaf classes), dengan membagikan bandwidth sesuai dengan alokasinya masing-masing. 3. Link-sharing Scheduler, yang bertujuan membagikan bandwidth yang tak terpakai sesuai dengan struktur link-sharingnya. 4. Estimator, merupakan bagian blok umpan balik bagi mekanisme penjadwalan CBQ. II.2 Hierarchical Token Bucket (HTB) Hierarchical Token Bucket (HTB) merupakan teknik penjadwalan paket yang baru-baru ini diperkenalkan bagi router berbasis Linux, dikembangkan pertama kali oleh Martin Devera pada akhir 2001 untuk diproyeksikan sebagai pilihan (atau pengganti) mekanisme penjadwalan yang saat ini masih banyak dipakai yaitu CBQ. HTB diklaim menawarkan kemudahan pemakaian dengan teknik peminjaman dan implementasi pembagian trafik yang lebih akurat. Dasar kerja HTB hampir sama dengan disiplin antrian CBQ bahkan diagram blok sistem CBQ dengan HTB tidak ada perbedaan, hanya saja pada General Scheduler HTB menggunakan mekanisme Deficit Round Robin (DRR) dan pada blok umpan balik, Estimator, HTB tidak menggunakan Eksponential Weighted Moving Average (EWMA) melainkan Token Bucket Filter (TBF). Pada HTB terdapat parameter ceil sehingga kelas akan selalu mendapatkan bandwidth di antara base link dan nilai ceil linknya. Parameter ini dapat dianggap sebagai Estimator kedua, sehingga setiap kelas dapat meminjam bandwidth selama bandwidth total yang diperoleh memiliki nilai di bawah nilai ceil. Hal ini mudah diimplementasikan dengan cara tidak

mengijinkan proses peminjaman bandwidth pada saat kelas telah melampaui link ini (keduanya leaves dan interior dapat memiliki ceil). Sebagai catatan, apabila nilai ceil sama dengan nilai base link, maka akan memiliki fungsi yang sama seperti parameter bounded pada CBQ, di mana kelas-kelas tidak diijinkan untuk meminjam bandwidth. Sedangkan jika nilai ceil diset tak terbatas atau dengan nilai yang lebih tinggi seperti kecepatan link yang dimiliki, maka akan didapat fungsi yang sama seperti kelas non-bounded. III. IMPLEMENTASI BANDWIDTH MANAGER CBQ DAN HTB Implementasi ini dibagi kedalam 3 skenario besar yaitu 1. Skenario dengan beberapa kelas a. Skenario dengan dua leaf class berdasarkan IP Address Band width : 10 Mbit

RO O T Band width : 256 Kbit I P : 192.168 .1.1

b.

A

B

Band width : 192 Kbit


I P : 192.168 .1.2

I P : 192.168 .1.3

Skenario dengan dua leaf class berdasarkan port Bandwidth : 10 Mbit

ROO T Bandwidth : 256 Kbit I P : 192.168.1.1

Bandwidth : 192 Kbit

Bandwidth : 64 Kbit

I P : 192.168.1.2

I P : 192.168.1.3

A

B

C

c.

D

Port 3001

Port 4001

B andw idth 192 K bit


Skenario dengan empat leaf class berdasarkan port

Bandwid th : 10 MBit

RO O T Bandwid th : 256 Kbit I P : 192 .168.1.1

Bandwid th : 192 Kbit

Bandwid th : 64 Kbit

I P : 192 .168.1.2

I P : 192 .168.1.3 A

C

Port 3001 B andw idth 128 K bit

B

D


E


F


d.

Skenario dengan enam leaf class berdasarkan port

IV.1.A Skenario dengan leaf class berdasarkan IP address (BAB III.IV.A.1) 1.

Bandwidth : 10 Mbit

Throughput

RO O T

Throughput CBQ vs HTB Berdasarkan IP Address

Bandwidth : 256 Kbit I P : 192.168.1.1

300

250

Bandwidth : 192 Kbit

A

Throughput (kbit/s)

Bandwidth : 64 Kbit I P : 192.168.1.3

I P : 192.168.1.2 B

200

CBQ IP 192.168.1.2. CBQ IP 192.168.1.3 HTB IP 192.168.1.2 HTB IP 192.168.1.3

150

100

50

C

D

E

F

G

H 0

Port 3001

Port 3002

Port 3003

Port 4001

Port 4002

Port 4003






B andw idth 8 K bit

0

5

10

15

20

25

30

35

40

45

50

55

60

65

70

Waktu (t)

2.

Skenario dengan parameter khusus a. Skenario dengan parameter meminjamkan bandwidth idle”

“tidak

Band width : 10 Mbit


A

B

Band width : 192 Kbit I P : 192.168 .1.2 Boun ded

b.

Band width : 64 Kbit I P : 192.168 .1.3 Boun ded

Skenario 2 IP Address untuk mendapatkan parameter respon time Band width : 10 Mbit


3.

A

B



I P : 192.168 .1.2

I P : 192.168 .1.3

Skenario dengan topologi yang berbeda a. Skenario dengan divais Router eth1

eth0

network ID : 192.168.1.0 eth0

Workstation 1

Server

PC Router

Hub

eth0

network ID : 192.168.2.0

eth0

Workstation 2

Dari grafik diatas didapat throughput IP 192.168.1.2 dengan CBQ sebesar 207 kbps dan dengan HTB diperoleh 192 kbps, untuk IP 192.168.1.3 sebelum terjadi efek link sharing dengan CBQ didapat throughput 66 kbps dengan HTB diperoleh 63.6 kbps. Dengan hanya melihat dari sisi throughput bisa dipastikan CBQ menghasilkan nilai throughput yang lebih baik dibanding dengan HTB namun karena penulis melakukan pengaturan bandwidth dengan menerapkan suatu rule berupa pembatasan bandwidth untuk IP 192.168.1.2 sebesar 192 kbps dan IP 192.168.1.3 sebesar 64 kbps maka pada penerapan HTB tidak terjadi kebocoran bandwidth dan pada CBQ terjadi kebocoran sehingga dapat dipastikan penerapan manajemen bandwidth dengan HTB berdasarkan IP Address jika dilihat dari parameter throughput lebih baik dibandingkan dengan CBQ. Ripple yang diperoleh HTB sebelum terjadinya efek link sharing lebih baik dibandingkan dengan CBQ, dalam arti ripple yang terjadi lebih kecil/sedikit namun ketika efek dari link sharing terjadi yaitu pada t > 44 detik untuk CBQ dan t > 45 detik untuk HTB, CBQ memiliki ripple yang lebih baik dibanding dengan HTB. 2. Waktu pemrosesan pesan dalam Bandwidth Manager (tbm) Waktu pemrosesan pesan dalam CBQ maupun HTB dapat dihitung dengan menggunakan rumus tbm = tb-tm, tbm = waktu pemrosesan pesan dalam Bandwidth Manager tb = waktu pengiriman pesan melalui Bandwidth Manager tm = waktu pengiriman pesan tanpa Bandwidth Manager =

b.

Skenario dengan divais Bridge

eth1

eth0

Workstation 1

Untuk CBQ pada IP 192.168.1.2 Server

PC Bridge

Hub

eth0

eth0

tm =

1 × 1024 × 1024 × 8 × 1000 207 × 1024

= 39570 ms = 39.57 detik tbm CBQ = 40.67 – 39.57 = 1.10 detik

eth0

Workstation 2

IV. ANALISA HASIL IMPLEMENTASI BANDWIDTH MANAGER IV.1. Skenario manajemen bandwidth beberapa kelas (BAB III.IV.A)

packet _ size × 8 × 1000ms line _ speed

Untuk HTB pada IP 192.168.1.2 dengan

tm =

1 × 1024 × 1024 × 8 × 1000 192 × 1024

= 42667 ms = 42.667 detik

tbm HTB = 43.8 – 42.67 = 1.13 detik Untuk CBQ pada IP 92.168.1.3 tm =

1 × 1024 × 1024 × 8 × 1000 132.6 × 1024

= 61780 ms = 61.78 detik tbm CBQ = 63.4 – 62.53 = 0.87 detik Untuk HTB pada IP 192.168.1.3 tm =

1 × 1024 × 1024 × 8 × 1000 127 × 1024

= 64504 ms = 64.504 detik tbm HTB = 66. – 64.504 = 1.56 detik Dari hasil perhitungan didapat tbm CBQ lebih cepat dibanding dengan tbm HTB, hal ini menandakan untuk pembagian kelas berdasarkan IP Address jika dilihat dari waktu proses pemrosesan pesan, CBQ lebih cepat dibanding dengan HTB. 3. Jitter Hasil pengukuran memberikan kesimpulan bahwa untuk alokasi bandwidth berdasarkan kelas berupa IP Address, Jitter pada HTB lebih baik dibanding dengan CBQ, dengan diperolehnya nilai jitter yang lebih kecil. 4. Loss Datagram CBQ maupun HTB untuk skenario ini tidak memiliki loss datagram sehingga pesan yang dikirim melalui pemfilteran Bandwidth Manager diterima di klien sama besarnya yaitu 1 Mbyte. Datagram yang dikirim sebesar 714 buah dan diterima di klien tanpa kehilangan satupun dengan jumlah totalnya 1 Mbyte. IV.1.B Skenario leaf class berdasarkan Port (Bab III.IV.A.2 - Bab III. IV.A.5) Dalam skenario ini diperlihatkan cara mengalokasikan bandwidth berdasarkan pada nomor port, port pada protokol TCP/IP mencerminkan jenis layanan/aplikasi yang digunakan, nomor-nomor port dari 255 ke bawah telah dialokasikan untuk jenis layanan/aplikasi tertentu. Untuk skenario manajemen bandwidth berdasarkan port dibagi dalam 3 skenario yaitu skenario dengan dua port, 4 port dan enam port. Skenario dengan dua port menggunakan port 3001 dan 4001 sebagai port destination, port 3001 diatur oleh Bandwidth Manager menggunakan bandwidth sebesar 192 kbps dan port 4001 dengan bandwidth 64 kbps. Skenario dengan empat port menggunakan port 3001, port 3002, port 4001 dan port 4002. Port 3001 mendapat alokasi bandwidth 128 kbps, port 3002 dengan 64 kbps, port 4001 memiliki rate 48 kbps dan port 4002 mendapat jatah 16 kbps. Skenario ketiga dengan 6 buah port dengan port 3001, port 3002, port 3003, port 4001, port 4002 dan port 4003. Port 3001 mendapat alokasi 90 kbps, port 3002 : 64 kbps, port 3003 : 48 kbps, port 4001 : 32 kbps, port 4002 Pesan yang dikirimkan dari server ke masingmasing port untuk setiap skenario. Sebelum diterima oleh portnya masing-masing, pesan tersebut dialirkan kedalam rule Bandwidth Manager yang telah dibuat penulis masing-masing kelas yang berdasarkan port tersebut bisa saling meminjam bandwidth saat bandwidth salah satu kelas sedang tidak menerima data/idle. Pesan

yang dikirim untuk skenario dengan dua port sebesar 1 Mbyte dan untuk skenario dengan empat dan 6 port sebesar 512 Kbyte. Pesan yang dikirim tidak secara langsung diterima oleh port melainkan harus melalui alamat IP oleh karena itu pesan untuk port-port bernomor 300X harus melalui IP Address 192.168.1.2 dan untuk port bernomor 400X perlu melalui IP Address 192.168.1.3. 1. Throughput Throughput sebelum terjadinya efek link sharing maupun setelahnya menunjukkan bahwa terjadi kebocoran bandwidth pada Bandwidth Manager CBQ walaupun throughput yang didapat lebih besar dibanding dengan Bandwidth Manager HTB, hal ini berarti rule CBQ yang telah dibuat penulis tidak secara akurat membatasi bandwidth yang dikehendaki. Berbeda dengan HTB, throughput yang didapat menunjukkan kepatuhan pada rule HTB yang telah dibuat penulis yaitu selalu dibawah nilai bandwidth yang telah ditentukan penulis dalam rule Bandwidth Manager. Ripple yang diperoleh dari hasil implementasi kedua Bandwidth Manager berdasarkan port menunjukkan bahwa, ripple yang didapat oleh HTB lebih kecil dibanding dengan CBQ, ini berarti implementasi HTB dengan port menunjukkan hasil yang lebih baik dibanding CBQ. Semakin banyak port yang dibuka untuk melayani suatu layanan maka ripple yang akan diperoleh akan semakin besar hal ini diakibatkan oleh semakin sibuknya klien yang meminta beberapa layanan secara simultan yang berakibat pada ketidakstabilan throughput yang diperoleh. 2. Waktu pemrosesan pesan dalam Bandwidth Manager (tbm) tbm CBQ vs HTB menunjukkan bahwa dalam skenario CBQ vs HTB berdasarkan port, waktu pemrosesan CBQ lebih cepat dibandingkan dengan HTB dengan didapat nilai tbm CBQ yang lebih kecil dibandingkan dengan tbm HTB. 3. Jitter Jitter HTB secara umum memiliki nilai yang lebih baik dibanding HTB walaupun dari perbandingan beberapa port CBQ memiliki nilai jitter yang lebih baik dibanding HTB namun jika kita melihat selisih jitter CBQ dan HTB terlihat HTB memiliki selisih yang kecil terhadap CBQ ketika nilai jitter HTB lebih buruk dan memperoleh selisih lebih besar ketika nilai jitternya lebih baik dibanding CBQ. 4. Loss datagram Loss datagram CBQ lebih buruk dibanding HTB terutama terjadi pada skenario 6 port, loss ini diakibatkan oleh ketidakmampuan klien menerima datagram yang dikirimkan melalui Bandwidth Manager secara simultan dengan beberapa port dibuka untuk menerima layanan, secara umum loss datagram yang melebihi toleransi ini menjadikan loss datagram CBQ pada skenario perbandingan berdasarkan port lebih jelek dibandingkan HTB. IV.2. Skenario manajemen bandwidth dengan parameter khusus (BAB III.IV.B) IV.2.A Skenario dengan parameter “tidak meminjamkan bandwidth idle” (BAB III.IV.B.1)

350

Throughput (kbit/s)

300

250

CBQ IP 192.168.1.2 CBQ IP 192.168.1.3 HTB IP 192.168.1.2 HTB IP 192.168.1.3

200

150

100

50

0 0

20

40

60

80

100

120

140

Waktu (t)

Grafik diatas menunjukkan berfungsinya efek parameter khusus bounded untuk CBQ dan ceil = rate untuk HTB, saat IP 192.168.1.2 tidak lagi menerima data yang berarti alokasi bandwidthnya tidak sedang dipergunakan (CBQ t > 42.3 detik, HTB t > 43.8 detik), IP 192.168.1.3 yang masih sibuk menerima data tidak dapat menggunakan bandwidth idle IP 192.168.1.3 karena terhalang rule yang telah dibuat penulis. Dari grafik diatas juga didapat throughput IP 192.168.1.2 dengan CBQ sebesar 198 kbps dan dengan HTB diperoleh 192 kbps, untuk IP 192.168.1.3 sebelum terjadi efek link sharing dengan CBQ didapat throughput 65.4 kbps dengan HTB diperoleh 63.9 kbps. Nampak sekali CBQ mengalami kebocoran penggunaan bandwidth yang telah penulis buat tapi tidak untuk HTB, hal ini menandakan HTB lebih baik dibanding CBQ jika dilihat dari kepatuhan terhadap rule mengenai throughput yang telah dideklarasikan penulis pada Bandwidth Manager. Ripple yang dihasilkan HTB pada skenario ini lebih buruk dibanding CBQ namun masih dalam tingkat yang wajar. Secara umum ripple yang dihasilkan pada skenario ini lebih baik bila dibandingkan dengan skenario berdasarkan IP Address tanpa penerapan parameter “tidak meminjamkan bandwidth idle”. 2. Waktu pemrosesan pesan dalam Bandwidth Manager (tbm) Untuk CBQ pada IP 92.168.1.2 tm =

1 × 1024 × 1024 × 8 × 1000 198 × 1024

= 41373 ms = 41.37 detik tbm CBQ = 42.3 – 41.37 = 0.93 detik Untuk HTB pada IP 192.168.1.2 tm =

1 × 1024 × 1024 × 8 × 1000 192 × 1024

= 42667 ms = 42.667 detik tbm HTB = 43.8 – 42.67 = 1.13 detik

tm =

1 × 1024 × 1024 × 8 × 1000 65.4 × 1024

= 125260 ms = 125.6 detik tbm CBQ = 128.3 –125.6 = 2.7 detik Untuk HTB pada IP 192.168.1.3 tm =

1 × 1024 × 1024 × 8 × 1000 63.9 × 1024

= 128200 ms = 128.2 detik tbm HTB = 131.4 – 128.2 = 3.2 detik Dari hasil perhitungan didapat tbm CBQ lebih baik dibanding dengan tbm HTB, hal ini menandakan untuk pembagian kelas berdasarkan IP Address dengan parameter tidak menggunakan bandwidth idle jika dilihat dari waktu proses pemrosesan pesan, CBQ lebih cepat dibanding dengan HTB. 3. Jitter Hasil pengukuran memberikan gambaran bahwa untuk alokasi bandwidth berdasarkan kelas berupa IP Address dengan parameter khusus, Jitter pada HTB lebih baik dibanding dengan CBQ terutama pada selisih yang cukup signifikan saat jitter HTB mengungguli CBQ dan perbedaan yang tidak begitu mencolok saat jitter CBQ mendapat nilai yang lebih baik dibanding HTB. 4. Loss Datagram CBQ maupun HTB untuk skenario ini tidak memiliki loss datagram sehingga pesan yang dikirim melalui pemfilteran Bandwidth Manager diterima di klien sama besarnya yaitu 1 Mbyte. Datagram yang dikirim sebesar 714 buah dan diterima di klien tanpa kehilangan satupun dengan jumlah totalnya 1 Mbyte. IV.2.B Skenario 2 IP Address untuk mendapatkan parameter respon time dan round trip time (BAB III.IV.B.2) Parameter respon time dan round trip time diperoleh melalui pengaktifan aplikasi ping dengan memeriksa konektivitas klien saat menggunakan bandwidth bersama dengan klien lainnya. Paket Ping sebanyak 30x64 byte dikirimkan, dilakukan 3 kali untuk mendapatkan nilai round trip time dan respon time masing-masing klien. Nilai Rata-Rata Respon Time Pemakaian Bandwidth Bersama

Nilai Rata-Rata Round Trip Time Pemakaian Bandwidth Bersama 6000

5141.094

5000

169405.5 159373.8

160x103

CBQ HTB

CBQ HTB

140x103

4000

3000

2000

180x103

5645.85

Respon Time (milidetik)

Throughput CBQ vs HTB 400

Untuk CBQ pada IP 92.168.1.3

Waktu Respon (milidetik)

Skenario ini menunjukkan penggunaan parameter yang mematikan fungsi link sharing berarti kelas-kelas yang sedang melayani antrian hanya dapat menggunakan bandwidth sebatas pada alokasinya masing-masing, bandwidth kelas lain yang idle tidak dapat digunakan untuk meningkatkan rate bandwidth kelas yang sedang menerima antrian pesan. Skenario ini pada dasarnya membagi link menjadi dua kelas berdasarkan IP Address dengan alokasi bandwidthnya sebagai berikut IP 192.168.1.2 dengan bandwidth 192 kbps dan IP 192.168.1.3 mendapat alokasi rate 64 kbps. 1. Throughput

1727.043

1802.704

120x103 100x103 80x103 60x103

51811.3 54081.12

40x103

1000

20x103 0

0 IP 192.168.1.2

IP 192.168.1.3

IP 192.168.1.2

IP 192.168.1.3

Dari Gambar dapat disimpulkan respon time untuk satu paket tunggal, CBQ lebih baik dibanding HTB dan interval dimulainya permintaan klien sampai dengan akhir dari jawaban server , CBQ lebih cepat dibanding HTB berarti waktu merespon suatu layanan dengan Bandwidth Manager HTB lebih lambat dibanding menggunakan Bandwidth Manager CBQ. IV.3 Skenario manajemen bandwidth dengan topologi jaringan yang berbeda (BAB III.IV.C) Pada skenario ini, diimplementasikan Bandwidth Manager yaitu CBQ dan HTB pada topologi jaringan

yang berbeda yaitu topologi dengan divais Bridge dan topologi dengan divais Router. Router dan Bridge yang dipakai merupakan PC yang difungsikan sebagai divais tersebut. Untuk fungsi sebagai Router, PC yang berbasis Linux ini tidak perlu dikompilasi ulang karena standar kernelnya telah mendukung kemampuan PC sebagai Router namun untuk fungsi sebagai Bridge diperlukan tambahan perangkat lunak pendukung yang mampu memfungsikan PC sebagai divais Bridge. Bila kernel yang terpasang di PC Linux merupakan kernel hasil instalasi OS Linux maka sebagian fungsi Bridge telah terpasang tetapi jika kernel yang digunakan merupakan hasil peningkatan dari kernel standar, perlu dipastikan kompilasi kernel telah mengaktifkan terlebih dahulu opsi “802.1d Ethernet Bridging” pada bagian “Network Options”. Perangkat lunak pendukung Bridge dapat didownload secara gratis di http://Bridge.sourceforge.net. Kernel yang digunakan untuk skenario topologi dengan Bridge dan Router memakai versi 2.4.18 (kernel standar OS Linux 7.3 dan 8.0) Skenario dengan topologi jaringan yang berbeda, mengalokasikan bandwidth berdasarkan alamat IP klien yaitu IP 192.168.1.2 mendapat alokasi bandwidth 32 kbps dan IP 192.168.1.3 mendapat jatah 16 kbps, message/pesan yang dikirim dari server sebesar 151 Kbyte. IV.3.A Skenario dengan divais Router (BAB III.IV.C.1) 1. Throughput

terjadi, ripple CBQ lebih baik dibandingkan dengan HTB. 2. Waktu pemrosesan pesan dalam Bandwidth Manager (tbm) tRouter

Bandwidth Manager

IP Address

192.168.1.2

192.168.1.3

(detik)

tnon-Router (detik)

tx (detik)

tdelay-Router

tbm

(detik)

(detik)

0.7656

CBQ

36.4

35.634

0.7658

0.0002

HTB

48.4

47.37

1.0275

0.0002

1.0273

CBQ

38.2

37.28

0.9160

0.0002

0.9158

HTB

52.8

51.62

1.1760

0.0002

1.1758

Dari tabel diatas untuk skenario Topologi dengan Router, waktu pemrosesan pesan dalam Bandwidth Manager CBQ lebih cepat dibandingkan dengan HTB. 3. Jitter Jitter yang diperoleh CBQ dan HTB secara umum tidak ada yang saling mengungguli hanya saja dari selisih jitter, HTB memiliki perbedaan selisih yang lebih baik dibanding dengan CBQ 4. Loss Datagram Pesan yang dikirim server melalui Bandwidth Manager CBQ maupun HTB diterima seluruhnya oleh klien sebanyak 105 datagram, ini berarti tidak terjadi loss datagram saat penerapan Bandwidth Manager CBQ maupun HTB pada skenario jaringan dengan topologi menggunakan Router. IV.3.B. Skenario dengan divais Bridge (BAB III.IV.C.2) 1. Throughput Throughput CBQ vs HTB Topologi dengan Bridge 220

Throughput CBQ vs HTB Topologi dengan Router

200

180 160 140 120

160

Throughput (kbit/s)


200

Throughput (kbit/s)


180

220

140 120 100 80 60

100

40

80

20

60

0

40

0

10

20

30

40

50

60

20

Waktu (t)

0 0

10

20

30

40

50

60

Waktu (t)

Throughput pada IP 192.168.1.2 untuk CBQ maupun HTB mematuhi rule pembatasan bandwidth yang telah dibuat penulis yaitu sebesar 32 kbps, throughput pada IP 192.168.1.3 sebelum terjadi efek link sharing (t < 44.6 untuk CBQ, t < 44.9 untuk HTB) untuk CBQ didapat hasil yang melanggar rule yaitu rata-rata 18.5 kbps sedangkan untuk HTB sebesar 16 kbps berarti tidak ada kebocoran bandwidth namun ketika efek link sharing terjadi pada HTB maupun CBQ terjadi kebocoran bandwidth HTB sebesar 48.2 kbps dan CBQ sebesar 49 kbps padahal batas maksimal yang dijiinkan dalam rule adalah 48 kbps, hal ini terjadi dikarenakan oleh penggunaan kernel standar (2.4.18) yang belum memungkinkan dukungan penuh terhadap Bandwidth Manager HTB maupun CBQ. Ripple yang terjadi pada IP 192.168.1.2 tidak begitu nampak, hanya pada HTB yang sedikit berfluktuasi pada 21.3 < t < 23.5, untuk IP 192.168.1.3 sebelum efek link sharing, HTB memiliki ripple yang lebih kecil dibandingkan dengan CBQ tetapi setelah

Pola throughput yang dihasilkan skenario ini mirip dengan pola pada skenario topologi menggunakan Router, hanya saja pada skenario ini tidak terjadi fluktuasi throughput pada HTB. Throughput pada IP 192.168.1.2 untuk CBQ maupun HTB mematuhi rule pembatasan bandwidth yang telah dibuat penulis yaitu sebesar 32 kbps, throughput pada IP 192.168.1.3 sebelum terjadi efek link sharing (t < 44.6 untuk CBQ, t < 44.9 untuk HTB) untuk CBQ didapat hasil yang melanggar rule yaitu rata-rata 18.5 kbps sedangkan untuk HTB sebesar 16 kbps berarti tidak ada kebocoran bandwidth namun ketika efek link sharing terjadi pada HTB maupun CBQ terjadi kebocoran bandwidth HTB sebesar 48.2 kbps dan CBQ sebesar 49 kbps padahal batas maksimal yang diijinkan dalam rule adalah 48 kbps, hal ini terjadi dikarenakan oleh penggunaan kernel standar (2.4.18) yang belum memungkinkan dukungan penuh terhadap Bandwidth Manager HTB maupun CBQ. Sebelum terjadi efek link sharing HTB memiliki ripple yang lebih kecil dibandingkan dengan CBQ tetapi

setelah terjadi, ripple CBQ lebih baik dibandingkan dengan HTB. 2. Waktu pemrosesan pesan dalam Bandwidth Manager (tbm) Waktu proses pesan pada PC-Bridge (ty) =tdelay-Bridge + tbm = 0.0001 detik1 + tbm Waktu pengiriman pesan melalui PC-Bridge = tBridge Waktu pengiriman tanpa PC-Bridge =tnon-Bridge

6.

Skenario

packet _ size × 8 = × 1000ms line _ speed

2 leaf class berdasarkan IP Address 2 leaf class berdasarkan Port 4 leaf class berdasarkan Port 6 leaf class berdasarkan Port Tanpa peminjaman bandwidth idle Topologi menggunakan Router Topologi menggunakan Bridge

ty = tBridge - tnon-Bridge IP Address 192.168.1.2 192.168.1.3

Bandwidth Manager CBQ HTB CBQ HTB

tBridge (detik)

36.4 48.4 38.2 52.8

tnon-Bridge

ty (detik)

(detik)

35.634 47.37 37.28 51.62

0.7658 1.0275 0.9160 1.1760

tdelay-Bridge

tbm

(detik)

(detik)

0.0001 0.0001 0.0001 0.0001

0.7657 1.0274 0.9159 1.1759

Dari tabel diatas untuk skenario Topologi dengan Bridge, waktu pemrosesan pesan dalam Bandwidth Manager CBQ lebih cepat dibandingkan dengan HTB. 3. Jitter Secara umum jitter yang diperoleh CBQ maupun HTB tidak ada yang saling mengungguli hanya saja memiliki kesamaan dengan skenario topologi menggunakan Router, hasil dari selisih jitter HTB memiliki perbedaan selisih yang lebih baik dibanding dengan CBQ 4. Loss Datagram Pesan yang dikirim server melalui Bandwidth Manager CBQ maupun HTB diterima seluruhnya oleh klien sebanyak 105 datagram, berarti dalam skenario ini memiliki kesamaan dengan skenario menggunakan Router yaitu tidak terjadi loss datagram. V.PENUTUP I. Kesimpulan 1. Class Based Queuing (CBQ) dan Hierarchical Token Bucket (HTB) merupakan suatu mekanisme penjadwalan paket yang bersifat classful berarti CBQ dan HTB mempunyai kemampuan untuk menjadwalkan paket berdasarkan kelas-kelas yang tersusun secara hirarki. 2. CBQ dan HTB dapat berfungsi sebagai Bandwidth Manager yang mampu memberikan alokasi bandwidth kepada kelas-kelas sesuai dengan kebutuhan dan keinginan pengguna Bandwidth Manager. 3. Kelas-kelas yang dibentuk oleh CBQ maupun HTB dapat berdasarkan pada IP Address dan nomor port. 4. Throughput yang dihasilkan kelas yang menggunakan HTB secara umum mampu memenuhi ketentuan/rule yang diimplementasikan dibanding CBQ, berarti CBQ kurang akurat dibanding HTB dalam hal throughput yang dihasilkan pada setiap kelas. 5. Ripple pada skenario yang menggunakan CBQ sebelum efek link sharing muncul lebih buruk dibandingkan dengan penggunaan HTB, namun ketika efek link sharing terjadi, hasil ripple yang 1

[5] p:53

terjadi adalah sebaliknya. Efek link sharing pada CBQ memberikan nilai ripple yang lebih stabil dibanding dengan HTB. Secara umum nilai jitter yang diperoleh kelas yang menggunakan HTB lebih kecil dibanding dengan kelas yang menggunakan CBQ.

7.

Persentase CBQ terhadap HTB Jitter

Waktu Proses

11.45 % 1.2 % 19.3 % 18.6 % 9 % 36.5 % 2.8 %

-36.5 % -2.3 % -10.3 % -81.1 % -19.2 % -52.5 % -30.99 %

Waktu pemrosesan message/pesan menggunakan HTB lebih lambat bila dibandingkan menggunakan CBQ, hal ini menandakan datagram yang dikirim oleh CBQ ke destinationnya lebih cepat tersampaikan dibandingkan menggunakan HTB. 8. Secara umum penggunaan Bandwidth Manager CBQ maupun HTB tidak menghasilkan loss datagram namun pada skenario dengan 6 leaf class berdasarkan nomor port, CBQ memberikan loss datagram sampai 10 %, hal ini terjadi pada ketidakmampuan CBQ menangani secara simultan layanan dengan membuka port yang terlalu banyak. HTB memberikan nilai yang stabil pada loss datagram yaitu nyaris tidak menghasilkan nilai loss datagram kecuali pada skenario dengan 6 leaf class itupun dengan nilai loss yang sangat kecil sekali 0.04 %, hal ini menandakan secara garis besar Bandwidth Manager HTB lebih baik dalam nilai persentase kehilangan datagram dibanding CBQ. 9. Respon time terhadap suatu kelas yang sedang menerapkan HTB lebih lambat dibandingkan dengan respon time kelas yang menggunakan Bandwidth Manager CBQ. Hal ini berarti waktu memberikan layanan terhadap suatu aplikasi dengan CBQ lebih cepat dibanding dengan HTB. 10. Semakin banyak layanan dengan membuka banyak port secara simultan maka ripple throughput yang didapat semakin besar II. Saran 1. Untuk analisa perbandingan lebih lanjut, sebaiknya digunakan disiplin antrian selain FIFO pada leaf classnya. 2. Implementasi Bandwidth Manager dengan OS Linux sebaiknya menggunakan versi kernel terbaru minimal menggunakan versi kernel 2.4.18. 3. Untuk mencegah ripple throughput yang sangat besar disarankan menggunakan prioritas yang berbeda pada setiap kelas. 4. Pemilihan penggunaan Bandwidth Manager CBQ maupun HTB sebaiknya disesuaikan dengan jenis aplikasi yang sering digunakan. Bila jenis aplikasi mempunyai ukuran data yang kecil dan memerlukan respon layanan yang cepat maka penggunaan CBQ sudah memadai namun bila ukuran datanya besar, membutuhkan keakurasian alokasi bandwidth yang tinggi dan tidak mementingkan respon layanan yang cepat maka pilihan HTB adalah lebih baik

DAFTAR PUSTAKA [1]

Alistair Croll, Managing Bandwidth Deploying QoS in Enterprise Networks, Prentice Hall, New Jersey, 2000

[2]

Bert Hubert, Linux Advanced Routing and Traffic Control, http://lartc.org

[3]

Fulvio Risso, Quality of Service on Packet Switched Networks, Politecnico di Torino Dipartimento di Automatica e Informatica Facoltà di Ingegneria Dottorato in Ingegneria Informatica e dei Sistemi - XII ciclo, 2000

[4]

Gabriel Paues, An implementation of capacity reservation devices in IP networks, Swedish Institute of Computer Science, 2002

[5]

John Blommers, Practical Planning for Network Growth, Prentice Hall, New Jersey, 1996

[6]

Lars Wischhof, Packet Scheduling for Bandwidth Sharing and Quality of Service Support in Wireless Local Area Networks, Institut für Telekommunikationssysteme Fakultät IV (Elektrotechnik und Informatik) Technische Universität Berlin, 2002

[7]

Martin Devera, HTB Manual User Guide, http://luxik.cdi.cz/~devik/qos/

[8]

Paul Ferguson, Quality of Service, John Wiley & Sons, Canada, 1998

[9]

Saravanan Radhakrishnan, Linux - Advanced Networking Overview Version 1, Information and Telecommunications Technology Center Department of Electrical Engineering & Computer Science The University of Kansas, 1999

[10]

Stef Coene, http: // www. docum. org/ stef. coene / qos, 2001

[11]

Werner Almesberger, Linux Traffic Control – Implementation Overview, Technical Report SSC/1998/037, EPL, 1998

IP

Recommend Documents