QUIC tidak cukup cepat di internet cepat

• QUIC adalah protokol yang diharapkan membawa perubahan besar dalam peningkatan performa aplikasi web, tetapi performanya tidak memenuhi harapan
• Makalah ini menganalisis performa QUIC secara sistematis pada jaringan berkecepatan tinggi

Abstrak

• Pada internet berkecepatan tinggi, stack UDP+QUIC+HTTP/3 menunjukkan penurunan throughput data hingga 45,2% dibanding TCP+TLS+HTTP/2
• Kesenjangan performa antara QUIC dan HTTP/2 makin besar seiring meningkatnya bandwidth dasar
• Masalah ini diamati pada klien transfer data ringan dan browser web utama (Chrome, Edge, Firefox, Opera), beragam host (desktop, mobile), serta berbagai jaringan (broadband kabel, seluler)
• Tidak hanya memengaruhi transfer file, tetapi juga berbagai aplikasi seperti streaming video (penurunan bitrate video hingga 9,8%) dan penjelajahan web
• Akar penyebab diidentifikasi melalui analisis pelacakan paket yang ketat serta profiling kernel dan ruang pengguna
• Secara khusus, overhead pemrosesan di sisi penerima tinggi akibat paket data yang berlebihan dan ACK QUIC di ruang pengguna
• Makalah ini menyajikan rekomendasi konkret untuk mengurangi masalah performa yang diamati

Akar penyebab penurunan performa

• Terjadi overhead pemrosesan paket yang berlebihan pada level kernel di sisi penerima
  • QUIC tidak menggunakan UDP GRO (Generic Receive Offload), sehingga harus memproses jauh lebih banyak paket dibanding TCP
  • Hal ini dikonfirmasi dari jumlah pemanggilan fungsi netif_receive_skb yang jauh lebih banyak pada QUIC
• Overhead pemrosesan paket berlebihan juga terjadi pada ruang pengguna untuk QUIC
  • Ada overhead besar untuk memproses banyak paket yang diteruskan dari kernel
  • Pembuatan ACK QUIC di ruang pengguna juga menjadi penyebab overhead

Usulan untuk mengurangi penurunan performa

• Mengadopsi UDP GRO di sisi penerima
  • Mengurangi jumlah paket yang harus diproses oleh stack UDP sehingga menurunkan overhead kernel dan ruang pengguna
  • Namun, menerapkan UDP GRO di berbagai lingkungan klien mungkin tidak mudah
• Meningkatkan solusi offloading seperti GSO/GRO agar sesuai untuk QUIC
  • Mendukung offloading untuk rangkaian paket UDP dengan ukuran yang berbeda-beda
  • Menambahkan pengaturan pacing yang tepat pada GSO untuk mencegah kemacetan jaringan
• Mengoptimalkan logika QUIC di sisi penerima
  • Menunda pengiriman ACK QUIC untuk mengurangi overhead pembuatan respons
  • Menggunakan recvmmsg untuk membaca beberapa paket UDP sekaligus demi meningkatkan performa
• Menggunakan unduhan multi-thread
  • Untuk file berukuran besar, unduhan multi-thread yang memanfaatkan beberapa inti CPU dapat meningkatkan performa penerimaan
  • Namun, isu fairness perlu dipertimbangkan

[GN⁺]

Opini Hacker News

• antarmuka syscall rumit, dan API dasarnya terlalu lambat dibanding paket berukuran normal (sekitar 1500 byte)
  • GSO membantu, tetapi API-nya rumit dan belakangan ini juga banyak bug
• biaya syscall meningkat karena mitigasi Spectre
  • ada kebutuhan untuk mengganti API BSD socket/POSIX
  • uring itu rumit, tetapi dibutuhkan API tingkat menengah
• buffer UDP sistem secara bawaan terlalu kecil
  • saat ini hanya dipakai para ahli, dan para ahli menyesuaikan konfigurasinya
• optimisasi stack UDP dimungkinkan
  • GSO menunjukkan hal ini, tetapi GSO sendiri mahal dan rumit
• beberapa optimisasi yang tersedia saat ini hanya bekerja pada skala kecil/menengah
  • misalnya, binding koneksi untuk menghindari lookup rute
• menerapkan GSO dapat secara signifikan meningkatkan performa
  • kemungkinan perlu memperbesar ukuran buffer di sisi platform
• pada masa awal QUIC, stack UDP kurang dioptimalkan dibanding stack TCP
  • diperlukan optimisasi seperti generic receive offload untuk UDP
• HTTP/2 juga tampaknya dirilis terlalu terburu-buru
  • Chrome menghapus dukungan server push
  • perlu pemikiran yang lebih matang
• QUIC dan HTTP/2 menunjukkan performa yang mirip saat bandwidth jaringan rendah
  • ketika bandwidth melebihi 500Mbps, performa QUIC menurun
  • ini terutama menjadi masalah di jaringan lokal
• Google cenderung mengalihkan beban pemrosesan ke pengguna
  • misalnya, codec video AV1 didistribusikan saat konsumen belum memiliki kemampuan HW decoding
• makalah penelitiannya ada di arXiv
  • https://arxiv.org/pdf/2310.09423
• ada penyebutan ping dengan RTT 0.23ms
  • pada latensi tinggi pun, QUIC tetap yang terbaik
• membaca RFC9000 sulit dan rumit
  • ide tingkat tinggi QUIC itu sederhana, tetapi spesifikasinya menuntut banyak penanganan kasus khusus
• file PDF gratis untuk riset ini tersedia
  • https://arxiv.org/pdf/2310.09423
• memindahkan protokol koneksi ke ruang pengguna mungkin bukan rencana yang baik