একটি G.729 প্যাকেট IPsec টানেলের মধ্য দিয়ে গণনা
একটি সমাধান করা G.729 উদাহরণ দেখায় কীভাবে পেলোড, RTP, ESP ও Ethernet ফ্রেমিং যোগ হয়, এবং কেন একই কল প্রতিটি সীমানায় ভিন্ন ব্যান্ডউইথ খরচ করে।
IPsec-এর উপর ভয়েসকে কোডেক বিটরেট হিসেবে উদ্ধৃত করা হয়, এবং কোডেকের নিজের সীমানা ছাড়া প্রতিটি সীমানায় সেই সংখ্যাটি ভুল। অডিও 8 kbit/s, এটি বহনকারী প্যাকেট বড়, ESP খোলস আরও বড়, এবং Ethernet ফ্রেম এমন ফ্রেমিং যোগ করে যা টানেলের উপর করা ক্যাপচার কখনো দেখায় না। নির্দিষ্ট ফরম্যাট থেকে একটি প্যাকেট গণনা করাই জানার একমাত্র উপায় যে ভৌত লিংককে আসলে কী বহন করতে হয়। নিচের আলোচনা কেবল এক দিকের জন্য তা করে, এবং এখানকার প্রতিটি সংখ্যা পাটিগণিত, পরিমাপ নয়।
কোডেকের সংখ্যা নয়, প্যাকেটাইজেশন বাছাই থেকে শুরু করুন
একটি কোডেক চার্ট পেলোড হার দেয় এবং আর কিছু নয়: G.729 8 kbit/s দেয়, যা প্রতি 30 ms-এ 30 বাইট অডিও। এটি হেডার, সুরক্ষা বা ফ্রেমিং সম্পর্কে কিছু বলে না, আর এই তিনটিই ফলাফল নিয়ন্ত্রণ করে। ইন্টারভাল হলো একটি নীতি-সিদ্ধান্ত যাতে দুই প্রান্তকে একমত হতে হয়, তাই এটি আগে বাছুন ও উল্লেখ করুন, কারণ পরের প্রতিটি সংখ্যা সেই একক সিদ্ধান্তের উপর নির্ভর করে।
এই উদাহরণ 30 ms ব্যবহার করে, তাই প্যাকেট হার প্রতি সেকেন্ডে 33.3। এটি 12 বাইটের RTP হেডার, 8 বাইটের UDP হেডার এবং অপশনবিহীন 20 বাইটের অভ্যন্তরীণ IPv4 হেডার ধরে নেয়, এবং কোনো SRTP, হেডার কম্প্রেশন বা ট্রাফিক-ফ্লো-গোপনীয়তা প্যাডিং নেই; যেকোনো পরিবর্তন বাজেটও সরিয়ে দেয়, তাই অনুমানগুলো উত্তরের পাশেই থাকা উচিত।
অভ্যন্তরীণ হেডার যোগ করুন, তারপর ESP খোলস
অ্যাপ্লিকেশন পেলোড যোগ RTP যোগ UDP যোগ IP পাঠায়, যা এই প্যাকেটাইজেশনে 70 বাইট। সেই অভ্যন্তরীণ স্ট্রিম 18.7 kbit/s-এ দাঁড়ায়, যা ইতিমধ্যে কোডেক হারের দ্বিগুণেরও বেশি, কারণ প্যাকেটের অধিকাংশই অডিও নয়, হেডার। ওই বাইটগুলোর একটিও কণ্ঠ নয়; সেগুলো ঠিকানা ও ক্রম দেওয়ার মূল্য। টানেলের উপরে নেওয়া ক্যাপচার ঠিক এই সংখ্যাটিই দেখায়, এবং মানুষ যখন বলে কলটি ছোট, তখন এই সংখ্যাটিই উদ্ধৃত করে।
এটি সেই সংখ্যাও যা কখনো তারে পৌঁছায় না। ESP টানেল মোড 8 বাইটের SPI ও সিকোয়েন্স নম্বর, AES-GCM-এর জন্য 8 বাইটের স্পষ্ট IV, 2 বাইটের ট্রেইলার এবং 16 বাইটের প্রমাণীকরণ ট্যাগ যোগ করে। 70 বাইটের পেলোড ও ট্রেইলার মিলে 72 হয়, যা ইতিমধ্যে চার বাইটের সারিবদ্ধতা পূরণ করে, তাই এখানে অতিরিক্ত প্যাডিং দরকার নেই।RFC 4106 GCM-এর IV ও ট্যাগের আকার নির্ধারণ করে, এবং দুটোই পাদটীকায় নয়, পাটিগণিতেই থাকা উচিত:
30 payload, G.729 at 30 ms
12 RTP
8 UDP
20 inner IPv4
--
70 inner IP packet
8 ESP SPI and sequence
8 explicit IV
2 pad length and next header
16 authentication tag
--
104 ESP packetNAT ট্রাভার্সালের জন্য প্রয়োজনীয় বাইরের হেডার যোগ করুন
ESP খোলসের বাইরে 20 বাইটের বাইরের IPv4 হেডার এবং NAT ট্রাভার্সালের জন্য 8 বাইটের UDP হেডার থাকে, তাই প্যাকেট 132 বাইট হয়। UDP এনক্যাপসুলেশন আছে কারণ প্যাকেটকে দুই প্রান্তের মাঝের অনুবাদকারী ডিভাইস পেরোতে হয়, এবং এটি সুরক্ষিত পেলোড না ছুঁয়ে বাইরের আকার বদলায়। প্রতি সেকেন্ডে 33.3 প্যাকেটে 132 বাইট প্রায় 35.2 kbit/s, বা কোডেকের নামমাত্র হারের প্রায় চার গুণ।
ট্যাগ বা IV কোনোটিই ছোট করতে অনুমান থেকে বাদ দেওয়া যায় না, কারণ দুটোই লিংক আসলে যা বহন করবে তার অংশ। যে অনুমান এগুলো বাদ দেয়, তা এমন প্যাকেট বর্ণনা করে যা প্রাপক প্রত্যাখ্যান করত। একই কথা ট্রেইলারের ক্ষেত্রেও, যা সুরক্ষিত অঞ্চলের ভিতরে পেলোডের সীমানা ও পরবর্তী হেডার চিহ্নিত করতে আছে।
সংখ্যাটি উদ্ধৃত করার আগে সীমানার নাম দিন
বাইরের IP সংখ্যা এখনো Ethernet ফ্রেমিং বাদ দেয়। ট্যাগযুক্ত বা ট্যাগহীন অ্যাক্সেস লিংক 14 বাইটের MAC হেডার ও 4 বাইটের ফ্রেম চেক সিকোয়েন্স যোগ করে, ফ্রেমকে 150 বাইট করে, যা একটি সুইচ পোর্ট গণনা করে। একই প্যাকেট হারে তা 40 kbit/s, কোডেক হারের পাঁচ গুণ, এবং পার্থক্যটি অপচয় নয়, বহনের খরচ।
| Boundary | Packet size | Rate at 33.3 packets/s | What it counts |
|---|---|---|---|
| Codec payload | 30 bytes | 8.0 kbit/s | The audio alone |
| Inner IP packet | 70 bytes | 18.7 kbit/s | Application headers included |
| Outer IP packet | 132 bytes | 35.2 kbit/s | ESP and NAT-T included |
| Ethernet frame | 150 bytes | 40.0 kbit/s | Link framing included |
40 kbit/s সংখ্যাটি এখনো প্রিম্যাম্বল, ইন্টারফ্রেম গ্যাপ, VLAN ট্যাগ, প্রোভাইডার এনক্যাপসুলেশন, RTCP, সিগন্যালিং এবং বিপরীত দিকে যাওয়া অডিও বাদ দেয়। এটি এক দিকের অনুমান, লিংক সংরক্ষণ নয়, এবং এটিকে সংরক্ষণ হিসেবে উদ্ধৃত করলে এক জায়গায় লিংককে যা সংরক্ষণ করতে হয় তা বাড়িয়ে বলা হয় আর অন্য জায়গায় কমিয়ে বলা হয়। হোস্ট ক্যাপচারও লিংকের যোগ করা ফ্রেমিং মিস করতে পারে, তাই সংখ্যার পাশে সীমানার নাম দিতে হয়, এবং তাই একটি সীমানা সারণি একক শিরোনাম সংখ্যার চেয়ে বেশি কাজে লাগে। যে দিকটি আপনি গণনা করেননি, তার জন্য আলাদাভাবে সংরক্ষণ করুন।
ইন্টারফেসের বিপরীতে পাটিগণিত যাচাই করুন
অনুমানটিকে বিশ্বাস করার আগে পরিচিত সংখ্যক প্যাকেটের জন্য ইন্টারফেস যা রিপোর্ট করে তার সঙ্গে তুলনা করুন। টানেল ডিভাইসের বদলে ভৌত ইন্টারফেসে ক্যাপচার করুন, যাতে আপনি যে ফ্রেমিং হিসাব করতে চাইছেন তা অন্তর্ভুক্ত হয়, এবং নিখুঁত মিলের বদলে সামান্য অমিল আশা করুন।
sudo tcpdump -ni eth0 -c 50 'udp port 4500'
ip -s link show eth0ক্যাপচার বাইরের প্যাকেটের আকার নিশ্চিত করে, আর ইন্টারফেস কাউন্টার ফ্রেমিংসহ হার দেখায়। দুটো যদি Ethernet-এর অনুমোদনের মতো পরিমাণে আলাদা হয়, তাহলে পাটিগণিত ঠিক এবং কেবল সীমানার নাম ভুল ছিল। একটি ফ্রেম হেডারের চেয়ে অনেক বড় পার্থক্য লিংকের অন্য কিছুকে নির্দেশ করে, যেমন পুনঃপ্রেরণ বা ইন্টারফেস ভাগ করা অন্য প্রবাহ। প্যাকেটাইজেশন ইন্টারভাল, সুরক্ষা স্যুট ও সীমানা সংখ্যার পাশে লিখুন, কারণ এই তিনটি ছাড়া একটি অনুমান পরবর্তী পাঠক পরিমাপ হিসেবে উদ্ধৃত করেন।