VPN-এর উপর রিয়েল-টাইম ট্র্যাফিকের জন্য একটি বিলম্ব বাজেট নির্ধারণ করুন
অ্যাপটিকে যে সময়সীমা পূরণ করতে হবে সেখান থেকে শুরু করুন, তারপর নির্দিষ্ট পরিস্থিতিতে একমুখী বিলম্ব ও জিটার মাপুন। শেষ-প্যাকেটের থ্রেশহোল্ড ছাড়া কোনো গড় কিছুই প্রমাণ করে না।
রিয়েল-টাইম VPN-এর অভিযোগের বিরুদ্ধে ব্যর্থ হওয়ার জন্য একটি সময়সীমা দরকার, আর «কম বিলম্ব» তেমন সময়সীমা নয়। কথোপকথন বা দূরবর্তী সেশনটিকে কী দিতে হবে তা ঠিক করুন, তারপর নির্দিষ্ট পরিস্থিতিতে সেই প্রয়োজন অনুযায়ী পথটি মাপুন। দেরিতে আসা প্যাকেটের থ্রেশহোল্ড ছাড়া প্রতিটি ফলাফলই বিতর্কযোগ্য। নিচের বরাদ্দটি একটি নকশা-সিদ্ধান্ত, এবং এটি আছে যাতে পরিমাপের উত্তর দেওয়ার মতো কিছু থাকে।
প্রোব স্পর্শ করার আগেই সময়সীমাটি লিখে ফেলুন
সময়সীমাটি আসে অ্যাপ্লিকেশন ও তার ব্যবহারকারীদের কাছ থেকে, কোনো বিক্রেতার বিপণন পৃষ্ঠা থেকে নয়। একটি লাইভ ভয়েস কল, একটি দূরবর্তী ডেস্কটপ সেশন এবং একটি রাতের ব্যাকআপ সম্পূর্ণ ভিন্ন অপেক্ষার সময় সহ্য করে, আর যে ব্যর্থতাটি গুরুত্বপূর্ণ তা সাধারণত মধ্যমা নয়, লেজ। সংখ্যাটি যে কাজের চাপের অন্তর্গত তার সঙ্গে লিখে রাখুন।
তারপর এটি বরাদ্দ করুন। ক্যাপচার ও প্যাকেটাইজেশন বাজেটের একটি অংশ খায়, অ্যাক্সেস লিংক ও টানেল আরেকটি অংশ খায়, প্রাপকের ডি-জিটার বাফার ইচ্ছাকৃতভাবে প্যাকেট ধরে রাখে, আর অ্যাপ্লিকেশন প্রসেসিং বাকিটা নেয়। এই পর্যায়গুলোর নাম দেওয়া টানেল এনক্রিপশনকে প্রতিটি ধীর প্যাকেটের জন্য ডিফল্ট সন্দেহভাজন বানানোর বদলে অনুপাতে রাখে।
শেষে চারটি লাইনে পরিমাপের চুক্তিটি সংজ্ঞায়িত করুন: প্রান্তবিন্দু ও দিক, ট্র্যাফিকের আকৃতি, চলাকালীন পরিস্থিতি, এবং যে ফলাফল আপনি রিপোর্ট করবেন। একটি শান্ত রবিবারের নমুনা আর একটি ব্যস্ত মঙ্গলবারের নমুনা ভিন্ন প্রশ্নের উত্তর দেয়, তাই কোনটি সংগ্রহ করেছেন তা উল্লেখ করুন। যদি চারটি লাইনই পূরণ করতে না পারেন, তবে রানটি শুরু হওয়ার জন্য প্রস্তুত নয়। সেই চেকলিস্টই দুইটি রিপোর্টকে মাসের পর মাস তুলনাযোগ্য করে তোলে, যখন কেউ আর মনে রাখে না লিংকটি আর কী বহন করছিল।
প্রতিটি পর্যায়ে বাজেট ভাগ করুন
সারণিটি পরিকল্পনার সহায়ক, ধরা পড়া ডেটা নয়। প্রথম প্রোবের আগেই প্রতিটি সারির মালিক লিখুন, কারণ মালিকই সেই ব্যক্তি যাকে আপনি ডাকেন যখন সেই পর্যায় তার অংশ ছাড়িয়ে যায়।
| Stage | What it contributes | Who owns it |
|---|---|---|
| Capture and packetization | Encoder frame size, aggregation | Application owner |
| Tunnel and transit | Encryption, queueing, path length | Network owner |
| Receiver buffer | Deliberate waiting to absorb variation | Application owner |
| Application processing | Decode and render time | Application owner |
দুইটি সারি সাধারণত মানুষকে অবাক করে। প্রাপকের বাফার বিলম্ব যোগ করলে তা ত্রুটি নয়, কারণ এটি যে কাজের জন্য কনফিগার করা হয়েছিল তা-ই করছে। আর টানেলের অংশ প্রায়শই তার সামনের সারির চেয়ে ছোট, বিশেষ করে এমন আপলিংকে যা আপলোডের সময় সম্পৃক্ত হয়ে যায়।
কোনো পর্যায়ের মালিক না থাকলে বাজেটটি কল্পকথা। মাপার আগেই একজনকে নিয়োগ করুন, নইলে পরের সভাটি কাটবে কার সংখ্যা ভুল তা নিয়ে তর্কে।
সৎ ঘড়ি দিয়ে একমুখী বিলম্ব মাপুন
একমুখী বিলম্ব হলো সেই সংখ্যা যা সময়সীমার কাছে গুরুত্বপূর্ণ, আর এর জন্য দুই প্রান্তে সিঙ্ক্রোনাইজড ঘড়ি দরকার। একমুখী বিলম্বের মেট্রিক চায় আপনি ফলাফলের সঙ্গে সিঙ্ক্রোনাইজেশন পদ্ধতি, রেজোলিউশন ও আনুমানিক স্কিউ রিপোর্ট করুন। দুইটি অসিঙ্ক্রোনাইজড হোস্ট ভুল রাশির জন্য খুব নিখুঁত সংখ্যা তৈরি করতে পারে।
এক মুঠোর বদলে কয়েকশ প্যাকেট ধরুন, আর একই সময়ে ঘড়ির অবস্থা লিখে রাখুন:
$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3রাউন্ড-ট্রিপ সময় একটি আলাদা পরিমাপ, দুইটি একমুখী মান যোগ করা নয়। RTT অর্ধেক করা সমমিত পথ ও সমমিত সারি ধরে নেয়, আর মোবাইল আপলিংকের উপর দিয়ে টানেল নিয়মিতভাবে দুইটি অনুমানই ভাঙে। RTT-কে RTT হিসেবেই রিপোর্ট করুন এবং একমুখী বাজেটের বাইরে রাখুন।
লেজ ও দেরিতে আসা প্যাকেট রিপোর্ট করুন
বণ্টনটি সংক্ষেপ করুন: মধ্যমা, 95তম ও 99তম পার্সেন্টাইল, সবচেয়ে খারাপ অবস্থা, ক্ষতি, এবং সময়সীমার চেয়ে দেরিতে আসা প্যাকেটের সংখ্যা। রিয়েল-টাইম কাজের চাপের জন্য গড় হলো সেই সংখ্যাগুলোর মধ্যে সবচেয়ে কম উপযোগী, কারণ মসৃণ গড় একটি লেজ লুকাতে পারে যা প্রতি তৃতীয় কল নষ্ট করে।
বিলম্বের তারতম্য সরাসরি প্রাপকের বাফারিংয়ে ঢোকে। বেশি বাফারিং তারতম্য লুকায় ও অপেক্ষা বাড়ায়, তাই একটি স্ট্রিম তার সময়সীমা ছাড়িয়ে যাওয়ার সময়ও স্থিতিশীল দেখাতে পারে। তারতম্যের একটি সূত্র বেছে নিন, যে ব্যবধানে মাপলেন তা উল্লেখ করুন, আর রানগুলোর মধ্যে তা সামঞ্জস্যপূর্ণ রাখুন।
প্রতিনিধিত্বমূলক ক্রস-ট্র্যাফিক দিয়ে রানটি পুনরাবৃত্তি করুন। যে পথ নিষ্ক্রিয় থাকলে বাজেট পূরণ করে এবং ব্যাকআপ উইন্ডোর সময় তা মিস করে, সে আপনাকে শিডিউলিং সম্পর্কে দরকারি কিছু বলেছে, যা কোনো একক শান্ত পরিমাপ প্রকাশ করত না। ফলাফলের পাশে পরিস্থিতি লিখে রাখুন, নইলে পরের ইঞ্জিনিয়ার এমন দুইটি নমুনা তুলনা করবে যা কখনোই তুলনাযোগ্য ছিল না।
নকশাটি গ্রহণ করুন যখন মাপা লেজটি আপনি সত্যিই চালান এমন কাজের চাপে বাজেটে ফিট করে, আর রিপোর্টে যে পর্যায় ছাড়িয়ে গেছে তার নাম দিয়ে এটি প্রত্যাখ্যান করুন।