Post on 12-Apr-2016
description
PENGEMBANGAN APLIKASI DiffServ dengan DISIPLIN ANTRIAN
HIERARCHY TOKEN BUCKET dan RANDOM EARLY DETECTION
SEBAGAI BANDWIDTH LIMITING
Skripsi
Sebagai Salah Satu Syarat untuk Memperoleh Gelar Sarjana Komputer
Fakultas Sains dan Teknologi
Universitas Islam Negeri Syarif Hidayatullah Jakarta
Oleh :
Deni Zakya
NIM. : 105091002901
PROGRAM STUDI TEKNIK INFORMATIKA
FAKUTAS SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGERI SYARIEF HIDAYATULLAH
JAKARTA
2010
PENGEMBANGAN APLIKASI DiffServ dengan DISIPLIN ANTRIAN
HIERARCHY TOKEN BUCKET dan RANDOM EARLY DETECTION
SEBAGAI BANDWIDTH LIMITING
Oleh :
Deni Zakya
NIM. : 105091002901
PROGRAM STUDI TEKNIK INFORMATIKA
FAKUTAS SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGERI SYARIEF HIDAYATULLAH
JAKARTA
2010
vii
KATA PENGANTAR
Segala Puji dan Syukur penulis panjatkan kepada Allah SWT atas segala
karunia-Nya karena penulis dapat menyelesaikan penulisan Skripsi ini dengan
judul Pengembangan Aplikasi DiffServ dengan Disiplin Antrian Hierarchy
Token Bucket dan Random Early Detection Sebagai Bandwidth Limiting
dengan baik. Shalawat serta salam penulis haturkan kepada Nabi Muhammad
SAW, para sahabat dan keluarga beliau.
Setelah seluruh penulisan Skripsi ini terlaksana, penulis ingin
mengucapkan banyak terimakasih kepada seluruh pihak yang telah membantu
baik itu berupa motivasi, bimbingan, moril maupun materil, yang ditujukan
kepada:
1. Bapak DR. Syopiansyah Jaya Putra, M.SIS, selaku Dekan Fakultas Sains
dan Teknologi, UIN Syarif Hidayatullah Jakarta.
2. Bapak Yusuf Durrachman, M. Sc, MIT, selaku Ketua Program Studi
Teknik Informatika, Fakultas Sains dan Teknologi, UIN Syarif
Hidayatullah Jakarta
3. Bapak Viktor Amrizal, M.Kom, selaku dosen pembimbing I yang selalu
memberikan bimbingan, semangat dan meluangkan waktunya.
4. Ibu Arini, M.T, selaku dosen pembimbing II yang telah memberikan
pengarahan dan membantu menyelesaikan penulisan skripsi ini.
viii
Jakarta, 19 April 2010
Deni Zakya
105091002901
Penulis sadar bahwa penyusunan skripsi ini masih jauh dari sempurna,
oleh karena itu penyusun mengharapkan kritik dan saran yang bersifat
membangun agar penyusunan skripsi ini menjadi lebih baik lagi.
Akhir kata, semoga skripsi ini bermanfaat khususnya kepada penulis
sendiri dan bagi yang membacanya.
vi
ABSTRAK
Deni Zakya, Pengembangan Aplikasi DiffServ dengan Disiplin Antrian Hierarchy
Token Bucket dan Random Early Detection Sebagai Bandwidth Limiting. Di bawah
bimbingan Victor Amrizal, M.Kom dan Arini, M.T.
Pertumbuhan internet memunculkan warnet yang menggunakan koneksi internet sebagai
komponen dasar bisnis tersebut. Pengelola warnet akan menggunakan minimal satu koneksi
internet dan membaginya dengan semua node yang terkoneksi dengan internet. Banyaknya
node yang terkoneksi ke router akan menyebabkan kondisi jaringan mengalami
kongesti/kepadatan. Sehingga terlihat ada satu atau lebih node yang mendominasi
penggunaan bandwidth jaringan. Untuk itu diperlukan konsep Quality of Service
(QoS), salah satu cara mengaplikasikan QoS pada jaringan IP adalah dengan
Differentiated Service(DiffServ). Penulis menggunakan penjadwalan paket Hierarchy
Token Bucket dan Random Early Detection pada penelitian ini. Klasifikasi akan
didasarkan pada node yang terhubung, protocol tcp atau udp dan jaringan IIX(lokal)
dan internasional. Klasifikasi IIX dan Internasional diambil karena adanya perbedaan
kecepatan yang signifikan dari kedua jaringan tersebut. Analisis kualitas layanan pada
jaringan dilakukan dengan mengukur parameter throughput, delay, jitter dan packet
loss. Pada akhirnya Implementasi DiffServ menggunakan TrafficControl dengan
disiplin antrian HTB dan RED dapat berperan untuk mengatur penggunaan
bandwidth tiap node pada jaringan. Aplikasi dapat membedakan asal paket dari
jaringan IIX(lokal) atau internasional. Dan memberikan batasan kecepatan yang
sesuai untuk tiap koneksi. Penggunaan antrian HTB dan RED memberikan kualitas
layanan yang baik tanpa mengorbankan parameter pengujian throughput, delay, jitter
dan packet loss yang besar. Penulis menggunakan Extreme Programming sebagai
Metodologi pengembangan perangkat lunak. Terlihat dari hasil pengujian yang
memberikan nilai pengujian dari parameter tersebut relatif kecil dibandingkan dengan
penggunaan best effort atau hanya dengan disiplin antrian FIFO.
Kata Kunci : Bandwidth Limiting, TrafficControl, Hierarchy Token Bucket, Random
Early Detection.
BAB I
PENDAHULUAN
1.1 Latar Belakang
Pertumbuhan internet memunculkan warnet yang menggunakan koneksi internet sebagai
komponen dasar bisnis tersebut. Pengelola warnet akan menggunakan minimal satu koneksi
internet dan membaginya dengan semua node yang terkoneksi dengan internet. Penggunaan
router pada jaringan komputer warnet dapat menghubungkan koneksi lokal warnet dengan
internet.
Banyaknya node yang terkoneksi ke router akan menyebabkan kondisi jaringan
mengalami kongesti/kepadatan. Hal tersebut akan menyebabkan beberapa paket yang
diterima atau dikirim oleh router hilang sebagian. Dampaknya akan ada beberapa node yang
kehilangan paket data yang seharusnya diterima. Sehingga terlihat seolah-olah ada satu atau
lebih node yang mendominasi penggunaan bandwidth jaringan(Welzl, 2005).
Hal tersebut terjadi karena pada router secara default menerapkan disiplin antrian First In
First Out (FIFO). Selain itu pula penggunaan jaringan IP yang menerapkan best effort
service(Li, 1999), jaringan yang memberikan throughput dan waktu pengiriman bervariasi
tergantung kepada beban trafik saat pengiriman terjadi, memberikan dampak turunnya performa
jaringan dan menurunnya Quality of Service (QoS) pada jaringan tersebut. Layanan internet
seperti streaming audio ataupun video akan mendapatkan penurunan performa, karena kurangnya
throughput pada layanan ini.
Untuk itu diperlukan konsep Quality of Service (QoS) yang dapat memberikan performa
yang baik untuk semua layanan. Jaringan yang mengaplikasikan QoS dengan baik, harus mampu
membedakan trafik atau tipe layanan dan memperlakukan trafik tersebut secara berbeda untuk
memberikan jaminan sumber daya tiap trafik.
Salah satu cara mengaplikasikan QoS pada jaringan IP adalah dengan Differentiated
Service(DiffServ)(Blake, 1998). DiffServ bekerja dengan cara mengklasifikasikan trafik dan
memberikan perlakuan yang sesuai untuk tiap trafik. QoS memiliki beberapa modul untuk
menjalankan tugasnya, antara lain pengklasifikasi trafik, penanda trafik, traffic policing,
manajemen antrian aktif, penjadwalan paket dan traffic shaping. Penulis menggunakan
penjadwalan paket HTB dan RED pada penelitian ini.
Untuk menerapkan DiffServ, penulis akan menggunakan kernel linux, TrafficControl dan
Iptables. Klasifikasi akan didasarkan pada node yang terhubung, protocol tcp atau udp dan
jaringan IIX(lokal) dan internasional. Klasifikasi IIX dan Internasional diambil karena adanya
perbedaan kecepatan yang signifikan dari kedua jaringan tersebut.
Judul yang penulis angkat adalah “Pengembangan Aplikasi DiffServ dengan disiplin
antrian Hierarchy Token Bucket dan Random Early Detection sebagai bandwidth limiting”.
Linux digunakan sebagai sistem operasi yang digunakan pada penelitian ini. Penulis akan
membangun aplikasi dengan GUI yang memudahkan pengguna untuk mengatur penggunaan
bandwidth. Penulis menjembatani penggunaan modul kernel, TrafficControl dan Iptables
yang relatif sulit, dengan aplikasi ini.
Penelitian ini akan menguji tingkat kualitas jaringan yang telah mengimplementasikan
DiffServ. Beberapa parameter yang digunakan untuk mengukur kualitas jaringan, antara lain
throughput, delay, jitter dan packet loss.
1.2 Rumusan Masalah
Masalah yang dapat dirumuskan dalam tugas akhir ini sebagai berikut :
1. Efisiensi penggunaan bandwidth tiap node pada jaringan dengan memberikan alokasi
bandwidth sesuai kebutuhan.
2. Pemisahan alokasi bandwidth tiap node. Klasifikasi didasarkan pada asal dari paket
yang datang, IIX untuk jaringan lokal(indonesia) dan International untuk jaringan
Internet. Klasifikasi lainnya berdasarkan protocol, TCP atau UDP.
3. Membangun aplikasi berbasis DiffServ dengan router linux.
4. Menguji Quality of Service tiap-tiap node pada jaringan.
1.3 Batasan Masalah
Agar pembahasan mengenai topik ini tidak terlalu meluas maka diperlukan batasan
masalah. Adapun batasan masalah untuk skripsi ini antara lain:
1. Aplikasi yang penulis buat akan menjembatani pengguna untuk melakukan
konfigurasi tidak langsung DiffServ pada kernel linux dengan Traffic Control,
Iptables dan Python.
2. Merumuskan konfigurasi yang digunakan aplikasi untuk pemisahan bandwidth IIX &
Internasional serta paket tcp dan udp untuk tiap node yang terhubung ke jaringan
internet.
3. Pengujian dan analisis QoS dengan parameter nilai bandwidth, jitter dan packet loss.
1.4 Tujuan dan Manfaat Penelitian
Penelitian yang penulis lakukan bertujuan untuk:
1. Tujuan Umum
1. Mengembangkan aplikasi bandwidth management yang bersifat open source dan
user friendly.
2. Tujuan Khusus
1. Memadukan iptables dan TC(traffic control) sebagai fondasi awal aplikasi.
2. Memberikan pengelolaan bandwidth yang sesuai pada jaringan.
3. Memberikan antar muka grafis yang sederhana dan mudah digunakan.
Manfaat yang di dapatkan dalam penelitian ini adalah :
1. Memberikan aplikasi yang mampu mengatur penggunaan bandwidth sesuai
kebutuhan.
2. Memberikan aplikasi yang murah dan mudah diterapkan.
3. Menghasilkan aplikasi open source yang bebas digunakan/dikembangkan siapa
saja.
1.5 Metodologi Penelitian
Metode Penelitian yang penulis gunakan adalah sebagai berikut :
1. Studi Pustaka.
Studi pustaka yang penulis lakukan adalah dengan mempelajari literatur tentang
traffic control pada linux dan queueing discipline.
2. Metode Pengembangan Perangkat Lunak(Software Development Method).
Metode pengembangan perangkat lunak yang penulis gunakan adalah Agile
Software Development dengan Extreme Programming. Tahapannya adalah
sebagai berikut :
1. Planning, perencanaan dari aplikasi yang akan dibuat dengan menjelaskan
fitur dan kegunaan dari aplikasi.
2. Design, proses desain dari hasil perencanaan sebelumnya.
3. Coding, proses pembuatan unit test untuk kemudian digunakan sebagai
penguji pada code yang akan diimplementasikan.
4. Testing, proses pengujian terhadap code yang diimplementasikan dengan
unit test yang sebelumnya telah dibuat.
5. Release, tahap akhir aplikasi siap diimplementasikan/digunakan oleh
pengguna, setelah sebelumnya dipastikan sudah melewati tahapan testing.
1.6 Sistematika Penelitian
Penelitian ini terdiri dari lima bab, dengan penjelasan tiap-tiap bab sebagai berikut :
BAB I : PENDAHULUAN
Pada bab ini berisi tentang Latar Belakang, Rumusan Masalah, Batasan Masalah, Tujuan
dan Manfaat Penelitian, Metodologi Penelitian serta Sistematika Penulisan Penelitian.
BAB II: LANDASAN TEORI
Pada bab ini menjelaskan tentang teori perangkat keras dan perangkat lunak, definisi
sistem, analisa sistem, definisi perancangan sistem dan jenis program yang digunakan.
BAB III: Metodologi Penelitian
Pada bab ini akan menguraikan dan memberikan penjelasan mengenai perancangan
perangkat keras, perancangan sistem sehingga dapat diketahui rencana yang akan
dikerjakan.
BAB IV: Pembahasan dan Implementasi
Pada bab ini akan menjelaskan mengenai pembuatan sistem dan pengujian sistem.
BAB V: Penutup
Bab ini berisi kesimpulan dari pembahasan masalah dan saran-saran berkenaan dengan
Penelitian ini.
BAB II
LANDASAN TEORI
2.1. Pengantar Quality of Service
Pertama kali jaringan IP diterapkan hanya membawa satu tipe informasi yaitu data
non-real time, sehingga jaringan bisa didesain untuk berjalan secara best-effort yang
memperlakukan semua paket sama. Tujuan utama dari jaringan IP adalah memastikan
perangkat terminal mempunyai protokol dan kecerdasan yang sesuai untuk menjamin
transmisi data yang bisa diandalkan sehingga jaringan bisa berjalan sesederhana
mungkin.
Pada pertengahan tahun 90-an, tipe jaringan data dan suara mulai disatukan. Ide
utama adalah konvergensi lalu lintas suara dan data, dan menciptakan sebuah jaringan
yang mampu membawa suara dan data. Dengan konvergensi tersebut, terdapat tantangan
baru. Dalam jaringan baru tersebut, operasi best effort yang dilakukan jaringan IP tidak
lagi mampu memenuhi kebutuhan berbagai macam lalu lintas data yang dibawa oleh
jaringan. Untuk menjawab masalah tersebut, muncul konsep Quality of Service(QoS)
(Welzl, 2005).
QoS dapat didefinisikan dari dua sudut pandang: QoS dari sudut pandang
pengguna dan QoS dari sudut pandang jaringan. Dari sudut pandang pengguna, QoS
merupakan pandangan pengguna terhadap kualitas layanan yang diterima dari penyedia
jaringan, seperti suara, video, maupun data. Dari sudut pandang jaringan, istilah QoS
mengacu kepada kemampuan jaringan menyediakan QoS yang diharapkan oleh
pengguna. Kemampuan yang dibutuhkan oleh jaringan dalam menyediakan QoS di
jaringan paket dapat dibagi menjadi dua. Pertama, untuk menyediakan QoS, sebuah
jaringan paket harus mampu membedakan kelas-kelas lalu lintas data sehingga pengguna
dapat memperlakukan satu atau lebih kelas lalu lintas data berbeda dengan kelas lalu
lintas data lainnya. Kedua, setelah jaringan mampu membedakan kelas-kelas lalu lintas
data, jaringan harus mampu memperlakukan kelas-kelas tersebut secara terpisah dengan
menyediakan jaminan sumber daya dan perbedaan layanan dalam jaringan.
Persepsi pengguna terhadap kualitas layanan dilakukan dengan melakukan tes
secara subjektif, sebagai fungsi dari keterbatasan pada jaringan seperti, waktu tunda,
jitter, dan paket hilang. Jumlah keterbatasan pada jaringan akan bergantung dari
mekanisme QoS yang diimplementasikan pada jaringan.
Pada sebuah jaringan yang membawa berbagai tipe lalu lintas data, keterbatasan
yang menjadi elemen penting pada suatu tipe lalu lintas data bisa saja menjadi tidak
penting untuk tipe lalu lintas data lainnya, dan sebaliknya. Mekanisme QoS yang
diimplementasikan pada jaringan harus mampu mengoptimalkan hal tersebut.
2.1.1. Fungsi Dasar QoS
Tanpa mekanisme QoS, sebuah jaringan IP menyediakan layanan yang
sifatnya best effort. Pada layanan best effort, semua paket tidak dapat dibedakan dan
diberikan perlakuan forwarding yang sama. Sebuah mekanisme QoS pada jaringan IP
meyediakan kemampuan untuk membedakan paket dan memberikan perlakuan yang
berbeda. Dua mekanisme QoS utama yang tersedia untuk jaringan IP adalah
Integrated Service (IntServ) dan Differentiated Service (DiffServ) (Welzl, 2005).
Istilah traffic flow menunjukkan aliran trafik dan tiap alirannya mewakili sumber
trafik yang berbeda-beda. Pada layanan best effort, semua paket digabungkan
kedalam sebuah aliran massal tanpa mempedulikan asal trafik. Pada IntServ, tiap-tiap
aliran dibedakan dari awal sampai akhir. Pada DiffServ, tiap-tiap aliran trafik tidak
dibedakan per aliran, melainkan dikumpulkan terlebih dahulu menjadi kelas-kelas
kecil. Kelas-kelas trafik tersebut diberikan perlakuan yang berbeda-beda tiap hopnya
(Li,1999).
Pembahasan akan ditekankan pada metoda QoS DiffServ, dan akan
dijelaskan lebih lanjut pada sub bab berikutnya. Untuk menyediakan QoS dalam
jaringan IP jaringan harus mampu menjalankan tugas dasar, yaitu membedakan trafik
atau tipe layanan menjadi beberapa kelas dan memperlakukan kelas-kelas trafik
secara berbeda dengan menyediakan jaminan resource dan pembedaan layanan pada
jaringan.
2.1.2. Traffic Policing
Traffic Policing digunakan untuk mengecek apakah trafik yang masuk
pada port masukan sesuai dengan laju trafik yang telah disetujui antara pengguna dan
penyedia jasa jaringan IP. Traffic policing terdiri dari pengukuran trafik berdasarkan
laju trafik yang telah disetujui dan menandai atau menandai ulang paket berdasarkan
keluaran hasil pengukuran tersebut. Sebuah paket kemungkinan dapat dijatuhkan
berdasarkan proses traffic policing ini. Traffic policing terdiri atas dua submodul,
yaitu traffic meter dan packet marker/re-marker.
Biasanya, traffic policing menyesuaikan laju trafik yang datang dengan
acuan laju tertentu, dengan acuan yang digunakan dapat berupa satu acuan laju yaitu
Committed Information Rate (CIR) atau dua acuan laju, CIR dan Peak Information
Rate (PIR). Untuk mendapatkan laju yang sesuai dengan CIR dan PIR, traffic
policing menggunakan tiga parameter yaitu Peak Burst Size (PBS), Committed Burst
Size (CBS) dan Excess Burst Size (EBS) (Blake, 1998).
a. Peak Information Rate.
Peak Information Rate (PIR) merupakan laju maksimum pengiriman bit seorang
pengguna yang disetujui bersama antara pengguna dan penyedia layanan oleh sebuah
Service Level Agreement (SLA). Bagi seorang pengguna, laju pengiriman
maksimum secara fisik dibatasi oleh laju jalur dari pelanggan tersebut.
PIR dari seorang pelanggan tidak akan lebih besar dari laju jalur pelanggan
tersebut. Bila PIR dinyatakan sebagai λ max , maka secara teori invers dari PIR
adalah laju kedatangan paket minimum yang dinyatakan sebagai 1/ λ max .
PIR dinyatakan dalam ukuran bytes per sekon. PIR menyatakan laju pengiriman
paket IP dan karenanya, dalam menghitung jumlah byte pada sebuah paket IP,
seluruh paket termasuk header IP diperhitungkan; header yang berada pada layer
yang lebih bawah, misalnya layer 2 dan overhead dari jalur fisik tertentu, tidak
diperhitungkan.
b. Committed Information Rate.
Commited Information Rate (CIR) merupakan laju trafik rata-rata jangka
panjang yang disediakan oleh penyedia jasa layanan yang dijamin kepada pelanggan
sesuai persetujuan. CIR dinyatakan dalam satuan byte per sekon. Dalam menghitung
jumlah byte pada sebuah paket IP untuk CIR, seluruh paket termasuk header IP
diperhitungkan. Akan tetapi, seperti PIR, hanya layer IP yang diperhitungkan untuk
menghitung CIR dan header dari layer yang lebih bawah, misalnya layer dua dan
overhead lainnya tidak ikut diperhitungkan.
Biasanya, pengiriman paket merupakan sederetan luapan tiba-tiba paket (burst)
yang diselingi oleh jeda waktu tanpa pengiriman paket sama sekali. Saat paket
datang dalam luapan mendadak tersebut, paket-paket dikirimkan pada laju
maksimum, yaitu PIR. Karena hal ini tidak berlangsung secara kontinyu, maka laku
rata-rata pada jangka panjang akan lebih kecil dari PIR. Karenanya, CIR biasanya
akan lebih kecil dari PIR.
c. Burst Sizes
Ada tiga parameter pendukung ukuran burst yang digunakan dalam traffic
policing : Committed Burst Size, Excess Burst Size (EBS), dan Peak Burst Size
(PBS). CBS merupakan ukuran burst maksimum yang bisa dijamin oleh jaringan dan
merupakan jumlah maksimum paket dalam ukuran byte yang dapat dikirimkan pada
PIR dengan memperhatikan CIR yang telah disetujui. EBS merupakan batasan lain
dari ukuran burst yang melebihi CBS, dan CBS < EBS. Paket yang melebihi EBS
akan ditandai merah. CBS dan EBS digunakan secara berkesinambungan dengan
CIR. PBS merupakan parameter ukuran burst yang mirip dengan CBS, yang
didefinisikan secara berkesinambungan dengan PIR.
2.1.3. Traffic Metering
Ada dua macam traffic metering dan mekanisme pewarnaan paket, yaitu :
1. Single Rate Three Color Marker (srTCM)
2. Two Rate Three Color Marker (trTCM)
2.1.4. Manajemen Antrian Aktif
Tanpa adanya Manajemen Antrian Aktif atau Active Queue Management
(AQM) pada router, router menggunakan mekanisme yang disebut sebagai metode
tail drop. Metode ini merupakan teknik manajemen antrian yang bersifat pasif, yaitu
paket yang melimpah dibuang secara otomatis saat antrian benar-benar penuh.
Keuntungan utama dari metode ini adalah kesederhanaannya. Akan tetapi metode tail
drop dapat berujung pada fenomena yang disebut sebagai sinkronisasi global TCP
(Braithwaite, 2006).
Sinkronisasi global TCP terjadi dalam proses sebagai berikut. Ketika host
pengirim TCP menerima sebuah acknowledgement negative (NAK) yang berarti ada
paket TCP yang hilang saat melewati jaringan, host tersebut berasumsi bahwa
hilangnya paket disebabkan terjadinya kongesti pada jaringan. Untuk membantu
mengurangi aliran trafik yang masuk ke dalam jaringan, TCP secara otomatis
mengurangi laju pengiriman paket.
Pada metode tail drop, saat buffer penuh, semua paket yang datang menuju
buffer seluruhnya dijatuhkan. Bila paket ini merupakan paket TCP, semua aliran
TCP yang mengalami kehilangan paket akan memelankan laju pengiriman secara
simultan dan kembali mengulangi transmisi pada waktu yang hampir bersamaan.
Karena semua aliran TCP yang terpengaruh dengan keadaan tersebut bereaksi
dalam perilaku yang sinkron, maka kondisi kongesti pada jaringan akan berosilasi
antara kondisi kongesti penuh (saat semua aliran TCP mengirim paket dengan laju
penuh) dan tanpa kongesti (semua aliran TCP memelankan laju pengiriman paket).
Fenomena ini disebut sebagai sinkronisasi global TCP dan menyebabkan utilisasi
resource jaringan yang tidak efisien.
Manajemen antrian aktif adalah mekanisme pengendalian kongesti yang
bertugas untuk mencegah terjadinya sinkronisasi TCP. Ide utama dari AQM adalah
untuk mengantisipasi terjadinya kongesti dan mengambil tindakan untuk mencegah
atau mengurangi efek dari kongesti. Metode AQM yang biasa dan penulis gunakan
adalah Random Early Detection (RED).
2.1.5. Penjadwalan Paket
Penjadwalan paket (packet scheduling) digunakan untuk menjadwalkan paket
pada antrian sehingga kapasitas jaringan pada port keluaran dapat terdistribusi merata
pada semua kelas trafik yang memasuki jaringan (Welzl, 2005). Penjadwalan paket
dapat dikatakan sebagai inti dari mekanisme QoS.
1. First-In-First-Out
First-In-First-Out (FIFO) merupakan disiplin antrian default yang
digunakan bila tidak ada algoritma penjadwalan paket lain yang digunakan.
Pada FIFO, paket diantrikan pada sebuah jalur antrian dan dilayani sesuai
urutan memasuki antrian tersebut. Karena paket yang datang pertama kali
adalah juga paket yang dilayani pertama kali, maka antrian FIFO juga sering
disebut sebagai antrian First-Come-First-Served (FCFS). Keuntungan utama
dari dari mekanisme FIFO ini adalah kesederhanaannya. FIFO hanya
membutuhkan sebuah buffer, yang dapat menyimpan paket yang datang dan
mengirimkannya sesuai urutan kedatangannya. Pada router berbasis
perangkat lunak, hal ini akan meringankan beban kerja router.
FIFO memperlakukan semua paket sederajat sehingga cocok digunakan
untuk jaringan best effort. Masalah utama yang dihadapi FIFO adalah FIFO
tidak dapat membedakan (atau hanya memiliki kemampuan yang sangat
terbatas untuk membedakan) kelas trafik. Karena ketiadaan perbedaan kelas
ini, semua aliran trafik akan mengalami perlakuan yang sama. Akan tetapi
pada saat terjadi kongesti, FIFO memiliki kecenderungan yang berbeda
terhadap paket TCP dan UDP. FIFO cenderung mendahulukan trafik UDP
karena protokol TCP akan menurunkan transmisinya saat terjadi kongesti.
2. Priority Queuing
FIFO menempatkan setiap paket pada sebuah antrian tanpa memperhatikan
perbedaan antar kelas trafik. Cara yang sederhana untuk menciptakan
perbedaan kelas trafik adalah dengan menggunakan Priority Queuing (PQ).
Pada PQ, antrian dibagi sebanyak N antrian, dengan urutan prioritas 1 sampai
dengan N. Urutan pelayanan paket bergantung dari urutan prioritas dan
keberadaan paket pada antrian dengan prioritas lebih tinggi.
Misal terdapat sejumlah antrian dari antrian 1 sampai antrian j. Bila pada
saat paket yang berada di antrian j mendapat giliran dilayani, datang paket
pada antrian dengan prioritas lebih tinggi, misalnya antrian (j-3), maka paket
yang berada pada antrian (j-3) akan dilayani terlebih dahulu.
Seperti FIFO, keuntungan utama dari PQ adalah kesederhanaan: PQ
menyediakan jalan mudah untuk menciptakan perbedaan kelas trafik.
Masalah utama dari PQ adalah bila tidak dikonfigurasi secara benar, PQ dapat
menyebabkan berhentinya layanan pada antrian prioritas bawah. Bila pada
antrian prioritas atas laju layanan lebih kecil dari laju kedatangan paket, maka
paket pada antrian tidak akan berhenti dilayani. Akibatnya, paket pada antrian
prioritas di bawahnya tidak akan mendapat kesempatan untuk dilayani.
Karena kemungkinan terjadinya hal tersebut, maka penggunaan PQ perlu
dilakukan secara hati- hati.
PQ lebih cocok digunakan saat trafik prioritas tinggi merupakan sebagian
kecil dari keseluruhan trafik di jaringan. Misal terdapat sebagian kecil trafik
yang sangat penting dan harus diproses secepat mungkin. Cara paling
sederhana untuk menangani trafik tersebut adalah membuat prioritas tertinggi
untuk trafik tersebut. Karena trafik tersebut hanya sebagian kecil dari
keseluruhan trafik, efeknya terhadap trafik lainnya akan minimal.PQ
merupakan antrian yang paling tepat diterapkan untuk trafik real time, seperti
video dan VoIP. Trafik tersebut biasanya menggunakan trafik UDP.
Cara lain menangani keterbatasan kapasitas jaringan pada antrian prioritas
rendah adalah membatasi laju layanan pada prioritas tinggi. Misal pada
prioritas pertama laju layanan dibatasi 10% dari kapasitas jaringan. Artinya
prioritas antrian tertinggi hanya akan dilayani secara PQ bila konsumsi
kapasitas jaringan pada antrian tersebut berada di bawah batas 10 %.
3. Fair Queuing.
Cara lain memberikan pembedaan kelas trafik adalah Fair Queuing (FQ).
Pada FQ, paket datang diklasifikasikan kedalam N antrian, Setiap antrian
diberikan alokasi kapasitas jaringan sebesar 1/N total kapasitas jaringan.
Setiap antrian dilayani secara berurutan (round robin) dengan melewati
antrian yang kosong. Pada setiap gilirannya, satu paket dikeluarkan dari
antrian. FQ sangat sederhana, dan tidak membutuhkan mekanisme alokasi
kapasitas jaringan secara khusus. Bila ditambahkan sebuah kelas antrian baru
ke dalam N buah antrian, kapasitas jaringan tiap antrian otomatis diubah
menjadi sebesar 1/(N+1) untuk tiap antrian.
FQ memiliki dua buah persoalan utama. Pertama, karena kapasitas
jaringan keluaran dibagi secara merata ke dalam N antrian, bila tiap kelas
memiliki kebutuhan kapasitas jaringan yang berbeda FQ tidak akan
mendistribusikan kebutuhan kapasitas jaringan sesuai kebutuhannya. Kedua,
karena pada setiap giliran layanan paket yang dikeluarkan adalah satu buah,
tanpa bergantung pada ukuran paket, maka distribusi kapasitas jaringan antar
antrian yang sesungguhnya tidak akan sama besar. Antrian yang memiliki
paket dengan ukuran lebih besar akan mendapat bagian kapasitas jaringan
yang lebih besar dari 1/N total kapasitas jaringan.
4. Class-Based WFQ
Class Based (CB)-WFQ mirip dengan WRR yang telah dijelaskan
sebelumnya. Pada CB-WFQ, aliran trafik dibagi ke dalam kelas-kelas, tetapi
dengan pembagian kapasitas jaringan yang bergantung dari kebutuhan
masing-masing kelas, dengan total kapasitas jaringan seluruh kelas adalah
100% kapasitas jaringan keluaran. Perbedaannya adalah, pada WRR, aliran
trafik pada masing- masing kelasnya dibagi berdasarkan FQ, sedangkan pada
CB-WFQ aliran trafik pada masing-masing kelas dibagi berdasarkan WFQ.
5. Hierarchy Token Bucket
Hierarchy Token Bucket (HTB) merupakan cara untuk mengaplikasikan
CB-WFQ pada router berbasis linux menggunakan traffic controller. HTB
menjamin jumlah layanan yang diterima sebuah kelas trafik paling kecil
sesuai dengan jumlah yang dibutuhkan dan diberikan kepadanya. Apabila
sebuah kelas menggunakan kapasitas jaringan lebih kecil dari yang diberikan
kepadanya, sisa kapasitas jaringan yang tidak digunakan didistribusikan ke
kelas lainnya.
Trafik VoIP diberikan bagian sebesar 100 kbps. Akan tetapi bila trafik
VoIp yang masuk besarnya lebih kecil dari 100 kbps, sisa kapasitas jaringan
akan diberikan kepada trafik lainnya, sehingga total trafik yang memakai link
utama akan tetap 128 kbps.
2.1.6. Traffic Shaping
Traffic shaping digunakan untuk mengatur laju aliran trafik yang datang
untuk membentuk laju trafik sedemikian rupa agar laju trafik keluaran bersifat lebih
mulus. Bila laju trafik yang datang bersifat sangat acak (bursty) maka perlu
ditempatkan dulu pada sebuah buffer sehingga laju keluaran lebih konstan(Li, 1999).
Dengan cara ini, traffic shaping membuat aliran trafik lebih sesuai dengan
profil trafik yang didefinisikan sebelumnya, misalnya SLA. Analogi dari traffic
shaping ini adalah, misalnya, pada pintu masuk jalan tol. Pengemudi diminta berhenti
sejenak pada gerbang masuk jalan tol. Pengemudi kemudian dipersilahkan memasuki
jalan tol dengan kecepatan tertentu, misalnya 60 km/jam. Dengan cara ini mobil akan
memasuki jalan tol pada kecepatan yang cenderung sama yaitu 60 km/jam walaupun
memasuki jalan tol pada kecepatan yang bervariasi. Akan tetapi pemberhentian trafik
sementara akan menyebabkan terjadinya delay tambahan pada paket selama di
buffer.
Ada dua tipe traffic shaper, yaitu traffic shaper murni dan token bucket traffic
shaper. Token bucket traffic shaper sering juga disebut sebagai leaky bucket traffic
shaper.
1. Traffic Shaper Murni
Pada traffic shaper murni, paket yang datang ditempatkan pada sebuah
buffer, atau tempat penampungan sementara, dengan kedalaman d dan
dikeluarkan dalam laju konstan r. Traffic shaper murni tidak
memperkenankan terjadinya lonjakan laju pada aliran keluaran. Biasanya, laju
keluaran traffic shaper, r, akan lebih kecil dari laju jalur yang sebenarnya, C.
Dengan traffic shaper murni, laju keluaran r akan menentukan batas atas dari
laju trafik keluaran karena lonjakan laju trafik (burst) tidak diperbolehkan.
Bila ukuran burst melebihi kedalaman d, maka paket yang meluap berlebih
akan dibuang.
2. Token Bucket Traffic Shaper
Token bucket traffic shaper menggunakan sistem keranjang, yang hamper
serupa dengan keranjang C yang digunakan pada srTCM dan trTCM. Token
diletakkan pada keranjang token dengan laju token konstan sebesar r. Laju
token r ini mirip dengan CIR. Keranjang token memiliki kedalaman d yang
mirip dengan kedalaman keranjang C, yaitu CBS. Bila keranjang token telah
penuh, tidak ada lagi token yang ditambahkan ke dalam keranjang.
Setiap token membolehkan buffer mengeluarkan satu byte paket. Bila
tidak ada paket yang tersisa pada buffer, keranjang token akan tertutup dan
tidak ada token yang dikeluarkan. Saat ada paket yang memasuki buffer,
token dikeluarkan dalam laju jalur C, dan paket dikeluarkan dalam
“lonjakan†laju. Akan tetapi bila keranjang berada dalam keadaan
kosong, paket yang berada dalam buffer harus menunggu sampai ada token
yang memasuki keranjang.
Hasil operasi ini adalah paket diperbolehkan keluar dalam lonjakan laju C.
Ukuran lonjakan atau burst dibatasi hanya sampai kedalaman keranjang, yaitu
d. Karena token diletakkan pada keranjang dengan laju r, maka laju rata-rata
dalam dari paket yang keluar buffer dalam jangka panjang akan sama dengan
r. Karenanya, token bucket traffic shaper memiliki cara kerja yang sama
dengan keranjang C pada srTCM dan trTCM kecuali keranjang token
diaplikasikan pada port keluaran sementara keranjang C pada port masukan.
2.2. Differentiated Services
Salah satu solusi untuk mengaplikasikan QoS adalah menerapkan arsitektur
Differentiated Service (DiffServ) pada jaringan. DiffServ bekerja dengan prinsip
pengklasifikasian trafik. Edge Router akan mengklasifikasikan paket datang berdasarkan
peraturan tertentu, dan memberikan tanda yang menandai paket dengan code point yang
menentukan level layanan yang akan diterima paket tersebut. Core Router akan
memberikan perlakuan berbeda terhad ap paket yang datang berdasarkan code point dan
isi dari tabel Per-Hop Behaviour (PHB) (Li, 1999).
2.2.1. Arsitektur DiffServ
Arsitektur DiffServ berdasarkan sebuah model sederhana dimana trafik
yang memasuki sebuah jaringan diklasifikasikan dan dapat dikondisikan pada tepi
jaringan dan ditempatkan pada beberapa Behavior Aggregate (BA) yang berbeda.
Setiap BA diidentifikasikan oleh sebuah Differentiated Service Code Point (DSCP),
sehingga BA dapat didefinisikan sebagai kumpulan paket dengan DSCP yang sama
yang melewati sebuah link pada arah tertentu. Pada inti jaringan, paket diteruskan
bergantung kepada PHB yang ditentukan oleh DSCP (Blake, 1998).
Sebuah domain DiffServ terdiri atas DiffServ boundary nodes dan
DiffServ interior nodes. DiffServ boundary nodes menghubungkan sebuah domain
DiffServ ke domain lainnya, baik domain DiffServ maupun domain non-DiffServ,
sementara DiffServ interior nodes hanya menghubungkan node-node yang berada
pada sebuah domain DiffServ yang sama.
Baik DiffServ boundary nodes maupun DiffServ interior nodes harus
mampu menjalankan PHB yang tepat kepada sebuah paket berdasarkan DSCP yang
dimilikinya. Sebagai tambahan, DiffServ boundary nodes mungkin diperlukan untuk
melakukan fungsi pengondisian trafik yang didefinisikan oleh SLA antara domain
DiffServ tersebut dan domain lain yang berpasangan dengan domain tersebut. SLA
mungkin mengandung parameter-parameter seperti paket hilang maksimum, waktu
tunda paket maksimum, dll. SLA menjelaskan aturan-aturan dan kondisi-kondisi dari
layanan yang ditawarkan.
DiffServ interior nodes mungkin dibutuhkan untuk menjalankan fungsi
pengondisian trafik yang terbatas seperti penulisan ulang DSCP. Interior nodes hanya
perlu mengetahui bagaimana menangani beberapa kelas-kelas trafik daripada
menyimpan pengetahuan tentang ratusan dari aliran trafik individual. Di sini,
informasi per aliran dibuang di dalam domain. Mereka tidak mengimplementasikan
fungsi pengondisian trafik. Secara umum, interior nodes melakukan tugas yang lebih
sederhana dari boundary nodes. Interior node yang mengimplementasikan klasifikasi
dan fungsi pengondisian trafik yang lebih kompleks akan memiliki karakterisitik
yang sama dengan DiffServ boundary nodes.
Diffserv boundary nodes bertindak sebagai DiffServ ingress node dan
DiffServ egress node untuk arah trafik yang berbeda. Trafik memasuki sebuah
domain DiffServ melalui DiffServ ingress node dan keluar melalui DiffServ egress
node. Sebuah DiffServ ingress node bertanggung jawab dalam memastikan trafik
yang memasuki domain DiffServ memenuhi SLA antara domain tersebut dan domain
lain yang terhubung dengan ingress node. Diffserv egress node dapat melakukan
fungsi pengondisian trafik pada trafik yang diteruskan ke domain yang terhubung
secara langsung, bergantung pada SLA antara kedua domain.
Router yang bekerja sebagai DiffServ boundary nodes umumnya disebut
sebagai edge router, sedangkan router yang bekerja sebagai interior nodes biasanya
disebut sebagai core router.
2.2.2. Traffic Conditioner
Sebuah traffic conditioner terdiri atas elemen-elemen berikut: meter,
marker, shaper, dan dropper. Aliran trafik akan diseleksi oleh classifier, yang akan
meneruskannya ke bagian traffic conditioner. Meter digunakan (apabila diperlukan)
untuk membandingkan aliran trafik terhadap suatu profil trafik. Hasil keluaran
sebuah meter dapat mempengaruhi proses marking, dropping, atau shaping terhadap
paket tersebut (Blake, 1998).
Sebuah traffic conditioner tidak perlu selalu terdiri atas empat elemen yang
disebutkan sebelumnya. Contohnya, pada kasus dimana tidak ada profil trafik yang
mempengaruhi, paket cukup melewati classifier dan marker saja.
Traffic conditioner biasanya terletak di DiffServ ingress dan egress node,
tetapi dapat juga diletakkan pada interior node di dalam sebuah domain DiffServ,
ataupun di dalam domain non-DiffServ.
1. Meter
Traffic meter membandingkan properti sementara dari aliran trafik yang
diseleksi oleh classifier terhadap suatu profil trafik yang diberikan TCA. Suatu
meter meneruskan informasi ke fungsi pengondisian lainnya untuk menjalankan
proses yang sesuai, baik untuk paket yang memenuhi profil maupun tidak
memenuhi profil.
2. Marker
Packet marker mengisi field DSCP pada paket dengan nilai tertentu, untuk
menggabungkan paket tersebut ke BA yang sesuai. Marker dapat diatur untuk
menandai setiap paket yang memasukinya ke dalam satu codepoint tertentu, atau
diatur untuk menandai paket dengan suatu set codepoint yang mewakili PHB
tertentu, bergantung kepada kondisi meter. Marker juga dapat melakukan proses re-
marking, yaitu mengubah nilai codepoint dari suatu paket.
3. Shaper
Shaper menahan sebagian atau seluruh trafik pada suatu aliran trafik untuk
membentuk aliran trafik yang sesuai dengan profil trafik. Proses yang dilakukan
oleh shaper disebut shaping. Shaper biasanya memiliki buffer yang berukuran
terbatas, sehingga paket dapat dibuang bila tidak tersedia buffer yang cukup untuk
menampung trafik yang akan ditahan.
4. Dropper
Dropper bekerja untuk membuang sebagian atau seluruh paket pada suatu aliran
trafik untuk membentuk aliran trafik yang sesuai dengan profil trafik yang telah
ditentukan. Proses tersebut disebut policing. Dropper dapat diibaratkan sebagai
sebuah shaper yang memiliki ukuran buffer nol atau sangat kecil.
2.3. Linux Traffic Control
Implementasi DIffServ pada linux menggunakan traffic control yang berfungsi
untuk pengalokasian dari suatu bandwidth untuk mendukung kebutuhan atau keperluan
aplikasi atau suatu layanan jaringan. Traffic control adalah kumpulan aturan dan
mekanisme yang mengizinkan sebuah jaringan untuk memenuhi kualitas layanan secara
efisien. Beberapa mekanisme yang digunakan seperti shaping, scheduling, monitoring,
policing, signaling, pricing, admission control, congestion control dan flow control dan
lainnya. Selain itu traffic control dapat diartikan sebagai kumpulan fungsi dari sebuah
jaringan untuk mencegah kondisi padat, yang membentuk mengatur aliran data pada titik
tertentu dalam system (Brown, 2006).
Traffic control adalah sekumpulan sistem dan mekanisme antrian terhadap paket
data yang diterima maupun dikirim pada sebuah router. Termasuk untuk memutuskan
untuk menerima paket data pada kecepatan tertentu pada sebuah interface dan
memutuskan untuk mengirim paket data dengan urutan maupun kecepatan tertentu pada
output dari interface (Hubert, 2004).
Pada umumnya traffic control terdiri atas antrian tunggal yang mengumpulkan
paket data yang masuk dan mendequeue seketika paket data yang diterima. Metode
antrian ini biasa disebut dengan FIFO.
2.3.1. Metode Traffic Control pada Kernel Linux
Terdapat beberapa metode yang digunakan oleh traffic control pada
interface (Hubert , 2004), yaitu :
1. Shaping
Shapers menahan paket untuk mencapai kecepatan yang diinginkan.
shaping adalah mekanisme untuk menahan paket data sebelum transimisi
pada output queue untuk mencapai outpu kecepatan yang diinginkan.
Metode ini adalah yang biasa digunakan user untuk solusi pengendalian
bandiwdth. Penundaan paket sebagai bagian dari solusi traffic control
membuat tiap mekanisme shaping kedalam bentuk mekanisme untuk
menjaga paket tidak hilang. Shaper mencoba untuk membatasi atau
membentuk traffic untuk mencapai tanpa melampaui kecepatan yang
dikonfigurasi (biasanya diukur dalam paket per detik atau bits/bytes per
detik). Shaper dapat melancarkan bursty traffic.Salah satu keuntungan dari
shaping bandwidth adalah kemampuan untuk mengendalikan latency dari
paket data. Mekanisme dasar untuk shaping ke kecepatan yang diinginkan
biasanya mekanisme token dan bucket.
2. Scheduling
Scheduler mengatur paket untuk output. scheduling adalah mekanisme
untuk pengaturan paket di antara input dan output dari sebagian besar
antrian. scheduler yang biasanya digunakan adalah FIFO scheduler. Jika
melihat dari sudut pandang yang lebih umum, mekanisme traffic control
apapun yang berada pada output queue dapat diartikan sebagai scheduler,
karena paket diurutkan untuk output. Mekanisme scheduling umum
lainnya mencoba untuk beradaptasi dengan kondisi jaringan. Fair queuing
algorithm mencoba untuk mencegah suatu client atau aliran data yang
mendominasi penggunaan jaringan. Algoritma Round Robin memberikan
tiap aliran data ataupun client gilirannya untuk dequeue paket.
3. Classifying
Classifier mengurutkan atau memisahkan traffic ke dalam beberapa
queue. Classifying adalah mekanisme untuk menentukan paket mana yang
dipisah untuk diperlakukan berbeda, dan dimungkinkan dengan output
queue yang berbeda. Selama proses penerimaan, routing dan transmisi
paket data, peralatan jaringan dapat mengklasifikasikan paket data
tersebut dengan berbagai cara. Klasifikasi termasuk di dalamnya marking
packet yang biasanya terjadi pada ruang lingkup dari jaringan yang berada
pada kendali administrasi tunggal atau dapat terjadi pada tiap-tiap hop.
Linux model mengizinkan paket data untuk melewati beberapa macam
classifier dan untuk diteruskan ke policer.
4. Policing
Policing menghitung dan membatasi traffic dalam queue tertentu. Policing
sebagai bagian dari elemen traffic control adalah mekanisme sederhana
yang menentukan paket apa saja yang dibatasi. Policing biasanya
digunakan pada perbatasan jaringan untuk memastikan bahwa peer tidak
mengkonsumsi lebih dari bandwidth yang sebelumnya dialokasikan.
Policer akan menerima traffic pada kecepatan tertentu dan melakukan
sebuah aksi pada traffic yang melewati kecepatan ini. Solusi yang lebih
kasar adalah dengan membuang paket, meskipun paket data dapat
diklasifikasikan ulang daripada dibuang. Policer akan mencek traffic
terhadap kecepatan yang akan masuk ke dalam queue. Jika paket akan
masuk ke dalam queue dengan nilai kecepatan dibawah dari semestinya,
lakukan satu hal( izinkan enqueuing). Jika suatu paket melebihi kecepatan
yang seharusnya, lakukan hal lain. Meskipun policer menggunakan
mekanisme token bucket, policer tidak mampu menunda paket data
seperti halnya mekanisme shaping.
5. Dropping
Dropping membuang keseluruhan paket data, aliran data atau klasifikasi.
Dropping sebuah paket data adalah mekanisme untuk menentukan paket
apa yang dibuang.
6. Marking
Marking adalah mekanisme untuk menandai paket data. Digunakan untuk
memilih paket yang nantinya akan diproses oleh qdisc.
2.3.2. Queuing Discipline
Antrian menentukan cara mengirimkan data. Penting untuk diingat bahwa
kita hanya bisa menentukan data yang kita kirim (Hubert, 2004). Cara kerja dari
internet membuat kita tidak memiliki kemampuan untuk mengendalikan apa yang
orang lain kirimkan. Setiap output interface membutuhkan scheduler dan secara
default adalah FIFO.
Secara sederhana qdisc adalah scheduler. Qdisc lain yang tersedia pada
Linux akan mengatur kembali paket data yang memasuki antrian tergantung pada
aturan scheduler tersebut. Qdisc adalah bagian penting dari Linux traffic control dan
biasa disebut queueing discipline.
Terdapat banyak qeueuing discipline pada kernel linux, namun pada
pembahasan kali ini hanya 2 yang kita gunakan. Random Early Detection, untuk
menanggulangi congestion. Hierarchical Token Bucket, untuk membagi bandwidth
sesuai dengan kebutuhan, misal berdasarkan ip ataupun port yang diinginkan.
1. Random Early Detection
Bagian ini menjelaskan algoritma RED. RED menghitung average queue size
menggunakan low-pass filter dengan exponential weighted moving average. Average
queue size dibandingkan dengan 2 thresholds, minimum threshold dan maximum
threshold. Ketika average queue size kurang dari minimum threshold tak ada paket
yang di mark. Ketika average queue size lebih besar dari maximum threshold, setiap
paket yang datang di mark. Jika paket yang dimark dibuang atau jika semua node
sumber bekerja sama dapat dipastikan bahwa average queue size tidak secara
signifikan melampaui maximum threshold (Hubert, 2004).
Ketika average queue size berada di antara minimum dan maximum threshold,
tiap paket yang datang di mark dengan probabilitas pa, di mana pa adalah fungsi dari
average queue size avg. Tiap kali paket ditandai, probabilitas dari paket yang di mark
dari suatu koneksi adalah berbanding lurus terhadap pembagian koneksi dari
bandwidth pada gateway. Algoritma RED adalah sebagai berikut :
for each packet arrival
calculate the average queue size avg
if minth <= avg < maxth
calculate probability pa
with probability pa:
mark the arriving packet
else if maxth <= avg
mark the arriving packet
Berbeda dengan tail-drop algorithm yang membuang paket ketika buffer penuh,
RED algorithm membuang paket yang datang dengan metode probabilitas.
Probabilitas terhadap pembuangan paket akan meningkat seiring dengan
perkembangan dari pergitungan average queue size. Sebagai catatan RED merespon
terhadap panjang queue per rata-rata waktu bukan pada saat itu. Untuk itu jika queue
telah kosong pada waktu sebelumnya. RED tidak akan berusaha untuk membuang
paket(kecuali melampaui queue tentunya). Di lain pihak, jika queue sebelumnya
penuh, paket yang baru datang akan memiliki kemungkinan besar untuk dibuang.
RED algorithm terdiri atas 2 bagian utama, yaitu : menghitung average queue
size dan memutuskan untuk membuang atau tidak paket yang datang.
A. Penghitungan Average Queue Size
RED menghitung average queue size menggunakan low-pass filter. Untuk itu
ukuran queue yang berasal dari traffic yang melonjak atau dari kepadatan tetap
tidak akan ditentukan oleh hal tersebut. Low-pass filter yang digunakan adalah
exponential weighted moving average(EWMA) dengan formula berikut :
avg = (1−wq)avg+wq.q
keterangan :
avg = ukuran rata-rata paket yang masuk.
wq = bobot antrian.
q = ukuran antrian actual.
B. Keputusan pembuangan paket
Pada tahapan ini, RED menentukan untuk membuang atau tidak paket yang
datang. Terdapat 2 parameter RED, minth(minimum threshold) dan
maxth(maximum threshold). Ukuran paket rata-rata yang berada di bawah nilai
minth tidak akan dibuang, sedangkan ketika berada di atas nilai maxth paket akan
langsung dibuang. Ketika berada di antara kedua nilai tersebut, paket akan
dibuang dengan probabilitas yang beragam dari 0 sampai nilai maksimum
probabilitasnya(maxp). Berikut formula penghitungan probabilitas untuk ukuran
paket rata-rata yang berada di antara kedua nilai tersebut :
pb = maxp(avg - minth)/(maxth - minth)
pa = pb/(1−count . pb)
keterangan :
pa = nilai kemungkinan suatu paket.
maxp = nilai maksimum probabilitas.
avg = nilai ukuran rata-rata paket.
maxth = nilai maksimal rata-rata paket.
minth = nilai minimum rata-rata paket.
count = jumlah paket data yang masuk.
2. Hierarchical Token Bucket
HTB adalah salah satu queueing discipline berbasis class(classful). HTB
berbasis atas class hierarkis yang terdiri atas tiga tipe, yaitu : root, inner dan leaf.
Root adalah induk dari semua class dan semua lalu lintas data akan melewatinya.
Inner class memiliki induk class, dapat berupa root ataupun inner class lain, dan
memiliki class turunan. Leaf adalah kelas akhir atau class yang hanya memiliki class
induk tanpa class turunan (Devera, 2002). Leaf adalah class yang menampung paket
data yang ada di queue.
HTB memastikan bahwa jumlah layanan yang disediakan untuk tiap class
kurang atau sama dengan jumlah yang telah ditetapkan. Ketika sebuah class memiliki
permintaan yang kurang dari jumlah yang ditetapkan, sisa bandwidth akan
didistribusikan ke class yang lain.
HTB scheduler
Terdapat pohon class pada HTB scheduler. Terdapat pula list global yang
disebut self feed, yang terdapat pada sebelah kanan. Self feed terdiri atas self
slot. Terdapat satu slot per priority per level. Tiap self slot memiliki beberapa
class. Semua class pada slot memiliki level dan prioritas seperti slot.
Tiap inner(non-leaf) class memiliki inner feed slots. Terdapat satu inner
feed slot per priority dan per inner class. Terdapat Self slot yang memiliki
beberapa class dengan prioritas yang sama seperti slot dan class pasti pemilik
dari slot children. Feed mengindikasikan prioritas dari class. Dapat dilihat pada
bagan di bawah.
Gambar 2.1 Prioritas pengiriman paket (Devera, 2002)
Ketika leaf class ingin mengirimkan paket, HTB akan mencek
prioritasnya. Paket data akan mulai dikirim dengan urutan prioritas paling tinggi
dan level paling rendah. Semua akan dikirim sampai ke prioritas paling rendah
dan level paling tinggi.
Gambar 2.2 Prioritas Paket (Devera, 2002)
Jika dilihat pada bagan di atas, leaf2 akan dikirim terlebih dahulu
disbanding leaf1. Karena leaf2 berada pada level yang lebih rendah, meskipun
memiliki prioritas yang lebih rendah.
Contoh Kasus
Pada gambar 2.3, tidak ada paket yang datang. Maka tiap leaf tidak
melakukan apa-apa.
Gambar 2.3 Diagram HTB(Devera, 2002)
Pada gambar 2, terdapat paket yang datang pada class C dan D dan berada
di bawah min-rate. Sehingga leaf berwarna hijau. Tiap leaf diberikan
prioritasnya masing-masing(biru = rendah, merah = tinggi). Karena D memiliki
prioritas yang lebih tinggi, maka D akan mengirimkan paket data. Kemudian
diikuti oleh kelas C yang memiliki prioritas lebih rendah.
Gambar 2.4 Diagram HTB paket datang(Devera, 2002)
Kali ini paket data pada D melebihi min-rate yang seharusnya, sehingga D
menjadi warna kuning. Untuk itu D harus meminjam ke class di atasnya, yaitu B.
D akan melepaskan diri dari self feed dan masuk ke inner feed B dan otomatis B
akan masuk ke self feed yang sesuai. Keadaan ini akan mengakibatkan class C
akan didequeue paketnya terlebih dahulu dibanding B, karena memiliki level
terendah.
Gambar 2.5 Diagram HTB node D overload. (Devera, 2002)
Kondisi sekarang C melampaui ceil dan tidak bisa pinjam ke A. D
melampaui rate dan meminjam ke B. Di B melampaui rate dan meminjam ke A.
di A tidak melampui rate dan berstatus hijau. D dapat mengirimkan paket data.
Tapi C harus menunggu sampai C normal.
Gambar 2.6 Diagram HTB node C overload(Devera, 2002)
Sekarang C berada pada status kuning yang artinya melampaui rate dari C.
C harus meminjam dari A dan sekarang berada di level 2. Sama halnya dengan
D dan E, harus meminjam ke B. Pada B melampaui rate, dan harus meminjam ke
A. A tidak melampaui rate. Karena semua berada pada level 2 di posisi class A.
Paket data yang akan dikirim adalah yang memiliki prioritas paling tinggi. Dan
yang memiliki prioritas paling tinggi akan menggunakan algoritma round robin
untuk dequeuenya.
Gambar 2.7 Diagram HTB paket A mengirim(Devera, 2002)
2.4. TC tools
Pada paket iproute2, tc adalah satu-satunya yang dapat digunakan untuk traffic
control. Karena tc secara langsung berinteraksi dengan kernel untuk pembuatan,
penghapusan dan modifikasi terhadap struktur traffic control. TC tool menampilkan
semua konfigurasi terhadap struktur kernel untuk mendukung traffic control. Utilitas ini
menggunakan argument awal salah satu dari tiga komponen linux traffic control yaitu :
qdisc, class dan filter (Hubert, 2004).
Syntax dasar penggunaan TC :
Penggunaan : tc [ OPTIONS ] OBJECT { COMMAND | help }
where OBJECT := { qdisc | class | filter }
OPTIONS := { −s[tatistics] | −d[etails] | −r[aw] }
2.4.1. tc qdisc
Gambar 2.8 tc qdisc (Hubert, 2004)
Keterangan :
1. Menambahkan queueing discipline. Dapat dirubah menjadi del untuk
menghapus qdisc.
2. Device yang akan ditambahkan qdisc.
3. Berarti egress atau output pada interface. Kata root wajib digunakan,
meskipun pada qdisc lain yang memiliki fungsi terbatas dapat menambahkan
qdisc pada ingress di device yang sama.
4. Handle angka spesifik dari user dengan bentuk major:minor. Angka minor
untuk yang memiliki qdisc akan selalu nol(0). Biasa disingkat dengan syntax
“1:”, angka minor akan otomatis nol(0).
5. Queueing yang dipakai, pada contoh ini adalah HTB. Setelah ini adalah
parameter khusus dari qdisc yang dipakai. Contoh ini tidak menyertakan itu.
2.4.2. tc class
Gambar 2.9 tc class (Hubert, 2004)
Keterangan :
1. Menambahkan class. Bisa diubah menjadi del untuk menghapus class.
2. Device yang ingin ditambahkan class baru.
3. Spesifikasi dari handle induk(biasanya qdisc) yang ingin kita tambahkan class
baru.
4. Ini adalah handle unik dengan pola major:minor untuk identifikasi class.
Angka minor harus tidak boleh nol(0).
5. qdisc yang akan digunakan pada class ini.
6. nilai rate yang nantinya dapat di pinjam oleh class/qdisc turunan.
7. nilai ceil(tepi) yang dipakai sebagai batasan rate yang dapat dipinjam.
2.4.3. tc filter
Gambar 2.10 tc filter (Hubert, 2004)
Keterangan :
1. Menambahkan filter, dapat juga diganti dengan del untuk membuang filter.
2. device yang ingin ditambahkan filter.
3. parent handle yang ingin kita tambahkan filter.
4. filter berdasarkan protocol tertentu. Contoh ini dalah ip.
5. parameter prio untuk filter didahulukan dibanding yang lain.
6. classifier yang digunakan TC untuk filter.
7. parameter untuk classifier. Pada kasus ini paket dengan port 22 akan dipilih.
8. sama dengan baris 7, mencocokan dengan protocol tertentu.
9. paket data yang terpilih nantinya akan dikirim ke class pada parameter ini.
10. policer dan opsional untuk tc.
11. policer akan melakukan satu aksi ketika melampaui kecepatan ini dan parameter
aksi berada pada baris setelah ini.
12. sama seperti konsep burst pada HTB.
13. minimum policed unit. Untul menghitung semua paket yang masuk gunakan mpu
0.
14. Aksi yang dilakukan oleh policer.
2.4.4. TC untuk penggunaan RED
Asumsikan kondisi jaringan dengan bandwidth 128kbps dan latency
500msec. Berikut perhitungannya :
Bandwidth = 128kbps = 16000 Byte / sec
Latency = 500msec = 0.5 sec
Max = Bandwidth * Latency
= 16000 * 0.5
= 8000
Min = Max / 2
= 4000
Limit = 8 * max
= 8 * 8000
= 64000
Burst = (2 * min + max) / (3 * avpkt)
= (2 * 4000 + 8000) / (3 * 1000)
= 5.33
#tc qdisc add dev eth0 root red limit 64000 min 4000 max 8000 burst 5.33 avpkt
1000 probability 0.02 bandwidth 128
2.4.5. TC untuk penggunaan HTB
Misal kita ingin membatasi penggunaan bandwidth klien. Asumsikan kita
memiliki bandwidth 2Mbit dan klien A dengan 128Kbit dan klien B dengan 512Kbit.
Dan untuk klasifikasi port SSH = 64Kbit, TELNET = 4Kbit, POP3 = 32Kbit, SMTP
= 32Kbit.
Gambar 2.11 contoh HTB tree (Hubert, 2004)
#tc qdisc add dev eth0 root handle 1:0 htb
#tc class add dev eth0 parent 1:0 classid 1:1 htb rate 2Mbit ceil 2Mbit
#tc class add dev eth0 parent 1:1 classid 1:2 htb rate 128Kbit ceil 128Kbit
#tc class add dev eth0 parent 1:1 classid 1:3 htb rate 512Kbit ceil 512Kbit
#tc class add dev eth0 parent 1:2 classid 1:21 htb rate 64Kbit ceil 64Kbit
#tc class add dev eth0 parent 1:2 classid 1:22 htb rate 4Kbit ceil 128Kbit
#tc class add dev eth0 parent 1:3 classid 1:31 htb rate 32Kbit ceil 32Kbit
#tc class add dev eth0 parent 1:3 classid 1:32 htb rate 32Kbit ceil 32Kbit
#tc qdisc add dev eth0 parent 1:21 handle 210: pfifo limit 10
#tc qdisc add dev eth0 parent 1:22 handle 220: pfifo limit 10
#tc qdisc add dev eth0 parent 1:31 handle 310: pfifo limit 10
#tc qdisc add dev eth0 parent 1:32 handle 320: pfifo limit 10
#tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.1/24
match ip sport 22 0xff flowid 1:21
#tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.1/24
match ip sport 23 0xff flowid 1:22
#tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.2/24
match ip sport 25 0xff flowid 1:31
#tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.2/24
match ip sport 110 0xff flowid 1:32
2.5. Python
Python adalah salah satu bahasa pemrograman script. Karena script sehingga
bersifat interpreted tapi python memungkinkan untuk dicompile. Memiliki pendekatan
Berorientasi Objek dan yang terpenting adalah terstruktur secara sintaks kodenya.
Struktur sintaks akan diatur dengan indentasi tiap baris kodenya. Prinsip dasar dari
python adalah kesederhanaan (http://docs.python.org/).
2.5.1. Hello World
Setiap contoh yang ada dapat dicoba di linux, untuk mencoba di system operasi
lain sesuaikan bagian shebang(#!). Buat file hello.py dan masukkan baris kode berikut :
#!/usr/bin/env python
print “Hello World!”
Jalankan file tadi dengan menambahkan atribut execute dengan perintah :
$ chmod u+x hello.py
Jalankan file hello.py dengan perintah berikut :
$ ./hello.py
Hello World!
Setelah dieksekusi akan tampil teks Hello World!. Karena bersifat interpreted,
tidak perlu ada proses kompilasi sebelumnya.
2.5.2. Dasar Python
1. Literal
Literal adalah bilangan seperti 5, 5,2, 4e12, string seperti ‘ini adalah string’
atau “ini string juga.”. Literal dapat digunakan dan ditampung pada variable
nantinya.
2. Bilangan
Terdapat 4 tipe bilangan pada python, diantaranya :
1) Integer, 2, 4, 10, 1000, dll.
2) Long Integer, nilainya lebih besar dari integer.
3) Floating Point, 2,3, 1,0, dll.
4) Complex, (-5+4j) dan (2.3 - 4.6j).
3. String
String pada python dapat ditandai dengan tanda petik satu, dua maupun tiga.
‘string dengan satu petik’
“string dengan dua petik”
‘’’ string dengan tiga petik
dapat dibuat multi baris‘’’
4. Variabel
Untuk penamaan variable wajib didahului oleh huruf atau underscore ‘_’.
Berikut contoh penamaan yang benar.
nama
_nama
Nama
Variabel akan langsung bisa digunakan ketika kita memberikan nilai ke
dalamnya. Berikut contohnya :
nama = “deni”
usia = 22
5. Indentasi
Indentasi sangat penting pada python, karena python membaca indentasi
dari kode program untuk menentukan alur dan blok dari tiap bagian kode.
Kode berikut akan error bila dijalankan :
x = 5
y = 3
z = 4
print x
di bagian lain akan dipelajari tentang control program dan fungsi. Pada
bagian itu indentasi akan sering digunakan.
2.5.3. Operator dan Ekspresi
1. Operator
Berikut operator yang ada pada python :
+ - * ** / // %
<< >> & | ^ ~
< > <= >= == != <>
2. Ekspresi
Penggunaan ekspresi pada python cukup sederhana, berikut contohnya :
length = 5
breadth = 2
area = length * breadth
3. Alur Kendali
Terdapat beberapa pernyataan pada python untuk mengatur alur kendali
program, diantaranya adalah if, while dan for..in.
1) If
Pernyataaan if akan menguji kebenaran dari ekspresi, kemudian akan
menjalankan blok yang diinginkan. Berikut contoh penggunaannya :
x = 0
if x < 1:
print x
elif x > 0:
print “x lebih besar dari 0”
else:
print “error”
2) While
Pernyataan ini akan mengulang blok yang sudah ditentukan selama
ekspresi dalam while masih bernilai benar. Berikut contohnya:
ulang = True
while ulang:
print “baris yang akan dijalankan selama
masih bernilai true”
else:
print “baris yang dijalankan ketika bernilai
false”
3) For .. in
Pada pernyataan ini, perulangan akan terjadi sebanyak N sesuai dengan
jumlah sequence object yang digunakan.
for i in range(1,5)
print i
2.5.4. Fungsi
Untuk membuat fungsi cukup menggunakan keyword def. Kemudian diikuti nama
fungsi dan parameternya. Berikut contohnya :
def Tambah():
print x + 1
Jika mengikuti konvensi dari python, minimal sebuah fungsi akan
memiliki parameter self. Sehingga didapat fungsi berikut :
def Tambah(self):
print x
Jika ingin menambah parameter lain, cukup dengan memisahkan dengan
tanda koma(,). Sebagai contoh :
def Tambah(self, x, y):
print x + y
Sebuah fungsi dapat memiliki nilai kembalian / return value. Cukup
dengan menggunakan keyword return.
def Tambah(self, x, y):
return x + y
2.5.5. Pemrograman Berorientasi Objek
1) Class
Penggunaan class pada python hanya menggunakan keyword class. Berikut
contohnya :
class Manusia:
def Bicara(self):
print “berbicara”
Untuk menginstansiasi objek dari class yang kita buat. Cukup dengan kode
berikut :
objManusia = Manusia()
objManusia.Bicara()
2) Method
Penggunaan dan pembuatan method pada class, sama dengan fungsi biasa.
Perbedaan hanya terlihat pada cara memanggil method. Berikut contohnya :
class Mobil:
def Nama(self, nama):
self.nama = nama
print self.nama
objMobil = Mobil()
objMobil.Nama(“Sedan”)
Contoh di atas akan menghasilkan kata sedan. Terlihat pada definisi fungsi
terdapat 2 parameter yaitu: self dan nama. Tapi untuk memanggil fungsi
cukup melewatkan untuk variable setelah self. Karena self tidak dianggap
sebagai parameter.
3) __init__ method
Pada python terdapat constructor method pada class. Disebut dengan __init__
method. Method ini akan dipanggil terlebih dahulu ketika objek dibuat dari
kelas tersebut. Berikut contoh penggunaannya:
class Mobil:
def __init__(self):
print “mobil dibuat”
t = Mobil()
4) Inheritance
Untuk membuat turunan kelas pada python sangat mudah. Hanya
menggunakan tanda (kelas induk). Berikut contohnya :
class Induk:
def __init__(self):
print “kelas induk”
class Turunan(Induk):
def __init__(self):
print “kelas turunan”
2.5.6. PyGTK
PyGTK 2.0 adalah sekumpulan modul Python yang menyediakan
antarmuka untuk GTK Python 2.x. Seluruh PyGTK dokumen mengacu pada versi
2.x PyGTK dan GTK, GTK merujuk pada versi 2.x GTK. Situs web utama untuk
PyGTK adalah www.pygtk.org. Penulis utama PyGTK adalah James Henstridge,
james@daa.com.au.
Python adalah sebuah bahasa pemrograman yang extensible, berorientasi
obyek yang disediakan dengan kumpulan modul yang menyediakan akses ke
sebagian besar operating system services, internet services (seperti HTML, XML,
FTP, dll), grafis (termasuk OpenGL, TK, dll), fungsi penanganan string, layanan
mail (IMAP, SMTP, POP3, dll), multimedia (audio, JPEG) dan layanan
kriptografi. Selain itu ada banyak modul lain yang tersedia dari pihak ketiga yang
menyediakan banyak layanan lainnya.
GTK pada dasarnya adalah sebuah application programmers interface
(API) berorientasi objek. Walaupun sepenuhnya ditulis dalam C, diimplementasikan
dengan menggunakan gagasan kelas dan callback functions (pointer ke fungsi).
Dengan menggunakan pygtk, pengguna python dapat dengan mudah menggunakan
GTK sebagai GUI untuk program mereka. Hanya dengan menggunakan python yang
memanggil GTK widgets yang diperlukan untuk program mereka.
2.5.7. Matplotlib
Matplotlib adalah pustaka 2D plotting python yang menghasilkan diagram
dalam berbagai format hardcopy dan lingkungan interaktif lintas platform.
Matplotlib dapat digunakan dalam python scripts, python dan ipython shell (ala
matlab atau mathematica), web application servers, dan 6 graphical user interface
toolkits.
Matplotlib mencoba untuk membuat hal yang mudah menjadi mudah dan
yang sulit menjadi mungkin. Anda bisa generate plots, histograms, power spectra,
bar charts, errorcharts, scatterplots, dan lain-lain, hanya dengan beberapa baris kode.
Gambar 2.12 contoh plot dengan matplotlib
Sebagai contoh, untuk generate 10.000 gaussian angka acak dan membuat
histogram berisi data dalam 100 bins, cukup dengan mengetikkan:
>>> from pylab import randn, hist
>>> x = randn(10000)
>>> hist(x, 100)
Untuk power user, anda memiliki kendali penuh atas model garis, font
properties, axes properties, dan lainnya, lewat object oriented interface atau
sekumpulan fungsi yang mirip bagi pengguna Matlab®. Pylab mode menyediakan
semua fungsi pyplot plotting dan juga fungsi non-plotting functions dari numpy dan
matplotlib.mlab.
2.6. Extreme Programming
Extreme Programming (XP) adalah metode pengembangan perangkat lunak yang
ringan dan termasuk salah satu agile methods yang dipelopori oleh Kent Beck, Ron
Jeffries, dan Ward Cunningham. Sasaran XP adalah tim yang dibentuk berukuran antara
kecil sampai medium saja, tidak perlu menggunakan sebuah tim yang besar.
Menurut Pressman(2005), Extreme Programming adalah proses yang paling
banyak digunakan pada agile process. Perencanaan kegiatan diatur sebagai kerangka
empat – perencanaan(planning), desain(design), pengkodean(coding) dan
pengujian(testing) - XP menunjukkan sejumlah teknik yang inovatif dan kuat yang
memungkinkan tim tangkas untuk membuat perangkat lunak rilis sering memberikan fitur
dan fungsi yang telah dijelaskan dan kemudian diprioritaskan oleh pelanggan.
Menurut Schach(2005), Extreme Programming adalah salah satu dari sejumlah
paradigma baru yang secara kolektif disebut sebagai proses tangkas oleh Beck. Mereka
ditandai dengan penekanan lebih sedikit pada analisis dan desain dari di hampir semua
model siklus-hidup yang lain dan dengan pelaksanaan dimulai jauh lebih awal dalam
siklus hidup, karena perangkat lunak bekerja dianggap lebih penting daripada
dokumentasi rinci. Responsif terhadap perubahan lain tujuan utama proses tangkas,
begitu pula pentingnya bekerja sama dengan klien.
Extreme Programming (berikutnya akan disingkat sebagai XP) adalah sebuah
pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan
berbagai tahapan dalam proses pengembangan tersebut sehingga menjadi lebih adaptif
dan fleksibel. Walaupun menggunakan kata programming, XP bukan hanya berfokus
pada coding tetapi meliputi seluruh area pengembangan perangkat lunak(Beck, 2004).
Penulis menggunakan model proses Extereme Programming dari Pressman
dengan perencanaan kegiatan berupa perencanaan(planning), desain(design),
pengkodean(coding) dan pengujian(testing) serta diakhiri release dari aplikasi.
2.6.1. Nilai-nilai Dasar XP
Berikut adalah nilai-nilai mendasar yang menjadi roh dari XP pada setiap
tahapan proses pengembangan perangkat lunak(Beck, 2004):
1. Communication
XP memfokuskan pada komunikasi yang baik antar anggota tim. Para
anggota tim harus membangun saling pengertian, mereka juga wajib saling
berbagi pengetahuan dan keterampilan dalam mengembangkan perangkat lunak.
Ego dari para programer yang biasanya cukup tinggi harus ditekan dan mereka
harus membuka diri untuk bekerjasama dengan programer lain dalam
menuliskan kode program.
2. Courage
Para anggota tim dan penanggungjawab pengembangan perangkat lunak
harus selalu memiliki keyakinan dan integritas dalam melakukan tugasnya.
Integritas ini harus selalu dijaga bahkan dalam kondisi adanya tekanan dari
situasi sekitar (misalnya oleh klien atau pemilik perusahaan). Untuk dapat
melakukan sesuatu dengan penuh integritas terlebih dahulu para anggota tim
harus terlebih dahulu memiliki rasa saling percaya. Rasa saling percaya inilah
yang coba dibangun dan ditanamkan oleh XP pada berbagai aspeknya.
3. Simplicity
Lakukan semua dengan sederhana. Hal tersebut adalah salah satu nilai dasar
dari XP. Gunakan method yang pendek dan simpel, jangan terlalu rumit dalam
membuat desain, hilangkan fitur yang tidak ada gunanya, dan berbagai proses
penyederhanaan lain akan selalu menjadi nilai utama dari setiap aspek XP.
4. Feedback
Berikan selalu feedback kepada sesama anggota tim maupun pihak-pihak
lain yang terlibat dalam pengembangan perangkat lunak. Utarakan selalu
pikiran anda dan diskusikan kesalahan-kesalahan yang muncul selama proses
pengembangan. Dengarkan selalu pendapat rekan yang lain, dengan adanya
feedback inilah seringkali kita menyadari bagian mana yang salah atau bisa
ditingkatkan lagi dari perangkat lunak yang dikembangkan.
5. Quality Work
Semua nilai di atas berujung pada sebuah kondisi di mana kita melakukan
pekerjaan dengan berkualitas. Dengan proses yang berkualitas maka
implikasinya akan muncul pula perangkat lunak yang berkualitas sebagai hasil
akhirnya.
2.6.2. Aspek Dasar XP
Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan
Beck dan Jeffries pada C3 Project(Beck, 2004). Teknik-teknik tersebut dapat
diamati pada gambar berikut ini:
Gambar 2.13 XP practices(Beck, 2004)
1. The Planning Game
Pendekatan XP dalam perencanaan sangat mirip dengan metode yang
diterapkan pada RAD (Rapid Application Development). Proses pendek dan
cepat, mengutamakan aspek teknik, memisahkan unsur bisnis dengan unsur
teknis dan pertemuan intensif antara klien dengan developer. Pada XP proses ini
menggunakan terminologi “game” karena Beck menyarankan untuk
menggunakan teknik score card dalam menentukan requirements. Semakin sulit
aspek teknis yang dibutuhkan semakin tinggi pula skor pada kartu rencana
tersebut.
2. Small Releases
Setiap release dilakukan dalam lingkup sekecil mungkin pada XP. Setiap
developer menyelesaikan sebuah unit atau bagian dari perangkat lunak maka
hasil tersebut harus segera dipresentasikan dan didiskusikan dengan klien. Jika
memungkinkan untuk menerapkan unit tersebut pada perusahaan, hal itu juga
dapat dilakukan sekaligus sebagai tes awal dari penerapan keseluruhan sistem.
Kendati demikian hal ini tidak selalu perlu dilakukan karena harus dihitung
terlebih dahulu sumberdaya yang dibutuhkan. Apakah lebih menguntungkan
langsung melakukan tes terhadap unit tersebut atau melakukan tes setelah unit
tersebut terintegrasi secara sempurna pada sistem.
3. Metaphor
Metaphor pada dasarnya sama dengan arsitektur perangkat lunak.
Keduanya menggambarkan visi yang luas terhadap tujuan dari pengembangan
perangkat lunak. Beck sendiri seperti para penandatangan Agile Manifesto
lainnya bercita-cita menyederhanakan proses pengembangan perangkat lunak
yang saat ini sudah dianggap terlalu rumit. Arsitektur yang saat ini banyak berisi
diagram dan kode semacam UML dianggap terlalu rumit untuk dimengerti,
terutama oleh klien. Metaphor, walaupun mirip dengan arsitektur lebih bersifat
naratif dan deskriptif. Dengan demikian diharapkan komunikasi antara klien
dengan developer akan berlangsung lebih baik dan lancar dengan penggunaan
metaphor.
4. Simple Design
Sebagai salah seorang penandatangan Agile Manifesto, Beck adalah
seorang yang tidak menyukai desain yang rumit dalam sebuah pengembangan
perangkat lunak. Tidak heran jika dia memasukkan Simple Design sebagai salah
satu unsur XP. Pada XP desain dibuat dalam lingkup kecil dan sederhana. Tidak
perlu melakukan antisipasi terhadap berbagai perubahan di kemudian hari.
Dengan desain yang simpel apabila terjadi perubahan maka membuat desain
baru untuk mengatasi perubahan tersebut dapat dengan mudah dilakukan dan
resiko kegagalan desain dapat diperkecil.
5. Refactoring
Refactoring adalah salah satu aspek paling khas dari XP. Refactoring
seperti didefinisikan oleh Martin Fowler adalah ”Melakukan perubahan pada
kode program dari perangkat lunak dengan tujuan meningkatkan kualitas dari
struktur program tersebut tanpa mengubah cara program tersebut bekerja”.
Refactoring sendiri sangat sesuai untuk menjadi bagian XP karena Refactoring
mengusung konsep penyederhanaan dari proses desain maupun struktur baris
kode program. Dengan Refactoring tim pengembang dapat melakukan berbagai
usaha untuk meningkatkan kualitas program tanpa kembali mengulang-ulang
proses desain. Fowler adalah salah satu kolega dekat dari Kent Beck karena itu
tidak mengherankan bahwa cara berpikir mereka terhadap proses
pengembangan perangkat lunak sangat mirip satu dengan lainnya.
6. Testing
XP menganut paradigma berbeda dalam hal tes dengan model
pengembangan perangkat lunak lainnya. Jika pada pengembangan perangkat
lunak lainnya tes baru dikembangkan setelah perangkat lunak selesai menjalani
proses coding maka pada XP tim pengembang harus membuat terlebih dahulu
tes yang hendak dijalani oleh perangkat lunak. Berbagai model tes yang
mengantisipasi penerapan perangkat lunak pada sistem dikembangkan terlebih
dahulu. Saat proses coding selesai dilakukan maka perangkat lunak diuji dengan
model tes yang telah dibuat tersebut. Pengetesan akan jauh lebih baik apabila
dilakukan pada setiap unit perangkat lunak dalam lingkup sekecil mungkin
daripada menunggu sampai seluruh perangkat lunak selesai dibuat. Dengan
memahami tahap ini kita dapat melihat bahwa siklus pada XP adalah
requirement analysis � test � code � design. Sekilas terlihat hal ini tidak
mungkin dilakukan tetapi pada kenyataannya memang gambaran inilah yang
paling dapat menjelaskan tentang XP.
7. Pair Programming
Pair programming adalah melakukan proses menulis program dengan
berpasangan. Dua orang programer saling bekerjasama di komputer yang sama
untuk menyelesaikan sebuah unit. Dengan melakukan ini maka keduanya selalu
dapat berdiskusi dan saling melakukan koreksi apabila ada kesalahan dalam
penulisan program. Aspek ini mungkin akan sulit dijalankan oleh para
programer yang memiliki ego tinggi dan sering tidak nyaman untuk berbagi
komputer bersama rekannnya.
8. Collective Ownership
Tidak ada satupun baris kode program yang hanya dipahami oleh satu orang
programer. XP menuntut para programer untuk berbagi pengetahuan untuk tiap
baris program bahkan beserta hak untuk mengubahnya. Dengan pemahaman
yang sama terhadap keseluruhan program, ketergantungan pada programer
tertentu ataupun berbagai hambatan akibat perbedaan gaya menulis program
dapat diperkecil. Pada level yang lebih tinggi bahkan dimungkinkan para
programer dapat bertukar unit yang dibangunnya.
9. Coding Standards
Pair programming dan collective ownership hanya akan dapat berjalan
dengan baik apabila para programer memiliki pemahaman yang sama terhadap
penulisan kode program. Dengan adanya coding standards yang telah disepakati
terlebih dahulu maka pemahaman terhadap program akan menjadi mudah untuk
semua programer dalam tim. Hal ini dapat diterapkan sebagai contoh pada
penamaan variabel dan penggunaan tipe data yang sama untuk tiap elemen
semua record atau array pada program.
10. Continous Integration
Melakukan build setiap hari kerja menjadi sebuah model yang disukai oleh
berbagai tim pengembang perangkat lunak. Hal ini terutama didorong oleh
keberhasilan penerapan sistem ini oleh Microsoft dan telah sering
dipublikasikan. Dengan melakukan build sesering mungkin berbagai kesalahan
pada program dapat dideteksi dan diperbaiki secepat mungkin. Apabila banyak
tim pengembang perangkat lunak meyakini bahwa build sekali sehari adalah
minimum maka pada XP hal tersebut adalah maksimum. Pada XP tim
disarankan untuk melakukan build sesering mungkin misalnya setiap 4 jam atau
bahkan lebih cepat lagi.
11. 40-hours Week
Beck berpendapat bekerja 8 jam sehari dan 5 hari seminggu adalah
maksimal untuk tiap programer. Lebih dari itu programer akan cenderung
membuat berbagai error pada baris-baris kode programnya karena kelelahan.
12. On-Site Customer
Sebuah pendekatan klasik, di mana XP menganjurkan bahwa ada anggota
dari klien yang terlibat pada proses pengembangan perangkat lunak. Yang lebih
penting lagi ia harus ada di tempat pemrogaman dan turut serta dalam proses
build dan test yang dilakukan. Apabila ada kesalahan dalam pengembangan
diharapkan klien dapat segera memberikan masukan untuk koreksinya.
2.6.3. Extreme Programming Software Development Process.
Gambar 2.14 XP Software Development Process(Pressman, 2005)
XP mencakup beberapa aturan dan praktek yang terdiri atas planning,
design, coding dan test(Pressman, 2005). Berikut penjelasan dari masing-masing
tahapan yang akan dilakukan pada pembuatan aplikasi ini,
1. Planning.
planning
Design
coding
testing release
Pada tahap ini perencanaan terhadap software yang diinginkan mengacu pada
user stories. User stories menggambarkan fitur dan fungsi yang dibutuhkan
terhadap software tersebut. Ketika semua user stories telah ditentukan, developer
akan menentukan lama pengerjaan untuk tiap-tiap user stories.
2. Desain.
Proses desain pada XP mengikuti prinsip KIS(Keep It Simple). Desain akan
berisikan semua implementasi dari stories tanpa ada pengurangan maupun
penambahan. Desain yang memiliki fungsi tambahan tidak disarankan.
XP menggunakan CRC(Class-Responsibility-Collaborator) cards untuk
mengidentifikasi dan mengorganisasikan kelas berorientasi objek yang berkaitan
dengan proses pengembangan software.
Jika terdapat kesulitan untuk melakukan desain terhadap stories, XP
menyarankan untuk membuat prototype dari desain tersebut. Hal tersebut disebut
sebagai spike solution, prototype nantinya akan diimplementasikan dan
dievaluasi.
XP menyarankan refactoring, sebuah teknik pengembangan yang juga teknik
desain. Fowler mendeskripsikan refactoring sebagai berikut:
“Refactoring adalah proses perubahan sebuah system software dengan satu
cara yang tidak merubah behaviour eksternal dari kode yang meningkatkan
struktur internal. Hal ini adalah cara untuk membersihkan kode dan
memodifikasi ataupun menyederhanakan desain internal yang meminimalisasi
peluang munculnya bug. Pada dasarnya, ketika melakukan refactor kita
meningkatkan desain dari kode setelah tertulis.”
Perubahan desain dapat terjadi walaupun sudah memasuki tahap
coding/implementasi. Hal tersebut dilakukan untuk mendapat desain yang baik
dan kode yang bersih.
3. Coding.
Pada tahap ini, proses pengembangan tidak langsung melakukan implementasi
terhadap desain yang telah dibuat. Pembuatan unit test untuk tiap-tiap stories yang
nantinya akan diimplementasikan. Saat unit test selesai dibuat, pengembang lebih
baik fokus terhadap apa yang akan diimplementasikan untuk melewati unit test.
Tahap ini akan mengacu pada desain sebelumnya. Karena pembuatan unit test
dilakukan terlebih dahulu. Maka implementasi desain sebaiknya dibuat untuk
melewati unit test yang dibuat.
4. Testing.
Tahap ini akan menggunakan unit test yang sebelumnya telah dibuat. Karena
pembuatan dari unit test adalah pendekatan utama dari XP. Unit test yang dibuat
sebaiknya diimplementasikan dengan penggunaan framework untuk otomatisasi.
Testing akan dilakukan dengan unit test yang sebelumnya telah dibuat. PyUnit
akan digunakan sebagai framework untuk melakukan testing terhadap aplikasi.
5. Release.
Tahap akhir setelah melewati semua test dan dinyatakan bebas dari bug dan
dapat diimplementasikan/digunakan oleh pengguna.
2.7. Studi Sejenis
Penelitian oleh Pramudita(2008) yang dilaksanakan di gedung Labtek VIII
Institut Teknologi Bandung (ITB) dan lab di gedung Pusat Antar Universitas (PAU)
ITB. Tujuan dari tugas akhir ini adalah memberikan Quality of Service (QoS)
dengan mengimplementasikan Differentiated Service (DiffServ) pada jaringan testbed,
mengukur dan menganalisis parameter-parameter kualitas layanan jaringan berbasis
DiffServ, serta mencari disiplin antrian yang mampu memberikan layanan paling
sesuai dengan kebutuhan kelas trafik Expedited Forwarding (EF) dan Assured
Forwarding (AF).
Hasil pengujian memperlihatkan bahwa DiffServ mampu mengklasifikasikan
trafik ke dalam kelas-kelas yang sesuai dan memberikan pelayanan yang berbeda di
antara kelas-kelas trafik tersebut. Implementasi masih menggunakan script dan bersifat
statis, dan disarankan pengklasifikasian dilakukan secara dinamis.
Penelitian lain oleh Marieska(2008) pada Wimax. IEEE Standard 802.16 tidak
mendefinisikan algoritma penjadwalan. Algoritma penjadwalan bukan bagian dari
standar sehingga perancang sistem Wimax dapat memilih algoritma yang paling cocok
untuk diterapkan di jaringannya. Gabungan beberapa jenis algoritma mungkin
menghasilkan nilai metrik yang lebih baik daripada satu jenis algoritma. Dan penerapan
bersifat statis dan terbatas pada simulator.
Penelitian tersebut melakukan penerapan pada jaringan lab sehingga masih
menggunakan klasifikasi statis dan harus dilakukan konfigurasi ulang jika ingin
diterapkan pada jaringan yang sebenarnya. Penulis akan menggunakan disiplin antrian
dan menerapkan secara dinamis pada jaringan. Sehingga konfigurasi untuk jaringan dapat
bersifat dinamis.
2.7.1. Perbandingan aplikasi berbasis tc
Penggunaan tc secara langsung menggunakan baris perintah dinilai sangat
menyulitkan bagi sebagian pengguna. Terdapat beberapa aplikasi yang
mengimplementasikan tc dengan lebih mudah diantaranya,
1. Traffik http://sourceforge.net/projects/traffik/
“A Linux Traffic Control Management Interface: build tc-style rules for
control network flows. Have support to set queue disciplines to interface
(root) or inside a class (leaf), create classes and classifiers.”
Antarmuka manajemen linux traffic control: membuat tc-style rules untuk
kendali aliran jaringan. Memiliki dukungan untuk menset queue disciplines
untuk interface(root) atau didalam class (leaf), classes dan classifiers.
Gambar 2.15 Traffik
Sudah mengimplementasikan beberapa qdisc, tapi masih belum memberikan
log untuk memonitor seberapa besar bandwidth yang dikonsumsi tiap-tiap
node.
2. Banjar http://sourceforge.net/projects/banjar/
“Web-based bandwidth management tools based on tc and iptables for internet
cafe or small to medium network administrators.” Bandwidth management
tools berbasis web pada tc dan iptables untuk warung internet atau
administrator jaringan skala kecil sampai sedang.
Gambar 2.16 Banjar
Memiliki pemisahan bandwidth IIX dan International, tapi belum memiliki
log untuk penggunaan bandwidth tiap-tiap node.
3. YABMAS http://sourceforge.net/projects/yabmas/
“Yet Another Bandwidth Management and Authentication System is a
small bash script which allows automated management of client bandwidth
allocation, and client authentication by MAC address through the use of
iptables and htb/tc scheduling.”
Yet Another Bandwidth Management and Authentication System adalah
bash script kecil yang mengizinkan manajemen otomatis dari alokasi
bandwidth klien dan otentikasi dengan MAC address melalui penggunaan
iptables dan htb/tc scheduling.
Sebuah skrip yang memudahkan penggunaan tc dengan htb qdisc. Masih
belum menerapkan penggunaan log yang memudahkan pengguna melihat
konsumsi bandwidth tiap node.
BAB III
METODOLOGI PENELITIAN
3.1. Alat dan Bahan
Bahan yang digunakan adalah paket data yang diterima. Untuk kemudian dialirkan ke
jaringan yang dibangun untuk tujuan penelitian ini.
Adapun peralatan yang digunakan dibagi dua, yaitu :
1. Perangkat Keras
•••• PC server(1 unit) dengan spesifikasi :
1. Operating System : Fedora Core 10.
2. 2 kartu interface .
•••• PC client(3 unit) dengan spesifikasi :
1. Operating System : Windows XP.
2. 1 kartu interface.
•••• Switch
2. Perangkat Lunak
•••• IPTABLES.
•••• TC.
•••• Linux Kernel 2.6.x.
•••• GTK.
•••• Python.
3.2. Metode Penelitian
3.2.1. Metode Pengumpulan Data
1. Studi Pustaka
Studi pustaka dilakukan untuk mendapatkan bahan dan data yang diperlukan
dalam melakukan penelitian ini. Sumber yang diambil berupa buku, jurnal, paper,
tesis dan disertasi yang banyak terdapat di internet. Pencarian penelitian sebelumnya
juga dilakukan untuk membandingkan dan mempelajari sehingga dapat diterapkan
pula pada penelitian ini.
3.2.2. Metode Pengembangan Perangkat Lunak
1. Extreme Programming
Extreme Programming(Pressman, 2005) adalah suatu pendekatan baru terhadap
model pengembangan perangkat lunak yang kontroversial berdasar pada model
iterative dan incremental. Langkah awal adalah tim pengembang menetapkan
beberapa fitur(stories) yang diinginkan klien untuk diimplementasikan pada produk.
Untuk tiap fitur tim memberitahukan kepada klien tentang lama pengerjaan dan
biayanya. Langkah ini berada pada bagian planning untuk analisis kebutuhan
perangkat lunak tersebut.
Gambar 3.1 Extreme Programming process(Pressman, 2005)
XP mencakup beberapa aturan dan praktek yang terdiri atas planning, design,
coding dan test(Pressman, 2005). Berikut penjelasan dari masing-masing tahapan
yang akan dilakukan pada pembuatan aplikasi ini,
1. Planning.
Pada tahap ini perencanaan terhadap software yang diinginkan mengacu pada
user stories. User stories menggambarkan fitur dan fungsi yang dibutuhkan
terhadap software tersebut. Ketika semua user stories telah ditentukan, developer
akan menentukan lama pengerjaan untuk tiap-tiap user stories.
Adapun beberapa fungsi dan kebutuhan dari aplikasi adalah sebagai berikut:
1. Aplikasi mampu generate parameter TC dan iptables yang dibutuhkan.
2. Aplikasi mampu generate parameter untuk TC dan iptables yang akan
dibutuhkan oleh aplikasi.
3. Aplikasi membuat laporan realtime untuk mengukur pemakaian
bandwidth.
planning
design
coding
testing release
2. Desain.
Proses desain pada XP mengikuti prinsip KIS(Keep It Simple). Desain akan
berisikan semua implementasi dari stories tanpa ada pengurangan maupun
penambahan. Desain yang memiliki fungsi tambahan tidak disarankan.
XP menggunakan CRC(Class-Responsibility-Collaborator) cards untuk
mengidentifikasi dan mengorganisasikan kelas berorientasi objek yang berkaitan
dengan proses pengembangan software.
Jika terdapat kesulitan untuk melakukan desain terhadap stories, XP
menyarankan untuk membuat prototype dari desain tersebut. Hal tersebut disebut
sebagai spike solution, prototype nantinya akan diimplementasikan dan
dievaluasi.
XP menyarankan refactoring, sebuah teknik pengembangan yang juga teknik
desain. Fowler mendeskripsikan refactoring sebagai berikut:
“Refactoring adalah proses perubahan sebuah system software dengan satu
cara yang tidak merubah behaviour eksternal dari kode yang meningkatkan
struktur internal. Hal ini adalah cara untuk membersihkan kode dan
memodifikasi ataupun menyederhanakan desain internal yang meminimalisasi
peluang munculnya bug. Pada dasarnya, ketika melakukan refactor kita
meningkatkan desain dari kode setelah tertulis.”
Perubahan desain dapat terjadi walaupun sudah memasuki tahap
coding/implementasi. Hal tersebut dilakukan untuk mendapat desain yang baik
dan kode yang bersih.
Pada desain, perancangan aplikasi akan terdiri dari beberapa bagian
diantaranya sebagai berikut :
1. Perancangan desain GUI dengan pembuatan prototype dengan
menggunakan GTK.
2. Desain input yang diperlukan.
3. Desain ouput yang diperlukan.
4. Perancangan class yang dibutuhkan dengan CRC.
5. Perancangan tampilan laporan penggunaan bandwidth.
3. Coding.
Pada tahap ini, proses pengembangan tidak langsung melakukan implementasi
terhadap desain yang telah dibuat. Pembuatan unit test untuk tiap-tiap stories yang
nantinya akan diimplementasikan. Saat unit test selesai dibuat, pengembang lebih
baik fokus terhadap apa yang akan diimplementasikan untuk melewati unit test.
Tahap ini akan mengacu pada desain sebelumnya. Karena pembuatan unit test
dilakukan terlebih dahulu. Maka implementasi desain sebaiknya dibuat untuk
melewati unit test yang dibuat. Aplikasi akan dibuat menggunakan python dan
GTK sebagai GUI.
4. Testing.
Tahap ini akan menggunakan unit test yang sebelumnya telah dibuat. Karena
pembuatan dari unit test adalah pendekatan utama dari XP. Unit test yang dibuat
sebaiknya diimplementasikan dengan penggunaan framework untuk otomatisasi.
Testing akan dilakukan dengan unit test yang sebelumnya telah dibuat. PyUnit
akan digunakan sebagai framework untuk melakukan testing terhadap aplikasi.
5. Release.
Tahap ini setelah semua test dilakukan dan dinyatakan bebas bug dan siap
diimplementasikan/digunakan oleh pengguna.
METODE EXTREME PROGRAMMING
Analisis Kebutuhan
Perumusan Masalah
Pemilihan judul penelitian
Studi Pustaka
Planning
Desain
Testing
Aplikasi mampu generate parameter TC dan
iptables yang dibutuhkan.
Aplikasi mampu generate parameter untuk TC
dan iptables.
Perancangan desain GUI dengan pembuatan
prototype dengan menggunakan GTK.
Desain Input
Desain Output
Coding
Perancangan class yang dibutuhkan dengan CRC.
Pembuatan Unit Test.
Release Penarikan Kesimpulan dari sistem
Perancangan tampilan laporan penggunaan bandwidth.
Aplikasi membuat laporan realtime untuk
mengukur pemakaian bandwidth.
Pengujian
Tahap Pemograman
BlackBox Testing
Unit Testing
Pengujian QoS
Gambar 3.2 Ilustrasi Metodologi Penelitian Perancangan Aplikasi
Bandwidth Management dengan TC.
BAB IV
PEMBAHASAN
4.1. Planning
Tahap ini penulis melakukan analisis terhadap user stories(kebutuhan) terhadap
aplikasi yang akan dibuat. Karena framework yang dapat berkomunikasi dengan traffic
control di modul kernel linux adalah tc. Maka penulis akan menggunakan tc sebagai
jembatan penghubung antar aplikasi bantu yang penulis buat dengan queueing discipline
yang digunakan.
TC bukan sebuah API yang dapat diakses langsung dengan memanggil dari kode
program. Untuk itu diperlukan pemanggilan langsung terhadap tool tersebut dan
melakukan parsing terhadap outputnya. TC dapat langsung digunakan sebagai tools untuk
mengatur lalu lintas jaringan. Pengaturan untuk tiap-tiap queueing discipline memiliki
syntax yang berbeda.
4.1.1. Analisis penggunaan bandwidth.
Protokol ip yang digunakan router menggunakan disiplin antrian First In First Out
(FIFO) yang bersifat best effort service. Router akan melewatkan paket data dengan
waktu yang bervariasi sesuai dengan beban trafik yang ada. Hal tersebut dapat
memberikan kongesti pada jaringan dan tidak adanya pembedaan tiap paket data yang
lewat. Sehingga tiap node tidak mendapatkan QoS yang sesuai. Berikut hasil pengujian
menggunakan disiplin antrian FIFO,
Tabel 4.1 Pengukuran kecepatan tanpa bandwidth management
Percobaan ke- Node 1 Node 2
Upload Download Upload Download
1 85 kbps 255 kbps 34 kbps 127 kbps
2 80 kbps 244 kbps 39 kbps 185 kbps
Koneksi internet pada tiap isp memiliki jalur masing-masing, sehingga langsung
menuju jaringan global. Hal ini berdampak pada kecepatan yang sama ketika kita
mengakses konten lokal, karena untuk mengaksesnya kita harus berputar ke jaringan luar
negeri dulu. APJII membentuk IIX untuk mengatasi masalah tersebut. IIX adalah jaringan
interkoneksi nasional dengan menggabungkan semua ISP yang ada di Indonesia. Dengan
begitu jumlah hop antar router akan berkurang dan memberikan throughput yang lebih
baik. Berikut pengujian dengan server yang berada pada jaringan IIX,
Tabel 4.2 Pengukuran kecepatan untuk jaringan IIX
Percobaan ke- Node 1 Node 2
Upload Download Upload Download
1 88 kbps 768 kbps 66 kbps 721 kbps
2 87 kbps 754 kbps 64 kbps 701 kbps
Dari hasil pengujian di atas terlihat belum adanya klasifikasi tiap paket, sehingga
terdapat ketimpangan throughput antar node. Terlihat satu node mengkonsumsi
bandwidth jaringan lebih banyak dari node yang lain. Untuk itu diperlukan klasifikasi
berdasarkan node yang terhubung dengan jaringan serta berdasarkan paket tcp ataupun
udp. Pembedaan kecepatan juga dilakukan untuk paket data yang dikirim ke atau dari
jaringan IIX ataupun internasional.
4.1.2. Aplikasi mampu generate parameter TC dan iptables yang dibutuhkan.
1. HTB
HTB yang bersifat classful qdisc, memiliki pengaturan tc yang lebih banyak
dibanding classless. Pada HTB tidak hanya mengatur qdisc tapi juga bisa dibuat child
dari qdisc yang ada, dengan begitu kita dapat melakukan pengaturan yang lebih luas
lagi. Terdapat beberapa pengaturan yang wajib pada classful qdisc pada kasus ini
HTB.
1. pengaturan qdisc
#tc qdisc add dev eth1 root handle 1: htb default 9999
#tc qdisc add dev eth1 parent 1:2 handle 21: pfifo limit 10
pada pengaturan qdisc dapat dilihat syntax baku sebagai berikut,
#tc qdisc [add|del] dev device_name [root|parent
CLASSID|handle QHANDLE] [QDISC_KIND]
Berikut penjelasan dari tiap pengaturan yang diperlukan :
2. opsi add adalah untuk menambahkan qdisc pada device network
tertentu dan del untuk menghapusnya.
3. opsi device_name untuk pengaturan network device yang akan diatur.
4. opsi root untuk pengaturan qdisc induk.
5. opsi parent adalah classid dari parent qdisc.
6. opsi handle adalah qdiscid untuk qdisc tersebut.
7. opsi QDISC_KIND adalah jenis qdisc yang ingin digunakan.
2. pengaturan class
#tc class add dev eth1 parent 1:0 classid 1:1 htb rate
1Mbit ceil 2Mbit
#tc class add dev eth1 parent 1:1 classid 1:2 htb rate
64Kbit ceil 256Kbit
pada pengaturan class dapat dilihat syntax baku sebagai berikut,
#tc class [add|del] dev device_name [root|parent CLASSID]
[classid CLASSID] QDISCKIND rate n ceil n
Berikut penjelasan dari pengaturan yang diperlukan :
a) Opsi add adalah untuk menambahkan class dan del untuk
menghapusnya.
b) Opsi device_name adalah network device yang akan diberikan class.
c) Opsi root untuk pengaturan class induk.
d) Opsi parent adalah classid induk dari class tersebut.
e) Opsi CLASSID adalah classid yang digunakan sebagai id class
tersebut.
f) Opsi QDISCKIND adalah qdisc yang digunakan pada class tersebut.
g) Opsi rate adalah kecepatan normal class tersebut.
h) Opsi ceil adalah kecepatan maksimum class tersebut.
3. pengaturan filter
#tc filter add dev eth1 parent 1:0 protocol ip u32 match ip
dst 192.168.0.12/32 flowid 1:2
untuk pengaturan filter berikut syntax baku :
#tc filter [add|del] dev device_name [parent CLASSID]
protocol proto [u32 match selector|fw classid CLASSID]
[root|handle handleid|flowid FLOWID]
penjelasan dari pengaturan yang diperlukan :
a) opsi add digunakan untuk menambah filter dan del untuk menghapus
filter.
b) Opsi device_name adalah network device yang ditambah filter.
c) Opsi parent adalah parent yang memiliki qdisc root dari device_name.
d) Opsi protocol untuk menentukan filter pada protocol yang diinginkan.
e) Opsi u32 ataupun fw adalah untuk mencocokan paket data yang ingin
difilter.
f) Opsi handle maupun flowid untuk mencocokkan classid yang akan
difilter.
Dari beberapa pengaturan sebelumnya akan didapat konfigurasi yang
digambarkan sebagai berikut :
Gambar 4.3 HTB tree bandwidth management
Untuk penambahan tiap node yang akan ditambahkan pada tree tersebut. Cukup
ditambahkan pada level 0 dan level 1 saja, dengan penambahan id yang sesuai dengan
ketentuan. Node sebelah di kiri digunakan untuk klasifikasi paket data dari dan ke
jaringan IIX dan sebelah kanan untuk jaringan internasional. Tiap-tiap node nantinya
Class main link
Classid 1:1
Class IIX
Classid 1:2
Class Internasional
Classid 1:3
Class IIX node
Classid 1:n2
Class Intl Node
Classid 1:n3
Class tcp node
Classid 1:n2*2
Class udp
Classid 1:n2*2+1
Qdisc Leaf
RED Qdisc
Handleid n2*2:
Qdisc Leaf
RED Qdisc
Handleid n2*2+1:
Level
0
1
2
3
akan diklasifikasikan lagi paket data pada transport layer yaitu apakah paket tersebut
TCP atau UDP.
Classid 1:1 digunakan untuk menghandle maksimum bandwidth yang ada. Classid
1:2 digunakan untuk menghandle maksimum bandwidth untuk koneksi IIX. Classid
1:3 digunakan untuk menghandle maksimum bandwidth untuk koneksi internasional.
Dan child dari node IIX dan Internasional akan digunakan untuk menghandle tiap
node dalam jaringan. Classid child akan berupa 1:n2 untuk paket data IIX dan 1:n3
untuk paket data Internasional, dimana n adalah bilangan bulat. Tiap node akan
memiliki leaf class yang membedakan paket TCP dan UDP. Tiap-tiap node class
yang menghandle tiap node pada jaringan akan bertambah secara dinamis sesuai
kebutuhan user, dan child classnya akan mengikuti.
Berikut potongan kode untuk generate class seperti gambar 4.3 di atas,
# tc qdisc add dev DEVICE root htb default 8888
# tc class add dev DEVICE parent 1:0 classid 1:1 htb rate RATE
ceil MAXRATE
# tc class add dev DEVICE parent 1:1 classid 1:2 htb rate RATE
ceil MAXRATE
# tc filter add dev DEVICE parent 1:0 handle 6666 fw classid 1:2
# tc class add dev DEVICE parent 1:1 classid 1:3 htb rate RATE
ceil MAXRATE
# tc filter add dev DEVICE parent 1:0 handle 9999 fw classid 1:3
# bagian ini akan digenerate oleh aplikasi secara dinamis sesuai
kebutuhan pengguna.
# tc class add dev DEVICE parent 1:2 classid 1:N2 htb rate RATE
ceil MAXRATE
# tc filter add dev DEVICE parent 1:0 protocol ip u32 match ip dst
IP flowid 1:N2
# tc class add dev DEVICE parent 1:3 classid 1:N3 htb rate RATE
ceil MAXRATE
# tc filter add dev DEVICE parent 1:0 protocol ip u32 match ip dst
IP flowid 1:N3
# tc class add dev DEVICE parent 1:N2 classid 1:N2*2 htb rate RATE
ceil MAXRATE
# tc filter add dev DEVICE parent 1:N2 u32 match ip protocol 6
0xff flowid 1:N2*2
# tc class add dev DEVICE parent 1:N2 classid 1:N2*2+1 htb rate
RATE ceil MAXRATE
# tc filter add dev DEVICE parent 1:N2 u32 match ip protocol 17
0xff flowid 1:N2*2+1
# tc class add dev DEVICE parent 1:N3 classid 1:N3*2 htb rate RATE
ceil MAXRATE
# tc filter add dev DEVICE parent 1:N3 u32 match ip protocol 6
0xff flowid 1:N3*2
# tc class add dev DEVICE parent 1:N3 classid 1:N3*2+1 htb rate
RATE ceil MAXRATE
# tc filter add dev DEVICE parent 1:N3 u32 match ip protocol 17
0xff flowid 1:N3*2+1
2. RED
Pengaturan RED lebih singkat dibanding pengaturan HTB. Hal ini dikarenakan
RED yang bersifat classless. Pengaturan RED hanya memerlukan beberapa
parameter, diantaranya :
a) limit rate, batasan kecepatan yang diizinkan.
b) min rate, batasan minimum kecepatan yang diizinkan.
c) max rate, batasan maksimum kecepatan yang diizinkan. Ketika melewati
paket akan didrop.
d) burst rate
e) probability, kemungkinan paket yang akan didrop. Direkomendasikan
20% - 30%.
f) Avpkt, average packet yang direkomendasikan diset 1000.
Adapun bentuk syntax dari RED yang diset dari TC adalah sebagai berikut:
#tc qdisc add dev DEV root red limit LIMIT min MIN max MAX
burst BURST avpkt 1000 probability PROP
Nilai yang diset pada RED haruslah dalam satuan Byte bukan bit. Maka
sebelumnya harus dikonversi ke dalam Byte. Berikut rumus untuk
mendapatkan beberapa parameter di atas.
Bandwidth : 64kbps = 8000KB/s
Latency : 0.5 s.
Max : Bandwidth * Latency = 8000 * 0.5 = 4000
Min : Max / 2 = 2000
Limit : 8 * Max = 8 * 4000 = 32000
Burst : (2 * min + max) / (3 * avpkt) = (2 * 2000 + 4000) / (3 * 1000) =
2.667
Jika kita gunakan parameter di atas, maka akan kita gunakan pada tc sebagai
berikut,
#tc qdisc add dev eth0 parent ID red limit 32000 min 2000 max
4000 burst 2.667 avpkt 1000 probability 0.02
Aplikasi nantinya akan meminta input berupa bandwidth dan latency yang
dimiliki. Dan akan langsung mengenerate parameter lain, untuk kemudian
menjalankan tc dengan parameter ada.
3. Iptables
Aplikasi ini dibutuhkan untuk melakukan filtering terhadap tiap paket data
yang datang maupun dikirim dari router. Filter akan lebih spesifik untuk mencari
dan menandai paket data mana yang datang maupun dikirim ke jaringan IIX
ataupun Internasional. Karna nantinya kedua paket data tersebut akan
diperlakukan berbeda.
Berikut potongan kode untuk melakukan filtering terhadap paket data yang
datang dari IIX dan untuk dari Internasional akan ditandai bila tidak termasuk
paket tersebut,
# clear iptables
#$IPTABLES = perintah iptables
#$DEV_UPLINK = device yang menghadap jaringan internet
#$DEV_DOWNLINK = device yang menghadap jaringan lokal
$IPTABLES -t mangle -F
$IPTABLES -t filter -F
$IPTABLES -t nat –F
$IPTABLES -t mangle -X
$IPTABLES -t mangle -N IIX
# bagian ini akan diulang dan ditambahkan ip dari server yang
terhubung dengan IIX
$IPTABLES -t mangle -A IIX -i $DEV_UPLINK -p ! icmp -s
167.205.0.0/16 -j CONNMARK --set-mark 103
$IPTABLES -t mangle -A IIX -i $DEV_UPLINK -p ! icmp -s
167.205.0.0/16 -j RETURN
$IPTABLES -t mangle -A IIX -i $DEV_DOWNLINK -p ! icmp -d
167.205.0.0/16 -j CONNMARK --set-mark 103
$IPTABLES -t mangle -A IIX -i $DEV_DOWNLINK -p ! icmp -d
167.205.0.0/16 -j RETURN
#bagian ini akan menangani sisa paket data yang tidak cocok pada
rules sebelumnya dan ditentukan sebagai paket data dari jaringan
internasional
$IPTABLES -t mangle -N INTL
$IPTABLES -t mangle -A INTL -i $DEV_UPLINK -p ! icmp -s 0.0.0.0/0
-j CONNMARK --set-mark 104
$IPTABLES -t mangle -A INTL -i $DEV_UPLINK -p ! icmp -s 0.0.0.0/0
-j RETURN
$IPTABLES -t mangle -A INTL -i $DEV_DOWNLINK -p ! icmp -d
0.0.0.0/0 -j CONNMARK --set-mark 104
$IPTABLES -t mangle -A INTL -i $DEV_DOWNLINK -p ! icmp -d
0.0.0.0/0 -j RETURN
$IPTABLES -t mangle -A PREROUTING -j IIX
$IPTABLES -t mangle -A PREROUTING -j INTL
4.1.3. Aplikasi mampu generate parameter untuk TC dan Iptables.
Terlihat dari analisis kebutuhan parameter TC sebelumnya. Terdapat beberapa parameter
untuk TC yang dibutuhkan. Beberapa di antaranya adalah :
a) Network device yang akan digunakan.
b) Kecepatan maksimum untuk tiap network device yang digunakan.
c) Beberapa parameter untuk HTB
1) classid untuk tiap node. Node qdisc root dengan handle 1:0, node parent class
dengan classid 1:1. Node IIX dengan 1:2, node internasional dengan classid
1:3. child class IIX akan menggunakan classid 1:n2 dan internasional dengan
classid 1:n3, untuk n adalah bilangan bulat. Untuk qdisc child class tersebut
akan mengikuti classid dengan handle n2: untuk IIX dan n3 untuk
Internasional, untuk n adalah bilangan bulat
2) Maksimum rate untuk parent class.
3) Rate untuk tiap class node yang tidak melebihi parent class.
d) Bandwidth dan latency yang dimiliki oleh network device yang menggunakan
RED.
e) Ip yang digunakan oleh tiap network interface yang digunakan untuk routing oleh
iptables
f) Daftar ip host yang terhubung jaringan IIX untuk penanda paket data yang dikirim
ataupun diterima.
4.1.4. Konfigurasi yang dibutuhkan sebagai gateway server.
Konfigurasi yang dibutuhkan hanya melakukan setting terhadap iptables. Iptables
nantinya akan membuat setiap paket data yang masuk ke dalam server untuk
diteruskan ke internet. Proses yang dapat dilakukan berupa SNAT maupun
Masquerade.
Aplikasi nantinya akan mengenerate syntax iptables sesuai keinginan dan
langsung mengeksekusinya. Berikut adalah contoh syntax yang dibutuhkan untuk
SNAT dan masquerade.
SNAT
$IPTABLES -t nat -A POSTROUTING -o DEV -j SNAT –to-source
IPPUBLIC
Masquerade
$IPTABLES -t nat -A POSTROUTING -o DEV -j MASQUERADE
Untuk penggunaan SNAT diperlukan input berupa ip public nantinya digunakan
untuk merubah ip private yang digunakan dalam LAN. Sedangkan penggunaan
Masquerade tidak memerlukan input, karena akan langsung merubah ke ip public
yang ada.
4.1.5. Aplikasi membuat laporan realtime untuk pengukur pemakaian
bandwidth.
Pada TC terdapat opsi untuk melihat rate yang terjadi untuk setiap class. Tapi
terdapat kekurangan pada penggunaanya. Tidak adanya log ataupun laporan yang
bersifat realtime. Untuk mendapatkan kecepatan yang diberikan untuk tiap class,
cukup dengan perintah berikut :
#tc -s -d class show dev DEV
Perintah tersebut akan memberikan output berupa laporan untuk semua class
yang ada, berikut salah satu contoh laporan yang akan muncul:
class htb 1:10 parent 1:1 leaf 101: prio 0 quantum 1000 rate
64000bit ceil 64000bit burst 1599b/8 mpu 0b overhead 0b cburst
1599b/8 mpu 0b overhead 0b level 0
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: 195312 ctokens: 195312
Output yang muncul terdiri dari banyak parameter, beberapa di antaranya
adalah kecepatan minimum dan maksimum. Nilai 1:10 adalah classid yang
dimaksud dan parent adalah parent class dari class tersebut. Untuk melihat
kecepatan yang sedang berjalan, parameter rate akan memberikan nilai berupa
kecepatan aktual pada saat perintah ini dieksekusi. Kekurangan inilah yang
nantinya akan dibuat log berupa diagram garis yang akan update tiap detik dan
memberikan fungsi pelaporan terhadap user mengenai kecepatan aktual yang
dimiliki suatu class saat itu.
Aplikasi nantinya akan mencocokan classid yang ada dengan hasil output
perintah sebelumnya. Setelah itu langsung ditampilkan dan nilai kecepatan
sebelumnya akan disimpan dan dari sini akan terlihat fungsi log untuk kecepatan
tiap waktu.
4.1.6. User Stories
Dari hasil analisis user stories sebelumnya dapat disimpulkan bahwa terdapat
beberapa user stories yang dapat dibagi, di antaranya :
1. Konfigurasi qdisc HTB dan RED dengan TC
2. Aplikasi mampu konfigurasi Iptables untuk marking dan routing.
3. Penggunaan TC untuk mengambil data kecepatan tiap node.
4. Penggunaan TC untuk setting qdisc sebelumnya.
4.2. Design
4.2.1 Class Design
Proses desain akan dilakukan menggunakan Class Responsibilities, and
Collaboration (CRC) Card. Penggunaan CRC card untuk mengarahkan berpikir
secara objek dibanding secara prosedural. Tiap-tiap CRC card akan
merepresentasikan tiap objek yang dibutuhkan. Proses desain di sini akan lebih fokus
pada bagaimana tiap objek saling berinteraksi bukan bagaimana membuat objek
tersebut.
Dari user stories pada tahap planning, penulis membuat beberapa class yaitu :
1. HTB, digunakan untuk mengenerate TC statement.
2. RED, digunakan untuk mengenerate TC statement.
3. TC, digunakan untuk mengeksekusi TC statement yang sebelumnya dibuat
oleh class lain.
4. BWGUI, digunakan untuk menangani GUI dari aplikasi.
5. Client, digunakan untuk menangani informasi tiap klien.
6. BandwidthConsumption, digunakan untuk menangani penggunaan bandwidth
tiap client.
HTB
RED
TC
Client
Generate tc statement untuk
root qdisc.
Generate tc statement untuk
tambah/edit/hapus client.
BWGUI
TC
HTB
RED
Client
BandwidthConsumtpion
Generate tc statement sesuai
dengan algoritma RED yang
sudah ditetapkan.
Generate tc statement untuk
edit dan hapus RED qdisc.
Eksekusi statement untuk TC.
Parsing output untuk
kecepatan aktual tiap-tiap
class.
Client
Menangani GUI untuk
aplikasi.
Setting TC dengan tampilan
grafis.
Memberikan laporan
penggunaan bandwidth tiap
client dengan plot.
Gambar 4.4 Class HTB
Gambar 4.5 Class RED
Gambar 4.6 Class TC
Gambar 4.7 Class BWGUI
Class BWGUI akan menggunakan class HTB, RED dan TC. Karena class
BWGUI yang nantinya akan menangani input dan output dari pengguna. Karena
Client
BandwidthConsumption
TC
Client
Menangani informasi tiap
client, di antaranya:
- IP address
- Rate
Parsing kecepatan aktual tiap
kelas dari TC.
Menyimpan kecepatan tiap
class untuk ditampilkan pada
plot.
HTB
RED
TC
Client
BandwidthConsumption
Gambar 4.8 Class Client
Gambar 4.9 Class BandwidthConsumption
Gambar 4.10 Desain Class
BWGUI
input berupa nilai bandwidth rate dan informasi client. Maka class BWGUI
memerlukan class tersebut. Class HTB menggunakan class client untuk menampung
informasi client berupa IP, bandwidth rate dan lainnya. Class TC hanya
berkomunikasi dengan BWGUI dan BandwidthConsumption. Karena
BandwidthConsumption memerlukan class TC untuk mengambil bandwidth rate dari
tiap class dan melakukan parsing terhadap outputnya.
4.2.2 GUI design
Gambar 4.11 Layout BWTC tab Gateway
Layout untuk GUI memiliki beberapa widget, di antaranya menu, plot, tab, dan
beberapa textbox dan button. Untuk tampilan awal dari aplikasi, terlihat dari gambar
4.11 Terdapat tab gateway yang aktif, di dalamnya memiliki 2 group frame.
Sebelah kiri adalah NAT settings yang berguna untuk mengeset PC sebagai
gateway atau hanya melewatkan paket. Dan terdapat 2 textbox untuk setting network
interface yang digunakan untuk terhubung ke internet dan jaringan local.
Sebelah kanan adalah Max Upload & Download Rate yang digunakan untuk
mengatur kecepatan maksimum upload dan download yang dimiliki. Terdapat 2
Textbox, satu untuk mengatur upload dan untuk mengatur download. Satuan yang
digunakan dalam textbox tersebut adalah kbps.
Gambar 4.12 Layout BWTC tab Download Rate
Pada tab selanjutnya atau tab Download Rate, terdapat beberapa tombol dan table.
Tombol Add Client berfungsi menambah informasi klien dan mengatur kecepatan
klien tersebut. Tombol Edit Client berfungsi mengubah informasi klien yang sudah
masuk. Tombol Delete Client berfungsi menghapus klien dari table dan melepas
pengaturan kecepatan.
Fungsi dari table di bawahnya adalah untuk menampilkan klien yang telah
ditambah. Informasi klien ditampilkan pada table tersebut. Dan ketika dipilih akan
menampilkan log berupa plot di bagian atas.
Gambar 4.12 Layout BWTC tab Upload Rate
Pada Tab ini terdapat sebuah group frame Upload Settings yang berisi textbox
untuk upload limit, probability dan latency. Tidak seperti download rate, pada tab
upload rate tidak bergantung pada berapa klien karena menggunakan RED yang tidak
memiliki fungsi classifier. Proses nantinya akan mengenerate RED ke dalam network
interface yang sebelumnya disetting sebagai inet interface.
Gambar 4.13 Layout BWTC dialogbox Client.
Pada tab Download Rate, terdapat button Add Client dan Edit Client. Aksi dari
kedua button tersebut akan memunculkan dialogbox seperti di atas. Dialogbox akan
muncul untuk meminta informasi terkait klien yang ingin diatur kecepatan
downloadnya.
Gambar 4.14 Layout BWTC menu File.
Menu file digunakan untuk membuat setting baru ataupun mengambil setting
yang sudah ada dan menyimpannya ketika ada perubahan.
Gambar 4.15 Layout BWTC menu Help
Menu help hanya memberikan dialogbox about dan penggunaan dari aplikasi ini.
Gambar 4.16 Layout BWTC plot log rate.
Plot akan muncul ketika pengguna memilih salah satu klien yang ada dalam table.
Ketika terpilih plot akan memunculkan diagram garis untuk menunjukkan
penggunaan bandwidth dari klien tersebut. Plot akan terupdate tiap 1 detik dan
memberikan log realtime kepada pengguna.
4.3. Coding
Setelah desain selesai, masuk ke tahap coding. Tahap ini tidak langsung membuat
code dari tiap objek dari hasil desain sebelumnya. Pembuatan Unit Test untuk menguji
tiap class didahulukan. Contoh Unit Test yang akan dibuat adalah sebagai berikut :
import unittest
from modules.RED import RED
def test_qdisc(self):
red = RED()
self.assertEqual(red.qdisc, 'root red')
def test_red(self):
red = RED()
self.assertEqual(red.setRed(128000),'/sbin/tc qdisc add dev
eth0 root red limit 64000 min 4000 max 8000 burst 5 avpkt 1000
probability 0.02 bandwidth 128')
if __name__ == '__main__':
unittest.main()
Terlihat pengujian terhadap class RED dilakukan untuk menguji attribute qdisc
dan fungsi setRed. Penggunaan fungsi assert equal digunakan untuk membandingkan
antara hasil output dan nilai seharusnya yang keluar. Pengujian dilakukan untuk
semua class yang ada. Setelah beberapa unit test dibuat, implementasi dari desain bisa
dilakukan. Tahap penulisan kode dimaksimalkan untuk lolos dari unit test. Hal ini
berguna untuk mencegah dari adanya bug pada kode yang ditulis. Berikut contoh
kode untuk RED :
class RED():
def __init__(self, dev = 'eth0', bandwidth=384000):
self.bandwidth = bandwidth # bps
self.maxupload = bandwidth / 8 # Byte
self.limit = 0
self.min = 0
self.max = 0
self.burst = 0
self.latency = 0.5 # detik
self.avpkt = 1000 # 1000 nilai default dari red
self.probability = 0.02 # probabilitas untuk mark dan drop
20%
self.tc = '/sbin/tc'
self.command = 'qdisc add'
self.dev = dev
self.qdisc = 'root red'
self.space = ' '
def setRed(self, bandwidth, probability=0.02, latency=0.5):
try:
self.latency = latency
self.probability = probability
self.bandwidth = bandwidth
self.maxupload = bandwidth / 8
self.max = self.maxupload * self.latency
self.min = self.max / 2
self.limit = self.max * 8
self.burst = (2 * self.min + self.max) / (3 *
self.avpkt)
self.burst = self.burst
val = self.addQdisc()
return val
except:
print 'bad value'
def getRED(self):
return self.setRed(self.bandwidth)
def addQdisc(self):
perintah = self.tc + self.space
perintah += self.command + self.space
perintah += 'dev ' + self.dev + self.space
perintah += self.qdisc + self.space
perintah += 'limit' + self.space + str(int(self.limit)) +
self.space
perintah += 'min' + self.space + str(int(self.min)) +
self.space
perintah += 'max' + self.space + str(int(self.max)) +
self.space
perintah += 'burst' + self.space + str(self.burst) +
self.space
perintah += 'avpkt' + self.space + str(self.avpkt) +
self.space
perintah += 'probability' + self.space +
str(self.probability) + self.space
perintah += 'bandwidth' + self.space +
str(self.bandwidth/1000)
return perintah
def delRED(self):
return '/sbin/tc qdisc del dev ' + self.dev + ' root'
Setelah kode ditulis, langsung dilakukan pengetesan dengan test case yang
sebelumnya dibuat. Berikut hasil dari eksekusi unit test tersebut :
..F.
=================================================================
=====
FAIL: test_red (__main__.TestRED)
-----------------------------------------------------------------
-----
Traceback (most recent call last):
File "test.py", line 28, in test_red
self.assertEqual(red.setRed(128000),'/sbin/tc qdisc add dev
eth0 root red limit 64000 min 4000 max 8000 burst 5 avpkt 1000
probability 0.02 bandwidth 128')
AssertionError: '/sbin/tc qdisc add dev eth0 root red limit 64000
min 4000 max 8000 burst 5.33333333333 avpkt 1000 probability 0.02
bandwidth 128' != '/sbin/tc qdisc add dev eth0 root red limit 64000
min 4000 max 8000 burst 5.33 avpkt 1000 probability 0.02 bandwidth
128'
-----------------------------------------------------------------
-----
Ran 4 tests in 0.000s
FAILED (failures=1)
Terlihat ada gagal pada unit test tersebut. Hal ini karena terdapat perbedaan antara
hasil output dan nilai yang seharusnya keluar. Terdapat perbedaan pada statement
burst yang seharusnya bernilai 5 tapi output dari fungsi yang diuji adalah
5.33333333333. Untuk itu perlu diperbaiki fungsi tersebut. Nilai burst yang
seharusnya bilangan bulat bukannya pecahan. Sehingga kode berikut self.burst =
self.burst dirubah menjadi self.burst = int(math.ceil(self.burst)).
Eksekusi kembali unit test sebelumnya dan didapat hasil berikut :
....
-----------------------------------------------------------------
-----
Ran 4 tests in 0.000s
OK
Proses perubahan kode secara terus menerus sampai didapat kode yang sederhana
dinamakan refactoring. Refactoring merupakan aspek penting pada metode Extreme
Programming. Karena detil kode untuk tiap class tidak dijelaskan, maka pada tahap
inilah penulisan kode akan melebihi desain dan terus mengembangkan desain
tersebut.
Lakukan terus perubahan dan pecahkan fungsi yang memiliki terlalu banyak baris
kode menjadi beberapa fungsi. Dengan begitu fungsi akan mudah dimengerti cara
kerjanya. Secara tidak langsung mengembangkan desain sederhana yang sebelumnya
dibuat tanpa merubah cara program berjalan.
4.4. Testing
Untuk menguji bug pada kode yang ditulis sebelumnya, unit test yang sebelumnya
telah dibuat dieksekusi. Lakukan refactoring terus menerus sampai bug hilang. Untuk
menguji fungsionalitas dari aplikasi digunakan BlackBox Testing.
4.4.1 Unit Testing
Setelah semua kode ditulis, lakukan eksekusi terhadap unit test yang telah dibuat.
Sebaiknya tambahkan lebih banyak test case untuk tiap unit case. Hal ini diperlukan
untuk mendeteksi bug yang kemungkinan muncul akibat proses refactoring
sebelumnya.
Setelah beberapa iterasi dihasilkan test case untuk beberapa fungsi. Berikut adalah
potongan test case yang akan diuji,
class TestRED(unittest.TestCase):
"RED tests"
def test_red(self):
red = RED('eth0', 128000)
self.assertEqual(red.getRED(),'/sbin/tc qdisc add dev eth0
root red limit 64000 min 4000 max 8000 burst 5 avpkt 1000
probability 0.02 bandwidth 128')
def test_DelRED(self):
red = RED()
self.assertEqual(red.delRED(), '/sbin/tc qdisc del dev eth0
root')
class TestHTB(unittest.TestCase):
"HTB tests"
def test_class(self):
classifier = Classifier('eth0', '1:1', '1:2', '64Kbit',
'1Mbit')
self.assertEqual(classifier.getClass(), '/sbin/tc class add
dev eth0 parent 1:1 classid 1:2 htb rate 64Kbit ceil 1Mbit')
class TestClient(unittest.TestCase):
"Client tests"
def test_client(self):
self.client = Client('Client 1','192.168.1.10', 64000,
64000, 512000, 128000,'00:FF:00:10:AF:89')
self.assertEqual(self.client.get_name(), 'Client 1')
self.assertEqual(self.client.get_ip(), '192.168.1.10')
self.assertEqual(self.client.get_dload(), 64000)
self.assertEqual(self.client.get_uload(), 64000)
self.assertEqual(self.client.get_dmax(), 512000)
self.assertEqual(self.client.get_umax(), 128000)
self.assertEqual(self.client.get_mac(),
'00:FF:00:10:AF:89')
class TestBandwidthConsumption(unittest.TestCase):
"BandwidthConsumption tests"
def test_BConsumption(self):
bc = BandwidthConsumption()
class TestTC(unittest.TestCase):
"TC tests"
def test_TC(self):
tc = TC()
Dan hasil yang didapat setelah mengeksekusi test case di atas adalah sebagai
berikut,
....
-----------------------------------------------------------------
-----
Ran 6 tests in 0.000s
OK
4.4.2 BlackBox Testing
Pada blackbox testing penulis mencoba melakukan tes terhadap semua
fungsionalitas dari aplikasi ini. Berikut beberapa hasil tes yang penulis lakukan
terhadap aplikasi dan hasilnya,
1. Pengujian Set firewall untuk fungsi SNAT atau Masquerade.
Gambar 4.17 pengujian firewall feature
Pengguna mengisi ip public yang digunakan yang nantinya akan digunakan
sebagai source NAT. Interface yang berhubungan dengan internet dan
jaringan lokal diatur di sini.
Gambar 4.18 cek firewall
Pengecekan apakah SNAT di iptables berhasil dieksekusi atau tidak. Hasilnya
menunjukkan berhasil memberikan satu rule untuk SNAT.
Gambar 4.19 pengujian masquerade
Berbeda dengan yang tadi, di sini dilakukan pengetesan untuk masquerade.
Perubahan SNAT secara dinamis dan pengaturan interface. Cara yang
dilakukan hampir sama dengan sebelumnya.
Gambar 4.20 cek masquerade
Terlihat pengaturan sebelumnya berhasil memberikan satu rule ke iptables
untuk melakukan masquerade.
2. Pengujian Set Max Download dan Max Upload rate.
Gambar 4.21 pengujian max download dan upload
Di sebelah kanan terdapat pengaturan untuk maksimum dan minimum upload
yang diijinkan. Pengaturan ini bergantung pada koneksi internet yang kita
miliki.
Gambar 4.22 cek tc max rate
Pengaturan untuk download berhasil dan menambah rule pada TC dengan
HTB qdisc.
Gambar 4.23 cek tc max rate
Pengaturan upload dengan RED qdisc juga berhasil dilakukan di sini.
3. Pengujian Tambah, Ubah dan Hapus Client.
Gambar 4.24 pengujian tambah node
Di sini dilakukan pengujian untuk menambah client yang ingin diatur alokasi
bandwidthnya.
Gambar 4.25 penambahan node
Gambar 4.26 cek tc leaf
Terlihat bertambah satu rule untuk client yang ditambah sebelumnya.
Gambar 4.27 pengubahan node
Client yang sebelumnya telah ditambah, dapat diubah parameternya.
Pengujian perubahan parameter dilakukan di sini.
Gambar 4.28 cek perubahan pada leaf
Perubahan parameter berhasil merubah rule pada tc yang ada.
Gambar 4.29 penghapusan node
Perintah hapus dilakukan di sini. Pengujian untuk menghapus rule client dari
table dan rule TC.
Gambar 4.30 cek penghapusan pada tc
Terlihat sudah terhapus rule dari client yang dihapus tersebut.
4. Pengujian Tampilkan plot untuk bandwidth rate tiap client.
Gambar 4.33 pengujian tampilan plot
Tabel 4.4 Pengujian black box
Fungsi Status
Set firewall untuk fungsi SNAT atau Masquerade OK
Set Max Download dan Max Upload rate OK
Tambah, Ubah dan Hapus Client OK
Set Upload Rate OK
Tampilkan plot untuk bandwidth rate tiap client OK
4.5. Release
Tahap ini aplikasi sudah dapat diimplementasikan, dan penulis melakukan
pengujian implementasi untuk membuktikan apakah aplikasi dapat memenuhi
fungsinya sebagai bandwidth limiting.
4.5.1 Implementation Test
Penulis akan melakukan implementation tes dengan beberapa node yang
berhubungan langsung dengan gateway. Berikut topologi jaringan yang digunakan :
Gambar 4.34 Topologi jaringan pengujian
Pengujian akan dilakukan dengan beberapa parameter, di antaranya:
1. Rate : 64kbps, max rate : 64kbps
2. Rate : 64kbps, max rate : 128kbps
3. Rate : 128kbps, max rate : 128kbps
4. Rate : 128kbps, max rate : 256kbps
Berikut hasil dari pengujian alokasi bandwidth untuk tiap node yang melewati
gateway:
1. Pengujian rate : 64kbps, max rate 64kbps
Gambar 4.35 Pengujian node download dan upload 64kbps
2. Pengujian rate : 64kbps, max rate 128kbps
Gambar 4.36 pengujian
node kecepatan 64kbps, kecepatan maksimum 128kbps.
3. Pengujian rate : 128kbps, max rate 128kbps
Gambar
4.37
Pengujian node kecepatan
128kbps, maksimum 128kbps.
4. Pengujian rate : 128kbps, max rate 256kbps
Gambar 4.38
Pengujian node
kecepatan 128kbps,
maksimum kecepatan 256kbps.
4.5.2 QoS Testing
Setelah pengujian aplikasi berjalan dengan baik dan sesuai dengan desain
sebelumnya. Pengujian lanjutan untuk menguji pengaturan QoS berjalan dengan baik
atau tidak. Pengujian akan dilakukan dengan 2 situs pengujian, yaitu speedtest.net
untuk menguji throughput dan pingtest.net untuk menguji delay, jitter dan packet
loss.
Pengujian pertama akan dilakukan dengan menggunakan disiplin antrian HTB
saja. Terdapat 3 node yang terhubung dengan gateway dan scenario pengujian
menggunakan server lokal dan internasional,
1. Tiap node diberi kecepatan download 128kbps, maksimum 128 kbps dan
upload 32 kbps maksimum 32kbps.
Tabel 4.5 Qos Testing 1, hasil Speedtest.net.
Koneksi Node 1 Node 2 Node 3
Upload Download Upload Download Upload Download
IIX 30 kbps 126 kbps 34 kbps 127 kbps 24 kbps 118 kbps
Internasional 28 kbps 131 kbps 39 kbps 125 kbps 29 kbps 117 kbps
Tabel 4.6 QoS Testing 1, hasil Pingtest.net
2.
iap
node
diberi
kecep
atan download 128kbps, maksimum 256kbps dan upload 32kbps
maksimum 64kbps.
Tabel 4.7 QoS Testing 2, hasil Speedtest.net
Koneksi Node 1 Node 2 Node 3
Upload Download Upload Download Upload Download
IIX 56 kbps 255 kbps 61 kbps 127 kbps 62 kbps 198 kbps
Internasional 48 kbps 244 kbps 48 kbps 185 kbps 58 kbps 211 kbps
Tabel 4.8 QoS Testing 2, hasil Pingtest.net
Node 1 Node 2 Node 3
Node 1 Node 2 Node 3
delay jitter Packet
loss
delay jitter Packet
loss
delay jitter Packet
loss
1 56 ms 10 ms 0 % 51 ms 9 ms 0 % 54 ms 11 ms 0 %
2 76 ms 15 ms 0 % 32ms 11 ms 0 % 66 ms 12 ms 0 %
delay jitter Packet
loss
delay jitter Packet
loss
delay jitter Packet
loss
1 35ms 13ms 0 % 33 ms 11 ms 0% 38ms 15ms 0%
2 33ms 12ms 0 % 38 ms 13 ms 0% 32ms 16ms 0%
3. Tiap node diberi kecepatan 256kbps, maksimum 256kbps dan upload 64
kbps maksimum 64kbps.
Tabel 4.9 QoS Testing 3, hasil Speedtest.net
Koneksi Node 1 Node 2 Node 3
Upload Download Upload Download Upload Download
IIX 75 kbps 255 kbps 52 kbps 262 kbps 60 kbps 278 kbps
Internasional 70 kbps 244 kbps 64 kbps 248 kbps 62 kbps 286 kbps
Tabel 4.10 QoS Testing 3, hasil Pingtest.net
Node 1 Node 2 Node 3
delay jitter Packet
loss
delay jitter Packet
loss
delay jitter Packet
loss
1 25 ms 8ms 0% 28 ms 6ms 0% 27 ms 8ms 0%
2 26 ms 9ms 0% 24 ms 5ms 0% 26 ms 9ms 0%
Pengujian pertama akan dilakukan dengan menggunakan disiplin antrian HTB
dan RED untuk leaf class. Terdapat 3 node yang terhubung dengan gateway dan
scenario pengujian menggunakan server lokal dan internasional,
1. Tiap node diberi kecepatan download 128kbps, maksimum 128 kbps dan
upload 32 kbps maksimum 32kbps
Tabel 4.11 QoS Testing 4, hasil Speedtest.net
Koneksi Node 1 Node 2 Node 3
Upload Download Upload Download Upload Download
IIX 32 kbps 127 kbps 34 kbps 127 kbps 32 kbps 128 kbps
Internasional 28 kbps 124 kbps 32 kbps 128 kbps 32 kbps 126 kbps
Tabel 4.12 QoS Testing 4, hasil Pingtest.net
Node 1 Node 2 Node 3
delay jitter Packet
loss
delay jitter Packet
loss
delay jitter Packet
loss
1 52ms 12ms 0% 65ms 16ms 0% 50ms 15ms 0%
2 77ms 14ms 1% 60ms 17ms 0% 49ms 14ms 0%
2. Tiap node diberi kecepatan download 128kbps, maksimum 256kbps dan
upload 32kbps maksimum 64kbps.
Tabel 4.13 QoS Testing 5, hasil Speedtest.net
Koneksi Node 1 Node 2 Node 3
Upload Download Upload Download Upload Download
IIX 65 kbps 226 kbps 64 kbps 228 kbps 62 kbps 232 kbps
Internasional 60 kbps 222 kbps 59 kbps 209 kbps 58 kbps 218 kbps
Tabel 4.14 QoS Testing 5, hasil Pingtest.net
Node 1 Node 2 Node 3
delay jitter Packet
loss
delay jitter Packet
loss
delay jitter Packet
loss
1 40ms 14ms 0% 38ms 14ms 0% 35ms 12ms 0%
2 38ms 13ms 0% 35ms 13ms 0% 40ms 15ms 0%
3. Tiap node diberi kecepatan 256kbps, maksimum 256kbps dan upload 64
kbps maksimum 64kbps.
Tabel 4.15 QoS Testing 6, hasil Speedtest.net
Koneksi Node 1 Node 2 Node 3
Upload Download Upload Download Upload Download
IIX 64 kbps 255 kbps 64 kbps 256 kbps 64 kbps 255 kbps
Internasional 62 kbps 254 kbps 60 kbps 252 kbps 62 kbps 256 kbps
Tabel 4.16 QoS Testing 6, hasil Pingtest.net
Node 1 Node 2 Node 3
delay jitter Packet
loss
delay jitter Packet
loss
delay jitter Packet
loss
1 22ms 1ms 0% 21ms 1ms 0% 24ms 3ms 0%
2 23ms 2ms 0% 21ms 1ms 0% 22ms 2ms 0%
4.6. Analisis pengujian
Implementation Test dan QoS Testing memberikan hasil yang sesuai dengan
fungsi dari HTB untuk memberikan jaminan alokasi bandwidth tiap kelas yang ada.
Secara default ketika kita tidak memberikan disiplin antrian pada kelas di HTB, disiplin
antrian pfifo akan digunakan pada kelas tersebut. Dengan begitu kapasitas jaringan yang
ada akan diperebutkan oleh masing-masing sub kelas. RED bertugas untuk menjatuhkan
paket data secara acak yang memiliki probabilitas tinggi dan berperan besar dalam
memberikan kongesti pada jaringan. Dampak yang diberikan adalah adanya penurunan
kecepatan. Hal ini dikarenakan sifat dari TCP yang akan memelankan laju pengiriman
datanya ketika terdapat paket data yang jatuh.
Terlihat dari percobaan pada situs speedtest.net(subbab 4.6.4), kecepatan yang
diperoleh tiap node bervariasi. Tiap node saling berebut jaringan dan memberikan
kecepatan yang cukup bervariasi. Sedangkan percobaan berikutnya yang menggunakan
disiplin antrian RED memiliki kecepatan yang hampir sama. Karena RED akan
menjatuhkan paket data secara aktif dan mencegah kongesti pada jaringan. Dampaknya
laju TCP tiap kelas akan menurun dan tidak saling berebut. Terlihat setelah penggunaan
RED, laju tiap node relatif stabil dan sama.
Hasil uji pingtest.net(subbab 4.6.4), tiap node memiliki nilai delay, jitter dan
packet loss yang cukup baik. Hal ini dapat dilihat dari hasil yang cukup untuk digunakan
oleh aplikasi seperti voice ataupun streaming.
BAB V
KESIMPULAN
5.1. Kesimpulan
Setelah melakukan pengetesan terhadap aplikasi yang telah dibuat dan menyelesaikan penelitian
ini. Dapat ditarik kesimpulan sebagai berikut:
1. Aplikasi DiffServ menggunakan TrafficControl dengan disiplin antrian HTB dan RED
dapat berperan untuk mengatur penggunaan bandwidth tiap node pada jaringan. Hasil
pengujian dapat dilihat di Implementation Test(subbab 4.5.1) dan QoS testing(subbab
4.5.2).
2. Aplikasi dapat membedakan asal paket dari jaringan IIX(lokal) atau internasional. Dan
memberikan batasan kecepatan yang sesuai untuk tiap koneksi. Hasil pengujian dapat
dilihat pada QoS testing(subbab 4.5.2).
3. Aplikasi dapat diterapkan pada router linux berbasis DiffServ. Karena bersifat open
source dan dapat dimodifikasi dan ditambah fungsionalitasnya.
4. Pengujian QoS dengan parameter uji delay, jitter dan packet loss memberikan hasil yang
baik. Terlihat dari hasil pengujian yang memberikan nilai pengujian dari parameter
tersebut relatif kecil bila dibandingkan dengan sebelumnya yang menggunakan disiplin
antrian FIFO atau default dari router. Hasil pengujian dapat dilihat pada QoS
Testing(subbab 4.5.2).
5.2. Saran
Berikut ini beberapa saran yang mungkin berguna untuk digunakan sebagai bahan pertimbangan
yang ingin melakukan penelitian atau aplikasi yang hampir sama,
1. Dimungkinkan untuk menerapkan semua queueing discipline yang ada. Sehingga
pengguna bebas memilih yang ingin digunakan.
2. Memberikan log berupa diagram garis yang lebih luas dan dimungkinkan untuk disimpan
dalam database untuk keperluan auditing di lain waktu.
3. Python sebagai scripting language dan menggunakan Extreme Programming sebagai
metode yang digunakan dapat mempercepat dan menyederhanakan proses pembuatan
aplikasi.
1
DAFTAR PUSTAKA
Almesberger, Werner. 2001. Differentiated Services on linux.
ftp://icaftp.epfl.ch/pub/linux/diffserv/misc/dsid-01.ps.gz
Beck, Kent. 2004. Extreme Programming Explained: Embrace Change, Second
Edition. Massachusetts: Addison Wesley Professional.
Blake, et. al. 1998. An Architecture for Differentiated Services. RFC 2475.
http://www.ietf.org/rfc/rfc2475
Braden, et. al. 1998. Recommendations on Queue Management and Congestion
Avoidance in the Internet. RFC 2309. http://www.ietf.org/rfc/rfc2309.txt
Braithwaite, Stephen. 2006. Implementation of AQMs on Linux made Easy. The
University of Southern Queensland.
http://eprints.usq.edu.au/2075/1/Braithwaite-6800-Queuing.pdf
Brown, Martin A. 2006. Traffic Control HOWTO. Version 1.0.2. http://linux-
ip.net/articles/Traffic-Control-HOWTO/. diakses pada hari ini.
C H, Swaroop. A Byte of Python. http://www.byteofpython.info.
Devera, Martin. 2002. HTB Linux queuing discipline manual - user guide.
http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm
Floyd, Sally dan Van Jacobson. 1993. Random Early Detection Gateways for
Congestion Avoidance. Lawrence Berkeley Laboratory University of
California. http://www.icir.org/floyd/papers/red/red.html
Floyd, et. al. 2001. Adaptive RED: An Algorithm for Increasing the Robustness
of RED’s Active Queue Management.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.78.7450&rep=rep1
&type=pdf
Floyd, Sally. Congestion Control Principles. RFC 2914.
http://www.ietf.org/rfc/rfc2914
Hubert , Bert. 2004. Linux Advanced Routing & Traffic Control HOWTO.
http://lartc.org/lartc.pdf
Li, Suqiao. 1999. Network Traffic Control and Bandwidth Management in
Internet: A Differentiated Services Case Study. McGill University.
2
http://digitool.library.mcgill.ca/R/?func=dbin-jump-
full&object_id=30688&local_base=GEN01-MCG02
Marieska, Mastura Diana. 2008. Analisis Algoritma Penjadwalan Berbasis
Quality of Service pada Wimax. http://digilib.itb.ac.id/
Nagle, John. 1984. Congestion Control in IP/TCP Internetworks. RFC 896.
http://tools.ietf.org/html/rfc896
Nichols, et. al. 1998. Definition of the Differentiated Services Field (DS Field)
in the IPv4 and IPv6 Headers. RFC 2474. http://www.ietf.org/rfc/rfc2474.txt
Pramudita, Damar Aji. 2008. Differentiated Service(DiffServ) di Jaringan
Testbed menggunakan Disiplin Antrian PRIORITY QUEUEING dan
HIERARCHY TOKEN BUCKET. http://digilib.itb.ac.id/
Python v2.6.1 Documentation. http://docs.python.org/
Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering,
Sixth Edition. New York: McGraw Hill.
Pressman, Roger S. 2005. Software Engineering: A Practitioner’s Approach,
Sixth Edition. New York: McGraw Hill.
Valenzuela, et. al. 2004. Hierarchical Token Bucket Algorithm to Enhance QoS
in IEEE 802.11: Proposal, Implementation dan Evaluation.
http://ieeexplore.ieee.org/iel5/9623/30413/01400539.pdf?arnumber=1400539
Welzl, Michael. 2005. Network congestion control : managing Internet traffic.
England:John Wiley & Sons Ltd.
Pengembangan Aplikasi DiffServ dengan Disiplin Antrian Hierarchy
Token Bucket dan Random Early Detection Sebagai Bandwidth
Limiting
Deni Zakya
Fakultas Sains dan Teknologi
Universitas Islam Negeri Syarif Hidayatullah Jakarta
Tel : (021) 823026 Fax : (021) 8624025
Email : denizakya@gmail.com
ABSTRACT
Growth of the Internet led to the cafe to use internet connection as a basic component of the business. Cafe manager
will use at least one Internet connection and share it with all the nodes are connected to the Internet. Number of
nodes that are connected to the router will cause the network conditions experienced congestion / density. So it looks
like there are one or more nodes that dominate network bandwidth usage. For that needed the concept of Quality of
Service (QoS), one way to apply QoS in IP networks with Differentiated Services (DiffServ). The author uses a
packet scheduling Hierarchy Token Bucket and Random Early Detection in this study. Classification will be based
on the connected node, protocol tcp or udp and IIX network (local) and international. International Classification of
IIX and taken because of the significant difference in speed from the second network. Analysis of quality of service
on the network is done by measuring the parameters of throughput, delay, jitter and packet loss. In the end, using the
DiffServ Implementation TrafficControl with RED queue discipline HTB and may act to regulate the use of
bandwidth for each node in the network. Applications can distinguish the origin of a network packet IIX (local) or
international. And provide the appropriate speed limit for each connection. Use of HTB and RED queues provide
good quality care without sacrificing throughput testing parameters, delay, jitter and packet loss that big. The author
uses Extreme Programming as a methodology of software development. Seen from the test results that provide value
testing of these parameters is relatively small compared with the use of best effort or just with FIFO queue
discipline.
Keywords: Bandwidth Limiting, TrafficControl, Hierarchy Token Bucket, Random Early Detection.
1. PENDAHULUAN
1.1. Latar Belakang
Penggunaan router pada jaringan
komputer warnet dapat
menghubungkan koneksi lokal warnet
dengan internet. Banyaknya node yang
terkoneksi ke router akan menyebabkan
kondisi jaringan mengalami
kongesti/kepadatan. Sehingga terlihat
seolah-olah ada satu atau lebih node
yang mendominasi penggunaan
bandwidth jaringan(Welzl, 2005). 1.2. Rumusan Masalah
Masalah yang dapat dirumuskan dalam tugas
akhir ini sebagai berikut :
1. Efisiensi penggunaan bandwidth tiap node
pada jaringan dengan memberikan alokasi
bandwidth sesuai kebutuhan.
2. Pemisahan alokasi bandwidth tiap node.
Klasifikasi didasarkan pada asal dari paket
yang datang, IIX untuk jaringan
lokal(indonesia) dan International untuk
jaringan Internet. Klasifikasi lainnya
berdasarkan protocol, TCP atau UDP.
3. Membangun aplikasi berbasis DiffServ
dengan router linux.
4. Menguji Quality of Service tiap-tiap node
pada jaringan.
1.3. Batasan Masalah
Agar pembahasan mengenai topik ini tidak
terlalu meluas maka diperlukan batasan masalah.
Adapun batasan masalah untuk skripsi ini antara
lain:
1. Aplikasi yang penulis buat akan
menjembatani pengguna untuk
melakukan konfigurasi tidak langsung
DiffServ pada kernel linux dengan
Traffic Control, Iptables dan Python.
2. Merumuskan konfigurasi yang
digunakan aplikasi untuk pemisahan
bandwidth IIX & Internasional serta
paket tcp dan udp untuk tiap node yang
terhubung ke jaringan internet.
3. Pengujian dan analisis QoS dengan
parameter nilai bandwidth, jitter dan
packet loss.
1.4. Tujuan dan Manfaat Penelitian
Penelitian yang penulis lakukan bertujuan
untuk:
1. Tujuan Umum
1. Mengembangkan aplikasi
bandwidth management yang
bersifat open source dan user
friendly.
2. Tujuan Khusus
1. Memadukan iptables dan TC(traffic
control) sebagai fondasi awal
aplikasi.
2. Memberikan pengelolaan
bandwidth yang sesuai pada
jaringan.
3. Memberikan antar muka grafis
yang sederhana dan mudah
digunakan.
Manfaat yang di dapatkan dalam penelitian
ini adalah :
1. Memberikan aplikasi yang mampu
mengatur penggunaan bandwidth
sesuai kebutuhan.
2. Memberikan aplikasi yang murah dan
mudah diterapkan.
3. Menghasilkan aplikasi open source
yang bebas digunakan/dikembangkan
siapa saja.
1.5. Metodologi Penelitian
Metode Penelitian yang penulis gunakan adalah
sebagai berikut :
1. Studi Pustaka.
Studi pustaka yang penulis lakukan
adalah dengan mempelajari literatur
tentang traffic control pada linux dan
queueing discipline.
2. Metode Pengembangan Perangkat
Lunak(Software Development
Method). Metode pengembangan
perangkat lunak yang penulis gunakan
adalah Agile Software Development
dengan Extreme Programming.
Tahapannya adalah sebagai berikut :
1. Planning, perencanaan dari
aplikasi yang akan dibuat dengan
menjelaskan fitur dan kegunaan
dari aplikasi.
2. Design, proses desain dari hasil
perencanaan sebelumnya.
3. Coding, proses pembuatan unit
test untuk kemudian digunakan
sebagai penguji pada code yang
akan diimplementasikan.
4. Testing, proses pengujian
terhadap code yang
diimplementasikan dengan unit
test yang sebelumnya telah dibuat.
5. Release, tahap akhir aplikasi siap
diimplementasikan/digunakan
oleh pengguna, setelah
sebelumnya dipastikan sudah
melewati tahapan testing.
1.6. Sistematika Penelitian
Penelitian ini terdiri dari lima bab, dengan
penjelasan tiap-tiap bab sebagai berikut :
BAB I : PENDAHULUAN
Pada bab ini berisi tentang Latar Belakang,
Rumusan Masalah, Batasan Masalah, Tujuan dan
Manfaat Penelitian, Metodologi Penelitian serta
Sistematika Penulisan Penelitian.
BAB II: LANDASAN TEORI
Pada bab ini menjelaskan tentang teori perangkat
keras dan perangkat lunak, definisi sistem,
analisa sistem, definisi perancangan sistem dan
jenis program yang digunakan.
BAB III: Metodologi Penelitian
Pada bab ini akan menguraikan dan memberikan
penjelasan mengenai perancangan perangkat
keras, perancangan sistem sehingga dapat
diketahui rencana yang akan dikerjakan.
BAB IV: Pembahasan dan Implementasi
Pada bab ini akan menjelaskan mengenai
pembuatan sistem dan pengujian sistem.
BAB V: Penutup
Bab ini berisi kesimpulan dari pembahasan
masalah dan saran-saran berkenaan dengan
Penelitian ini.
2. LANDASAN TEORI
2.1. Pengantar Quality of Service
Pertama kali jaringan IP diterapkan hanya
membawa satu tipe informasi yaitu data
non-real time, sehingga jaringan bisa
didesain untuk berjalan secara best-
effort yang memperlakukan semua paket
sama. Tujuan utama dari jaringan IP adalah
memastikan perangkat terminal mempunyai
protokol dan kecerdasan yang sesuai untuk
menjamin transmisi data yang bisa
diandalkan sehingga jaringan bisa berjalan
sesederhana mungkin.
Pada sebuah jaringan yang membawa
berbagai tipe lalu lintas data, keterbatasan
yang menjadi elemen penting pada suatu
tipe lalu lintas data bisa saja menjadi tidak
penting untuk tipe lalu lintas data lainnya,
dan sebaliknya. Mekanisme QoS yang
diimplementasikan pada jaringan harus
mampu mengoptimalkan hal tersebut.
2.1.1. Fungsi dasar QoS
Dua mekanisme QoS utama yang
tersedia untuk jaringan IP adalah
Integrated Service (IntServ) dan
Differentiated Service (DiffServ)
(Welzl, 2005). Istilah traffic flow
menunjukkan aliran trafik dan tiap
alirannya mewakili sumber trafik yang
berbeda-beda. Pada layanan best
effort, semua paket digabungkan
kedalam sebuah aliran massal tanpa
mempedulikan asal trafik. Pada
IntServ, tiap-tiap aliran dibedakan dari
awal sampai akhir. Pada DiffServ,
tiap-tiap aliran trafik tidak dibedakan
per aliran, melainkan dikumpulkan
terlebih dahulu menjadi kelas-kelas
kecil. Kelas-kelas trafik tersebut
diberikan perlakuan yang berbeda-
beda tiap hopnya (Li,1999).
Pembahasan akan ditekankan pada
metoda QoS DiffServ, dan akan
dijelaskan lebih lanjut pada sub bab
berikutnya. Untuk menyediakan QoS
dalam jaringan IP jaringan harus
mampu menjalankan tugas dasar,
yaitu membedakan trafik atau tipe
layanan menjadi beberapa kelas dan
memperlakukan kelas-kelas trafik
secara berbeda dengan menyediakan
jaminan resource dan pembedaan
layanan pada jaringan.
2.1.2. Traffic Policing Traffic Policing digunakan untuk
mengecek apakah trafik yang masuk
pada port masukan sesuai dengan laju
trafik yang telah disetujui antara
pengguna dan penyedia jasa jaringan
IP. Traffic policing terdiri dari
pengukuran trafik berdasarkan laju
trafik yang telah disetujui dan
menandai atau menandai ulang paket
berdasarkan keluaran hasil
pengukuran tersebut.
Biasanya, traffic policing
menyesuaikan laju trafik yang datang
dengan acuan laju tertentu, dengan
acuan yang digunakan dapat berupa
satu acuan laju yaitu Committed
Information Rate (CIR) atau dua
acuan laju, CIR dan Peak Information
Rate (PIR). Untuk mendapatkan laju
yang sesuai dengan CIR dan PIR,
traffic policing menggunakan tiga
parameter yaitu Peak Burst Size
(PBS), Committed Burst Size (CBS)
dan Excess Burst Size (EBS) (Blake,
1998).
a. Peak Information Rate
b. Commited Information Rate
c. Burst Size
2.1.3. Traffic Metering
Ada dua macam traffic metering dan
mekanisme pewarnaan paket, yaitu.
1. Single Rate Three Color Marker
(srTCM).
2. Two Rate Three Color Marker
(trTCM).
2.1.4. Manajemen Antrian Aktif
Tanpa adanya Manajemen Antrian
Aktif atau Active Queue Management
(AQM) pada router, router
menggunakan mekanisme yang
disebut sebagai metode tail drop.
Akan tetapi metode tail drop dapat
berujung pada fenomena yang disebut
sebagai sinkronisasi global TCP
(Braithwaite, 2006). Pada metode tail
drop, saat buffer penuh, semua paket
yang datang menuju buffer seluruhnya
dijatuhkan. Bila paket ini merupakan
paket TCP, semua aliran TCP yang
mengalami kehilangan paket akan
memelankan laju pengiriman secara
simultan dan kembali mengulangi
transmisi pada waktu yang hampir
bersamaan.
Karena semua aliran TCP yang
terpengaruh dengan keadaan tersebut
bereaksi dalam perilaku yang sinkron,
maka kondisi kongesti pada jaringan
akan berosilasi antara kondisi kongesti
penuh (saat semua aliran TCP
mengirim paket dengan laju penuh)
dan tanpa kongesti (semua aliran TCP
memelankan laju pengiriman paket).
Manajemen antrian aktif adalah
mekanisme pengendalian kongesti
yang bertugas untuk mencegah
terjadinya sinkronisasi TCP. Ide
utama dari AQM adalah untuk
mengantisipasi terjadinya kongesti
dan mengambil tindakan untuk
mencegah atau mengurangi efek dari
kongesti.
2.1.5. Penjadwalan Paket
Penjadwalan paket (packet
scheduling) digunakan untuk
menjadwalkan paket pada antrian
sehingga kapasitas jaringan pada port
keluaran dapat terdistribusi merata
pada semua kelas trafik yang
memasuki jaringan (Welzl, 2005).
1. First In First Out
FIFO memperlakukan semua
paket sederajat sehingga
cocok digunakan untuk
jaringan best effort. Masalah
utama yang dihadapi FIFO
adalah FIFO tidak dapat
membedakan (atau hanya
memiliki kemampuan yang
sangat terbatas untuk
membedakan) kelas trafik.
2. Priority Queuing
Pada PQ, antrian dibagi
sebanyak N antrian, dengan
urutan prioritas 1 sampai
dengan N. Urutan pelayanan
paket bergantung dari urutan
prioritas dan keberadaan
paket pada antrian dengan
prioritas lebih tinggi.
3. Fair Queuing
Pada FQ, paket datang
diklasifikasikan kedalam N
antrian, Setiap antrian
diberikan alokasi kapasitas
jaringan sebesar 1/N total
kapasitas jaringan. Setiap
antrian dilayani secara
berurutan (round robin)
dengan melewati antrian
yang kosong.
4. Class Based WFQ
Pada CB-WFQ, aliran trafik
dibagi ke dalam kelas-kelas,
tetapi dengan pembagian
kapasitas jaringan yang
bergantung dari kebutuhan
masing-masing kelas, dengan
total kapasitas jaringan
seluruh kelas adalah 100%
kapasitas jaringan keluaran.
5. Hierarchy Token Bucket
HTB menjamin jumlah
layanan yang diterima
sebuah kelas trafik paling
kecil sesuai dengan jumlah
yang dibutuhkan dan
diberikan kepadanya.
Apabila sebuah kelas
menggunakan kapasitas
jaringan lebih kecil dari yang
diberikan kepadanya, sisa
kapasitas jaringan yang tidak
digunakan didistribusikan ke
kelas lainnya.
2.1.6. Traffic Shaping
Traffic shaping digunakan untuk
mengatur laju aliran trafik yang
datang untuk membentuk laju trafik
sedemikian rupa agar laju trafik
keluaran bersifat lebih mulus. Bila
laju trafik yang datang bersifat sangat
acak (bursty) maka perlu ditempatkan
dulu pada sebuah buffer sehingga laju
keluaran lebih konstan(Li, 1999).
2.2. Differentiated Services
DiffServ bekerja dengan prinsip
pengklasifikasian trafik.
2.2.1. Arsitektur DiffServ
Arsitektur DiffServ berdasarkan
sebuah model sederhana dimana trafik
yang memasuki sebuah jaringan
diklasifikasikan dan dapat
dikondisikan pada tepi jaringan dan
ditempatkan pada beberapa Behavior
Aggregate (BA) yang berbeda. Setiap
BA diidentifikasikan oleh sebuah
Differentiated Service Code Point
(DSCP), sehingga BA dapat
didefinisikan sebagai kumpulan paket
dengan DSCP yang sama yang
melewati sebuah link pada arah
tertentu. Pada inti jaringan, paket
diteruskan bergantung kepada PHB
yang ditentukan oleh DSCP (Blake,
1998).
2.2.2. Traffic Conditioner
Sebuah traffic conditioner terdiri atas
elemen-elemen berikut: meter,
marker, shaper, dan dropper. Aliran
trafik akan diseleksi oleh classifier,
yang akan meneruskannya ke bagian
traffic conditioner. Meter digunakan
(apabila diperlukan) untuk
membandingkan aliran trafik terhadap
suatu profil trafik. Hasil keluaran
sebuah meter dapat mempengaruhi
proses marking, dropping, atau
shaping terhadap paket tersebut
(Blake, 1998).
2.3. Linux Traffic Control
Traffic control adalah kumpulan aturan dan
mekanisme yang mengizinkan sebuah
jaringan untuk memenuhi kualitas layanan
secara efisien. Beberapa mekanisme yang
digunakan seperti shaping, scheduling,
monitoring, policing, signaling, pricing,
admission control, congestion control dan
flow control dan lainnya. Selain itu traffic
control dapat diartikan sebagai kumpulan
fungsi dari sebuah jaringan untuk
mencegah kondisi padat, yang membentuk
mengatur aliran data pada titik tertentu
dalam system (Brown, 2006).
2.3.1. Metode Traffic Control pada Kernel
Linux
Terdapat beberapa metode yang
digunakan oleh traffic control
pada interface (Hubert , 2004),
yaitu 1. Shaping
Shapers menahan paket untuk
mencapai kecepatan yang
diinginkan.
2. Scheduling
Scheduler mengatur paket untuk
output. scheduling adalah
mekanisme untuk pengaturan paket
di antara input dan output dari
sebagian besar antrian.
3. Classifying
Classifying adalah mekanisme
untuk menentukan paket mana yang
dipisah untuk diperlakukan
berbeda, dan dimungkinkan dengan
output queue yang berbeda.
4. Policing
Policing menghitung dan
membatasi traffic dalam queue
tertentu.
5. Dropping
Dropping membuang keseluruhan
paket data, aliran data atau
klasifikasi.
6. Marking
Marking adalah mekanisme untuk
menandai paket data.
2.3.2. Queuing Discipline
Antrian menentukan cara
mengirimkan data. Penting untuk
diingat bahwa kita hanya bisa
menentukan data yang kita kirim
(Hubert, 2004).
Terdapat banyak qeueuing
discipline pada kernel linux,
namun pada pembahasan kali ini
hanya 2 yang kita gunakan.
Random Early Detection, untuk
menanggulangi congestion.
Hierarchical Token Bucket, untuk
membagi bandwidth sesuai dengan
kebutuhan, misal berdasarkan ip
ataupun port yang diinginkan.
1. Random Early Detection
RED menghitung average queue
size menggunakan low-pass filter
dengan exponential weighted
moving average. Average queue
size dibandingkan dengan 2
thresholds, minimum threshold dan
maximum threshold. Ketika
average queue size kurang dari
minimum threshold tak ada paket
yang di mark. Ketika average queue
size lebih besar dari maximum
threshold, setiap paket yang datang
di mark. Jika paket yang dimark
dibuang atau jika semua node
sumber bekerja sama dapat
dipastikan bahwa average queue
size tidak secara signifikan
melampaui maximum threshold
(Hubert, 2004).
2. Hierarchical Token Bucket HTB berbasis atas class hierarkis
yang terdiri atas tiga tipe, yaitu :
root, inner dan leaf. Root adalah
induk dari semua class dan semua
lalu lintas data akan melewatinya.
Inner class memiliki induk class,
dapat berupa root ataupun inner
class lain, dan memiliki class
turunan. Leaf adalah kelas akhir
atau class yang hanya memiliki
class induk tanpa class turunan
(Devera, 2002).
HTB scheduler
Terdapat pohon class pada HTB
scheduler. Terdapat pula list global
yang disebut self feed, yang
terdapat pada sebelah kanan. Self
feed terdiri atas self slot. Terdapat
satu slot per priority per level. Tiap
self slot memiliki beberapa class.
Semua class pada slot memiliki
level dan prioritas seperti slot.
Prioritas pengiriman paket (Devera, 2002)
2.4. TC tools
Pada paket iproute2, tc adalah satu-satunya
yang dapat digunakan untuk traffic control.
Karena tc secara langsung berinteraksi
dengan kernel untuk pembuatan,
penghapusan dan modifikasi terhadap
struktur traffic control.
2.4.1. Tc qdisc
tc qdisc (Hubert, 2004)
2.4.2. Tc class
tc class (Hubert, 2004)
2.4.3. Tc filter
tc filter (Hubert, 2004)
2.5. Python
Python adalah salah satu bahasa
pemrograman script. Karena script
sehingga bersifat interpreted tapi python
memungkinkan untuk dicompile. Memiliki
pendekatan Berorientasi Objek dan yang
terpenting adalah terstruktur secara sintaks
kodenya.
2.6. Extreme Programming
Extreme Programming (XP) adalah metode
pengembangan perangkat lunak yang ringan
dan termasuk salah satu agile methods yang
dipelopori oleh Kent Beck, Ron Jeffries, dan
Ward Cunningham. Sasaran XP adalah tim
yang dibentuk berukuran antara kecil sampai
medium saja, tidak perlu menggunakan
sebuah tim yang besar.
Menurut Pressman(2005), Extreme
Programming adalah proses yang paling
banyak digunakan pada agile process.
Perencanaan kegiatan diatur sebagai
kerangka empat – perencanaan(planning),
desain(design), pengkodean(coding) dan
pengujian(testing) - XP menunjukkan
sejumlah teknik yang inovatif dan kuat yang
memungkinkan tim tangkas untuk membuat
perangkat lunak rilis sering memberikan
fitur dan fungsi yang telah dijelaskan dan
kemudian diprioritaskan oleh pelanggan.
XP Software Development Process(Pressman,
2005)
XP mencakup beberapa aturan dan praktek yang
terdiri atas planning, design, coding dan
test(Pressman, 2005).
2.7. Studi Sejenis
Penelitian oleh Pramudita(2008) yang
dilaksanakan di gedung Labtek VIII
Institut Teknologi Bandung (ITB) dan
lab di gedung Pusat Antar Universitas
(PAU) ITB. Penelitian lain oleh
Marieska(2008) pada Wimax. IEEE
Standard 802.16 tidak mendefinisikan
algoritma penjadwalan. Penulis akan
menggunakan disiplin antrian dan
menerapkan secara dinamis pada jaringan.
Sehingga konfigurasi untuk jaringan dapat
bersifat dinamis.
3. METODOLOGI PENELITIAN
3.1. Alat dan Bahan
Adapun peralatan yang digunakan dibagi
dua, yaitu :
1. Perangkat Keras
•••• PC server(1 unit)
dengan spesifikasi :
1. Operating System
: Fedora Core 10.
2. 2 kartu interface .
•••• PC client(3 unit) dengan
spesifikasi :
1. Operating System
: Windows XP.
2. 1 kartu
interface.
•••• Switch
2. Perangkat Lunak
•••• IPTABLES.
•••• TC.
•••• Linux Kernel 2.6.x.
•••• GTK.
•••• Python.
3.2. Metode Penelitian
3.2.1. Metode Pengumpulan Data
1. Studi Pustaka
Studi pustaka dilakukan untuk
mendapatkan bahan dan data
yang diperlukan dalam
melakukan penelitian ini. 3.2.2. Metode Pengembangan Perangkat
Lunak
1. Extreme Programming
Extreme Programming
(Pressman, 2005) adalah suatu
pendekatan baru terhadap
model pengembangan
perangkat lunak yang
kontroversial berdasar pada
model iterative dan
incremental. XP mencakup
beberapa aturan dan praktek
yang terdiri atas planning,
design, coding dan test. a. Planning
Adapun beberapa fungsi dan
kebutuhan dari aplikasi adalah
sebagai berikut:
1. Aplikasi mampu
generate parameter
TC dan iptables yang
dibutuhkan.
2. Aplikasi mampu
generate parameter
untuk TC dan iptables
yang akan dibutuhkan
oleh aplikasi.
3. Aplikasi membuat
laporan realtime
untuk mengukur
pemakaian
bandwidth.
b. Design
Pada desain, perancangan
aplikasi akan terdiri dari beberapa
bagian diantaranya sebagai berikut
:
1. Perancangan desain
GUI dengan
pembuatan prototype
dengan menggunakan
GTK.
2. Desain input yang
diperlukan.
3. Desain ouput yang
diperlukan.
4. Perancangan class
yang dibutuhkan
dengan CRC.
5. Perancangan tampilan
laporan penggunaan
bandwidth.
c. Coding
Saat unit test selesai dibuat,
pengembang lebih baik fokus
terhadap apa yang akan
diimplementasikan untuk
melewati unit test.
d. Test
Tahap ini akan menggunakan
unit test yang sebelumnya
telah dibuat.
4. PEMBAHASAN
4.1. Planning
4.1.1. Analisis penggunaan bandwidth
Berikut hasil pengujian menggunakan
disiplin antrian FIFO,
Percob
aan ke-
Node 1 Node 2
Upload Downloa
d
Uploa
d
Downloa
d
1 85 kbps 255 kbps 34
kbps
127 kbps
2 80 kbps 244 kbps 39
kbps
185 kbps
4.1.2. Aplikasi mampu generate
parameter untuk TC dan Iptables
a. Network device yang akan
digunakan.
b. Kecepatan maksimum untuk
tiap network device yang
digunakan.
c. Beberapa parameter untuk
HTB
a. classid untuk tiap node.
Node qdisc root dengan
handle 1:0, node parent
class dengan classid 1:1.
Node IIX dengan 1:2,
node internasional dengan
classid 1:3. child class IIX
akan menggunakan
classid 1:n2 dan
internasional dengan
classid 1:n3, untuk n
adalah bilangan bulat.
Untuk qdisc child class
tersebut akan mengikuti
classid dengan handle n2:
untuk IIX dan n3 untuk
Internasional, untuk n
adalah bilangan bulat
b. Maksimum rate untuk
parent class.
c. Rate untuk tiap class node
yang tidak melebihi
parent class.
d. Bandwidth dan latency yang
dimiliki oleh network device
yang menggunakan RED.
e. Ip yang digunakan oleh tiap
network interface yang
digunakan untuk routing oleh
iptables
f. Daftar ip host yang terhubung
jaringan IIX untuk penanda
paket data yang dikirim
ataupun diterima. 4.2. Design
4.2.1. Class Design
Dari user stories pada tahap
planning, penulis membuat
beberapa class yaitu :
1. HTB, digunakan untuk
mengenerate TC statement.
2. RED, digunakan untuk
mengenerate TC statement.
3. TC, digunakan untuk
mengeksekusi TC statement
yang sebelumnya dibuat
oleh class lain.
4. BWGUI, digunakan untuk
menangani GUI dari
aplikasi.
5. Client, digunakan untuk
menangani informasi tiap
klien.
6. BandwidthConsumption,
digunakan untuk menangani
penggunaan bandwidth tiap
client. 4.2.2. GUI Design
4.3. Coding
Tahap ini tidak langsung membuat code dari
tiap objek dari hasil desain sebelumnya.
Pembuatan Unit Test untuk menguji tiap
class didahulukan. Contoh Unit Test yang
akan dibuat adalah sebagai berikut :
import unittest
from modules.RED import RED
def test_qdisc(self):
red = RED()
self.assertEqual(red.qdisc,
'root red')
def test_red(self):
red = RED()
self.assertEqual(red.setRed(128
000),'/sbin/tc qdisc add dev
eth0 root red limit 64000 min
4000 max 8000 burst 5 avpkt
1000 probability 0.02 bandwidth
128')
if __name__ == '__main__':
unittest.main()
4.4. Test
Untuk menguji bug pada kode yang ditulis
sebelumnya, unit test yang sebelumnya
telah dibuat dieksekusi. Lakukan
refactoring terus menerus sampai bug
hilang.
5. KESIMPULAN
5.1. Kesimpulan
Setelah melakukan pengetesan terhadap
aplikasi yang telah dibuat dan
menyelesaikan penelitian ini. Dapat ditarik
kesimpulan sebagai berikut:
1. Aplikasi DiffServ menggunakan
TrafficControl dengan disiplin
antrian HTB dan RED dapat
berperan untuk mengatur
penggunaan bandwidth tiap node
pada jaringan. Hasil pengujian
dapat dilihat di Implementation
Test(subbab 4.5.1) dan QoS
testing(subbab 4.5.2).
2. Aplikasi dapat membedakan asal
paket dari jaringan IIX(lokal) atau
internasional. Dan memberikan
batasan kecepatan yang sesuai
untuk tiap koneksi. Hasil pengujian
dapat dilihat pada QoS
testing(subbab 4.5.2).
3. Aplikasi dapat diterapkan pada
router linux berbasis DiffServ.
Karena bersifat open source dan
dapat dimodifikasi dan ditambah
fungsionalitasnya.
4. Pengujian QoS dengan parameter
uji delay, jitter dan packet loss
memberikan hasil yang baik.
Terlihat dari hasil pengujian yang
memberikan nilai pengujian dari
parameter tersebut relatif kecil bila
dibandingkan dengan sebelumnya
yang menggunakan disiplin antrian
FIFO atau default dari router. Hasil
pengujian dapat dilihat pada QoS
Testing(subbab 4.5.2).
5.2. Saran
Berikut ini beberapa saran yang
mungkin berguna untuk digunakan
sebagai bahan pertimbangan yang ingin
melakukan penelitian atau aplikasi yang
hampir sama,
1. Dimungkinkan untuk
menerapkan semua queueing
discipline yang ada. Sehingga
pengguna bebas memilih yang
ingin digunakan.
2. Memberikan log berupa diagram
garis yang lebih luas dan
dimungkinkan untuk disimpan
dalam database untuk keperluan
auditing di lain waktu.
3. Python sebagai scripting
language dan menggunakan
Extreme Programming sebagai
metode yang digunakan dapat
mempercepat dan
menyederhanakan proses
pembuatan aplikasi. Daftar Pustaka
Almesberger, Werner. 2001.
Differentiated Services on linux.
ftp://icaftp.epfl.ch/pub/linux/diffser
v/misc/dsid-01.ps.gz
Beck, Kent. 2004. Extreme
Programming Explained: Embrace
Change, Second Edition.
Massachusetts: Addison Wesley
Professional.
Blake, et. al. 1998. An Architecture for
Differentiated Services. RFC 2475.
http://www.ietf.org/rfc/rfc2475
Braden, et. al. 1998.
Recommendations on Queue
Management and Congestion
Avoidance in the Internet. RFC
2309.
http://www.ietf.org/rfc/rfc2309.t
xt
Braithwaite, Stephen. 2006.
Implementation of AQMs on Linux
made Easy. The University of
Southern Queensland.
http://eprints.usq.edu.au/2075/1/Bra
ithwaite-6800-Queuing.pdf
Brown, Martin A. 2006. Traffic
Control HOWTO. Version 1.0.2.
http://linux-ip.net/articles/Traffic-
Control-HOWTO/. diakses pada
hari ini.
C H, Swaroop. A Byte of Python.
http://www.byteofpython.info.
Devera, Martin. 2002. HTB Linux
queuing discipline manual - user
guide.
http://luxik.cdi.cz/~devik/qos/htb/m
anual/userg.htm
Floyd, Sally dan Van Jacobson. 1993.
Random Early Detection Gateways
for Congestion Avoidance.
Lawrence Berkeley Laboratory
University of California.
http://www.icir.org/floyd/papers/re
d/red.html
Floyd, et. al. 2001. Adaptive RED: An
Algorithm for Increasing the
Robustness of RED’s Active Queue
Management.
http://citeseerx.ist.psu.edu/viewdoc/
download?doi=10.1.1.78.7450&rep
=rep1&type=pdf
Floyd, Sally. Congestion Control
Principles. RFC 2914.
http://www.ietf.org/rfc/rfc2914
Hubert , Bert. 2004. Linux Advanced
Routing & Traffic Control
HOWTO. http://lartc.org/lartc.pdf
Li, Suqiao. 1999. Network Traffic
Control and Bandwidth
Management in Internet: A
Differentiated Services Case Study.
McGill University.
http://digitool.library.mcgill.ca/R/?f
unc=dbin-jump-
full&object_id=30688&local_base
=GEN01-MCG02
Marieska, Mastura Diana. 2008.
Analisis Algoritma Penjadwalan
Berbasis Quality of Service pada
Wimax. http://digilib.itb.ac.id/
Nagle, John. 1984. Congestion Control
in IP/TCP Internetworks. RFC 896.
http://tools.ietf.org/html/rfc896
Nichols, et. al. 1998. Definition of the
Differentiated Services Field (DS
Field) in the IPv4 and IPv6
Headers. RFC 2474.
http://www.ietf.org/rfc/rfc2474.txt
Pramudita, Damar Aji. 2008.
Differentiated Service(DiffServ) di
Jaringan Testbed menggunakan
Disiplin Antrian PRIORITY
QUEUEING dan HIERARCHY
TOKEN BUCKET.
http://digilib.itb.ac.id/
Python v2.6.1 Documentation.
http://docs.python.org/
Schach, Stephen R. 2005. Object
Oriented and Classical Software
Engineering, Sixth Edition. New
York: McGraw Hill.
Pressman, Roger S. 2005. Software
Engineering: A Practitioner’s
Approach, Sixth Edition. New
York: McGraw Hill.
Valenzuela, et. al. 2004. Hierarchical
Token Bucket Algorithm to
Enhance QoS in IEEE 802.11:
Proposal, Implementation dan
Evaluation.
http://ieeexplore.ieee.org/iel5/9623/
30413/01400539.pdf?arnumber=14
00539
Welzl, Michael. 2005. Network
congestion control : managing
Internet traffic. England:John Wiley
& Sons Ltd.