Linux के लिए Multipath TCP (2022)

 (mptcp.dev)
1 पॉइंट द्वारा GN⁺ 2024-04-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • MPTCP RFC 8684 पर आधारित TCP extension है, जिसमें एक connection कई network interfaces को एक साथ इस्तेमाल करके bandwidth, latency और failure handling को बेहतर बनाता है
  • कई paths को parallel में इस्तेमाल करने वाली संरचना होने के कारण bandwidth aggregation, कम latency वाले path को प्राथमिकता देना, और path failure होने पर दूसरे path में reinjection संभव है
  • Linux में IPPROTO_MPTCP से socket बनाया जाता है और सामान्य TCP connection वाले subflow कॉन्फ़िगर किए जाते हैं; अगर peer या बीच के उपकरण support न करें, तो यह अपने-आप single-path TCP पर fallback हो जाता है
  • path management के लिए Linux v5.19 के आधार पर kernel built-in तरीका और mptcpd जैसे user-space daemon तरीका है, और Linux v6.8 के आधार पर packet scheduler सिर्फ़ एक है जिसे net.mptcp sysctl से नियंत्रित किया जाता है
  • Linux v6.10 के आधार पर features में socket() support, TCP fallback, kernel/user-space path management, TCP socket options, MIB·ss diagnostics·tracepoint debug features शामिल हैं

MPTCP TCP connection के तरीके को कैसे बदलता है

  • Multipath TCP(MPTCP) मानक TCP का एक extension है, जिसे RFC 8684 में परिभाषित किया गया है
  • एक MPTCP connection कई interfaces का एक साथ इस्तेमाल करके TCP packets भेज और प्राप्त कर सकता है
  • कई interfaces की bandwidth aggregate की जा सकती है या सबसे कम latency वाले interface को प्राथमिकता दी जा सकती है
  • अगर एक path टूट जाए, तो traffic को दूसरे path में सहजता से reinject करके failover किया जाता है
  • जहाँ सामान्य TCP एक समय में सिर्फ़ एक path का इस्तेमाल करता है, वहीं MPTCP 5G और Wi‑Fi जैसे कई paths को subflow के रूप में साथ इस्तेमाल कर सकता है

प्रमुख उपयोग के मामले

  • बिना रुकावट handover

    • मौजूदा connection को बनाए रखते हुए एक path से दूसरे path पर स्विच किया जा सकता है
    • Apple 2013 से smartphones में मुख्य रूप से इसी वजह से Multipath TCP का इस्तेमाल कर रहा है

  • सर्वश्रेष्ठ network चयन

    • latency, loss, cost, bandwidth जैसी शर्तों के आधार पर उपलब्ध paths में से “सबसे अच्छा” path चुना जाता है

  • network aggregation

    • कई paths को एक साथ इस्तेमाल करके throughput बढ़ाया जा सकता है
    • fixed-line और mobile network को जोड़कर files को तेज़ी से transfer करना इसका एक उदाहरण है

Linux में connection कैसे स्थापित होता है

  • Linux-विशेष IPPROTO_MPTCP protocol से नया socket बनाने पर subflow या path बनाया जाता है
  • subflow एक सामान्य TCP connection है, जो एक interface के माध्यम से data भेजता है
  • इसके बाद hosts के बीच negotiation के ज़रिए अतिरिक्त subflow बनाए जा सकते हैं
  • underlying TCP subflow के TCP option field में नए fields जोड़े जाते हैं ताकि दूसरा host MPTCP उपयोग का पता लगा सके
    • इन fields में MP_CAPABLE option जैसी चीज़ें शामिल होती हैं, जो peer को MPTCP उपयोग की जानकारी देती हैं
  • अगर peer host या बीच का middlebox MPTCP support नहीं करता, तो लौटने वाले SYN+ACK packet के TCP option field में MPTCP option नहीं होगा
    • इस स्थिति में connection सामान्य TCP पर fallback होकर single path पर जारी रहता है

Path Manager और Packet Scheduler

  • MPTCP अंदरूनी रूप से Path Manager और Packet Scheduler के बीच subflow creation, address announcement, और transmission path selection का काम बाँटता है

  • Path Manager

    • Path Manager subflow की creation से deletion तक प्रबंधन करता है और address announcement भी संभालता है
    • सामान्यतः client side subflow शुरू करता है, और server side ADD_ADDR तथा REMOVE_ADDR options के ज़रिए अतिरिक्त addresses announce करता है
    • Linux v5.19 के आधार पर net.mptcp.pm_type sysctl knob से दो तरह के path manager नियंत्रित किए जाते हैं
      • type 0: kernel built-in तरीका, जो सभी connections पर एक जैसे rules लागू करता है। यह ip mptcp से संबंधित है
      • type 1: user-space तरीका, जिसे mptcpd जैसे daemon नियंत्रित करते हैं और connection-दर-connection अलग rules लागू किए जा सकते हैं

  • Packet Scheduler

    • Packet Scheduler यह चुनता है कि अगला data packet भेजने के लिए कौन-सा subflow इस्तेमाल होगा
    • यह उपलब्ध bandwidth को अधिकतम कर सकता है, कम latency वाले paths को चुन सकता है, या configuration के अनुसार दूसरी policies लागू कर सकता है
    • Linux v6.8 के आधार पर packet scheduler सिर्फ़ एक है, और इसे net.mptcp के sysctl knob से नियंत्रित किया जाता है

Linux v6.10 के आधार पर features

  • Linux v6.10 के आधार पर MPTCP ये features प्रदान करता है
    • socket() system call में IPPROTO_MPTCP protocol support
    • जब peer या middlebox MPTCP support न करे, तब MPTCP से TCP में fallback
    • kernel built-in या user-space path manager का उपयोग करने वाला path management
    • TCP sockets में सामान्यतः इस्तेमाल होने वाले socket options
    • MIB counters, ss command द्वारा उपयोग किया जाने वाला diag support, और tracepoint सहित debug features
  • विस्तृत बदलाव ChangeLog में देखे जा सकते हैं

communication और संबंधित projects

kernel development resources

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-21
Hacker News टिप्पणियाँ

  • MPTCP के बारे में मैंने 2013 में ही सुन लिया था
    उस समय मोबाइल ऐप्स नेटवर्क बदलने पर इतने मज़बूत नहीं थे, इसे देखते हुए लगा था कि UX में बड़ा सुधार होगा और यह जल्दी अपनाया जाएगा
    लेकिन पिछले 10 सालों में इसे लगभग कोई traction नहीं मिला, और अब जाकर kernel option दिखना काफ़ी निराशाजनक है। इस बीच सबने HTTP calls को तरह-तरह के retry handlers में लपेट लिया, और mobile operating systems ने network connectivity को इतना abstract कर दिया कि यह TCP से ज़्यादा zeromq इस्तेमाल करने जैसा लगने लगा

    • लगता है काफ़ी innovation energy QUIC की तरफ़ चली गई। TCP में नया variant अच्छे से बना भी लो, तब भी बीच के network devices उसे मनमाने तरीके से तोड़ सकते हैं
      उदाहरण के लिए https://blog.apnic.net/2021/12/08/efficient-multipath-transp... देखें
    • मैं इसे पसंद करना चाहता था, और Apple ने इसे iOS में डाला भी, लेकिन असली servers पर इसे support करना बहुत मुश्किल था
      FreeBSD पर बिना load balancer के deploy किया था, तब latest patch नहीं थे, और अगर होते भी, तब भी private network IP को alternate path के रूप में advertise होने से रोकने के लिए काफ़ी काम करना पड़ता
      Linux में load balancer के पीछे होने पर streams को सही जगह भेजना बहुत जटिल था, और load balancer भी यह करना नहीं चाहता था
      दोनों streams को साथ handle करना high-throughput path में बहुत complexity जोड़ता है, इसलिए जोखिम बड़ा है, और बदलाव के लिए reboot भी चाहिए
      यह सब करने के बाद भी फायदा मुख्यतः iOS users को ही मिलता, और वे तो वैसे भी आम तौर पर बेहतर network इस्तेमाल करते हैं
    • 2000 में आया SCTP भी देखने लायक है। इसे भी अब तक लगभग अपनाया नहीं गया
      https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
    • delivery robot बनाते समय मैं 2 cellular modems के साथ तुरंत failover चाहता था, इसलिए MPTCP से उम्मीद थी
      आखिर में development time बचाने के लिए PepLink का SpeedFusion इस्तेमाल किया, लेकिन license cost महँगी थी। उम्मीद है आगे चलकर 2 cellular networks और 50ms से कम failover के लिए कोई मुफ्त solution आएगा
      multipath UDP + OpenVPN भी शायद एक practical solution हो सकता है
    • उल्टा यह निराशाजनक है कि इसे ऐसा ध्यान मिल रहा है जिसका यह हक़दार नहीं है। आधुनिक माहौल में TCP को आधे-अधूरे use cases के लिए एक-एक और hack जोड़ते रहने और combinations को balanced बनाने की बजाय, इसे SCTP से replace किया जाना चाहिए

  • यह समझ नहीं आता कि IPv4 address space का सिर्फ़ 32-bit होना ज़्यादा दुखद है या TCP का connection tuple में source/destination IP addresses का इस्तेमाल करना
    अगर time machine होती, तो Cerf और Kahn के पास जाकर दोनों चीज़ें बदलवाना चाहता

    • जानना चाहूँगा कि TCP को कैसे बदलने की बात हो रही है
      क्या मतलब यह है कि connection को दोनों तरफ़ के IP addresses और ports, यानी 4 fields से track करने वाली संरचना बदलनी चाहिए?
    • वे शायद कहेंगे कि उन्होंने पहले ही source routing दे दिया था, और वही आपकी चाही चीज़ का आधा हिस्सा है, साथ ही option के रूप में ठीक से specify भी किया गया है

  • अफ़सोस है कि MPTCP इस्तेमाल करने वाले projects, जैसे OpenWrt derivative projects, के links नहीं हैं
    GSOC में 2 साल तक students को mentor करते हुए मैंने OpenWrt में MPTCP patch किया था
    https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-sup...

    • यह project दिलचस्प हो सकता है: https://github.com/Ysurac/openmptcprouter
      मैंने हाल ही में ऐसी property खरीदी है जहाँ पूरी fiber line नहीं मिल सकती, लेकिन 5G पर 150~400Mbps मिल जाता है। मैं 2 5G lines लेकर MPTCP के साथ traffic को VPS तक tunnel करके lines को combine करने का सोच रहा हूँ
    • हाल ही में Home Assistant HAOS kernel में enable किया गया है
      https://github.com/home-assistant/operating-system/pull/3248
    • OpenWrt पर एक उदाहरण यह है
      http://www.openmptcprouter.com/
    • जानना चाहूँगा कि OpenWrt router पर MPTCP support होने से क्या फ़ायदा है
      लगता है web servers और mobile devices पर support होना सबसे ज़रूरी होगा

  • अगर transparent alternate path मौजूद है, तो समझ नहीं आता कि application की explicit choice क्यों चाहिए
    क्या kernel को सभी TCP connections के लिए इसे transparently handle नहीं करना चाहिए, ताकि path aggregation या link preference जैसे global decisions बेहतर तरीके से लिए जा सकें?

    • मेरी समझ में Linux TCP/networking subsystem maintainers ने इसे लगभग अनिवार्य शर्त की तरह थोप दिया था। शुरुआती upstream discussion[1] देखें तो यही default rule जैसा था
      upstream से पहले की पुरानी multipath TCP implementation का इरादा application के लिए पूरी तरह transparent होना था, और मुझे लगता है कि protocol के उद्देश्य से वही ज़्यादा मेल खाता है
      बेशक कई मामलों में application guidance मिलने पर MPTCP बेहतर हो सकता है, लेकिन उदाहरण के लिए LTE connection पर subflow बनाकर automatic failover के लिए तैयार रखना, पर उस subflow से data न भेजना—ऐसा standard system approach ही 95% मामलों के लिए काफ़ी होता
      [1] https://lore.kernel.org/all/alpine.OSX.2.21.1707181728570.11...
    • इसका इस्तेमाल करने का मतलब है कि एक TCP connection के लिए दोनों endpoints पर कई IPs जुड़े हो सकते हैं। कई मामलों में application का explicit support या awareness ज़रूरी हो जाता है
    • एक ही TCP connection पर कई IPs से communication की अनुमति देने पर नए security holes पैदा हो सकते हैं
      उदाहरण के लिए ऐसा application सोचें जो connection बनते समय client IP को whitelist से match करता हो और उसके बाद मान ले कि वह बदलेगा नहीं

  • मेरे लिए MPTCP का एकमात्र व्यावहारिक उपयोग मोबाइल नेटवर्क और Wi‑Fi को साथ में इस्तेमाल करके स्पीड बढ़ाना है। iOS और WeChat दोनों इसे support करते हैं
    लेकिन मोबाइल नेटवर्क metered होता है, इसलिए मैं इसे हमेशा बंद रखता हूँ। इसलिए व्यक्तिगत तौर पर MPTCP मेरे किसी काम का नहीं है

    • मैंने इस समस्या से निपटा है। हम इसे अंदरूनी तौर पर parking lot bug कहते थे
      ऐसी स्थिति जहाँ Wi‑Fi signal अभी भी दिखता है, लेकिन असल में सही से connect नहीं होता। MPTCP होने पर cellular पर failover हो जाता है

  • मैं Linux network stack और drivers को support, debug और patch करने का काम करता हूँ, इसलिए इसका इतना कम adoption होना हैरान करने वाला है
    SCTP की तरह, जो सामान्य TCP को replace करने की कोशिश करने वाली चीज़ों में से एक था, MPTCP भी शायद एक niche technology बनकर रह जाता है, जिसे कुछ application developers इस्तेमाल करते रहते हैं और बाकी दुनिया भूल जाती है

    • Apple Siri MPTCP का उपयोग करता है, इसलिए devices की संख्या देखें तो इसे पूरी तरह niche कहना मुश्किल है

  • मुझे एक ऐसा resource मिला जो MPTCP और QUIC के structural differences समझाता है और लेखकों द्वारा प्रस्तावित MPQUIC protocol का भी परिचय देता है
    QUIC एक UDP flow के ऊपर application streams को multiplex करता है, और MPTCP एक single stream को कई TCP subflows में बाँटता है। MPQUIC इन दोनों विशेषताओं को जोड़कर कई UDP subflows के ऊपर application streams को multiplex करता है
    [1]: "Multipath QUIC: A Deployable Multipath Transport Protocol" https://www.researchgate.net/publication/327122884_Multipath...
    अब जानना दिलचस्प होगा कि production environment में ये protocols कैसे compare करते हैं। क्या किसी ने दोनों इस्तेमाल किए हैं?

    • MPQUIC अभी भी IETF में discussion के तहत है। पिछली IETF meeting में भी और बदलावों पर चर्चा हुई थी, और दुर्भाग्य से इसी वजह से adoption धीमा हो रहा है
      https://lwn.net/Articles/964377/
      दोनों का लक्ष्य एक ही है। तकनीकी रूप से इनसे बहुत मिलते-जुलते behavior हासिल किए जा सकते हैं। MPTCP Linux kernel में implement किया गया है, जबकि QUIC user space में है

  • Apple भी इसे support करता है और Siri में इसका इस्तेमाल होता है
    https://developer.apple.com/documentation/foundation/urlsess...

    • दूसरी apps में भी इसे काफी आसानी से इस्तेमाल किया जा सकता है। यह built-in feature का हिस्सा है
      2011 में अपनी VoIP app को इतना robust चलते देखकर मैं हैरान रह गया था :D

  • अगर बीच के किसी भी middlebox में support न हो, तो लौटने वाले SYN+ACK packet के TCP options field में MPTCP option न होना काफी सीमित लगता है
    क्या middleboxes के लिए बस इतनी ही requirement है कि वे MPTCP options को जस का तस forward करें?

    • spec finalize करने से पहले इस बात पर बहुत testing की गई थी कि MPTCP enable करने से connectivity टूटती तो नहीं
      यह सुनिश्चित किया गया कि या तो यह सही तरह pass through हो, या सुरक्षित रूप से single-path TCP पर fallback हो जाए
      आम तौर पर, अगर middlebox unknown options को बदले बिना pass कर दे, और यह enforce न करे कि उसे दिखने वाला TCP sequence space continuous होना चाहिए, तो MPTCP उस device से होकर काम कर सकता है
      अगर रुचि हो तो इस पर दो papers हैं
      [1] https://www.usenix.org/conference/nsdi12/technical-sessions/...
      [2] https://www.researchgate.net/publication/229002024_Is_it_sti...

  • यह security और privacy settings के लिहाज़ से मददगार हो सकता है
    उदाहरण के लिए, चीन के Great Firewall को देखें—अगर traffic को कई uplink channels में बाँटा जा सके, तो क्या firewall के लिए उसे फिर से assemble करके enforce करना मुश्किल नहीं हो जाएगा?

    • अगर traffic समझ में न आए, तो उसे बस block कर दो या बहुत ज़्यादा rate-limit कर दो