Linux Inbound Policing vs Shaping - Pilih Mana?

Kamas Muhammad <kamas@lc.vlsm.org>


Tidak ada copyright apapun dalam dukumen ini, anda bebas menyalin, mencetak, maupun memodifikasi. Saran, koreksi, kritik, kesalahan ketik, maupun ucapan silakan dikirimkan ke email tersebut diatas. Terima Kasih.

Perlu Diketahui

Tulisan ini tidak menjelaskan definisi shaping/policing, tidak juga menjelaskan QoS itu apa, pentingnya apa, gunanya apa, dan seterusnya. Tulisan ini bertujuan membandingkan hasil kerja policing dan shaping pada inbound traffic. Kalau anda mencari tutorial tentang "shaping adalah" atau "policing adalah", silakan mencari di internet. Jumlahnya buanyak sekali kok :)

Yang ingin saya capai dari tulisan ini adalah memunculkan perbedaan hasil kerja kedua mekanisme itu terhadap konsumsi bandwidth yang anda peroleh dari ISP, serta seberapa transfer rate yang mungkin diperoleh oleh pengguna jaringan anda.

Sekilas Shaping & Policing

Shaping dan policing pada dasarnya punya tujuan yang sama, yaitu "membatasi konsumsi bandwidth" (gampangnya begitu). Perbedaan di antara keduanya adalah bahwa pada dasarnya shaping hanya bisa dilakukan pada outbound traffic (egress), sementara policing bisa dilakukan pada inbound maupun outbound (ingress/egress). Penjelasan lebih jauh yang cukup elegan cukup banyak bertebaran di internet, dan yang ini merupakan salah satu favorit saya. Saya ndak akan ngetik panjang lebar tentang ini, sehingga silakan dibaca sendiri.

Yang bagi saya cukup menarik adalah bahwa Linux (dengan menggunakan modul tertentu) dapat melakukan proses shaping untuk inbound traffic. Ya sebenarnya secara teknis kalimat ini salah, karena prosesnya adalah menyalin paket data yang masuk pada interface fisik ke suatu interface gadungan (secara fisik tidak ada), dan kemudian melakukan proses shaping pada egress queue interface itu.

Original trav

Diagram di atas adalah alur asli ketika ada paket data yang masuk. Dengan tambahan interface gadungan (IFB/IMQ), sederhananya, alurnya lebih kurang jadi seperti ini:

Original trav

Dengan alur seperti itu, akhirnya kita bisa shaping menggunakan HTB/CBQ qdisc pada proses egress queue interface gadungan sebelum paket itu masuk ke proses routing. Dari sudut pandang manusia, proses ini akan tampak seperti menghambat laju paket data pada proses inbound :)

Catatan Penting: Grafik di atas saya ngarang sendiri. Secara teknis mungkin sebenarnya ndak begitu. Karangan itu saya buat untuk mempermudah pemahamannya saja he..he..he..

Pertanyaannya

Dengan proses seperti diagram di atas, akhirnya dengan segala kelebihan dan kekurangan yang dimiliki oleh masing-masing mekanisme, sampailah kita kepada pertanyaan: "Mau pakai yang mana?"

Percobaannya

Untuk menjawab pertanyaan itulah saya bikin percobaan sederhana, dengan tujuan untuk mengetahui efek masing-masing mekanisme terhadap laju data yang diterima oleh router, serta laju data yang diterima oleh client. Diagram percobaannya seperti ini.

topologi

Tabel 1: Network Interfaces
Network Interface Router
eth0 192.168.1.11
eth2 10.1.1.1
Network Interface Server Web
eth0 192.168.1.50

Qdisc yang digunakan dalam percobaan saya adalah HTB, sedangkan psuedo device yang digunakan adalah IFB. Ada dua percobaan yang saya lakukan, yaitu shaping dan policing pada eth0, serta satu percobaan tambahan yaitu shaping pada eth2 tanpa ada pengaturan apa pun pada eth0.

Tabel 2: Percobaan
No Interface Router Mekanisme
1 eth0 policing
eth2 -
2 eth0 shaping (via ifb0)
eth2 -
3 eth0 -
eth2 shaping

Ada sebuah file besar di web server yang diunduh oleh komputer client. Angka yang digunakan dalam pencekikannya adalah 256 kbit/s. Perintah-perintah yang dipakai akan saya tunjukkan pada masing-masing percobaan. Saya sertakan juga grafik aktifitas transfer data yang saya buat menggunakan nload pada saat proses pengunduhan berjalan.

eth0 policing, eth2 fifo

Pada bagian ini eth0 melakukan policing dengan konfigurasi drop excess packet, sedangkan di eth2 tidak ada pengaturan apa-apa (qdisc FIFO atau mq).

tc qdisc del dev eth0 ingress
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 \
    match ip src 192.168.1.50 match ip sport 80 0xffff \
    police rate 256kbit burst 10k drop flowid :1

Untuk interface eth0, grafiknya begini:
nload -t 2000 -i 512 -o 512 -u k eth0

Sedangkan interface eth2, grafiknya begini:
nload -t 2000 -i 512 -o 512 -u k eth2

eth0 shaping (via ifb0), eth2 fifo

Seperti percobaan sebelumnya, tidak ada pengaturan apa-apa terhadap eth2. Pengaturan hanya ada di eth0, dengan metode shaping di interface ifb0. Paket data yang masuk ke eth0 di-mirror ke interface ifb0 yang kemudian dipasangi qdisc HTB.

modprobe ifb
ifconfig ifb0 up

tc qdisc del dev ifb0 root
tc qdisc add dev ifb0 root handle 1: htb default 20
tc class add dev ifb0 parent 1: classid 1:20 htb rate 256kbit

tc qdisc del dev eth0 ingress
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 \
    match ip src 192.168.1.50 match ip sport 80 0xffff \
    flowid 1:0 action mirred egress redirect dev ifb0

Untuk interface eth0, grafiknya begini:
nload -t 2000 -i 512 -o 512 -u k eth0

Sedangkan interface eth2, grafiknya begini:
nload -t 2000 -i 512 -o 512 -u k eth2

eth0 fifo, eth2 shaping

Yang terakhir eth0 tidak ada pengaturan apa-apa, tapi ada HTB di eth2.

tc qdisc del dev eth0 ingress

tc qdisc del dev eth2 root
tc qdisc add dev eth2 root handle 1: htb default 10
tc class add dev eth2 parent 1: classid 1:10 htb rate 256kbit

Untuk interface eth0, grafiknya begini:
nload -t 2000 -i 512 -o 512 -u k eth0

Sedangkan interface eth2, grafiknya begini:
nload -t 2000 -i 512 -o 512 -u k eth2

Simpulan

Kalau angkanya dirangkum, hasilnya begini:

Tabel 3: Hasil Percobaan
Percobaan eth0 eth2
1 (eth0 policing, eth2 fifo) Avg: 452.77 kBit/s
Min: 412.12 kBit/s
Max: 475.37 kBit/s
Avg: 251.70 kBit/s
Min: 227.09 kBit/s
Max: 263.11 kBit/s
2 (eth0 shaping, eth2 fifo) Avg: 254.03 kBit/s
Min: 197.57 kBit/s
Max: 306.50 kBit/s
Avg: 249.63 kBit/s
Min: 243.88 kBit/s
Max: 253.41 kBit/s
3 (eth0 fifo, eth2 shaping) Avg: 324.06 kBit/s
Min: 0.00 kBit/s
Max: 561.05 kBit/s
Avg: 248.99 kBit/s
Min: 243.48 kBit/s
Max: 253.35 kBit/s
  1. Secara keseluruhan, rata-rata transfer rate yang diperoleh oleh client tidak jauh beda. Selisih terbesar antara minimum rate dengan maximum rate terjadi pada percobaan 1 yaitu eth0 policing, eth2 fifo.
  2. Policing cenderung makan benwit (ISP) lebih banyak daripada shaping. Bandingkan grafik eth0 pada percobaan 1 dengan percobaan 2. Rata-rata downstream yang dicatat pada skema eth0 policing adalah 452.77 kBit/s, sekitar 196 kBit/s lebih besar daripada angka yang dikonfigurasikan (256 kBit/s). Rasa-rasanya 196kBit/s itu seharusnya masih bisa digunakan untuk melayani client yang lain, tapi jadi terbuang percuma.
  3. Percobaan ketiga menghasilkan grafik eth0 yang menarik, naik turun dengan indah.
  4. Mekanisme yang dipilih untuk pengaturan inbound traffic tidak akan menimbulkan perbedaan yang signifikan di sisi client. Yang mungkin bisa merasakan besar perbedaannya adalah ISP atau punggawa router, di mana skema policing menunjukkan konsumsi benwit yang (jauh) lebih besar daripada skema shaping. Dari hasil percobaan di atas, untuk pengaturan qos pada sisi inbound, policing makan benwit 70% lebih banyak daripada shaping.

Perlu diingat bahwa angka di atas dimunculkan dari 1 stream saja. Kalau ada beberapa client, sangat mungkin angkanya berbeda. Jadi, mekanisme apa yang anda pilih?

Bacaan

Ini ada beberapa info mendasar yang cukup bagus untuk dibaca sebagai informasi dasar tentang apa yang saya tulis di sini.

IFB
The Intermediate Functional Block device is the successor to the IMQ iptables module that was never integrated.
IMQ
Intermediate Queueing Device
LARTC
Linux Advanced Routing and Traffic Control

Thanks To...

Terimakasih buat teman-teman yang udah kasih respon, terutama koreksi tentang isi, penambahan informasi, serta tatanan penulisan yang membuat tulisan ini lebih manusiawi untuk dibaca: (urut abjad)