Kalau bicara optimasi bandwidth MikroTik, ada satu pendekatan yang menurut saya mulai layak dipertanyakan: terlalu sibuk memisahkan trafik berdasarkan jenis aplikasi.
Game diberi prioritas. YouTube diturunkan. Download dibatasi. Media sosial diberi jalur khusus. Streaming dibuat queue sendiri.
Kelihatannya canggih.
Tapi setelah jaringan mulai besar, biasanya muncul pertanyaan sederhana: memangnya kita mau terus mengejar IP dan pola trafik setiap aplikasi yang berubah setiap saat?
Saya lebih suka pendekatan yang sedikit lebih sederhana. Bandwidth dikelola berdasarkan siapa yang menggunakan, kemudian antreannya dibuat supaya latency tetap masuk akal ketika koneksi sedang penuh.
Di sinilah PCQ dan FQ-CoDel menarik untuk dibahas.
QoS Tidak Harus Berarti Memisahkan Game, Streaming dan Download
Secara sederhana, ada dua persoalan yang sering tercampur dalam pembahasan QoS.
Pertama, persoalan fairness. Jangan sampai satu pelanggan melakukan download besar lalu seluruh pengguna lain ikut merasakan internet menjadi lambat.
Kedua, persoalan latency. Ketika bandwidth penuh, jangan sampai antrean paket menumpuk terlalu besar sehingga ping melonjak.
PCQ sangat berguna untuk persoalan pertama. FQ-CoDel lebih menarik untuk persoalan kedua sekaligus memberikan fairness antar-flow.
Jadi masalahnya sebenarnya bukan sekadar:
PCQ versus FQ-CoDel, mana yang paling sakti?
Tetapi:
Fairness apa yang kita inginkan, dan di titik mana congestion terjadi?
Gambaran Sederhananya
Misalkan sebuah router memiliki koneksi Internet 500 Mbps dan digunakan oleh puluhan sampai ratusan perangkat.
Saya lebih menyukai model seperti ini:
INTERNET
|
500 Mbps
|
v
+----------------+
| MikroTik |
| Total Shaping |
+--------+-------+
|
Fairness / Queue
|
+--------------+--------------+
| | |
v v v
User A User B User C
| | |
v v v
Flow 1 Flow 1 Flow 1
Flow 2 Flow 2 Flow 2
Flow 3 Flow 3 Flow 3
Tidak perlu bertanya:
Ini YouTube atau TikTok?
Ini game atau download?
Ini WhatsApp atau Instagram?
Yang lebih penting:
Siapa yang sedang menggunakan bandwidth dan berapa besar antreannya?
Pendekatan seperti ini jauh lebih tahan terhadap perubahan aplikasi.
PCQ: Cocok Kalau Fokusnya Pembagian Bandwidth
PCQ bekerja dengan membuat substream berdasarkan classifier tertentu.
Untuk download, classifier yang umum digunakan adalah dst-address. Untuk upload, src-address.
Contoh sederhana:
/queue type
add name=PCQ-Download kind=pcq pcq-classifier=dst-address pcq-rate=0
add name=PCQ-Upload kind=pcq pcq-classifier=src-address pcq-rate=0Kemudian dapat diterapkan pada jaringan pelanggan:
/queue simple
add target=192.168.10.0/24 queue=PCQ-Upload/PCQ-Download max-limit=400M/400MIni bukan berarti setiap perangkat otomatis mendapat 400 Mbps.
Justru sebaliknya. max-limit membatasi kapasitas keseluruhan queue, sedangkan PCQ membagi trafik ke substream berdasarkan classifier.
Dalam jaringan dengan banyak pelanggan, pendekatan seperti ini cukup menarik. Daripada membuat queue manual untuk setiap pelanggan, pembagian dapat dilakukan secara dinamis.
FQ-CoDel: Ketika Ping Mulai Menjadi Masalah
Sekarang masuk ke bagian yang menurut saya lebih menarik.
Bandwidth besar tidak otomatis berarti latency bagus.
Contohnya begini:
Internet 500 Mbps
|
| trafik penuh
v
+-------------------+
| Antrean besar |
| ############### |
| ############### |
| ############### |
+-------------------+
|
v
Ping naik
Ketika antrean terlalu panjang, paket harus menunggu.
Hasilnya bisa sangat familiar:
Idle: 8 ms 9 ms 8 ms 10 ms Download besar: 150 ms 300 ms 500 ms 700 ms
Padahal speedtest mungkin masih menunjukkan angka yang terlihat bagus.
FQ-CoDel dirancang untuk menangani masalah antrean semacam ini. Di RouterOS, FQ-CoDel menggabungkan Fair Queuing dengan Controlled Delay.
Konsep sederhananya dapat digambarkan seperti ini:
TOTAL BANDWIDTH
|
v
+-------------+
| FQ-CoDel |
+------+------+
|
+------------+------------+
| | |
v v v
Flow 1 Flow 2 Flow 3
| | |
+------------+------------+
|
v
CLIENT
Yang menarik, FQ-CoDel juga mempunyai mode isolasi seperti dual-srchost dan dual-dsthost. Pemilihan mode harus disesuaikan dengan arah trafik dan tujuan fairness yang ingin dicapai.
Tidak Perlu Membuat QoS Berdasarkan Nama Aplikasi
Inilah alasan saya lebih menyukai pendekatan tersebut.
Hari ini mungkin:
Game -> priority 1 Streaming -> priority 3 Download -> priority 8
Besok aplikasi berubah.
CDN berubah. IP berubah. Port berubah. Protokol berubah. QUIC makin banyak digunakan.
Lalu konfigurasi QoS ikut dikejar-kejar.
Akhirnya router dipenuhi address-list, mangle, packet-mark dan queue yang sebenarnya dibuat hanya karena kita mencoba menebak isi trafik.
Bukan berarti klasifikasi trafik itu salah. Ada kasus yang memang membutuhkan QoS berbasis aplikasi atau layanan.
Tetapi untuk jaringan akses umum, saya mempertanyakan apakah kompleksitas tersebut benar-benar sebanding dengan manfaatnya.
Saya lebih suka:
BANDWIDTH
|
v
[ SHAPING ]
|
v
[ FAIRNESS ]
|
v
[ FQ-CoDel ]
|
+---- User A
+---- User B
+---- User C
+---- User D
Daripada:
Internet | +-- Game Queue +-- YouTube Queue +-- TikTok Queue +-- Facebook Queue +-- Download Queue +-- Streaming Queue +-- WhatsApp Queue +-- dan seterusnya
Yang kedua memang terlihat lebih enterprise.
Belum tentu lebih baik.
Tapi Ada Satu Hal yang Sering Salah
Jangan asal memasang queue di atas queue.
Misalnya kita mempunyai:
Total LAN
|
+-- FQ-CoDel
|
+-- Simple Queue User A
+-- Simple Queue User B
+-- Simple Queue User C
Secara konsep memang terlihat bagus.
Tetapi RouterOS menggunakan struktur HTB dan hubungan parent-child. Agar child queue bekerja sebagaimana mestinya, parent harus menangkap trafik yang diperlukan. Simple Queue juga mempunyai urutan pemrosesan tersendiri.
Artinya, double queuing bukan otomatis lebih baik.
Harus dilihat packet flow, parent-child relationship, limit-at, max-limit, jenis queue dan di mana congestion sebenarnya terjadi.
Kalau tidak, kita hanya membuat konfigurasi semakin rumit.
Shaping Harus Dilakukan di Tempat yang Tepat
Misalnya koneksi Internet nyata hanya 500 Mbps.
Saya tidak akan langsung mengatakan:
FQ-CoDel = 475 Mbpshanya karena angka 95 persen terlihat bagus.
Angka tersebut harus diuji.
Apakah bandwidth ISP benar-benar 500 Mbps? Apakah ada PPPoE? Ada VLAN? Ada overhead? Apakah bottleneck terjadi di MikroTik? Atau justru antrean terbentuk di perangkat ISP?
Kalau bottleneck berada di luar kendali kita, queue MikroTik tidak otomatis dapat mengendalikan antrean tersebut.
Secara konseptual, kita ingin MikroTik menjadi titik yang melakukan shaping sebelum bottleneck yang ingin kita kelola:
Bandwidth ISP
|
v
[ SHAPER ]
|
v
[ QUEUE ]
|
v
CLIENT
PCQ atau FQ-CoDel?
Jawabannya tergantung tujuan.
Kalau kebutuhan utama adalah membagi bandwidth secara dinamis antar-user, PCQ sangat masuk akal.
Kalau kebutuhan utamanya adalah menjaga latency ketika jaringan mengalami congestion, FQ-CoDel lebih menarik.
Kalau setiap user sudah mempunyai Simple Queue sendiri untuk batas paket bandwidth, FQ-CoDel dapat digunakan untuk menangani fairness dan antrean pada level yang tepat. Tetapi jangan langsung menumpuknya tanpa memahami hierarchy.
Untuk jaringan yang besar, saya justru lebih suka menguji kombinasi secara terukur daripada percaya pada template konfigurasi internet.
Uji, Jangan Percaya Mitos Setting
Ukur ping saat idle.
Kemudian saturasi download.
Ukur ping lagi.
Saturasi upload.
Ukur lagi.
Lihat packet loss, throughput, queue drop, CPU dan latency.
Baru setelah itu kita bicara apakah konfigurasi tersebut benar-benar bekerja.
Karena pada akhirnya, tujuan QoS bukan membuat konfigurasi MikroTik terlihat rumit.
Tujuannya sederhana: bandwidth terbagi dengan adil, koneksi tetap responsif, dan satu pengguna tidak membuat seluruh jaringan ikut menderita.
Dan kalau itu bisa dicapai tanpa harus membuat daftar panjang “game ini lewat queue A, YouTube lewat queue B, TikTok lewat queue C”, menurut saya justru lebih sehat.
PCQ dan FQ-CoDel bukan sekadar trik konfigurasi. Keduanya mempunyai konsep yang jelas untuk menangani fairness, pembagian bandwidth dan pengendalian delay.
Yang perlu kita lakukan tinggal satu: uji dengan kondisi jaringan nyata, bukan percaya mitos setting.
