टनल बैंडविड्थ पैरामीटर

नोट

यह प्रस्ताव स्वीकृत कर लिया गया है और अब यह Tunnel Creation ECIES specification में API 0.9.65 के अनुसार शामिल है। वर्तमान में कोई भी ज्ञात कार्यान्वयन नहीं हैं; कार्यान्वयन की तिथियाँ / API संस्करण TBD हैं।

अवलोकन

जैसे हमने पिछले कुछ वर्षों में नए प्रोटोकॉल, एन्क्रिप्शन प्रकार, और कंजेशन कंट्रोल सुधारों के साथ नेटवर्क के प्रदर्शन को बढ़ाया है, तेज़ एप्लिकेशन जैसे कि वीडियो स्ट्रीमिंग संभव हो रहे हैं। इन एप्लिकेशन को उनके क्लाइंट टनल में प्रत्येक हॉप पर उच्च बैंडविड्थ की आवश्यकता होती है।

हालाँकि, प्रतिभागी राउटर को टनल बनाते समय कोई जानकारी नहीं होती कि टनल कितना बैंडविड्थ उपयोग करेगा। वे केवल वर्तमान में सभी प्रतिभागी टनल द्वारा उपयोग किए गए कुल बैंडविड्थ और प्रतिभागी टनल के लिए कुल बैंडविड्थ सीमा के आधार पर एक टनल को स्वीकार या अस्वीकार कर सकते हैं।

अनुरोध करने वाले राउटर को भी हर हॉप पर उपलब्ध बैंडविड्थ की कोई जानकारी नहीं होती।

इसके अलावा, राउटरों के पास वर्तमान में किसी टनल पर इनबाउंड ट्रैफिक को सीमित करने का कोई तरीका नहीं है। यह किसी सेवा के ओवरलोड या DDoS के समय काफी उपयोगी हो सकता है।

यह प्रस्ताव इन मुद्दों को टनल बिल्ड अनुरोध और उत्तर संदेशों में बैंडविड्थ पैरामीटर जोड़कर संबोधित करता है।

डिज़ाइन

ECIES टनल बिल्ड संदेशों के रिकॉर्ड्स में बैंडविड्थ पैरामीटर जोड़ें (देखें Tunnel Creation ECIES specification) टनल बिल्ड विकल्प मैपिंग क्षेत्र में। छोटे पैरामीटर्स का उपयोग करें क्योंकि विकल्प क्षेत्र के लिए उपलब्ध स्थान सीमित है। टनल बिल्ड संदेशों का आकार स्थिर होता है इसलिए यह संदेशों के आकार में वृद्धि नहीं करता।

विशिष्टता

ECIES टनल बिल्ड संदेश विशिष्टता को अपडेट करें के रूप में:

लंबे और छोटे दोनों ECIES बिल्ड रिकॉर्ड्स के लिए:

बिल्ड अनुरोध विकल्प

रिकॉर्ड के टनल बिल्ड विकल्प मैपिंग क्षेत्र में निम्नलिखित तीन विकल्प सेट किए जा सकते हैं: एक अनुरोध करने वाला राउटर कोई भी, सभी, या कोई नहीं शामिल कर सकता है।

• m := इस टनल के लिए आवश्यक न्यूनतम बैंडविड्थ (KBps पॉजिटिव इनटीजर एक स्ट्रिंग के रूप में)
• r := इस टनल के लिए अनुरोधित बैंडविड्थ (KBps पॉजिटिव इनटीजर एक स्ट्रिंग के रूप में)
• l := इस टनल के लिए बैंडविड्थ की सीमा; केवल IBGW को भेजा जाता है (KBps पॉजिटिव इनटीजर एक स्ट्रिंग के रूप में)

बाध्यता: m <= r <= l

प्रतिभागी राउटर को टनल को अस्वीकार कर देना चाहिए यदि “m” निर्दिष्ट किया गया है और वह कम से कम उतना बैंडविड्थ प्रदान नहीं कर सकता।

अनुरोध विकल्पों को संबंधित एन्क्रिप्टेड बिल्ड अनुरोध रिकॉर्ड में प्रत्येक प्रतिभागी को भेजा जाता है, और अन्य प्रतिभागियों के लिए दृश्य नहीं होते हैं।

बिल्ड उत्तर विकल्प

निम्नलिखित विकल्प को रिकॉर्ड के टनल बिल्ड उत्तर विकल्प मैपिंग क्षेत्र में सेट किया जा सकता है, जब प्रतिक्रिया स्वीकृत हो जाती है:

• b := इस टनल के लिए उपलब्ध बैंडविड्थ (KBps पॉजिटिव इनटीजर एक स्ट्रिंग के रूप में)

यदि “m” या “r” में से कोई निर्दिष्ट किया गया हो, तो प्रतिभागी राउटर को इसे शामिल करना चाहिए बिल्ड अनुरोध में. यदि निर्दिष्ट किया गया हो, तो मान “m” मान के बराबर कम से कम होना चाहिए, लेकिन यह “r” मान से कम या अधिक भी हो सकता है यदि निर्दिष्ट किया गया हो।

प्रतिभागी राउटर को इस टनल के लिए कम से कम इतना बैंडविड्थ आरक्षित करने और प्रदान करने का प्रयास करना चाहिए, हालांकि यह गारंटी नहीं है। राउटर भविष्य में 10 मिनट की स्थिति की भविष्यवाणी नहीं कर सकते हैं, और प्रतिभागी ट्रैफ़िक एक राउटर के अपने ट्रैफ़िक और टनलों की तुलना में कम प्राथमिकता वाला होता है।

राउटर आवश्यकतानुसार उपलब्ध बैंडविड्थ का ओवर-आलोकेशन भी कर सकते हैं, और यह संभवतः वांछनीय है, क्योंकि टनल में अन्य हॉप इसे अस्वीकार कर सकते हैं।

इन कारणों से, प्रतिभागी राउटर के उत्तर को एक सर्वश्रेष्ठ प्रयास की प्रतिबद्धता के रूप में माना जाना चाहिए, लेकिन गारंटी नहीं।

उत्तर विकल्प संबंधित एन्क्रिप्टेड बिल्ड उत्तर रिकॉर्ड में अनुरोध करने वाले राउटर को भेजे जाते हैं, और अन्य प्रतिभागियों के लिए दृश्य नहीं होते हैं।

कार्यान्वयन नोट्स

बैंडविड्थ पैरामीटर टनल लेयर पर प्रतिभागी राउटर पर देखे जाते हैं, यानि प्रति सेकंड निश्चित-आकार की 1 KB टनल संदेशों की संख्या। ट्रांसपोर्ट (NTCP2 या SSU2) ओवरहेड शामिल नहीं है।

यह बैंडविड्थ क्लाइंट पर देखे गए बैंडविड्थ की तुलना में बहुत अधिक या कम हो सकता है। टनल संदेशों में उल्लेखनीय ओवरहेड होता है, जिसमें उच्च स्तरीय ओवरहेड के साथ रैचेट और स्ट्रीमिंग शामिल होती हैं। अस्थायी छोटे संदेश जैसे स्ट्रीमिंग ऐक्स प्रत्येक को 1 KB तक विकसित किया जाएगा। हालांकि, I2CP लेयर पर gzip संपीड़न बैंडविड्थ को काफी कम कर सकता है।

अनुरोध करने वाले राउटर पर सरलतम कार्यान्वयन यह है कि वर्तमान टनलों के औसत, न्यूनतम, और/या अधिकतम बैंडविड्थ का उपयोग करें और अनुरोध में डाले जाने वाले मानों की गणना करें। अधिक जटिल एल्गोरिदम संभव हैं और यह कार्यान्वतिकर्ता के ऊपर है।

वर्तमान में क्लाइंट को यह बताने के लिए कोई I2CP या SAM विकल्प परिभाषित नहीं हैं कि राउटर को कितना बैंडविड्थ चाहिए, और यहां कोई नया विकल्प प्रस्तावित नहीं किया गया है। आवश्यक होने पर विकल्पों को बाद में परिभाषित किया जा सकता है।

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

यह प्रस्ताव इनबाउंड गेटवे में “l” विकल्प द्वारा अनुरोध किए गए पर-टनल थ्रॉटलिंग को कार्यान्वयन करने की आवश्यकता है। यह अन्य प्रतिभागी हॉपों को पर-टनल या किसी प्रकार के वैश्विक थ्रॉटलिंग को कार्यान्वयन करने की आवश्यकता नहीं है, या किसी विशेष एल्गोरिदम या कार्यान्वयन को निर्दिष्ट नहीं करता, यदि कोई हो।

यह प्रस्ताव क्लाइंट राउटर को प्रतिभागी हॉप द्वारा वापस भेजे गए “b” मान पर ट्रैफिक को थ्रॉटल करने की आवश्यकता नहीं करता है, और एप्लिकेशन पर निर्भर करते हुए, यह संभव नहीं हो सकता, विशेष रूप से इनबाउंड टनल के लिए।

यह प्रस्ताव केवल द्वारा उत्पन्न किए गए टनलों को प्रभावित करता है। “फार-एंड” टनलों के लिए बैंडविड्थ अनुरोध या आवंटित करने के लिए कोई तरीका परिभाषित नहीं किया गया है जो एक सिरे से अंत-तक संचार के दूसरे सिरे के मालिक द्वारा उत्पन्न किया गया हो।

सुरक्षा विश्लेषण

प्राप्त करने की संभावना के आधार पर क्लाइंट फिंगरप्रिंटिंग या संबंध किया जा सकता है। क्लाइंट (उत्पत्तिकर्ता) राउटर को “m” और “r” मानों को यादृच्छिक रूप से भेजने की इच्छा हो सकती है बजाय हर हॉप पर वही मूल्य भेजने के; या बैंडविड्थ “बकेट्स” का प्रतिनिधित्व करने वाले सीमित सेट मान भेजें, या दोनों का कुछ संयोजन।

ओवर-आवंटन DDoS: जब अब यह संभव हो सकता है कि एक राउटर को भारी संख्या में टनलों के निर्माण और उपयोग से DDoS किया जाए, यह प्रस्ताव तर्कसंगत रूप से इसे बहुत आसान बना देता है, सिर्फ एक या अधिक टनलों के लिए बड़े बैंडविड्थ अनुरोध कर के।

कार्यान्वयन इस जोखिम को कम करने के लिए एक या अधिक निम्नलिखित रणनीतियों का उपयोग कर सकते हैं और करना चाहिए:

• उपलब्ध बैंडविड्थ का ओवर-आवंटन
• उपलब्ध बैंडविड्थ के कुछ प्रतिशत तक पर-टनल आवंटन को सीमित करें
• आवंटित बैंडविड्थ में वृद्धि की दर को सीमित करें
• उपयोग किए गए बैंडविड्थ में वृद्धि की दर को सीमित करें
• टनल के जीवनकाल में जल्दी उपयोग न होने पर टनल के लिए आवंटित बंडविड्थ को सीमित करें (उपयोग करें या खो दें)
• प्रति टनल औसत बैंडविड्थ का ट्रैकिंग
• अनुरोधित बनाम वास्तविक प्रयुक्त बंडविड्थ का ट्रैकिंग प्रति टनल

अनुकूलता

कोई समस्या नहीं। वर्तमान में ज्ञात सभी कार्यान्वयन बिल्ड संदेशों में मैपिंग फ़ील्ड को अनदेखा करते हैं, और गैर-खाली विकल्प क्षेत्र को सही ढंग से छोड़ देते हैं।

माइग्रेशन

कार्यान्वयन किसी भी समय समर्थन जोड़ सकते हैं, किसी समन्वयन की आवश्यकता नहीं है।

चूंकि वर्तमान में कोई API संस्करण परिभाषित नहीं है जहां इस प्रस्ताव के समर्थन की आवश्यकता है, राउटर को समर्थन की पुष्टि के लिए “b” प्रतिक्रिया की जाँच करनी चाहिए।