Komunitas jaringan sedang memperdebatkan apakah sudah waktunya untuk meningkatkan initial congestion window TCP lagi, menyusul dorongan sukses Google dari 1 ke 10 paket pada tahun 2011. Seiring halaman web yang telah berkembang secara dramatis dalam ukuran selama dekade terakhir, standar saat ini mungkin tidak lagi cukup untuk performa optimal.
Evolusi Jendela Kongesti Awal TCP
- Sebelum 2010: 1-3 paket (1,5-4,5 KB)
- 2011-sekarang: 10 paket (~15 KB)
- Usulan: 20-40 paket (30-60 KB)
- Cakupan pada 10 paket: ~85% aset dalam satu perjalanan pulang-pergi (data 2011)
Tantangan Teknis dengan Implementasi Saat Ini
Proposal untuk meningkatkan initial congestion window dari 10 ke antara 20 dan 40 paket menghadapi rintangan teknis yang signifikan. Para insinyur jaringan menunjukkan bahwa sekadar meningkatkan nilai ini bisa berdampak buruk secara spektakuler. Kekhawatiran utama berkisar pada tail loss - ketika paket di akhir transmisi terjatuh, memaksa seluruh koneksi untuk melambat dan pulih.
Tail loss: Ketika paket terakhir dalam transmisi hilang, menyebabkan jenis degradasi performa terburuk untuk protokol sliding window seperti TCP.
Para ahli komunitas menekankan bahwa initial congestion window beroperasi sebelum algoritma kontrol kemacetan apa pun memiliki waktu untuk mempelajari kondisi jaringan. Hal ini membuat keputusan tersebut sangat berisiko, karena tidak ada mekanisme umpan balik untuk memandu pilihan selama momen-momen krusial pertama dari sebuah koneksi.
Keterbatasan Algoritma BBR
Meskipun artikel asli menyarankan penggunaan algoritma kontrol kemacetan BBR Google bersamaan dengan initial window yang lebih tinggi, para profesional jaringan mengungkapkan skeptisisme terhadap pendekatan ini. BBR membutuhkan waktu yang cukup lama untuk berputar melalui fase pembelajarannya, yang berarti memberikan sedikit keuntungan selama tahap awal koneksi ketika initial window paling penting.
Fokus algoritma pada pemantauan variasi round-trip time untuk mendeteksi kemacetan, daripada hanya mengandalkan packet loss, tidak mengatasi tantangan fundamental dalam memilih titik awal yang tepat tanpa pengetahuan jaringan apa pun.
Algoritma Kontrol Kemacetan yang Disebutkan
- TCP New Reno: Algoritma tradisional berbasis kehilangan data
- CUBIC: Standar default saat ini di sebagian besar sistem
- BBR: Algoritma berbasis penundaan dari Google yang berfokus pada estimasi bandwidth
- TCP Vegas, Reno, TCTP: Berbagai alternatif dengan pendekatan yang berbeda
Miskonsepsi Protokol QUIC
Koreksi teknis yang signifikan muncul mengenai perilaku protokol QUIC. Bertentangan dengan klaim bahwa QUIC menghilangkan congestion window sepenuhnya, protokol tersebut sebenarnya mengimplementasikan algoritma kontrol kemacetan yang sama seperti TCP, termasuk CUBIC dan BBR. QUIC tidak secara ajaib menyelesaikan manajemen bandwidth - protokol ini masih harus menghormati batas kapasitas jaringan.
Implementasi QUIC biasanya menggunakan algoritma kontrol kemacetan yang sama, termasuk CUBIC dan BBR, setidaknya secara nominal.
Ini berarti bahwa bahkan ketika Google dan pemain utama lainnya bermigrasi ke QUIC, tantangan kontrol kemacetan yang mendasari tetap relevan untuk kedua protokol.
Bufferbloat Tetap Menjadi Masalah Nyata
Diskusi mengungkapkan ketidaksepakatan yang berkelanjutan tentang dampak bufferbloat saat ini terhadap performa internet. Sementara beberapa pihak berargumen bahwa ini adalah isu yang terlalu dilebih-lebihkan dari tahun 2010-an, yang lain memberikan contoh konkret dari efeknya yang berkelanjutan. Jaringan mobile, khususnya layanan internet rumah 5G, masih menunjukkan masalah bufferbloat yang signifikan di mana waktu ping melonjak secara dramatis selama transfer data.
Operator jaringan melaporkan kesuksesan menggunakan teknik active queue management seperti fq_codel dan CAKE untuk mengatasi masalah ini, menunjukkan bahwa masalah tersebut tidak hilang tetapi memerlukan perhatian berkelanjutan.
Bufferbloat: Ketika perangkat jaringan menggunakan buffer yang terlalu besar, menyebabkan paket menunggu terlalu lama dalam antrian daripada dijatuhkan, yang mengarah pada peningkatan latensi.
Solusi Active Queue Management
- fq_codel: Fair queuing dengan pengendalian delay
- CAKE: Common Applications Kept Enhanced
- L4S: Low Latency, Low Loss, Scalable Throughput
- Digunakan untuk mengatasi bufferbloat pada peralatan jaringan modern
Tantangan Adopsi Enterprise
Realitas manajemen jaringan enterprise menambahkan lapisan kompleksitas lain. Banyak organisasi menonaktifkan QUIC sepenuhnya, memaksa fallback ke koneksi TCP. Hal ini terjadi karena sebagian besar vendor firewall tidak dapat memeriksa lalu lintas QUIC, menciptakan kekhawatiran keamanan bagi administrator jaringan.
Perilaku enterprise yang meluas ini berarti optimisasi TCP tetap krusial untuk sebagian besar lalu lintas internet, bahkan ketika protokol yang lebih baru mendapat adopsi di lingkungan konsumen.
Komunitas jaringan terus menimbang manfaat potensial dari initial congestion window yang lebih tinggi terhadap risiko peningkatan kemacetan jaringan. Meskipun aplikasi web modern akan mendapat manfaat dari transmisi data awal yang lebih cepat, solusinya memerlukan pertimbangan yang hati-hati terhadap stabilitas jaringan dan keadilan di seluruh pengguna.
Referensi: An Argument for Increasing TCP's Initial Congestion Window... Again