तेज़ इंटरनेट पर QUIC पर्याप्त तेज़ नहीं है

• QUIC एक ऐसा प्रोटोकॉल है जिससे वेब एप्लिकेशन परफ़ॉर्मेंस में क्रांतिकारी सुधार की उम्मीद की जा रही थी, लेकिन इसका प्रदर्शन अपेक्षा से कम है
• यह शोधपत्र हाई-स्पीड नेटवर्क में QUIC के प्रदर्शन का व्यवस्थित विश्लेषण करता है

सार

• हाई-स्पीड इंटरनेट में UDP+QUIC+HTTP/3 स्टैक, TCP+TLS+HTTP/2 की तुलना में अधिकतम 45.2% तक कम डेटा थ्रूपुट दिखाता है
• QUIC और HTTP/2 के बीच परफ़ॉर्मेंस गैप, उपलब्ध बैंडविड्थ बढ़ने के साथ और बड़ा हो जाता है
• यह समस्या हल्के डेटा ट्रांसफ़र क्लाइंट और प्रमुख वेब ब्राउज़र (Chrome, Edge, Firefox, Opera), विभिन्न होस्ट (डेस्कटॉप, मोबाइल), और विभिन्न नेटवर्क (वायर्ड ब्रॉडबैंड, सेलुलर) में देखी गई
• यह केवल फ़ाइल ट्रांसफ़र ही नहीं, बल्कि वीडियो स्ट्रीमिंग (अधिकतम 9.8% वीडियो बिटरेट कमी), वेब ब्राउज़िंग जैसे विभिन्न एप्लिकेशनों को भी प्रभावित करता है
• सख्त पैकेट ट्रेसिंग विश्लेषण और kernel तथा user space profiling के माध्यम से मूल कारणों की पहचान की गई
• विशेष रूप से, अत्यधिक डेटा पैकेट और QUIC के user space ACK के कारण रिसीवर-पक्ष प्रोसेसिंग ओवरहेड बहुत अधिक है
• देखी गई परफ़ॉर्मेंस समस्याओं को कम करने के लिए ठोस सिफारिशें प्रस्तुत की गई हैं

परफ़ॉर्मेंस गिरावट के मूल कारण

• रिसीवर-पक्ष kernel स्तर पर अत्यधिक पैकेट प्रोसेसिंग ओवरहेड होता है
  • QUIC, UDP GRO(Generic Receive Offload) का उपयोग नहीं करता, इसलिए TCP की तुलना में उसे कहीं अधिक पैकेट प्रोसेस करने पड़ते हैं
  • इसकी पुष्टि इस बात से हुई कि netif_receive_skb फ़ंक्शन कॉल की संख्या QUIC में कहीं अधिक थी
• user space में भी QUIC का अत्यधिक पैकेट प्रोसेसिंग ओवरहेड होता है
  • kernel से आए बड़ी संख्या के पैकेटों को प्रोसेस करने में काफी ओवरहेड लगता है
  • user space में QUIC ACK बनाना भी ओवरहेड का एक कारण है

परफ़ॉर्मेंस गिरावट कम करने के लिए प्रस्ताव

• रिसीवर-पक्ष पर UDP GRO लागू करना
  • UDP स्टैक में प्रोसेस होने वाले पैकेटों की संख्या घटाकर kernel और user space ओवरहेड कम किया जा सकता है
  • लेकिन विभिन्न क्लाइंट वातावरणों में UDP GRO को डिप्लॉय करना आसान नहीं हो सकता
• GSO/GRO जैसी offloading solutions को QUIC के अनुरूप बेहतर बनाना
  • अलग-अलग आकार की UDP packet trains को भी offload किया जा सके, इसके लिए समर्थन देना
  • नेटवर्क भीड़भाड़ रोकने के लिए GSO में उपयुक्त pacing settings जोड़ना
• रिसीवर-पक्ष QUIC लॉजिक का अनुकूलन
  • QUIC ACK भेजने में देरी कर response generation ओवरहेड कम करना
  • recvmmsg का उपयोग करके एक बार में कई UDP पैकेट पढ़कर परफ़ॉर्मेंस सुधारना
• multi-threaded download का उपयोग
  • बड़े फ़ाइलों के लिए कई CPU cores का उपयोग करने वाले multi-threaded download से रिसीव परफ़ॉर्मेंस सुधारी जा सकती है
  • हालांकि, fairness issues पर विचार करना चाहिए

[GN⁺]

Hacker News राय

• syscall interface जटिल है, और बुनियादी API सामान्य आकार के packets (लगभग 1500 bytes) की तुलना में बहुत धीमा है
  • GSO मददगार है, लेकिन API जटिल है और हाल तक भी उसमें कई bugs रहे हैं
• Spectre mitigation की वजह से syscall की लागत और बढ़ गई है
  • BSD sockets / POSIX API को बदलने की ज़रूरत है
  • uring जटिल है, लेकिन एक मध्यम-स्तर के API की ज़रूरत है
• सिस्टम UDP buffer डिफ़ॉल्ट रूप से बहुत छोटे हैं
  • केवल विशेषज्ञ ही इन्हें इस्तेमाल कर रहे हैं, और विशेषज्ञ settings समायोजित करते हैं
• UDP stack optimization संभव है
  • GSO यह दिखाता है, लेकिन GSO खुद महंगा और जटिल है
• वर्तमान में उपलब्ध कुछ optimizations केवल छोटे/मध्यम पैमाने पर ही काम करते हैं
  • उदाहरण के लिए, route lookup से बचने के लिए connection binding
• GSO लागू करने पर performance में बड़ा सुधार हो सकता है
  • संभवतः platform पक्ष पर buffer size बढ़ाने की ज़रूरत होगी
• QUIC के शुरुआती दौर में UDP stack, TCP stack की तुलना में कम optimized था
  • UDP generic receive offload जैसी optimizations की ज़रूरत है
• HTTP/2 भी शायद जल्दीबाज़ी में जारी किया गया था
  • Chrome ने server push support हटा दिया
  • और अधिक सोच-विचार की ज़रूरत है
• QUIC और HTTP/2, network bandwidth कम होने पर समान performance दिखाते हैं
  • bandwidth 500Mbps से ऊपर जाते ही QUIC की performance गिरती है
  • यह मुख्य रूप से local network में समस्या बनती है
• Google में processing burden उपयोगकर्ताओं पर डालने की प्रवृत्ति है
  • उदाहरण के लिए, AV1 video codec तब वितरित किया गया जब उपभोक्ताओं के पास HW decoding क्षमता नहीं थी
• research paper arXiv पर है
  • https://arxiv.org/pdf/2310.09423
• RTT 0.23ms वाले ping का उल्लेख
  • उच्च latency पर भी QUIC सबसे बेहतर है
• RFC9000 पढ़ना कठिन और जटिल है
  • QUIC का उच्च-स्तरीय विचार सरल है, लेकिन specification में बहुत से exception handling की ज़रूरत पड़ती है
• research की मुफ़्त PDF फ़ाइल उपलब्ध है
  • https://arxiv.org/pdf/2310.09423
• connection protocol को user space में ले जाना शायद अच्छा विचार नहीं हो सकता