निम्नलिखित NTCP के बारे में एक चर्चा है जो मार्च 2007 में हुई थी। इसे वर्तमान implementation को दर्शाने के लिए अपडेट नहीं किया गया है। वर्तमान NTCP specification के लिए NTCP2 पेज देखें।
NTCP बनाम SSU चर्चा, मार्च 2007
NTCP प्रश्न
(zzz और cervantes के बीच IRC चर्चा से अनुकूलित)
NTCP को SSU की तुलना में क्यों प्राथमिकता दी जाती है, क्या NTCP में अधिक overhead और latency नहीं होती? इसमें बेहतर विश्वसनीयता है।
क्या NTCP पर streaming lib क्लासिक TCP-over-TCP समस्याओं से पीड़ित नहीं होता? क्या होगा यदि हमारे पास streaming-lib-originated traffic के लिए वास्तव में एक सरल UDP transport होता? मुझे लगता है कि SSU को तथाकथित वास्तव में सरल UDP transport बनने के लिए बनाया गया था - लेकिन यह बहुत अविश्वसनीय साबित हुआ।
zzz द्वारा “NTCP को हानिकारक माना गया” विश्लेषण
नए Syndie में पोस्ट किया गया, 2007-03-25। यह चर्चा को प्रोत्साहित करने के लिए पोस्ट किया गया था, इसे बहुत गंभीरता से न लें।
सारांश: NTCP में SSU की तुलना में अधिक latency और overhead होता है, और streaming lib के साथ उपयोग करने पर इसके collapse होने की संभावना अधिक होती है। हालांकि, traffic को SSU के बजाय NTCP के लिए प्राथमिकता के साथ route किया जाता है और यह वर्तमान में hardcoded है।
चर्चा
हमारे पास वर्तमान में दो transports हैं, NTCP और SSU। जैसा कि वर्तमान में लागू किया गया है, NTCP में SSU की तुलना में कम “bids” हैं इसलिए इसे प्राथमिकता दी जाती है, सिवाय उस स्थिति के जहाँ किसी peer के लिए एक स्थापित SSU connection है लेकिन कोई स्थापित NTCP connection नहीं है।
SSU, NTCP के समान है क्योंकि यह acknowledgments, timeouts, और retransmissions को implement करता है। हालांकि SSU, I2P code है जिसमें timeouts पर सख्त बाधाएं हैं और round trip times, retransmissions आदि पर उपलब्ध statistics हैं। NTCP, Java NIO TCP पर आधारित है, जो एक black box है और संभवतः RFC standards को implement करता है, जिसमें बहुत लंबे maximum timeouts शामिल हैं।
I2P के भीतर अधिकांश ट्रैफिक streaming-lib से उत्पन्न होता है (HTTP, IRC, Bittorrent) जो TCP का हमारा implementation है। चूंकि निम्न-स्तरीय transport आम तौर पर कम bids के कारण NTCP होता है, इसलिए सिस्टम TCP-over-TCP की सुप्रसिद्ध और भयानक समस्या के अधीन है http://sites.inka.de/~W1011/devel/tcp-tcp.html , जहां TCP की उच्च और निम्न दोनों layers एक साथ retransmissions कर रही हैं, जिससे collapse हो जाता है।
ऊपर दिए गए लिंक में वर्णित PPP over SSH परिदृश्य के विपरीत, हमारे पास निचली परत के लिए कई hops हैं, जिनमें से प्रत्येक एक NTCP link से कवर है। इसलिए प्रत्येक NTCP latency आमतौर पर उच्च-परत streaming lib latency से बहुत कम होती है। यह collapse की संभावना को कम करता है।
इसके अलावा, जब निचली परत TCP को कम टाइमआउट और पुनः प्रसारण की संख्या के साथ सख्ती से सीमित किया जाता है तो उच्च परत की तुलना में collapse की संभावनाएं कम हो जाती हैं।
.28 रिलीज़ ने अधिकतम स्ट्रीमिंग lib टाइमआउट को 10 सेकंड से बढ़ाकर 45 सेकंड कर दिया जिसने चीजों को काफी बेहतर बनाया। SSU अधिकतम टाइमआउट 3 सेकंड है। NTCP अधिकतम टाइमआउट संभवतः कम से कम 60 सेकंड है, जो RFC अनुशंसा है। NTCP पैरामीटर बदलने या प्रदर्शन की निगरानी करने का कोई तरीका नहीं है। NTCP परत का पतन [संपादक: टेक्स्ट खो गया]। शायद tcpdump जैसे बाहरी टूल से मदद मिले।
हालांकि, .28 चलाने पर, i2psnark द्वारा रिपोर्ट किया गया upstream आमतौर पर उच्च स्तर पर स्थिर नहीं रहता। यह अक्सर वापस ऊपर चढ़ने से पहले 3-4 KBps तक गिर जाता है। यह संकेत है कि अभी भी collapses हो रहे हैं।
SSU भी अधिक कुशल है। NTCP में अधिक ओवरहेड है और संभवतः अधिक राउंड ट्रिप टाइम है। NTCP का उपयोग करते समय (tunnel output) / (i2psnark data output) का अनुपात कम से कम 3.5 : 1 होता है। एक प्रयोग चलाते समय जहाँ कोड को SSU को प्राथमिकता देने के लिए संशोधित किया गया था (config विकल्प i2np.udp.alwaysPreferred का वर्तमान कोड में कोई प्रभाव नहीं है), अनुपात घटकर लगभग 3 : 1 हो गया, जो बेहतर दक्षता को दर्शाता है।
स्ट्रीमिंग lib stats की रिपोर्ट के अनुसार, चीजें काफी बेहतर हुई थीं - lifetime window size 6.3 से बढ़कर 7.5 हो गया, RTT 11.5s से घटकर 10s हो गया, sends per ack 1.11 से घटकर 1.07 हो गया।
यह काफी प्रभावी था जो आश्चर्यजनक था, यह देखते हुए कि हम केवल 3 से 5 कुल hops में से पहले hop के लिए transport को बदल रहे थे जो outbound संदेश लेते।
i2psnark की आउटबाउंड गति पर प्रभाव सामान्य विविधताओं के कारण स्पष्ट नहीं था। प्रयोग के लिए, इनबाउंड NTCP को अक्षम कर दिया गया था। i2psnark पर इनबाउंड गति पर प्रभाव स्पष्ट नहीं था।
प्रस्ताव
1A) यह आसान है - हमें bid priorities को उलट देना चाहिए ताकि SSU को सभी ट्रैफिक के लिए प्राथमिकता दी जा सके, यदि हम यह बिना अन्य सभी प्रकार की परेशानियां पैदा किए कर सकते हैं। इससे i2np.udp.alwaysPreferred configuration option ठीक हो जाएगा ताकि यह काम करे (या तो true या false के रूप में)।
1B) 1A) का विकल्प, उतना आसान नहीं - यदि हम अपने anonymity लक्ष्यों को प्रतिकूल रूप से प्रभावित किए बिना traffic को mark कर सकते हैं, तो हमें streaming-lib द्वारा generate किए गए traffic को identify करना चाहिए और SSU को उस traffic के लिए एक low bid generate करने देना चाहिए। इस tag को प्रत्येक hop के माध्यम से message के साथ जाना होगा ताकि forwarding routers भी SSU preference का सम्मान करें।
2) SSU को और भी सीमित करना (वर्तमान 10 से अधिकतम पुनः प्रेषणों को कम करना) संभवतः पतन की संभावना को कम करने के लिए बुद्धिमानी है।
3) हमें streaming lib के नीचे एक अर्ध-विश्वसनीय प्रोटोकॉल के लाभ बनाम हानि पर और अध्ययन की आवश्यकता है। क्या एकल hop पर retransmissions लाभकारी हैं और एक बड़ी जीत हैं या वे बेकार से भी बदतर हैं? हम एक नया SUU (secure unreliable UDP) कर सकते हैं लेकिन शायद यह इसके लायक नहीं है। यदि हम streaming-lib traffic के किसी भी retransmissions नहीं चाहते तो हम शायद SSU में एक no-ack-required message type जोड़ सकते हैं। क्या सख्ती से सीमित retransmissions वांछनीय हैं?
4) .28 में priority sending कोड केवल NTCP के लिए है। अब तक मेरी testing में SSU priority के लिए ज्यादा उपयोग नहीं दिखा है क्योंकि messages इतनी देर तक queue में नहीं रहते कि priorities कोई फायदा कर सकें। लेकिन और testing की जरूरत है।
5) नई streaming lib की 45s की max timeout शायद अभी भी बहुत कम है। TCP RFC 60s कहता है। यह संभवतः अंतर्निहित NTCP max timeout (संभावित रूप से 60s) से कम नहीं होना चाहिए।
jrandom द्वारा प्रतिक्रिया
नए Syndie में पोस्ट किया गया, 2007-03-27
कुल मिलाकर, मैं इसके साथ प्रयोग करने के लिए तैयार हूँ, हालांकि याद रखें कि NTCP पहली जगह क्यों है - SSU एक congestion collapse में असफल हो गया था। NTCP “बस काम करता है”, और जबकि सामान्य single-hop networks में 2-10% retransmission rates को संभाला जा सकता है, वह हमें 2 hop tunnels के साथ 40% retransmission rate देता है। यदि आप उन मापे गए SSU retransmission rates में से कुछ को शामिल करते हैं जो हमने NTCP के implement होने से पहले देखे थे (10-30+%), तो वह हमें 83% retransmission rate देता है। शायद वे दरें कम 10 second timeout की वजह से थीं, लेकिन इसे इतना बढ़ाना हमें नुकसान पहुंचाएगा (याद रखें, 5 से गुणा करें और आपको आधा सफर मिल गया)।
TCP के विपरीत, हमारे पास tunnel से यह जानने के लिए कोई फीडबैक नहीं है कि संदेश पहुंचा या नहीं - कोई tunnel स्तर के acks नहीं हैं। हमारे पास end to end ACKs हैं, लेकिन केवल कुछ संदेशों पर (जब भी हम नए session tags वितरित करते हैं) - मेरे router द्वारा भेजे गए 1,553,591 client संदेशों में से, हमने केवल 145,207 को ACK करने का प्रयास किया। अन्य चुपचाप असफल हो सकते हैं या पूर्ण रूप से सफल हो सकते हैं।
मैं हमारे लिए TCP-over-TCP तर्क से आश्वस्त नहीं हूं, विशेष रूप से विभिन्न paths में विभाजित होकर जिनसे हम transfer करते हैं। I2P पर measurements निश्चित रूप से मुझे अन्यथा समझा सकते हैं।
NTCP max timeout संभवतः कम से कम 60 सेकंड है, जो RFC अनुशंसा है। NTCP पैरामीटर बदलने या प्रदर्शन की निगरानी करने का कोई तरीका नहीं है।
सच है, लेकिन नेट कनेक्शन केवल तभी उस स्तर तक पहुंचते हैं जब कुछ वास्तव में बुरा हो रहा हो - TCP पर retransmission timeout अक्सर दसियों या सैकड़ों milliseconds की श्रेणी में होता है। जैसा कि foofighter बताते हैं, उनके पास अपने TCP stacks में 20+ वर्षों का अनुभव और bugfixing है, साथ ही एक अरब डॉलर का उद्योग है जो हार्डवेयर और सॉफ्टवेयर को उनकी जरूरतों के अनुसार अच्छा प्रदर्शन करने के लिए अनुकूलित करता है।
NTCP में अधिक overhead और संभवतः अधिक round trip times होते हैं। जब NTCP का उपयोग करते हैं तो (tunnel output) / (i2psnark data output) का अनुपात कम से कम 3.5 : 1 होता है। एक प्रयोग चलाने पर जहाँ कोड को SSU को प्राथमिकता देने के लिए संशोधित किया गया (config विकल्प i2np.udp.alwaysPreferred का वर्तमान कोड में कोई प्रभाव नहीं है), यह अनुपात घटकर लगभग 3 : 1 हो गया, जो बेहतर दक्षता को दर्शाता है।
यह बहुत दिलचस्प डेटा है, हालांकि यह bandwidth efficiency से ज्यादा router congestion की बात है - आपको 3.5*$n*$NTCPRetransmissionPct ./. 3.0*$n*$SSURetransmissionPct की तुलना करनी होगी। यह डेटा पॉइंट सुझाता है कि router में कुछ ऐसा है जो पहले से transfer हो रहे messages के excess local queuing का कारण बनता है।
lifetime window size 6.3 से बढ़कर 7.5, RTT 11.5s से घटकर 10s, sends per ACK 1.11 से घटकर 1.07.
याद रखें कि sends-per-ACK केवल एक नमूना है, पूर्ण गिनती नहीं (क्योंकि हम हर send को ACK करने की कोशिश नहीं करते)। यह एक random नमूना भी नहीं है, बल्कि निष्क्रियता की अवधि या गतिविधि के burst की शुरुआत के दौरान अधिक heavily नमूने लेता है - sustained load के लिए बहुत सारे ACKs की आवश्यकता नहीं होगी।
उस रेंज में window sizes अभी भी AIMD का वास्तविक लाभ प्राप्त करने के लिए दुखद रूप से कम हैं, और अभी भी एक single 32KB BT chunk को transmit करने के लिए बहुत कम हैं (floor को 10 या 12 तक बढ़ाना इसे कवर कर देगा)।
फिर भी, wsize stat आशाजनक लग रहा है - यह कितने लंबे समय तक बना रहा?
वास्तव में, परीक्षण उद्देश्यों के लिए, आप StreamSinkClient/StreamSinkServer या यहाँ तक कि apps/ministreaming/java/src/net/i2p/client/streaming/ में TestSwarm को देखना चाह सकते हैं - StreamSinkClient एक CLI app है जो चुनी गई file को चुने गए destination पर भेजता है और StreamSinkServer एक destination बनाता है और इसे भेजे गए किसी भी data को लिखता है (size और transfer time प्रदर्शित करते हुए)। TestSwarm दोनों को मिलाता है - random data को किससे भी यह connect करता है उसे flood करता है। यह आपको streaming lib पर sustained throughput capacity को मापने के लिए tools देना चाहिए, BT choke/send के विपरीत।
1A) यह आसान है - > हमें bid priorities को फ्लिप करना चाहिए ताकि SSU को सभी traffic के लिए प्राथमिकता दी जाए, यदि > हम यह बिना किसी अन्य समस्या के कर सकें। इससे > i2np.udp.alwaysPreferred configuration option ठीक हो जाएगा ताकि यह काम करे (true > या false के रूप में)।
i2np.udp.alwaysPreferred को सम्मानित करना किसी भी स्थिति में एक अच्छा विचार है - कृपया उस परिवर्तन को commit करने में संकोच न करें। हालांकि preferences को बदलने से पहले आइए थोड़ा और डेटा इकट्ठा करते हैं, क्योंकि NTCP को SSU-निर्मित congestion collapse से निपटने के लिए जोड़ा गया था।
1B) 1A का विकल्प), उतना आसान नहीं - > यदि हम अपने anonymity लक्ष्यों पर प्रतिकूल प्रभाव डाले बिना traffic को mark कर सकते हैं, तो हमें streaming-lib द्वारा generated traffic की पहचान करनी चाहिए > और SSU को उस traffic के लिए कम bid generate करने देना चाहिए। इस tag को प्रत्येक hop के माध्यम से > message के साथ जाना होगा > ताकि forwarding routers भी SSU preference का सम्मान करें।
व्यवहार में, तीन प्रकार का ट्रैफिक होता है - tunnel निर्माण/परीक्षण, netDb क्वेरी/रिस्पॉन्स, और streaming lib ट्रैफिक। नेटवर्क को इस तरह डिज़ाइन किया गया है कि इन तीनों के बीच अंतर करना बहुत कठिन हो।
2) SSU को और भी सीमित करना (वर्तमान > 10 से अधिकतम पुनः प्रसारण को कम करना) शायद समझदारी है ताकि पतन की संभावना कम हो सके।
10 retransmissions पर, हम पहले से ही मुश्किल में हैं, मैं सहमत हूं। transport layer की दृष्टि से एक, शायद दो retransmissions उचित है, लेकिन यदि दूसरी तरफ समय पर ACK करने के लिए बहुत अधिक congested है (implemented SACK/NACK capability के साथ भी), तो हम ज्यादा कुछ नहीं कर सकते।
मेरे विचार में, मुख्य समस्या को वास्तव में हल करने के लिए हमें यह समझना होगा कि router समय पर ACK करने के लिए इतना congested क्यों हो जाता है (जो मैंने पाया है, CPU contention के कारण होता है)। शायद हम router की processing में कुछ चीजों को व्यवस्थित कर सकते हैं ताकि पहले से मौजूद tunnel के transmission को नए tunnel request को decrypt करने की तुलना में higher CPU priority मिल सके? हालांकि हमें starvation से बचने के लिए सावधान रहना होगा।
3) हमें streaming lib के नीचे एक अर्ध-विश्वसनीय प्रोटोकॉल के फायदे बनाम नुकसान पर और अध्ययन की आवश्यकता है। क्या एक single hop पर retransmissions फायदेमंद हैं और एक बड़ी जीत हैं या वे बेकार से भी बदतर हैं? > हम एक नया SUU (secure unreliable UDP) कर सकते हैं लेकिन शायद इसकी कोई आवश्यकता नहीं। हम शायद SSU में एक no-ACK-required message type जोड़ सकते हैं यदि हमें streaming-lib traffic के किसी भी retransmissions की बिल्कुल आवश्यकता नहीं है। क्या tightly bounded retransmissions वांछनीय हैं?
जांचने योग्य - क्या होगा यदि हम केवल SSU के retransmissions को अक्षम कर दें? इससे शायद streaming lib के resend rates बहुत अधिक हो जाएंगे, लेकिन शायद ऐसा न भी हो।
4) .28 में प्राथमिकता भेजने का कोड केवल NTCP के लिए है। अब तक मेरी जांच में SSU प्राथमिकता के लिए ज्यादा उपयोग नहीं दिखा है क्योंकि संदेश इतनी देर तक queue में नहीं रहते कि प्राथमिकताएं कोई फायदा कर सकें। लेकिन और परीक्षण की जरूरत है।
UDPTransport.PRIORITY_LIMITS और UDPTransport.PRIORITY_WEIGHT है (जो TimedWeightedPriorityMessageQueue द्वारा मान्य है), लेकिन वर्तमान में weights लगभग सभी बराबर हैं, इसलिए कोई प्रभाव नहीं है। इसे समायोजित किया जा सकता है, बेशक (लेकिन जैसा कि आपने उल्लेख किया है, यदि कोई queuing नहीं है, तो इससे कोई फर्क नहीं पड़ता)।
5) नई streaming lib का 45s का max timeout शायद अभी भी बहुत कम है। TCP RFC > 60s कहता है। यह शायद underlying NTCP max timeout > (संभवतः 60s) से कम नहीं होना चाहिए।
वह 45s streaming lib का max retransmission timeout है, stream timeout नहीं। TCP में वास्तव में retransmission timeouts कई गुना कम होते हैं, हालांकि हाँ, exposed wires या satellite transmissions के माध्यम से चलने वाले links पर 60s तक जा सकते हैं ;) यदि हम streaming lib retransmission timeout को बढ़ाकर जैसे 75 seconds कर दें, तो हम एक web page load होने से पहले beer लेने जा सकते हैं (खासकर यह मानते हुए कि 98% से कम reliable transport है)। यही एक कारण है कि हम NTCP को प्राथमिकता देते हैं।
zzz का जवाब
नए Syndie में पोस्ट किया गया, 2007-03-31
10 retransmissions पर, हम पहले से ही बहुत बुरी स्थिति में हैं, मैं सहमत हूं। एक, शायद दो > retransmissions उचित है, transport layer से, लेकिन अगर दूसरा पक्ष > समय पर ACK करने के लिए बहुत congested है (implemented SACK/NACK capability के साथ भी), > तो हम बहुत कुछ नहीं कर सकते। > > मेरे विचार में, मूल समस्या को वास्तव में हल करने के लिए हमें यह समझना होगा कि > router इतना congested क्यों हो जाता है कि समय पर ACK नहीं कर पाता (जो, मैंने जो पाया है, > CPU contention के कारण है)। शायद हम router की processing में कुछ चीजें juggle कर सकते हैं > ताकि पहले से मौजूदा tunnel का transmission, नए tunnel request को decrypt करने से > अधिक CPU priority पा सके? हालांकि हमें starvation से बचने के लिए सावधान रहना होगा।
मेरी मुख्य stats-gathering तकनीकों में से एक है net.i2p.client.streaming.ConnectionPacketHandler=DEBUG को चालू करना और RTT times और window sizes को देखना जैसे वे आते-जाते हैं। एक पल के लिए सामान्यीकरण करते हुए, आमतौर पर 3 प्रकार के connections देखने को मिलते हैं: ~4s RTT, ~10s RTT, और ~30s RTT। 30s RTT connections को कम करने की कोशिश करना लक्ष्य है। यदि CPU contention कारण है तो शायद कुछ juggling से काम हो जाए।
SSU max retrans को 10 से कम करना वास्तव में अंधेरे में तीर चलाने जैसा है क्योंकि हमारे पास इस बात का अच्छा डेटा नहीं है कि क्या हम collapse हो रहे हैं, TCP-over-TCP की समस्याएं हो रही हैं, या क्या हो रहा है, इसलिए अधिक डेटा की आवश्यकता है।
देखने योग्य है - क्या होगा यदि हमने सिर्फ SSU के retransmissions को disable कर दिया? इससे शायद streaming lib resend rates काफी बढ़ जाएं, लेकिन हो सकता है ऐसा न हो।
जो बात मुझे समझ में नहीं आ रही है, अगर आप विस्तार से बता सकें, वह है non-streaming-lib ट्रैफिक के लिए SSU retransmissions के फायदे। क्या हमें tunnel messages (उदाहरण के लिए) के लिए semi-reliable transport की जरूरत है या वे unreliable या kinda-sorta-reliable transport (उदाहरण के लिए, अधिकतम 1 या 2 retransmissions) का उपयोग कर सकते हैं? दूसरे शब्दों में, semi-reliability क्यों?
(लेकिन जैसा कि आपने उल्लेख किया है, अगर कोई queuing नहीं है, तो इससे कोई फर्क नहीं पड़ता).
मैंने UDP के लिए priority sending को implement किया लेकिन यह NTCP side के code की तुलना में लगभग 100,000 गुना कम activate हुआ। शायद यह आगे की जांच के लिए एक सुराग या संकेत है - मुझे समझ नहीं आता कि यह NTCP पर इतना अधिक बार क्यों back up होगा, लेकिन शायद यह इस बात का संकेत है कि NTCP का performance क्यों खराब है।
jrandom द्वारा उत्तरित प्रश्न
नई Syndie पर पोस्ट किया गया, 2007-03-31
NTCP के कार्यान्वयन से पहले हमने देखी गई SSU retransmission दरें > (10-30+%) > > क्या router स्वयं इसे माप सकता है? यदि हां, तो क्या measured प्रदर्शन के आधार पर transport का चयन किया जा सकता है? (यानी यदि किसी peer के साथ SSU connection अनुचित संख्या में messages drop कर रहा है, तो उस peer को भेजते समय NTCP को प्राथमिकता दें)
हाँ, यह वर्तमान में उस stat का उपयोग एक साधारण MTU detection के रूप में करता है (यदि retransmission rate अधिक है, तो यह छोटे packet size का उपयोग करता है, लेकिन यदि यह कम है, तो यह बड़े packet size का उपयोग करता है)। जब हमने पहली बार NTCP को पेश किया था (और जब पहली बार मूल TCP transport से दूर जा रहे थे) तो हमने कुछ चीजों की कोशिश की थी जो SSU को प्राथमिकता देती थीं लेकिन किसी peer के लिए उस transport को आसानी से fail कर देती थीं, जिससे वह NTCP पर वापस आ जाता था। हालांकि, इस संबंध में निश्चित रूप से और भी बहुत कुछ किया जा सकता है, हालांकि यह जल्दी ही जटिल हो जाता है (bids को कैसे/कब adjust/reset करना है, इन preferences को कई peers में share करना है या नहीं, इसे एक ही peer के साथ कई sessions में share करना है या नहीं (और कितने समय तक), आदि)।
foofighter की प्रतिक्रिया
नए Syndie में पोस्ट किया गया, 2007-03-26
अगर मैंने चीजों को सही समझा है, तो TCP के पक्ष में मुख्य कारण (सामान्य रूप से, पुराने और नए दोनों प्रकार का) यह था कि आपको एक अच्छे TCP stack को code करने की चिंता करने की आवश्यकता नहीं है। जो सही करना असंभव रूप से कठिन नहीं है… बस यह कि मौजूदा TCP stacks की 20 साल की बढ़त है।
मेरी जानकारी के अनुसार, TCP बनाम UDP की प्राथमिकता के पीछे कोई गहरा सिद्धांत नहीं रहा है, सिवाय निम्नलिखित विचारों के:
- एक TCP-केवल नेटवर्क पहुंचने योग्य peers (जो अपने NAT के माध्यम से आने वाले कनेक्शन को आगे भेज सकते हैं) पर बहुत निर्भर होता है
- फिर भी अगर पहुंचने योग्य peers दुर्लभ हों, तो उनका उच्च क्षमता वाला होना टोपोलॉजिकल कमी की समस्याओं को कुछ हद तक कम करता है
- UDP “NAT hole punching” की अनुमति देता है जो लोगों को “एक प्रकार से pseudo-reachable” बनने देता है (introducers की सहायता से) जो अन्यथा केवल बाहर कनेक्ट हो सकते थे
- “पुराने” TCP transport implementation को बहुत सारे threads की आवश्यकता थी, जो performance killer था, जबकि “नया” TCP transport कम threads के साथ अच्छा काम करता है
- सेट A के routers UDP से saturated होने पर खराब हो जाते हैं। सेट B के routers TCP से saturated होने पर खराब हो जाते हैं।
- यह “लगता है” (यानी, कुछ संकेत हैं लेकिन कोई वैज्ञानिक डेटा या गुणवत्ता आंकड़े नहीं) कि A, B की तुलना में अधिक व्यापक रूप से deployed है
- कुछ नेटवर्क non-DNS UDP datagrams को एकदम खराब गुणवत्ता के साथ carry करते हैं, जबकि अभी भी TCP streams को carry करने की कुछ परवाह करते हैं।
इस पृष्ठभूमि में, transports की एक छोटी विविधता (जितनी आवश्यक हो, लेकिन अधिक नहीं) दोनों स्थितियों में समझदारी की बात लगती है। मुख्य transport कौन सा होना चाहिए, यह उनकी performance पर निर्भर करता है। जब मैंने UDP के साथ अपनी line की पूरी क्षमता का उपयोग करने की कोशिश की तो मैंने अपनी line पर भयानक समस्याएं देखी हैं। 35% के स्तर पर packet losses।
हम निश्चित रूप से UDP बनाम TCP प्राथमिकताओं के साथ खेल करने की कोशिश कर सकते हैं, लेकिन मैं इसमें सावधानी बरतने का आग्रह करूंगा। मैं आग्रह करूंगा कि इन्हें एक साथ बहुत कट्टरपंथी रूप से न बदला जाए, या इससे चीजें टूट सकती हैं।
zzz का जवाब (foofighter को)
नए Syndie में पोस्ट किया गया, 2007-03-27
जहाँ तक मुझे पता है, TCP बनाम UDP की प्राथमिकता के पीछे कोई गहरा सिद्धांत नहीं रहा है, सिवाय निम्नलिखित विचारों के:
ये सभी वैध मुद्दे हैं। हालांकि आप दोनों protocols को अलगाव में देख रहे हैं, बजाय इसके कि यह सोचें कि किसी विशेष उच्च-स्तरीय protocol (यानी streaming lib या नहीं) के लिए कौन सा transport protocol सबसे अच्छा है।
मैं यह कह रहा हूं कि आपको streaming lib को ध्यान में रखना होगा।
तो या तो सबके लिए प्राथमिकताएं बदलें या streaming lib ट्रैफिक को अलग तरीके से संभालें।
यही बात मेरे प्रस्ताव 1B) में कही गई है - streaming-lib ट्रैफिक के लिए non streaming-lib ट्रैफिक (जैसे tunnel build messages) से अलग प्राथमिकता रखना।
इस पृष्ठभूमि में, transports की एक छोटी विविधता (जितनी आवश्यक हो, लेकिन > अधिक नहीं) दोनों स्थितियों में समझदारी लगती है। मुख्य transport कौन सा होना > चाहिए, यह उनके प्रदर्शन पर निर्भर करता है। मैंने अपनी लाइन पर भयानक चीजें देखी हैं जब मैंने > UDP के साथ इसकी पूरी क्षमता का उपयोग करने की कोशिश की। 35% के स्तर पर packet losses।
सहमत। नया .28 संस्करण UDP पर पैकेट लॉस के लिए स्थिति बेहतर बना सकता है, या शायद नहीं।
एक महत्वपूर्ण बात - transport कोड transport की विफलताओं को याद रखता है। तो अगर UDP पसंदीदा transport है, तो यह पहले इसे आज़माएगा, लेकिन अगर यह किसी विशेष गंतव्य के लिए विफल हो जाता है, तो उस गंतव्य के लिए अगली कोशिश में यह UDP को फिर से आज़माने के बजाय NTCP को आज़माएगा।
हम निश्चित रूप से UDP बनाम TCP प्राथमिकताओं के साथ प्रयोग करने की कोशिश कर सकते हैं, लेकिन मैं इसमें सावधानी बरतने की सलाह दूंगा। मैं सुझाव दूंगा कि उन्हें एक साथ बहुत अधिक बदला न जाए, या इससे चीजें खराब हो सकती हैं।
हमारे पास चार tuning knobs हैं - चार bid values (SSU और NTCP, पहले से connected और पहले से connected नहीं के लिए)। हम SSU को NTCP पर केवल तभी प्राथमिकता दे सकते हैं जब दोनों connected हों, उदाहरण के लिए, लेकिन अगर कोई भी transport connected नहीं है तो पहले NTCP को try करें।
इसे धीरे-धीरे करने का दूसरा तरीका केवल streaming lib traffic को shift करना है (1B प्रस्ताव) हालांकि यह कठिन हो सकता है और इसके anonymity पर प्रभाव हो सकते हैं, मुझे नहीं पता। या फिर केवल पहले outbound hop के लिए traffic को shift करना (यानी flag को अगले router तक propagate न करना), जो आपको केवल आंशिक लाभ देता है लेकिन अधिक anonymous और आसान हो सकता है।
चर्चा के परिणाम
… और उसी समयावधि (2007) में अन्य संबंधित परिवर्तन:
- streaming lib parameters की महत्वपूर्ण ट्यूनिंग, जिससे outbound performance में काफी सुधार हुआ, 0.6.1.28 में लागू की गई
- NTCP के लिए priority sending 0.6.1.28 में लागू की गई
- SSU के लिए priority sending zzz द्वारा लागू की गई थी लेकिन कभी check in नहीं की गई
- Advanced transport bid control i2np.udp.preferred 0.6.1.29 में लागू की गई।
- NTCP के लिए pushback 0.6.1.30 में लागू की गई, anonymity concerns के कारण 0.6.1.31 में disable की गई, और उन चिंताओं को दूर करने के सुधारों के साथ 0.6.1.32 में फिर से enable की गई।
- zzz के proposals 1-5 में से कोई भी लागू नहीं किया गया है।