QUIC में Datagram के बिना timeliness हासिल करना
(quic.video)- लाइव वीडियो और इंटरनेट बातचीत में असली बात सिर्फ “unreliable delivery” नहीं, बल्कि पुराने डेटा को हटाकर नवीनतम डेटा को समय पर पहुँचाना है
- अगर राउटर भीड़भाड़ वाले packets को गिराने के बजाय उन्हें लंबे समय तक queue में जमा रखे, तो bufferbloat होता है, और real-time services में यह buffering से भी बदतर latency पैदा कर सकता है
- UDP के ऊपर सीधे protocol बनाने पर retransmission, congestion control, encryption, RTT estimation, path validation, flow control आदि फिर से implement करने पड़ते हैं, इसलिए QUIC library का इस्तेमाल करना अधिक सुरक्षित है
- सिर्फ QUIC से भी delay-based congestion control, स्वतंत्र stream splitting, और prioritization को मिलाकर datagram के बिना timeliness बनाई जा सकती है
- QUIC, WebTransport, और MoQ standards में datagram support शामिल हो रहा है, लेकिन UDP के ऊपर नया video protocol फिर से खड़ा करने के बजाय Media over QUIC के flow के साथ जाना बेहतर निष्कर्ष है
लक्ष्य “unreliability” नहीं, timeliness है
- TCP और UDP के चुनाव को अक्सर “reliable delivery” बनाम “unreliable delivery” के रूप में समझाया जाता है, लेकिन application वास्तव में unreliability खुद नहीं चाहती
- लाइव वीडियो या इंटरनेट बातचीत में पुराने डेटा को पूरा पाने से ज़्यादा महत्वपूर्ण है कि नवीनतम डेटा पहले पहुँचे
- real-time बातचीत में चेहरे पर buffering spinner दिखना या 5 सेकंड पुरानी आवाज़ सुनाई देना टालना चाहिए
- लाइव वीडियो उद्योग और गेमिंग उद्योग इसी timeliness के लिए TCP stream के बजाय अक्सर UDP datagram का उपयोग करते हैं
Datagram और network queue
- Datagram स्रोत पते से गंतव्य पते तक भेजा गया 0 और 1 का एक लिफाफा है, और सामान्यतः 1200 bytes को सुरक्षित आकार माना जाता है
- Datagram चुपचाप खो सकता है, और क्रम बदलकर भी पहुँच सकता है
- physical layer में डेटा analog signal में बदलकर माध्यम से गुजरता है, और वहाँ serialization, deserialization, buffering, queuing, retransmission, discard, corruption, delay, reordering, duplication, और loss हो सकते हैं
- जब network में बहुत ज़्यादा डेटा आ जाता है, तो router मनमाने bits नहीं, बल्कि packet boundary पर डेटा गिराता है
Bufferbloat और congestion control
- अगर router packets को तुरंत गिराने के बजाय queue में जमा रखे, तो bufferbloat होता है
- bufferbloat सभी packets को कई सेकंड तक delay कर सकता है, जिससे real-time delivery में सबसे खराब स्थिति बनती है
- queuing से बचने के लिए packet arrival time feedback से router queuing का अनुमान लगाना होता है, और sender को sending rate घटाकर queue खाली करनी होती है
- यह क्षेत्र congestion control से जुड़ा है, और unlimited speed से packets भेजना विनाशकारी हो सकता है
UDP के ऊपर सीधे बनाने पर उठानी पड़ने वाली क्षमताएँ
- अगर UDP का सीधे उपयोग करके transport protocol बनाना हो, तो कम-से-कम ये सुविधाएँ चाहिए
- बेहतर protocol बनाना हो, तो ये सुविधाएँ भी चाहिए
- maturity बढ़ानी हो, तो production environment और deployment भी ध्यान में रखने पड़ते हैं
- WebRTC, SRT, Sye, और RIST जैसे live video protocols UDP के ऊपर बनाए गए उदाहरण हैं
- इससे यह निष्कर्ष निकलता है कि नया protocol खुद बनाने के बजाय QUIC library का उपयोग करना बेहतर है
QUIC stream से timeliness बनाना
- QUIC में timeliness हासिल करने के तीन तरीके बताए जा सकते हैं
- buffer inflation से बचाव: BBR जैसे delay-based congestion control queueing को पहचानकर sending rate घटाते हैं
- WebRTC का transport-wide-cc इससे भी बेहतर तरीके का उदाहरण माना जा सकता है
- stream splitting: हर stream के भीतर bytes क्रमबद्ध और विश्वसनीय रूप से पहुँचते हैं, और stream वीडियो frame, game update, chat message, या JSON blob जैसी atomic unit बन सकती है
- stream prioritization: streams स्वतंत्र होती हैं, इसलिए वे क्रम की परवाह किए बिना पहुँच सकती हैं, और QUIC stack को निर्देश दिया जा सकता है कि महत्वपूर्ण streams पहले भेजी जाएँ
- कम प्राथमिकता वाली streams starving का शिकार हो सकती हैं, और bandwidth की बर्बादी से बचने के लिए उन्हें बंद किया जा सकता है
- यही तरीका Media over QUIC का मूल है
- Datagram का fire-and-forget स्वभाव सिर्फ तब उपयुक्त है जब real-time latency अनिवार्य हो; बाकी मामलों में QUIC streams का उपयोग किया जा सकता है
Datagram के आसपास के समझौते और अपवाद
- QUIC और संबंधित standards में datagram support भी शामिल है
- QUIC extension के ज़रिए datagram support देता है
- WebTransport datagram support को आवश्यक बनाता है
- नवीनतम MoQ version datagram support जोड़ता है
- अगला MoQ version datagram support को आवश्यक बनाने वाला है
- datagram support को इस वजह से शामिल किया जा सकता है कि इसे implement करना मामूली है और यह experimentation की अनुमति देता है
- OPUS में FEC support built-in है, इसलिए यह उस उदाहरण की तरह है जहाँ MoQ हर audio “frame” को datagram के रूप में भेजने की सुविधा देता है
- पुराने protocol DNS को अपवाद माना जा सकता है, लेकिन नई design में DNS over HTTPS जैसी दिशा अपनाना बेहतर माना गया है
- निष्कर्ष यह है कि UDP के ऊपर नया video protocol फिर से बनाने के बजाय Media over QUIC में भाग लेना बेहतर है
1 टिप्पणियां
Hacker News की राय
उदाहरण के लिए, NB-IoT जैसे माहौल में जहाँ सबसे खराब स्थिति में round-trip latency 10 सेकंड हो सकती है, वहाँ handshake और MTU discovery में round-trip समय बर्बाद होता है, वह ऐसे डेटा को भी लगातार भेजने की कोशिश करता रहता है जिसका अब कोई उपयोग नहीं है, और जब coverage खराब होने से latency बढ़ती है तो TCP इसे congestion से हुई packet loss मानकर bandwidth घटा देता है
इसके अलावा, load balancer या middlebox यह सोचकर कनेक्शन काट सकते हैं कि “4 सेकंड तक कोई जवाब नहीं आया, शायद यह खत्म हो गया”, और TCP डेटा संरचना को ध्यान में रखे बिना packet को बाँटता है, इसलिए पूरा डेटा मिलने तक उसकी व्याख्या नहीं की जा सकती — यह भी एक कमी है
कुछ मामलों में यह उपयोगी है, लेकिन कई बार nवाँ packet अभी न होने पर भी n+1वें packet का उपयोग किया जा सकता है
बड़े फ़ाइल ट्रांसफ़र में erasure coding से 5% packet loss को अपने-आप संभाला जा सकता है, या fountain code का उपयोग करके तब तक भेजा जा सकता है जब तक receiver यह न कह दे कि “सब मिल गया”
fountain code वही तरीका है जिससे deep-space probes डेटा भेजते हैं, और Jupiter या Mars तक की latency काफी गंभीर होती है
TCP handshake खत्म होने के बाद ही TLS handshake शुरू किया जा सकता है, लेकिन QUIC में शुरुआती handshake के अंदर ही TLS negotiation को संभालने के लिए protocol-level support है
नेटवर्क प्रोटोकॉल और encryption को loosely combine कर पाना ज़्यादा elegant लगता है, लेकिन अब लगभग हर transport encrypted होने वाली दुनिया में हर connection पर एक round trip कम कर पाना ज़्यादा व्यावहारिक फ़ायदा लगता है
R&D पक्ष में QUIC का उपयोग करने वाला एक नया सिस्टम बनाया गया, और out-of-order arrival की ज़्यादातर समस्याएँ हल हो गईं, लेकिन बिना adapter के सीधे support होने वाले third-party sensors सिर्फ UDP ही संभाल पाते हैं, इसलिए अब भी हर चीज़ के लिए UDP datagram ही इस्तेमाल होते हैं
ज़्यादा आम और बेहतर अभिव्यक्ति best-effort है, और UDP datagram की डिलीवरी के लिए पूरी कोशिश करता है, बस datagram गिर भी सकते हैं
इसका यह मतलब नहीं कि UDP स्वभाव से ही अविश्वसनीय है
https://en.wikipedia.org/wiki/Best-effort_delivery
असल में इसका मतलब A से B तक संदेश पहुँचाने के लिए अंत तक पूरी जान लगाना नहीं, बल्कि कुछ-कुछ “कोशिश तो की” जैसा है
अगर रास्ते के router में congestion हो, या link flap के कारण fast rerouting से पहले लगभग 50ms का black hole बन जाए, तब भी बात यही रहती है कि “खैर, कोशिश की थी”
इसके उलट TCP की reliable delivery कई बार retry करती है और application को सही क्रम वाला data stream देती है
reliable/unreliable भी शायद अच्छे शब्द नहीं हैं, लेकिन best-effort उससे बेहतर है, यह कहना आसान नहीं
non-reliable systems 95% मामलों में शानदार हो सकते हैं और raw throughput के लिए भी अच्छे हो सकते हैं, लेकिन आख़िरी 5% कई बार बहुत बड़ा फ़र्क पैदा करता है
“effort” शब्द में आम तौर पर कठिनाई के सामने कुछ हद तक डटे रहने का भाव होता है, लेकिन resource समस्या आते ही packet गिरा देना effort कहना मुश्किल है, best effort तो और भी नहीं
क़ानूनी·व्यावसायिक शब्दावली में “best efforts” का मतलब पक्का वादा नहीं होता, लेकिन खुलकर हाथ खड़े कर देना भी नहीं होता; networking में इसका उपयोग उससे काफ़ी अलग है
अलग बात यह है कि UDP और TCP के checksum भी datagram डिलीवर हो जाने पर उसकी integrity को बहुत मज़बूती से guarantee नहीं करते, बस hardware से थोड़ा बेहतर हैं
लेकिन best-effort ऐसा एहसास देता है कि delivery guarantee के लिए कुछ अतिरिक्त कोशिश की जाती है, जबकि हक़ीक़त में packet अगर अजीब लगे या बदकिस्मती से भरे हुए buffer से टकरा जाएँ तो बस गिरा दिए जाते हैं
मुझे lossy शब्द पसंद है, लेकिन यह भी उन “मुश्किल समस्याएँ सिर्फ दो ही हैं” वाली naming problem जैसा मामला है
अगर packet का पहुँचना ज़रूरी है तो TCP इस्तेमाल करें, और अगर बहुत फ़र्क नहीं पड़ता तो UDP इस्तेमाल करें
यह सरल किया हुआ स्पष्टीकरण है, लेकिन best effort एक बेवकूफ़ी भरा शब्द है; उसमें कोई effort नहीं है
congestion control की ज़रूरत तो साफ़ है, लेकिन उसके अलावा काफ़ी सवाल उठते हैं
अगर दुनिया datagram-first होती, तो कई data links को बहुत कुशलता से जोड़ा जा सकता था, या network boundaries पार करते हुए भी connection तोड़े बिना roaming में कोई समस्या नहीं होती
कई applications out-of-order frames को बिना अतिरिक्त लागत के संभाल सकती हैं, और अगर उन्हें UDP model के हिसाब से लिखा जाए तो वे कहीं ज़्यादा तेज़ हो सकती हैं
वास्तव में कम reliable transport पर जाने से software अपने-आप ज़्यादा reliable या efficient नहीं हो जाता
बल्कि टीम को संभालने वाले failure modes और complexity काफ़ी बढ़ जाते हैं
हालाँकि अगर connection के किसी हिस्से में संकरा bottleneck हो, तो वैसे भी उसी bottleneck पर drop होने वाले बहुत सारे packets बनाना कोई ख़ास मायने नहीं रखता
websites, audio, video आम तौर पर out-of-order frames के साथ अच्छी तरह नहीं चलते, और ज़्यादातर लोग audio या video का टूटना नहीं चाहते
कुछ video games missing packets को नज़रअंदाज़ कर सकते हैं, लेकिन ऐसे मामले पहले से ही UDP पर लिखे जाते हैं
ऐसा इसलिए माना जाता है कि वे packets retransmit नहीं होंगे, इसलिए अतिरिक्त traffic घटाने का यह एक प्रभावी तरीका है
अब UDP के ऊपर aggressively retransmit करने वाले protocols भी आ गए हैं, तो इससे स्थिति कितनी बदली है यह जानने की जिज्ञासा है
याद है कि कुछ साल पहले QUIC को इसी वजह से HTTP/1·HTTP/2 की तुलना में retransmission problems झेलनी पड़ी थीं
अगर लेख में इससे ज़्यादा प्रतिनिधि पंक्ति मिल जाए तो इसे फिर बदला जा सकता है
यह HN title guideline “मूल शीर्षक का उपयोग करें, लेकिन अगर वह भ्रामक या clickbait हो तो अपवाद है” के अनुसार था: https://news.ycombinator.com/newsguidelines.html
application के हिसाब से यह उचित हो सकता है
उदाहरण के लिए real-time multiplayer game में अगर processing पीछे रह जाए, तो पीछे छूटी चीज़ें अब महत्वपूर्ण नहीं रहतीं क्योंकि game state पहले ही बदल चुकी होती है
high-frequency trading applications में भी कुछ स्थितियों में 100ms पहले की घटना से ज़्यादा ताज़ा market data ही महत्वपूर्ण होता है
लेख UDP के उपयुक्त उदाहरण के रूप में games और live video का भी उल्लेख करता है
शुरुआत में एक “common belief” रखकर फिर उसका खंडन करने की संरचना है
उदाहरण के लिए DHCP, SLAAC, UPnP, mDNS, tinc, BitTorrent जैसी local discovery; local network streaming जैसे broadcast; और WireGuard, IPSec, OpenVPN, VLAN जैसी encapsulation इसमें आती हैं
क्योंकि retransmission ही नहीं, बल्कि reordering के लिए buffering से भी latency बढ़ती है, इसलिए loss को error correction या packet loss concealment के साथ स्वीकार करना बेहतर होता है
UDP और TCP का व्यवहार और trade-offs अलग हैं, इसलिए use case के हिसाब से चुनने से पहले उन्हें समझना ही पूरी बात है
“X कभी मत करो” जैसी gatekeeping की ज़रूरत नहीं है
सिर्फ़ शीर्षक देखकर भी काफ़ी स्पष्ट है कि यह UDP इस्तेमाल करने से रोकने वाली gatekeeping पोस्ट नहीं है
दरअसल लेख के अंत में लेखक QUIC इस्तेमाल करने का सुझाव देता है, जो UDP पर आधारित है
हाँ, आपको ख़ुद कहीं ज़्यादा details संभालनी पड़ेंगी
साथ ही, यह networking के low-level पहलुओं को सीखने का अच्छा तरीका भी है