Mewujudkan Ketepatan Waktu di QUIC tanpa Datagram

• Dalam video live dan percakapan internet, yang penting bukanlah “pengiriman tidak andal” itu sendiri, melainkan membuang data lama dan mengirimkan data terbaru tepat waktu
• Jika router tidak membuang paket yang mengalami kemacetan dan malah menumpuknya lama di antrean, bufferbloat bisa terjadi, dan pada layanan real-time hal ini dapat menimbulkan latensi yang lebih buruk daripada buffering
• Jika membangun protokol langsung di atas UDP, kita harus mengimplementasikan ulang retransmisi, kontrol kemacetan, enkripsi, estimasi RTT, validasi jalur, kontrol aliran, dan lain-lain, sehingga menggunakan library QUIC adalah pilihan yang lebih aman
• Hanya dengan QUIC pun, kita bisa mewujudkan ketepatan waktu tanpa datagram dengan menggabungkan kontrol kemacetan berbasis latensi, pemisahan stream yang independen, dan penetapan prioritas
• Standar QUIC, WebTransport, dan MoQ memang memasukkan dukungan datagram, tetapi kesimpulannya adalah lebih baik mengikuti alur Media over QUIC daripada menumpuk lagi protokol video baru di atas UDP

---

Tujuannya bukan “ketidakandalan”, melainkan ketepatan waktu

• Pilihan antara TCP dan UDP sering dijelaskan sebagai “pengiriman andal” versus “pengiriman tidak andal”, tetapi yang diinginkan aplikasi bukanlah ketidakandalan itu sendiri
• Dalam video live atau percakapan internet, lebih penting data terbaru tiba lebih dulu daripada menerima semua data lama
• Dalam percakapan real-time, kita ingin menghindari situasi seperti spinner buffering muncul di atas wajah atau mendengar suara dari 5 detik yang lalu
• Industri video live dan industri game sering memakai datagram UDP alih-alih stream TCP demi ketepatan waktu seperti ini

Datagram dan antrean jaringan

• Datagram adalah amplop berisi 0 dan 1 yang dikirim dari alamat sumber ke alamat tujuan, dan umumnya 1200 byte dianggap sebagai ukuran yang aman
• Datagram bisa hilang secara diam-diam, dan juga bisa tiba dalam urutan yang berubah
• Pada lapisan fisik, data diubah menjadi sinyal analog yang melewati media, dan proses seperti serialisasi, deserialisasi, buffering, antrean, retransmisi, pembuangan, kerusakan, penundaan, pengurutan ulang, duplikasi, dan kehilangan dapat terjadi
• Jika terlalu banyak data masuk ke jaringan, router tidak membuang bit acak, melainkan membuang data pada batas paket

Bufferbloat dan kontrol kemacetan

• Jika router tidak langsung membuang paket dan malah menumpuknya di antrean, bufferbloat akan terjadi
• bufferbloat dapat menunda semua paket sampai beberapa detik, sehingga menciptakan kondisi terburuk untuk pengiriman real-time
• Untuk menghindari antrean, kita perlu memperkirakan antrean router melalui umpan balik waktu kedatangan paket, lalu pengirim harus mengurangi laju kirim agar antrean kosong
• Ranah ini termasuk kontrol kemacetan, dan mengirim paket dengan kecepatan tak terbatas bisa berujung bencana

Fungsi-fungsi yang harus ditanggung saat membangun langsung di atas UDP

• Jika memakai UDP secara langsung untuk membuat protokol transport, setidaknya fitur berikut diperlukan
  • Retransmisi
  • Kontrol kemacetan
• Untuk membuat protokol yang lebih baik, fitur berikut juga diperlukan
  • Enkripsi
  • Estimasi RTT
  • Validasi jalur
  • Migrasi jalur
  • Pacing
  • Kontrol aliran
  • Negosiasi versi
  • Ekstensi
  • Penetapan prioritas
  • keep-alive
  • Multiplexing
• Untuk meningkatkan kematangan, lingkungan operasional dan deployment juga harus dipertimbangkan
  • Dukungan web
  • Penggunaan ulang port
  • MTU dinamis
  • Multipath
  • Load balancing stateless
  • Load balancing anycast
• Protokol video live seperti WebRTC, SRT, Sye, dan RIST adalah contoh yang dibangun di atas UDP
• Ini mengarah pada kesimpulan bahwa lebih baik memakai library QUIC daripada membuat protokol baru sendiri

Mewujudkan ketepatan waktu dengan stream QUIC

• Cara mencapai ketepatan waktu di QUIC dapat diringkas menjadi tiga hal
  • Menghindari pembengkakan buffer: kontrol kemacetan berbasis latensi seperti BBR mendeteksi antrean dan mengurangi laju kirim
  • transport-wide-cc milik WebRTC dapat dilihat sebagai contoh pendekatan yang lebih baik
  • Pemisahan stream: byte di dalam setiap stream tetap berurutan dan dikirim secara andal, sementara stream dapat menjadi unit atomik seperti frame video, pembaruan game, pesan chat, atau blob JSON
  • Penetapan prioritas stream: karena stream bersifat independen, stream dapat tiba tanpa bergantung pada urutan, dan kita bisa memberi tahu stack QUIC agar lebih dulu mengirimkan stream yang penting
  • Stream berprioritas rendah bisa mengalami starvation, dan bisa ditutup untuk menghindari pemborosan bandwidth
• Pendekatan ini adalah inti dari Media over QUIC
• Sifat fire-and-forget dari datagram hanya cocok saat benar-benar membutuhkan latensi real-time; di luar itu, stream QUIC bisa digunakan

Kompromi dan pengecualian seputar datagram

• QUIC dan standar terkait juga mencakup dukungan datagram
  • QUIC menyediakan dukungan datagram melalui ekstensi
  • WebTransport mewajibkan dukungan datagram
  • Versi terbaru MoQ menambahkan dukungan datagram
  • Versi MoQ berikutnya direncanakan akan mewajibkan dukungan datagram
• Dukungan datagram bisa disertakan karena implementasinya ringan dan memungkinkan eksperimen
• OPUS memiliki dukungan FEC bawaan, sehingga menjadi contoh ketika MoQ mendukung pengiriman setiap “frame” audio sebagai datagram
• Protokol lama seperti DNS bisa dianggap pengecualian, tetapi untuk desain baru, arahnya dinilai lebih baik mengikuti DNS over HTTPS
• Kesimpulannya: daripada membuat lagi protokol video baru di atas UDP, lebih baik berpartisipasi dalam Media over QUIC

[GN⁺]

Komentar Hacker News

• Masalah TCP sering muncul di bidang yang bandwidth-nya besar dan sensitif terhadap latensi seperti HFT atau video, tetapi TCP juga tidak terlalu bagus di jaringan ber-bandwidth rendah dan berlatensi tinggi
  Misalnya, di lingkungan seperti NB-IoT yang dalam skenario terburuk punya latensi pulang-pergi 10 detik, waktu round-trip terbuang untuk handshake dan penelusuran MTU, data yang sudah tidak berguna lagi tetap coba dikirim, dan ketika cakupan memburuk sehingga latensi meningkat, TCP menganggapnya sebagai kehilangan paket akibat kemacetan lalu menurunkan bandwidth
  Selain itu, load balancer atau middlebox bisa memutus koneksi dengan alasan “tidak ada respons selama 4 detik, pasti sudah hilang”, dan karena TCP memecah paket tanpa mempertimbangkan struktur data, hal yang disayangkan adalah data tidak bisa ditafsirkan sampai semuanya diterima
  • TCP mengasumsikan semua data tiba berurutan sebagai stream linear, dan jika paket ke-n tidak diterima, paket ke-(n+1) juga tidak ditampilkan ke aplikasi
    Dalam beberapa kasus ini berguna, tetapi ada banyak kasus ketika paket ke-(n+1) tetap bisa dimanfaatkan meski paket ke-n belum ada
    Untuk transfer file besar, erasure coding bisa menangani kehilangan paket 5% secara otomatis, atau fountain code bisa dipakai untuk terus mengirim sampai penerima mengatakan “sudah terima semua”
    Fountain code adalah cara wahana antariksa jauh mengirim data, dan latensi sampai Jupiter atau Mars cukup serius
  • Ini terutama benar bila memakai TLS, dan saat ini TLS pada praktiknya sudah mendekati default untuk use case utama
    Handshake TLS baru bisa dimulai setelah handshake TCP selesai, tetapi QUIC memiliki dukungan tingkat protokol untuk menangani negosiasi TLS di dalam handshake awal
    Menggabungkan protokol jaringan dan enkripsi secara longgar mungkin tampak lebih elegan, tetapi di dunia ketika hampir semua transmisi kini dienkripsi, keuntungan praktis berupa pengurangan satu waktu round-trip per koneksi tampak lebih besar
  • Saya penasaran apakah sekarang lapisan Wi-Fi di bawah TCP juga sering melakukan retransmisi sendiri untuk loss yang terjadi akibat sinyal lemah atau banyak noise
  • Saya penasaran apakah NB-IoT benar-benar masih digunakan sekarang. Saya ingat dulu sempat sangat digembar-gemborkan, tetapi setelah itu rasanya tidak lagi ramai dibicarakan
• Untuk streaming data sensor berfrekuensi tinggi, kami cukup memakai datagram UDP
  Di sisi R&D kami membuat sistem baru yang memakai QUIC dan menyelesaikan sebagian besar masalah kedatangan yang urutannya terbalik, tetapi sensor pihak ketiga yang harus didukung langsung tanpa adaptor hanya bisa UDP, jadi kami masih memakai datagram UDP untuk semuanya
  • Sistem media art di seluruh dunia juga hampir semuanya memakai OSC di atas UDP
  • Saya terpikir soal data sensor berfrekuensi tinggi, dan penasaran apakah ada angka penghematan daya dibanding TCP
  • Saya penasaran sistem itu dibuat dengan bahasa apa. Cukup keren
  • Untuk mendapatkan reliabilitas di atas UDP, sebenarnya bisa juga memakai RoCE
• Ini mungkin terlihat seperti mempermasalahkan hal kecil, tetapi saya menganggap penyebutan UDP sebagai unreliable itu bermasalah
  Istilah yang lebih umum dan lebih baik adalah best-effort; UDP berusaha sebaik mungkin untuk mengirimkan datagram, hanya saja datagram bisa dibuang
  Itu tidak berarti UDP pada dasarnya tidak bisa dipercaya
  https://en.wikipedia.org/wiki/Best-effort_delivery
  • best-effort adalah ungkapan yang eufemistis dan membingungkan bagi orang di luar bidang ini, dan bagi penutur asli bahasa Inggris pun bisa jadi justru lebih begitu
    Makna sebenarnya bukan bahwa ia berjuang habis-habisan untuk mengirim pesan dari A ke B, melainkan lebih dekat ke “sudah dicoba”
    Jika router di jalur sedang padat atau link flap membuat black hole sekitar 50 ms sebelum rerouting cepat, hasilnya kira-kira “yah, sudah dicoba”
    Sebaliknya, pengiriman andal TCP mencoba ulang berkali-kali dan menyediakan stream data yang berurutan kepada aplikasi
    reliable/unreliable mungkin juga istilah yang buruk, tetapi sulit mengatakan best-effort lebih baik
    Sistem yang tidak andal bisa sangat bagus sekitar 95% dan juga baik untuk throughput mentah, tetapi 5% terakhir sering kali membuat perbedaan yang sangat besar
  • Dalam networking, best effort delivery adalah istilah pengelakan yang tidak lebih baik dari unreliable, sampai-sampai layak dihapus
    “Upaya” biasanya menyiratkan tingkat kegigihan tertentu saat menghadapi kesulitan, tetapi membuang paket karena ada masalah resource sulit disebut sebagai upaya, apalagi best effort
    Dalam istilah hukum dan bisnis, “best efforts” memang lebih lemah daripada janji pasti tetapi bukan berarti terang-terangan lepas tangan, sedangkan pemakaiannya dalam networking cukup berbeda
    Terpisah dari itu, checksum UDP dan TCP juga tidak menjamin integritas dengan baik ketika datagram terkirim, hanya sedikit lebih baik daripada hardware
  • Saya kira “datagram bisa dibuang” justru adalah arti dari unreliable, jadi saya kurang paham kesalahpahaman apa yang ingin dihindari
  • Menyebut lapisan transport sebagai unreliable bukan ungkapan yang baik. Reliabilitas adalah sifat sistem, bukan metode transport; dengan TCP pun bisa dibuat sistem yang tidak andal, dan dengan UDP pun bisa dibuat sistem yang andal
    Namun best-effort memberi kesan ada semacam upaya untuk menjamin pengiriman, padahal kenyataannya paket yang tampak aneh atau sial bertemu buffer penuh langsung dibuang
    Saya suka lossy, tetapi ini termasuk masalah penamaan dalam “hanya ada dua masalah sulit”
  • Sejak tahun 80-an sudah disebut unreliable transport, dan memang itu tepat
    Jika paket harus sampai, pakai TCP; jika tidak terlalu penting, pakai UDP
    Ini memang penjelasan yang disederhanakan, tetapi best effort adalah istilah bodoh, dan tidak ada effort di sana
• Menurut saya abstraksi stream membuat terlalu mudah bagi orang untuk membuat program rapuh yang lambat pulih atau bahkan tidak bisa pulih saat koneksi terputus, dan juga memberi terlalu banyak batasan pada lapisan transport
  Congestion control jelas diperlukan, tetapi selain itu ada banyak hal yang saya ragukan
  Dalam dunia yang mengutamakan datagram, menggabungkan beberapa data link dengan sangat efisien atau roaming melintasi batas jaringan tanpa memutus koneksi seharusnya bukan masalah
  Banyak aplikasi bisa menangani frame yang urutannya terbalik tanpa biaya tambahan, dan jika ditulis sesuai model UDP, aplikasi bisa menjadi jauh lebih cepat
  • Argumennya adalah TCP terlalu nyaman sehingga software tidak ditulis dengan benar, tetapi lalu kita harus percaya bahwa dalam dunia yang mengutamakan datagram yang jauh lebih kompleks, software yang benar-benar tangguh dan efisien akan muncul; ini kurang meyakinkan
    Kenyataannya, berpindah ke metode transport yang reliabilitasnya lebih rendah tidak otomatis membuat software menjadi lebih andal atau efisien

Justru, mode kegagalan dan kompleksitas yang harus ditangani tim meningkat pesat

• Pada aplikasi yang memiliki kode koreksi kesalahan yang memadai, kontrol kemacetan pun bisa menjadi opsional
  Namun jika ada bottleneck sempit di suatu titik koneksi, rasanya tidak banyak gunanya menghasilkan sangat banyak paket yang toh akan dibuang di bottleneck itu
• Saya penasaran jenis aplikasi seperti apa yang dibayangkan. Dari sistem yang saat ini umum ditulis dengan TCP, apa yang bisa diubah ke UDP?
  Situs web, audio, dan video umumnya tidak cocok dengan frame yang urutannya terbalik, dan kebanyakan orang tidak ingin audio atau video tersendat
  Sebagian gim video boleh saja mengabaikan paket yang hilang, tetapi kasus seperti itu memang sudah ditulis dengan UDP
• Hal yang jarang disebut adalah bahwa ketika terjadi kemacetan, banyak jaringan membuang paket UDP lebih dulu
  Alasannya, paket seperti itu tidak akan ditransmisikan ulang, sehingga dianggap cara efektif untuk mengurangi trafik berlebih
  Sekarang ada protokol-protokol di atas UDP yang melakukan retransmisi secara agresif; saya penasaran bagaimana ini mengubah situasinya
  Saya juga ingat beberapa tahun lalu QUIC mengalami masalah retransmisi dibanding HTTP/1·HTTP/2 karena hal ini
• Saya mencoba mengganti judul clickbait dengan memakai ungkapan dari artikelnya sendiri
  Jika ada frasa yang lebih representatif di artikel, judul bisa diganti lagi
  Ini mengikuti pedoman judul HN, yaitu “gunakan judul asli, kecuali jika menyesatkan atau bersifat umpan klik”: https://news.ycombinator.com/newsguidelines.html
• Saya tidak setuju dengan premis tulisan ini. UDP bukan untuk ketidakandalan itu sendiri, melainkan kompromi: memilih pengiriman best-effort alih-alih jaminan demi mendapatkan kecepatan dan efisiensi
  Tergantung aplikasinya, itu masuk akal
  Misalnya dalam gim multiplayer real-time, jika pemrosesan tertinggal, item yang tertinggal tidak lagi penting karena status gim sudah berubah
  Aplikasi high-frequency trading juga, dalam situasi tertentu, hanya peduli pada data pasar terbaru, bukan apa yang terjadi 100 ms lalu
  • Itu bukan premis tulisan, melainkan anggapan umum yang kemudian langsung diluruskan oleh penulis
    Tulisan itu juga memberi contoh gim dan video live sebagai kasus yang cocok untuk UDP
  • Jika terus membaca, pada dasarnya tulisan itu juga mengatakan hal yang sama
    Strukturnya adalah mula-mula menyajikan “anggapan umum”, lalu membantahnya
• Hal-hal yang memang harus berbasis datagram adalah discovery lokal, broadcast, dan enkapsulasi paket
  Contohnya termasuk discovery lokal seperti DHCP, SLAAC, UPnP, mDNS, tinc, BitTorrent; broadcast seperti streaming jaringan lokal; serta enkapsulasi seperti WireGuard, IPSec, OpenVPN, dan VLAN
  • Ada yang terlewat: media real-time
    Retransmisi, bahkan buffering untuk menyusun ulang urutan saja, akan menambah latensi, jadi lebih baik menerima loss dengan koreksi kesalahan atau penyamaran kehilangan paket
  • Dari sudut pandang orang yang tidak punya banyak pengetahuan jaringan tingkat rendah, saya penasaran apakah bisa dijelaskan mengapa use case seperti ini membutuhkan datagram
  • Gim juga termasuk
• Judulnya clickbait yang bodoh, dan penulisnya juga mengakuinya di awal
  UDP dan TCP memiliki perilaku serta trade-off yang berbeda, jadi yang penting hanyalah memahaminya sebelum memilih sesuai use case
  Tidak perlu gatekeeping ala “jangan pernah melakukan X”
  • Kecuali tanda bintang di depan “never” pada judul ditambahkan dalam 10 menit setelah komentar itu muncul, tanda bintang itu jelas menunjukkan bahwa ada ketentuan detail
    Dari judul saja cukup jelas bahwa tulisan ini bukan sedang melakukan gatekeeping agar orang tidak memakai UDP
    Bahkan di bagian akhir, penulis menyarankan penggunaan QUIC yang berbasis UDP
• Sebagian besar aplikasi dan kasus akan memakai koneksi berbasis sesi, tetapi ada juga kegunaan untuk memakai datagram secara langsung, jadi tidak perlu takut
  Tentu saja, ada jauh lebih banyak detail yang harus diurus sendiri
  Sebagai bonus, ini juga cara yang bagus untuk mempelajari aspek tingkat rendah dari networking
  • SteamNetworkingMessages API untuk pengembangan gim memungkinkan pendekatan seperti ini dipakai dengan baik untuk use case tersebut tanpa perlu memikirkan bagian internalnya