Multipath TCP untuk Linux (2022)

 (mptcp.dev)
1 poin oleh GN⁺ 2024-04-21 | 1 komentar | Bagikan ke WhatsApp
  • MPTCP adalah ekstensi TCP berbasis RFC 8684 yang memungkinkan satu koneksi menggunakan beberapa antarmuka jaringan secara bersamaan untuk meningkatkan bandwidth, latensi, dan ketahanan terhadap gangguan
  • Karena dirancang untuk menggunakan beberapa jalur secara paralel, MPTCP memungkinkan agregasi bandwidth, preferensi untuk jalur berlatensi rendah, dan reinjeksi ke jalur lain saat terjadi kegagalan jalur
  • Di Linux, socket dibuat dengan IPPROTO_MPTCP lalu menyusun koneksi TCP biasa yang disebut subflow; jika pihak lawan atau perangkat perantara tidak mendukungnya, koneksi otomatis turun ke TCP jalur tunggal
  • Untuk pengelolaan jalur, per Linux v5.19 tersedia mode bawaan kernel dan mode daemon ruang pengguna seperti mptcpd, sedangkan per Linux v6.8 hanya ada satu packet scheduler yang dikendalikan lewat sysctl net.mptcp
  • Per Linux v6.10, fiturnya mencakup dukungan socket(), fallback ke TCP, pengelolaan jalur kernel/ruang pengguna, opsi socket TCP, serta fitur debug MIB, diagnostik ss, dan tracepoint

Bagaimana MPTCP mengubah cara kerja koneksi TCP

  • Multipath TCP (MPTCP) adalah ekstensi dari TCP standar yang didefinisikan dalam RFC 8684
  • Satu koneksi MPTCP dapat mengirim dan menerima paket TCP melalui beberapa antarmuka secara bersamaan
  • MPTCP dapat mengagregasikan bandwidth dari beberapa antarmuka atau memprioritaskan antarmuka dengan latensi paling rendah
  • Jika satu jalur terputus, trafik dapat direinjeksikan dengan mulus ke jalur lain untuk melakukan failover
  • Berbeda dengan TCP biasa yang hanya memakai satu jalur pada satu waktu, MPTCP dapat menggunakan beberapa jalur seperti 5G dan Wi‑Fi bersama-sama sebagai subflow

Contoh use case utama

  • Handover tanpa putus

    • Dapat berpindah dari satu jalur ke jalur lain sambil tetap mempertahankan koneksi yang ada
    • Apple telah menggunakan Multipath TCP di smartphone sejak 2013 terutama untuk alasan ini

  • Pemilihan jaringan optimal

    • Memilih jalur “terbaik” di antara jalur yang tersedia berdasarkan kondisi seperti latensi, kehilangan paket, biaya, dan bandwidth

  • Agregasi jaringan

    • Dapat meningkatkan throughput dengan memakai beberapa jalur secara bersamaan
    • Contohnya adalah menggabungkan jaringan tetap dan jaringan seluler untuk mentransfer file lebih cepat

Cara koneksi terbentuk di Linux

  • Saat membuat socket baru dengan protokol khusus Linux IPPROTO_MPTCP, sebuah subflow atau path akan dibuat
  • Subflow adalah koneksi TCP biasa yang mengirim data melalui satu antarmuka
  • Setelah itu, subflow tambahan dapat dibuat melalui negosiasi antar-host
  • Pada field TCP option milik subflow TCP dasarnya, ditambahkan field baru agar host lawan dapat mendeteksi penggunaan MPTCP
    • Field ini mencakup opsi seperti MP_CAPABLE yang memberi tahu pihak lawan bahwa MPTCP sedang digunakan
  • Jika host lawan atau middlebox di tengah tidak mendukung MPTCP, maka field TCP option pada paket SYN+ACK yang dikembalikan tidak akan berisi opsi MPTCP
    • Dalam kasus ini, koneksi akan turun ke TCP biasa dan berlanjut sebagai jalur tunggal

Path manager dan packet scheduler

  • Secara internal, MPTCP membagi tugas pembuatan subflow, pengumuman alamat, dan pemilihan jalur transmisi antara Path Manager dan Packet Scheduler

  • Path Manager

    • Path Manager mengelola subflow dari pembuatan hingga penghapusan, sekaligus 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, dua jenis path manager dikendalikan melalui sysctl knob net.mptcp.pm_type
      • type 0: mode bawaan kernel yang menerapkan aturan yang sama untuk semua koneksi. Terkait dengan ip mptcp
      • type 1: mode ruang pengguna yang dikendalikan daemon seperti mptcpd dan dapat menerapkan aturan berbeda per koneksi

  • Packet Scheduler

    • Packet Scheduler memilih subflow yang akan digunakan untuk mengirim paket data berikutnya
    • Dapat menerapkan kebijakan seperti memaksimalkan bandwidth yang tersedia, hanya memilih jalur dengan latensi lebih rendah, atau kebijakan lain sesuai konfigurasi
    • Per Linux v6.8 hanya ada satu packet scheduler, yang dikendalikan melalui sysctl knob di net.mptcp

Fitur per Linux v6.10

  • Per Linux v6.10, MPTCP menyediakan fitur berikut
    • Dukungan protokol IPPROTO_MPTCP pada system call socket()
    • Fallback dari MPTCP ke TCP ketika pihak lawan atau middlebox tidak mendukung MPTCP
    • Pengelolaan jalur menggunakan path manager bawaan kernel atau ruang pengguna
    • Opsi socket yang umum digunakan pada socket TCP
    • Counter MIB, dukungan diag yang digunakan perintah ss, dan fitur debug termasuk tracepoint
  • Perubahan yang lebih rinci dapat dilihat di ChangeLog

Komunikasi dan proyek terkait

Sumber daya pengembangan kernel

Bacaan terkait

1 komentar

 
GN⁺ 2024-04-21
Pendapat di Hacker News

  • MPTCP sudah pernah saya dengar sejak 2013
    Mengingat saat itu aplikasi mobile tidak terlalu tangguh terhadap perubahan jaringan, saya kira peningkatan UX-nya akan besar sehingga cepat diadopsi
    Namun selama 10 tahun terakhir hampir tidak mendapat traction, dan cukup muram rasanya melihat opsi kernel baru muncul sekarang. Sementara itu semua orang membungkus panggilan HTTP dengan berbagai handler retry, dan sistem operasi mobile mengabstraksikan konektivitas jaringan sedemikian rupa sehingga rasanya lebih mirip memakai zeromq daripada TCP

    • Sepertinya banyak energi inovasi berpindah ke QUIC. Karena di TCP, meskipun varian baru dibuat dengan baik, perangkat perantara bisa merusaknya secara sewenang-wenang
      Lihat contohnya di https://blog.apnic.net/2021/12/08/efficient-multipath-transp...
    • Saya ingin menyukainya dan Apple juga memasukkannya ke iOS, tetapi mendukungnya di server nyata terlalu sulit
      Saat dideploy di FreeBSD tanpa load balancer, patch terbaru tidak tersedia, dan sekalipun ada, perlu cukup banyak pekerjaan agar IP jaringan privat tidak diiklankan sebagai jalur alternatif
      Saat berada di belakang load balancer di Linux, mengirim stream ke tempat yang benar terlalu rumit, dan load balancer juga tidak mau melakukannya
      Menangani dua stream secara bersama-sama berarti memasukkan kompleksitas besar ke jalur throughput tinggi, sehingga risikonya besar, dan perubahan juga membutuhkan reboot
      Setelah semua itu dilakukan, manfaatnya terutama hanya untuk pengguna iOS, padahal mereka sejak awal cenderung memakai jaringan yang lebih baik
    • SCTP yang muncul pada 2000 juga layak diperhatikan. Ini juga hampir belum diadopsi sampai sekarang
      https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
    • Saat membuat robot pengantar, saya berharap pada MPTCP karena ingin melakukan failover instan dengan 2 modem seluler
      Pada akhirnya kami memakai SpeedFusion dari PepLink untuk menghemat waktu pengembangan, tetapi biaya lisensinya mahal. Saya berharap ke depan ada solusi gratis untuk 2 jaringan seluler dan failover di bawah 50 ms
      Multipath UDP + OpenVPN mungkin juga bisa menjadi solusi praktis
    • Justru yang membuat muram adalah ini mendapat perhatian yang sebenarnya tidak layak. Di lingkungan modern, TCP seharusnya digantikan oleh SCTP, bukan terus ditambahi satu per satu hack yang kira-kira cocok hanya untuk sekitar separuh use case lalu membuat orang memilih kombinasinya

  • Saya tidak tahu mana yang lebih menyedihkan: ruang alamat IPv4 yang hanya 32-bit, atau TCP yang memakai alamat IP sumber/tujuan dalam tuple koneksi
    Kalau punya mesin waktu, saya ingin kembali menemui Cerf dan Kahn lalu membuat mereka mengubah keduanya

    • Saya penasaran maksudnya bagaimana ingin mengubah TCP
      Apakah yang dimaksud struktur yang harus melacak koneksi dengan empat field, yaitu alamat IP dan port di kedua sisi?
    • Mereka mungkin akan berkata bahwa mereka sudah memberi kita source routing, yang merupakan setengah dari hal yang diinginkan, dan sudah dispesifikasikan dengan benar sebagai opsi

  • Sayang tidak ada tautan ke proyek yang memakai MPTCP, misalnya proyek turunan OpenWrt
    Saya pernah menjadi mentor mahasiswa selama 2 tahun di GSOC untuk mem-patch MPTCP ke OpenWrt
    https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-sup...

    • Proyek ini mungkin menarik: https://github.com/Ysurac/openmptcprouter
      Baru-baru ini saya membeli properti yang tidak bisa dipasangi jalur fiber penuh, tetapi lewat 5G bisa mendapat 150–400 Mbps. Saya sedang mempertimbangkan memakai 2 koneksi 5G dan men-tunnel trafik dengan MPTCP sampai ke VPS untuk menggabungkan koneksinya
    • Baru-baru ini diaktifkan di kernel Home Assistant HAOS
      https://github.com/home-assistant/operating-system/pull/3248
    • Salah satu contoh di OpenWrt adalah ini
      http://www.openmptcprouter.com/
    • Saya penasaran apa manfaatnya jika router OpenWrt mendukung MPTCP
      Sepertinya yang paling penting adalah dukungan di web server dan perangkat mobile

  • Kalau ada jalur alternatif yang transparan, saya tidak mengerti mengapa aplikasi perlu memilihnya secara eksplisit
    Bukankah kernel seharusnya menanganinya secara transparan untuk semua koneksi TCP agar bisa membuat keputusan global seperti agregasi jalur atau preferensi link dengan lebih baik?

    • Saya memahaminya sebagai syarat yang secara efektif dipaksakan oleh para maintainer subsistem TCP/networking Linux. Dari diskusi upstream awal[1], ini sudah ditetapkan sebagai aturan dasar
      Implementasi multipath TCP lama sebelum upstream memang dimaksudkan agar sepenuhnya transparan bagi aplikasi, dan menurut saya itu lebih sesuai dengan tujuan protokolnya
      Tentu dalam banyak kasus MPTCP bisa lebih baik jika mendapat panduan dari aplikasi, tetapi misalnya pendekatan sistem standar yang hanya membuat subflow pada koneksi LTE untuk menyiapkan failover otomatis tanpa mengirim data melalui subflow itu saja sudah akan cukup untuk 95% kasus
      [1] https://lore.kernel.org/all/alpine.OSX.2.21.1707181728570.11...
    • Menggunakan ini berarti untuk satu koneksi TCP, beberapa IP dapat terhubung di masing-masing endpoint. Dalam banyak kasus, aplikasi perlu mendukung atau menyadarinya secara eksplisit
    • Mengizinkan beberapa IP berkomunikasi di atas koneksi TCP yang sama bisa menciptakan celah keamanan baru
      Misalnya, bayangkan aplikasi yang mencocokkan IP klien dengan whitelist saat koneksi dibuat dan setelah itu berasumsi IP tersebut tidak berubah

  • Bagi saya, satu-satunya kegunaan praktis MPTCP adalah menaikkan kecepatan dengan memakai jaringan seluler dan Wi-Fi secara bersamaan. iOS dan WeChat sama-sama mendukungnya
    Namun jaringan seluler berbasis kuota, jadi selalu saya matikan. Karena itu, secara pribadi MPTCP tidak berguna bagi saya

    • Saya pernah menangani masalah ini. Secara internal kami menyebutnya bug parkiran
      Situasinya sinyal Wi-Fi masih terlihat, tetapi koneksi tidak benar-benar berfungsi. Dengan MPTCP, failover akan berpindah ke seluler

  • Saya bekerja mendukung, men-debug, dan memperbaiki stack jaringan Linux serta driver, dan saya terkejut adopsinya serendah ini
    Seperti SCTP dan hal-hal lain yang pernah mencoba menggantikan TCP biasa, MPTCP tampaknya tetap menjadi teknologi niche yang terus dipakai oleh sebagian pengembang aplikasi, sementara dunia lain melupakannya

    • Apple Siri memakai MPTCP, jadi kalau melihat jumlah perangkatnya, agak sulit menyebutnya sekadar niche

  • Saya menemukan materi yang menjelaskan perbedaan struktural antara MPTCP dan QUIC, sekaligus memperkenalkan protokol MPQUIC yang diusulkan para penulis
    QUIC memultipleks stream aplikasi di atas satu aliran UDP, sedangkan MPTCP membagi satu stream ke beberapa sub-aliran TCP. MPQUIC menggabungkan kedua ciri itu dengan memultipleks stream aplikasi di atas beberapa sub-aliran UDP
    [1]: "Multipath QUIC: A Deployable Multipath Transport Protocol" https://www.researchgate.net/publication/327122884_Multipath...
    Sekarang saya penasaran bagaimana protokol-protokol ini dibandingkan di lingkungan produksi. Ada yang pernah memakai keduanya?

    • MPQUIC masih sedang dibahas di IETF. Pada pertemuan IETF terakhir pun lebih banyak perubahan dibahas, dan sayangnya itu membuat adopsinya melambat
      https://lwn.net/Articles/964377/
      Keduanya berusaha mencapai tujuan yang sama. Secara teknis, perilakunya bisa dibuat sangat mirip. MPTCP diimplementasikan di kernel Linux, sedangkan QUIC berada di sisi user space

  • Apple juga mendukungnya dan menggunakannya untuk Siri
    https://developer.apple.com/documentation/foundation/urlsess...

    • Aplikasi lain juga bisa memakainya dengan cukup mudah. Fitur ini sudah termasuk secara bawaan
      Pada 2011, saya terkejut melihat aplikasi VoIP kami berjalan cukup tangguh :D

  • Jika salah satu perangkat perantara saja tidak mendukungnya, fakta bahwa field opsi TCP pada paket SYN+ACK yang dikembalikan tidak memiliki opsi MPTCP terdengar cukup membatasi
    Apakah satu-satunya persyaratan bagi perangkat perantara adalah meneruskan opsi MPTCP apa adanya?

  • Ini bisa membantu dalam pengaturan keamanan dan privasi
    Misalnya, jika memikirkan Great Firewall Tiongkok, bukankah ketika trafik bisa dibagi ke beberapa kanal uplink, firewall akan menjadi lebih sulit merakitnya kembali untuk penegakan aturan?

    • Kalau trafiknya tidak dikenal, cukup blokir saja atau batasi kecepatannya secara drastis