बॅकग्राउंड ॲप रीफ्रेश कशा प्रकारे सार्वजनिक WiFi च्या कार्यक्षमतेवर वाईट परिणाम करते

पार्श्वभूमीवरील ॲप रिफ्रेश (Background App Refresh) सार्वजनिक WiFi परफॉर्मन्स कसा खराब करतो - Purple कडून एक तांत्रिक माहिती (Technical Briefing). आपले स्वागत आहे. जर आपण एखाद्या अतिथी (guest) WiFi नेटवर्कसाठी जबाबदार असाल - मग ते हॉटेल असो, किरकोळ विक्रीचे दुकान (retail estate), स्टेडियम असो किंवा कॉन्फरन्स सेंटर असो - तर ही माहिती आपला एअर टाईम बजेटबद्दलचा विचार करण्याची पद्धत बदलणार आहे. मी तुम्हाला सार्वजनिक वायरलेस डेप्लॉयमेंटमधील सर्वात कमी समजल्या जाणाऱ्या क्षमता नष्ट करणाऱ्या घटकांपैकी एकाची ओळख करून देणार आहे: तो म्हणजे पार्श्वभूमीवरील ॲप रिफ्रेश (background app refresh). आपण प्रोटोकॉल पातळीवर हे नेमके काय आहे, उच्च-घनतेच्या (high-density) वातावरणात हे विशेषतः का विनाशकारी ठरते, आणि - सर्वात महत्त्वाचे म्हणजे - आज तुम्ही नेटवर्क लेयरवर याबद्दल काय करू शकता, हे सर्व समजून घेणार आहोत. चला या समस्येच्या व्याप्तीपासून सुरुवात करूया. तुमच्या नेटवर्कवर येणाऱ्या पाहुण्यांच्या प्रत्येक स्मार्टफोनमध्ये जवळपास ३० ते ८० इंस्टॉल केलेले ॲप्लिकेशन्स चालू असतात. त्यापैकी बऱ्याच मोठ्या प्रमाणातील ॲप्स हे बॅकग्राउंड रिफ्रेश सायकल्स चालवण्यासाठी कॉन्फिगर केलेले असतात - जे ॲनालिटिक्स सर्व्हर्स पोलिंग करणे, क्लाउड डेटा सिंक करणे, पुश नोटिफिकेशन टोकन्स मिळवणे, OS अपडेट्स तपासणे आणि जाहिरात नेटवर्क्सना पिंग करणे अशी कामे करतात. iOS वर, Apple चे Background App Refresh हे फीचर iOS 7 मध्ये आणले गेले होते आणि तेव्हापासून ते एक कायमस्वरूपी वैशिष्ट्य राहिले आहे. Android कडे JobScheduler आणि WorkManager API द्वारे त्याचे स्वतःचे समतुल्य पर्याय आहेत. मुख्य मुद्दा हा आहे: वापरकर्ता त्यांचे डिव्हाइस सक्रियपणे वापरत आहे की नाही याकडे दुर्लक्ष करून या प्रक्रिया चालतात. त्या शांतपणे, अदृश्यपणे आणि सतत सुरू असतात. आता, एक किंवा दोन डिव्हाइसेस असलेल्या घरगुती ब्रॉडबँड कनेक्शनवर, हे सहसा दिसून येत नाही. परंतु जेव्हा तुम्ही १,२०० प्रतिनिधी असलेल्या कॉन्फरन्स सेंटरमध्ये किंवा ४०० एकाच वेळी जोडलेल्या गेस्ट कनेक्शन असलेल्या रिटेल फ्लॅगशिप स्टोअरमध्ये याची व्याप्ती वाढवता, तेव्हा हे गणित खूप वेगाने बिघडू लागते. एंटरप्राइझ वायरलेस डेप्लॉयमेंटवरील संशोधनातून सतत असे दिसून येते की बॅकग्राउंड ट्रॅफिक - जसे की ॲनालिटिक्स बीकन्स, OS अपडेट चेक्स, ॲड नेटवर्क पिंग्स, पुश नोटिफिकेशन पोलिंग, क्लाउड सिंक आणि सोशल मीडिया रिफ्रेश सायकल्स - व्यस्त गेस्ट नेटवर्कवरील एकूण ॲक्सेस पॉइंट क्षमतेच्या ३० ते ४५ टक्क्यांच्या दरम्यान असू शकते. ही ती क्षमता आहे जी तुमच्या खऱ्या वापरकर्त्यांना - जे प्रेझेंटेशन स्ट्रीम करण्याचा, व्यवहार पूर्ण करण्याचा किंवा फक्त ब्राउझ करण्याचा प्रयत्न करत आहेत - त्यांना मिळत नाही. रेडिओ लेयरवर प्रत्यक्षात काय घडत आहे याचे तांत्रिक चित्र मी तुम्हाला देतो. एका 802.11 नेटवर्कमध्ये, ॲक्सेस पॉइंटशी जोडलेले प्रत्येक डिव्हाइस CSMA/CA - Carrier Sense Multiple Access with Collision Avoidance चा वापर करून एअर टाईमसाठी स्पर्धा करते. प्रत्येक बॅकग्राउंड रिफ्रेश विनंतीसाठी, पेलोड कितीही लहान असला तरी, संपूर्ण असोसिएशन सिक्वेन्स आवश्यक असतो: प्रोब रिक्वेस्ट, ऑथेंटिकेशन, असोसिएशन, आवश्यक असल्यास DHCP, आणि नंतर प्रत्यक्ष डेटा ट्रान्सफर. उच्च-घनतेच्या डेप्लॉयमेंटमध्ये, हा कंटेंशन ओव्हरहेड लक्षणीय असतो. एकाच ॲपमधील एकाच ॲनालिटिक्स बीकनद्वारे केवळ २०० बाइट्स डेटा ट्रान्सफर केला जाऊ शकतो, परंतु वायरलेस माध्यमावरील त्या ट्रान्झॅक्शनचा ओव्हरहेड एअर टाईममध्ये त्याच्या १० ते २० पट जास्त वापर करू शकतो.WiFi 6 - IEEE 802.11ax सह - आमच्याकडे OFDMA आणि BSS Colouring आहेत जे याचे अधिक कार्यक्षमतेने व्यवस्थापन करण्यास मदत करतात. परंतु या सुधारणांनंतरही, मूलभूत समस्या कायम राहते: जोपर्यंत तुम्ही नेटवर्क लेयरवर हस्तक्षेप करत नाही तोपर्यंत तुम्ही बॅकग्राउंड ट्रॅफिकद्वारे वापरलेला एअर टाइम परत मिळवू शकत नाही. रेडिओला हे माहित नसते किंवा त्याची काळजी नसते की एखादा पॅकेट वापरकर्ता व्हिडिओ पाहत आहे की एखादे ॲप व्हर्जिनियामधील टेलिमेट्री सर्व्हरशी गुपचूप संपर्क साधत आहे. या ठिकाणी तुमच्या आर्किटेक्चरमध्ये डीप पॅकेट इन्स्पेक्शन आणि ट्रॅफिक वर्गीकरण ही अत्यंत महत्त्वाची साधने बनतात. तुमचे वायरलेस कंट्रोलर आणि अपस्ट्रीम गेटवे यांच्यामध्ये असलेले योग्यरित्या कॉन्फिगर केलेले ट्रॅफिक वर्गीकरण इंजिन, बॅकग्राउंड रिफ्रेश ट्रॅफिकला त्याच्या डेस्टिनेशन, पेलोड सिग्नेचर आणि वर्तन पद्धतीद्वारे ओळखू शकते. Google Analytics, Firebase, Crashlytics, Flurry, Amplitude, Mixpanel आणि इतर डझनभर ज्ञात ॲनालिटिक्स एंडपॉइंट्स - यांच्याकडे चांगल्या प्रकारे दस्तऐवजीकरण केलेल्या IP श्रेणी आणि डोमेन पॅटर्न आहेत. DoubleClick, AppNexus आणि तत्सम प्लॅटफॉर्मवरील जाहिरात नेटवर्क एंडपॉइंट्स देखील तितक्याच चांगल्या प्रकारे कॅटलॉग केलेले आहेत. DNS किंवा IP लेयरवर लागू केलेली नियमितपणे अपडेट केलेली ब्लॉक लिस्ट, या विनंत्या कोणताही महत्त्वाचा बँडविड्थ वापरण्यापूर्वी त्यांना रोखू शकते. हा दृष्टिकोन व्हेंडर - न्यूट्रल आहे. तुम्ही Cisco Catalyst Centre, Aruba Central, Juniper Mist किंवा Ruckus SmartZone उपयोजन चालवत असाल तरीही, तत्त्व सारखेच आहे: वर्गीकृत करा, नंतर कृती करा. ओळखलेल्या बॅकग्राउंड ट्रॅफिकचे काय करायचे यासाठी तुमच्याकडे तीन पर्याय आहेत. तुम्ही ते पूर्णपणे ब्लॉक करू शकता - हा सर्वात आक्रमक दृष्टिकोन आणि क्षमता पुनर्प्राप्तीसाठी सर्वात प्रभावी आहे. तुम्ही त्याचे दर मर्यादित करू शकता - ट्रॅफिकला परवानगी देणे परंतु त्यास परिभाषित बँडविड्थ मर्यादेपर्यंत मर्यादित करणे, सामान्यत: बॅकग्राउंड श्रेणींसाठी प्रति डिव्हाइस 64 किलोबिट प्रति सेकंद. किंवा तुम्ही QoS DSCP मार्किंग वापरून त्याचे प्राधान्य कमी करू शकता, ज्यामुळे ते सर्वात कमी ट्रॅफिक क्लासमध्ये जाते जेणेकरून इतर कोणतेही ट्रॅफिक स्पर्धा करत नसतानाच ते एअर टाइम वापरेल. बहुतेक ठिकाणच्या ऑपरेटरसाठी, ज्ञात ॲनालिटिक्स आणि जाहिरात नेटवर्क एंडपॉइंट्स ब्लॉक करणे आणि पीक अवर्समध्ये OS अपडेट ट्रॅफिकचे दर मर्यादित करणे यांचे संयोजन, क्षमता पुनर्प्राप्ती आणि वापरकर्ता अनुभव यांचा सर्वोत्तम समतोल प्रदान करते. आता मी तुम्हाला दोन प्रत्यक्ष उपयोजन परिस्थितींमधून घेऊन जातो जिथे यामुळे मोजता येण्याजोगा फरक पडला आहे. पहिले उदाहरण युनायटेड किंगडम (UK) मिडलँड्समधील ३४० खोल्यांचे एक चार-तारांकित (फोर-स्टार) हॉटेल आहे. या प्रॉपर्टीने एका आधुनिक WiFi ६ इन्फ्रास्ट्रक्चरमध्ये गुंतवणूक केली होती - अतिथी मजले, कॉन्फरन्स सूट्स आणि सार्वजनिक क्षेत्रांमध्ये मिळून ४८ ॲक्सेस पॉइंट्स. हार्डवेअर गुंतवणुकीनंतरही, WiFi साठी अतिथींच्या समाधानाचे गुण सतत उद्दिष्टापेक्षा कमी होते. नेटवर्क टीमने Purple प्लॅटफॉर्मचा वापर करून ट्रॅफिक विश्लेषण केले आणि त्यांना आढळले की बॅकग्राउंड ॲप रिफ्रेश ट्रॅफिक दुपारी ३ ते संध्याकाळी ६ दरम्यानच्या पीक चेक-इन कालावधीत अतिथी SSID वरील उपलब्ध एअर टाईमचा ३८ टक्के हिस्सा वापरत होते. त्यानंतर ८४७ ज्ञात ॲनालिटिक्स आणि जाहिरात नेटवर्क डोमेन्स कव्हर करणारी एक लक्ष्यित ब्लॉक लिस्ट तैनात करण्यात आली. दोन आठवड्यांत, पीक कालावधी दरम्यान प्रति कनेक्ट केलेल्या डिव्हाइसचा सरासरी थ्रूपुट ३४ टक्क्यांनी वाढला आणि प्रॉपर्टीच्या अंतर्गत NPS ट्रॅकिंगवर अतिथी WiFi समाधानाचे गुण २२ पॉईंट्सनी सुधारले. दुसरे उदाहरण इंग्लंड आणि वेल्समधील ६० स्टोअर्स असलेली एक प्रादेशिक रिटेल साखळी आहे. प्रत्येक स्टोअर एक अतिथी WiFi SSID चालवते जे ग्राहक आणि इन-स्टोअर डिजिटल सायनेज दोन्हीद्वारे वापरले जाते. IT टीमला डिजिटल सायनेजच्या लेटनसीबद्दल तक्रारी येत होत्या - व्यस्त ट्रेडिंग कालावधीत स्क्रीन्स बफर होत होत्या. ट्रॅफिक विश्लेषणातून असे दिसून आले की अतिथी SSID शी कनेक्ट होणारी ग्राहकांची डिव्हाइसेस मोठ्या प्रमाणावर बॅकग्राउंड ट्रॅफिक निर्माण करत होती, ज्यामध्ये स्टोअर नेटवर्कवरून मल्टि-गीगाबाईट पेलोड्स खेचणाऱ्या iOS अपडेट चेक्सचा समावेश होता. ॲनालिटिक्स एंडपॉइंट्ससाठी DNS-स्तरीय ब्लॉकिंग आणि ओळखलेल्या OS अपडेट ट्रॅफिकसाठी प्रति सेकंद १ मेगाबिटची कठोर रेट मर्यादा यांच्या एकत्रित वापरामुळे सायनेज लेटनसीची समस्या पूर्णपणे सुटली. केंद्रीकृत पॉलिसी व्यवस्थापनाचा वापर करून संपूर्ण मालमत्तेवर हे निराकरण लागू करण्यासाठी चार तासांपेक्षा कमी वेळ लागला. तुमच्या स्वतःच्या वातावरणात हे लागू करण्यासाठी तुम्हाला फॉलो कराव्या लागणाऱ्या अंमलबजावणीच्या पायऱ्या आता मी सांगतो. पहिली पायरी म्हणजे बेसलाइन मापन. तुम्ही कोणत्याही कॉन्फिगरेशनला हात लावण्यापूर्वी, तुम्हाला तुमचे सध्याचे ट्रॅफिक प्रोफाइल समजून घेणे आवश्यक आहे. एक ट्रॅफिक विश्लेषण टूल तैनात करा - Purple चे WiFi Analytics प्लॅटफॉर्म हे नेटिव्हली प्रदान करते - आणि आठवड्याचे दिवस आणि वीकेंडचे पॅटर्न कॅप्चर करण्यासाठी ते किमान पाच व्यावसायिक दिवसांसाठी चालवा. तुम्ही ज्ञात बॅकग्राउंड-रिफ्रेश डेस्टिनेशनवर जाणाऱ्या ट्रॅफिकचे प्रमाण, बॅकग्राउंड ॲक्टिव्हिटीचे पीक कालावधी आणि प्रति-डिव्हाइस वापर दर शोधत आहात. दुसरी पायरी म्हणजे तुमची ब्लॉक लिस्ट तयार करणे. तुमचा पाया म्हणून OISD डोमेन ब्लॉक लिस्टने सुरुवात करा - ती उत्तम प्रकारे राखली जाते, कम्युनिटी-व्validated आहे आणि प्रमुख ॲनालिटिक्स तसेच जाहिरात नेटवर्क एंडपॉइंट्स कव्हर करते. ट्रॅफिक विश्लेषणातून मिळालेल्या तुमच्या स्वतःच्या निरीक्षणांसह यामध्ये भर घाला. महत्त्वाचे म्हणजे, सरसकट ब्लॉक करू नका. ठराविक बॅकग्राउंड ट्रॅफिक - विशेषतः पोर्ट ५२२३ वरील Apple Push Notification Service आणि Google Firebase Cloud Messaging - डिव्हाइसच्या कार्यक्षमतेसाठी आवश्यक आहे. हे ब्लॉक केल्याने वापरकर्त्यांच्या तक्रारी वाढतील. तुमची ब्लॉक लिस्ट संपूर्ण मालमत्तेवर लागू करण्यापूर्वी स्टेजिंग वातावरणात किंवा एकाच ॲक्सेस पॉइंट ग्रुपवर तपासा.पायरी तीन म्हणजे पॉलिसी डिप्लॉयमेंट (policy deployment). तुमचे क्लासिफिकेशन नियम वैयक्तिक ॲक्सेस पॉईंट्सवर लागू न करता WLAN कंट्रोलर पातळीवर लागू करा. यामुळे सातत्य सुनिश्चित होते आणि चालू व्यवस्थापन सोपे होते. जर तुमचा कंट्रोलर ॲप्लिकेशन-अवेअर QoS चे समर्थन करत असेल, तर प्रत्येक गोष्टीवर कडक बंदी घालण्याऐवजी पार्श्वभूमीतील कॅटेगरींचे प्राधान्य कमी करण्यासाठी DSCP मार्किंग वापरा — यामुळे तुम्हाला सुलभ पर्याय मिळतो आणि अनपेक्षित परिणामांचा धोका कमी होतो. पायरी चार म्हणजे सतत देखरेख ठेवणे. बॅकग्राउंड रिफ्रेश एंडपॉईंट्स बदलत राहतात. नवीन ॲनालिटिक्स SDKs समोर येतात. ॲप डेव्हलपर्स त्यांच्या सर्व्हरशी संपर्क साधण्यासाठी नवीन मार्ग शोधतात. तुमच्या ब्लॉक लिस्टचे दर तिमाहीला किमान एकदा पुनरावलोकन आणि अपडेट करणे आवश्यक आहे. जाहिरात आणि ॲनालिटिक्स नेटवर्क अपडेट्स समाविष्ट असलेल्या थ्रेट इंटेलिजन्स फीड्सचा वापर करून शक्य असेल तिथे हे स्वयंचलित करा. अनुपालनाच्या (compliance) दृष्टीकोनातून, हे लक्षात घेणे महत्त्वाचे आहे की नेटवर्क लेयरवर ट्रॅफिकचे वर्गीकरण आणि ब्लॉकिंग करणे म्हणजे RIPA किंवा तत्सम कायद्यांतर्गत इंटरसेप्शन मानले जात नाही, जर तुम्ही एन्क्रिप्टेड पेलोड्सच्या कंटेंटची तपासणी करत नसाल. तुम्ही डेस्टिनेशन मेटाडेटावर — IP ॲड्रेस आणि डोमेन नेम्सवर — प्रक्रिया करत आहात, संवादाच्या कंटेंटवर नाही. हे नेटवर्क व्यवस्थापनासाठी GDPR कलम ६ मधील कायदेशीर स्वारस्य (legitimate interests) आधारांशी सुसंगत आहे, परंतु तुम्ही तुमच्या पॉलिसीचे दस्तऐवजीकरण केले पाहिजे आणि तुमच्या नेटवर्क स्वीकार्य वापर पॉलिसीमध्ये (acceptable use policy) तसेच प्रायव्हसी नोटिसमध्ये त्याचा संदर्भ दिला गेला आहे याची खात्री केली पाहिजे. आता, टाळण्यासारख्या काही सामान्य चुका पाहूया. पहिली चूक म्हणजे ओव्हर-ब्लॉकिंग (over-blocking). योग्य चाचणी न घेता आक्रमक ब्लॉक लिस्ट तैनात करणारे संघ वारंवार पाहतात की त्यांनी नकळतपणे वापरकर्ते अवलंबून असलेल्या ॲपच्या कार्यक्षमतेला बाधा आणली आहे. महत्त्वपूर्ण सेवांसाठी नेहमी अलोव लिस्ट (allowlist) ठेवा आणि रोलबॅक प्लॅन तयार ठेवा. दुसरी चूक म्हणजे ५ GHz आणि ६ GHz बँड स्प्लिटकडे दुर्लक्ष करणे. बॅकग्राउंड रिफ्रेश ट्रॅफिक सामान्यतः २.४ GHz वर केंद्रित असते कारण जुनी डिव्हाइसेस आणि IoT एंडपॉईंट्स बाय-डिफॉल्ट त्या बँडचा वापर करतात. तुम्ही फक्त ५ GHz ट्रॅफिकचे विश्लेषण करत असल्यास, तुम्ही समस्येचा मोठा भाग गमावत असाल. तुमचे विश्लेषण सर्व बँड्स कव्हर करत असल्याची खात्री करा. तिसरी चूक म्हणजे याकडे वन-टाइम फिक्स (एकदाच करायची दुरुस्ती) म्हणून पाहणे. बॅकग्राउंड रिफ्रेश ट्रॅफिकचे पॅटर्न सतत बदलत असतात. सहा महिन्यांपूर्वी व्यापक असलेली ब्लॉक लिस्ट कदाचित सध्याच्या ॲनालिटिक्स एंडपॉईंट्समधील ३० टक्के एंडपॉईंट्स ब्लॉक करू शकत नाही. तुमच्या नेटवर्क व्यवस्थापन कॅलेंडरमध्ये नियमित पुनरावलोकनाची वेळ निश्चित करा. नेटवर्क आर्किटेक्ट्सकडून मला वारंवार ऐकू येणाऱ्या काही प्रश्नांच्या उत्तरांसह मी समारोप करतो. "ॲनालिटिक्स ट्रॅफिक ब्लॉक केल्याने माझ्या वापरकर्त्यांसाठी ॲपच्या कामगिरीवर परिणाम होईल का?" बहुतेक प्रकरणांमध्ये, नाही. ॲनालिटिक्स बीकन्स हे 'फायर-अँड-फॉरगेट' पद्धतीचे असतात. ॲप पुढील काम सुरू ठेवण्यापूर्वी प्रतिसादाची वाट पाहत नाही. वापरकर्त्याच्या हे लक्षातही येणार नाही. "हे एन्क्रिप्टेड DNS सोबत काम करते का?" स्टँडर्ड DNS-over-HTTPS ट्रॅफिक पारंपारिक DNS-आधारित ब्लॉकिंगला बायपास करू शकते. तुम्हाला एकतर गेटवेवर DoH इंटरसेप्ट करावे लागेल किंवा DNS ब्लॉकिंग व्यतिरिक्त ज्ञात ॲनालिटिक्स रेंजेससाठी IP-level ब्लॉकिंग वापरावे लागेल. एंटरप्राइझ-ग्रेड कंट्रोलर्समध्ये या दोन्ही दृष्टिकोनांना समर्थन दिले जाते. "कॉर्पोरेट SSID वरील BYOD डिव्हाइसेसचे काय?" हेच नियम लागू होतात, परंतु तुमच्याकडे 802.1X ऑथेंटिकेशन आणि प्रति-वापरकर्ता पॉलिसी अंमलबजावणीसह अतिरिक्त पर्याय आहेत. कॉर्पोरेट SSID साठी, कोणत्या बॅकग्राउंड ट्रॅफिकला परवानगी आहे याबद्दल तुम्ही अधिक स्पष्ट असू शकता. "मी बोर्डाला या गुंतवणुकीचे समर्थन कसे करू?" ROI चे गणित सोपे आहे. वाया गेलेल्या एअर टाइमपैकी ३० ते ४० टक्के रिकव्हर करणे म्हणजे तुमच्या विद्यमान इन्फ्रास्ट्रक्चरमध्ये एकही अतिरिक्त ॲक्सेस पॉइंट न खरेदी करता ३० ते ४० टक्के अधिक क्षमता जोडण्यासारखे आहे. ज्या ठिकाणांवर क्षमतेच्या तक्रारींचे निवारण करण्यासाठी हार्डवेअर रिफ्रेश करण्याचा विचार केला जात होता, तेथे नेटवर्क-स्तरीय ट्रॅफिक मॅनेजमेंट तो कॅपिटल खर्च दोन ते तीन वर्षांनी पुढे ढकलू शकते. या ब्रीफिंगमधील मुख्य कृतींचा सारांश सांगायचा तर. पहिले, ट्रॅफिक बेसलाइन विश्लेषण करा - ज्याचे तुम्ही मोजमाप करू शकत नाही त्याचे व्यवस्थापन तुम्ही करू शकत नाही. दुसरे, ज्ञात ॲनालिटिक्स आणि जाहिरात नेटवर्क एंडपॉइंट्सना लक्ष्य करणारी अपडेटेड ब्लॉक लिस्ट तैनात करा. तिसरे, पीक ट्रेडिंग किंवा इव्हेंटच्या तासांमध्ये OS अपडेट ट्रॅफिकसाठी रेट-लिमिटिंग वापरा. चौथे, सतत मॉनिटर करा आणि तुमच्या पॉलिसी त्रैमासिक अपडेट करा. आणि पाचवे, अनुपालन उद्देशांसाठी तुमच्या दृष्टिकोनाचे दस्तऐवजीकरण करा. Purple चे प्लॅटफॉर्म हा डेटा कसा समोर आणतो आणि मल्टी-साइट इस्टेट्समध्ये पॉलिसी उपयोजन कसे सक्षम करतो हे तुम्हाला पहायचे असल्यास, लिंक शो नोट्समध्ये आहे. तुमच्या वेळेबद्दल धन्यवाद.