Linux के लिए Multipath TCP (2022)

Multipath TCP का अवलोकन

• Multipath TCP(MPTCP) मानक TCP का एक विस्तार है, जिसका वर्णन RFC 8684 में किया गया है
• यह डिवाइस को एक समय में कई interfaces का उपयोग करके एक single MPTCP connection के माध्यम से TCP packets भेजने और प्राप्त करने की सुविधा देता है
• MPTCP कई interfaces की bandwidth को aggregate कर सकता है या सबसे कम latency वाले interface को प्राथमिकता दे सकता है
• इसके अलावा, यदि एक path डाउन हो जाए तो failover संभव है, और traffic को दूसरे path पर सहज रूप से फिर से भेजा जाता है

MPTCP के उपयोग के मामले

• MPTCP का उपयोग करके कई paths को parallel या एक साथ इस्तेमाल करना संभव होने से TCP की तुलना में नए उपयोग के मामले सामने आते हैं:
  • Seamless handovers: connection को बनाए रखते हुए एक path से दूसरे path पर स्विच करना। Apple 2013 से मुख्य रूप से इसी कारण smartphones में MPTCP का उपयोग कर रहा है。
  • Best network selection: latency, loss, cost, bandwidth आदि कुछ शर्तों के आधार पर "सबसे अच्छा" path उपयोग करना。
  • Network aggregation: अधिक throughput के लिए कई paths का एक साथ उपयोग। उदाहरण: files को अधिक तेज़ी से भेजने के लिए fixed और mobile networks को जोड़ना。

MPTCP की अवधारणा

• IPPROTO_MPTCP protocol (केवल Linux) के साथ नया socket बनाने पर subflows (या paths) बनते हैं, जो सामान्य TCP connections से बने होते हैं और एक interface के माध्यम से data भेजने के लिए उपयोग किए जाते हैं
• अतिरिक्त subflows बाद में hosts के बीच negotiate किए जा सकते हैं
• remote host को MPTCP उपयोग का पता चल सके, इसके लिए base TCP subflow के TCP option field में एक नया field जोड़ा गया है
• इस field में MP_CAPABLE option आदि शामिल होते हैं, जो दूसरे host को बताता है कि यदि वह MPTCP support करता है तो इसका उपयोग करे
• यदि remote host या बीच का middlebox MPTCP support नहीं करता, तो लौटाए गए SYN+ACK packet के TCP option field में MPTCP option शामिल नहीं होगा
• इस स्थिति में connection सामान्य TCP में "downgrade" हो जाता है और single path पर आगे बढ़ता है

यह व्यवहार Path Manager और Packet Scheduler नामक दो आंतरिक components के कारण संभव होता है।

Path Manager

• Path Manager subflows को creation से deletion तक संभालता है और address notifications की भी जिम्मेदारी लेता है
• सामान्यतः client side पर subflows शुरू किए जाते हैं और server side पर ADD_ADDR तथा REMOVE_ADDR options के माध्यम से अतिरिक्त addresses की सूचना दी जाती है
• Linux v5.19 के अनुसार net.mptcp.pm_type sysctl knob से नियंत्रित 2 Path Manager उपलब्ध हैं:
  • in-kernel (type 0): सभी connections पर एक ही नियम लागू करता है (ip mptcp देखें)
  • userspace (type 1): userspace daemon (जैसे mptcpd) द्वारा नियंत्रित, और प्रत्येक connection पर अलग नियम लागू कर सकता है

Packet Scheduler

• Packet Scheduler उपलब्ध subflows में से उस subflow को चुनने का काम करता है जिसका उपयोग अगला data packet भेजने के लिए किया जाएगा
• यह उपलब्ध bandwidth के उपयोग को अधिकतम कर सकता है, या केवल सबसे कम latency वाले path को चुन सकता है, या configuration के अनुसार अन्य नीतियाँ तय कर सकता है
• Linux v6.8 के अनुसार net.mptcp के sysctl knobs द्वारा नियंत्रित केवल एक Packet Scheduler है

MPTCP की प्रमुख विशेषताएँ (Linux v6.10 के अनुसार)

• socket() system call में IPPROTO_MPTCP protocol support
• यदि peer या middlebox MPTCP support नहीं करते, तो MPTCP से TCP पर fallback
• kernel के भीतर या userspace path manager का उपयोग करके path management
• वे socket options जो सामान्यतः TCP sockets में उपयोग किए जाते हैं
• MIB counters, diag support (ss command में उपयोग), और trace points सहित debug features

GN⁺ की राय

• MPTCP तब बहुत उपयोगी तकनीक है जब end device कई networks से जुड़ा हो। इसे 5G-Wi-Fi handover या heterogeneous network aggregation जैसे मामलों में प्रभावी ढंग से इस्तेमाल किया जा सकता है।
• लेकिन MPTCP को support करने वाले server और client, दोनों ओर implementation होना चाहिए, और बीच के network में भी MPTCP support होना चाहिए—यह एक सीमा है। इसके व्यापक रूप से अपनाए जाने में समय लग सकता है।
• Google का QUIC protocol भी इसी तरह की multipath सुविधा देता है, और क्योंकि QUIC अधिक सरल है तथा UDP आधारित है, इसलिए इसके अधिक तेज़ी से फैलने की संभावना है। MPTCP और QUIC के बीच प्रतिस्पर्धा की उम्मीद है।
• kernel-dependent Linux MPTCP implementation के विपरीत, Apple ने userspace में अपना स्वयं का MPTCP implementation बनाया है और उसे iOS तथा macOS में शामिल किया है। Google भी ऐसा ही दृष्टिकोण अपना सकता है।
• यदि MPTCP की path control या scheduling policies को application requirements के अनुरूप optimize करना है, तो application और MPTCP के बीच API के माध्यम से information exchange आवश्यक लगता है। इसके लिए अभी तक कोई standardized तरीका मौजूद नहीं दिखता।

[GN⁺]

Hacker News राय

• जब मैंने 2013 में पहली बार MPTCP के बारे में सुना था, तब mobile apps नेटवर्क बदलावों को संभालने में कमजोर थीं, इसलिए मुझे लगा था कि यह user experience सुधारने में बहुत मददगार होगा, लेकिन 10 साल बाद भी इस पर लगभग कोई ध्यान न दिया जाना बेहद निराशाजनक है
• IPv4 का 32-bit address space और TCP का connection tuple में source/destination IP addresses का इस्तेमाल — इनमें से कौन ज़्यादा दुखद है, समझ नहीं आता। अगर मेरे पास टाइम मशीन होती, तो मैं अतीत में जाकर इन दोनों चीज़ों को बदलना चाहता
• MPTCP का व्यावहारिक उपयोग mobile और Wi‑Fi नेटवर्क को साथ इस्तेमाल करके speed बढ़ाना है, लेकिन mobile data plans की वजह से मैं इसे हमेशा बंद रखता हूँ, इसलिए यह मेरे लिए बेकार है
• अफसोस है कि OpenWrt derived projects जैसे MPTCP का उपयोग करने वाले projects के links नहीं हैं। मैंने 2 साल तक GSOC में एक student को OpenWrt में MPTCP support patch करने के लिए mentor किया
• अगर transparent fallback है, तो समझ नहीं आता कि application की explicit opt-in क्यों ज़रूरी है। सबसे तर्कसंगत यही लगता है कि kernel सभी TCP connections के लिए इसे transparently handle करे और path aggregation/link preference पर global decisions ले
• Linux network stack और drivers को support/debug/fix करने का काम करते हुए मैं MPTCP की कम adoption rate देखकर हैरान हूँ। SCTP की तरह TCP को replace करने की कोशिश करने वाली सारी चीज़ें शायद कुछ गिने-चुने developers तक ही सीमित रह जाती हैं और बाकी दुनिया उन्हें भूल जाती है
• मुझे एक paper मिला जो MPTCP और QUIC के architectural differences, और लेखकों द्वारा प्रस्तावित MPQUIC protocol को समझाता है। QUIC एक single UDP flow पर application streams को multiplex करता है, जबकि MPTCP एक single stream को कई TCP subflows में split करता है। MPQUIC कई UDP subflows पर application streams को multiplex करके इन दोनों क्षमताओं को जोड़ता है
• Apple भी MPTCP को support करता है और इसे Siri में इस्तेमाल कर रहा है
• यह बात काफ़ी सीमित लगती है कि अगर बीच के middleboxes MPTCP option को support नहीं करते, तो SYN+ACK packet में MPTCP option शामिल नहीं होगा। क्या middleboxes की एकमात्र requirement सिर्फ़ MPTCP option को ज्यों का त्यों forward करना है?
• MPTCP security/privacy settings में मददगार हो सकता है। उदाहरण के लिए, अगर traffic को कई uplink channels में बाँट दिया जाए, तो चीन की सरकारी firewall के लिए blocking के मकसद से उस traffic को जोड़ना मुश्किल हो जाता है