Multipath TCP untuk Linux (2022)

Gambaran umum Multipath TCP

• Multipath TCP (MPTCP) adalah ekstensi dari TCP standar dan dijelaskan dalam RFC 8684
• Memungkinkan perangkat menggunakan beberapa antarmuka sekaligus untuk mengirim dan menerima paket TCP melalui satu koneksi MPTCP tunggal
• MPTCP dapat menggabungkan bandwidth dari beberapa antarmuka atau memprioritaskan antarmuka dengan latensi paling rendah
• Selain itu, meskipun satu jalur down, failover tetap dimungkinkan dan trafik akan diinjeksi ulang ke jalur lain secara mulus

Kasus penggunaan MPTCP

• Dengan MPTCP, beberapa jalur dapat digunakan secara paralel atau bersamaan, sehingga muncul kasus penggunaan baru dibandingkan TCP:
  • Seamless handovers: berpindah dari satu jalur ke jalur lain sambil tetap mempertahankan koneksi. Apple telah lama menggunakan MPTCP terutama di smartphone untuk alasan ini sejak 2013.
  • Best network selection: menggunakan jalur yang "terbaik" berdasarkan kondisi tertentu seperti latensi, loss, biaya, bandwidth, dan lain-lain.
  • Network aggregation: menggunakan beberapa jalur secara bersamaan untuk throughput yang lebih tinggi. Contoh: menggabungkan jaringan tetap dan seluler agar file dapat dikirim lebih cepat.

Konsep MPTCP

• Saat membuat socket baru dengan protokol IPPROTO_MPTCP (khusus Linux), akan dibuat subflow (atau jalur) yang terdiri dari koneksi TCP biasa yang digunakan untuk mentransmisikan data melalui satu antarmuka
• Subflow tambahan dapat dinegosiasikan kemudian antara host
• Field baru ditambahkan ke field opsi TCP pada subflow TCP dasar agar host jarak jauh dapat mendeteksi penggunaan MPTCP
• Field ini mencakup opsi seperti MP_CAPABLE yang memberi tahu host lain untuk menggunakannya jika mendukung MPTCP
• Jika host jarak jauh atau middlebox di tengah tidak mendukung MPTCP, field opsi TCP pada paket SYN+ACK yang dikembalikan tidak akan menyertakan opsi MPTCP
• Dalam kasus ini, koneksi akan "diturunkan" menjadi TCP biasa dan berlanjut melalui satu jalur tunggal

Perilaku ini dimungkinkan berkat dua komponen internal, yaitu Path Manager dan Packet Scheduler.

Path Manager

• Path Manager menangani subflow dari pembuatan hingga penghapusan, serta juga menangani pengumuman alamat
• Umumnya, sisi klien memulai subflow dan sisi server mengumumkan alamat tambahan melalui opsi ADD_ADDR dan REMOVE_ADDR
• Per Linux v5.19, ada 2 Path Manager yang dikendalikan oleh sysctl knob net.mptcp.pm_type:
  • in-kernel (tipe 0): menerapkan aturan yang sama ke semua koneksi (lihat ip mptcp)
  • userspace (tipe 1): dikendalikan oleh daemon ruang pengguna (misalnya mptcpd) dan dapat menerapkan aturan berbeda untuk tiap koneksi

Packet Scheduler

• Packet Scheduler bertugas memilih subflow mana di antara subflow yang tersedia yang akan digunakan untuk mengirim paket data berikutnya
• Dapat memaksimalkan penggunaan bandwidth yang tersedia, hanya memilih jalur dengan latensi paling rendah, atau menentukan kebijakan lain sesuai konfigurasi
• Per Linux v6.8, hanya ada satu Packet Scheduler yang dikendalikan oleh sysctl knob net.mptcp

Fitur utama MPTCP (per Linux v6.10)

• Dukungan protokol IPPROTO_MPTCP pada system call socket()
• Fallback dari MPTCP ke TCP jika peer atau middlebox tidak mendukung MPTCP
• Manajemen jalur menggunakan path manager di dalam kernel atau di ruang pengguna
• Opsi socket yang umum digunakan pada socket TCP
• Fitur debug termasuk counter MIB, dukungan diag (digunakan oleh perintah ss), dan tracepoint

Opini GN⁺

• MPTCP adalah teknologi yang sangat berguna ketika perangkat terhubung ke beberapa jaringan. Dapat dimanfaatkan secara efektif untuk handover 5G-Wi-Fi atau agregasi jaringan heterogen.
• Namun, ada keterbatasan karena MPTCP harus diimplementasikan di kedua sisi, baik server maupun klien, dan jaringan perantara juga harus mendukung MPTCP. Karena itu, tampaknya akan butuh waktu hingga menjadi umum.
• Protokol QUIC milik Google juga menyediakan fungsi multipath serupa, dan karena QUIC lebih sederhana serta berbasis UDP, diperkirakan penyebarannya akan lebih cepat. Persaingan antara MPTCP dan QUIC diperkirakan akan terjadi.
• Berbeda dengan implementasi MPTCP untuk Linux yang bergantung pada kernel, Apple secara mandiri mengimplementasikan MPTCP di user space dan memasangnya di iOS dan macOS. Google juga tampaknya berpotensi mengambil pendekatan serupa.
• Agar kontrol jalur dan kebijakan penjadwalan MPTCP dapat dioptimalkan untuk kebutuhan aplikasi, tampaknya dibutuhkan pertukaran informasi melalui API antara aplikasi dan MPTCP. Sejauh ini, tampaknya belum ada pendekatan yang terstandarisasi untuk hal tersebut.

[GN⁺]

Opini Hacker News

• Saat pertama kali mendengar tentang MPTCP pada 2013, saya pikir ini akan sangat membantu meningkatkan pengalaman pengguna karena aplikasi mobile saat itu lemah dalam menangani perubahan jaringan, tetapi sangat mengecewakan karena setelah 10 tahun pun teknologi ini hampir tidak mendapat perhatian
• Saya tidak tahu mana yang lebih menyedihkan: ruang alamat 32-bit IPv4, atau fakta bahwa TCP menggunakan alamat IP sumber/tujuan dalam tuple koneksi. Jika punya mesin waktu, saya ingin kembali ke masa lalu dan mengubah dua hal itu
• Penggunaan praktis MPTCP adalah memakai jaringan seluler dan Wi‑Fi bersama-sama untuk meningkatkan kecepatan, tetapi karena paket data seluler, saya pribadi selalu mematikannya jadi tidak berguna
• Disayangkan tidak ada tautan ke proyek-proyek yang menggunakan MPTCP, seperti proyek turunan OpenWrt. Selama 2 tahun saya membimbing mahasiswa di GSOC yang membuat patch dukungan MPTCP untuk OpenWrt
• Jika ada fallback transparan, saya jadi bertanya-tanya mengapa aplikasi perlu explicit opt-in. Rasanya paling masuk akal jika kernel menanganinya secara transparan untuk semua koneksi TCP dan membuat keputusan global tentang agregasi jalur/preferensi link
• Saya bekerja mendukung/debugging/memperbaiki stack jaringan dan driver Linux, dan terkejut dengan rendahnya tingkat adopsi MPTCP. Sepertinya semua hal yang mencoba menggantikan TCP yang sudah ada, seperti SCTP, ditakdirkan hanya dipakai segelintir developer lalu dilupakan oleh dunia lainnya
• Saya menemukan makalah yang menjelaskan perbedaan arsitektur antara MPTCP dan QUIC, serta protokol MPQUIC yang diusulkan penulis. QUIC memultipleks stream aplikasi ke dalam satu aliran UDP, sedangkan MPTCP membagi satu stream menjadi beberapa subflow TCP. MPQUIC menggabungkan keduanya dengan memultipleks stream aplikasi ke beberapa subflow UDP
• Apple juga mendukung MPTCP dan menggunakannya untuk Siri
• Tampaknya cukup membatasi bahwa jika middlebox di tengah tidak mendukung opsi MPTCP, maka opsi MPTCP tidak akan disertakan dalam paket SYN+ACK. Apakah satu-satunya persyaratan untuk middlebox hanyalah meneruskan opsi MPTCP apa adanya?
• MPTCP dapat membantu pengaturan keamanan/privasi. Misalnya, jika trafik dibagi ke beberapa kanal uplink, firewall pemerintah Tiongkok akan lebih sulit menggabungkan trafik tersebut untuk melakukan pemblokiran