Multicast আর QoS — একসাথে অনেককে পাঠানো আর অগ্রাধিকার

১ · একজনকে, সবাইকে, দলকে, কাছেরজনকে — চার রকম পাঠানো

এ পর্যন্ত প্রায় সব packet ছিল একজন প্রেরক থেকে একজন প্রাপকের দিকে। কিন্তু অনেক কাজে একই ডেটা একসাথে অনেকের দরকার — একটি টিভি চ্যানেল হাজার বাড়িতে। প্রত্যেককে আলাদা কপি পাঠালে প্রেরকের link ভেঙে পড়ে। এই পর্বের প্রথম অর্ধেক এর নেটওয়ার্ক-স্তরের সমাধান — multicast. দ্বিতীয় অর্ধেক অন্য প্রশ্ন: সবাই যখন একই লাইনে, কার packet আগে যাবে — QoS.

Router broadcast পার করে না (পর্ব ১৮); IPv6-এ broadcast নেই, তার কাজ করে multicast (পর্ব ২১)। Anycast-এর আলাদা ঠিকানা নেই — একই prefix কয়েক জায়গা থেকে BGP-তে ঘোষণা করলেই হয় (পর্ব ২৫, ৩৮)।

Multicast কেন — একটি হিসাব

ধরুন একটি অফিসে একটি ভিডিও সম্প্রচার চলছে, প্রতিটি stream ৪ Mbps, দেখছেন ১০০ জন। Unicast-এ সার্ভারকে ১০০টি আলাদা stream পাঠাতে হয় — সার্ভারের link-এ ১০০ × ৪ = ৪০০ Mbps, আর পথের প্রতিটি ভাগাভাগির link-এ একই ডেটার অনেক কপি। Multicast-এ সার্ভার পাঠায় একটি stream, ৪ Mbps; router আর switch শুধু যেখানে পথ ভাগ হয় সেখানে কপি বানায়। ফলে প্রতিটি link-এ এই চ্যানেলের সর্বোচ্চ একটি কপি — দর্শক ১০০ হোক বা ১০,০০০.

 Unicast: S থেকে ১০০টি কপি           Multicast: S থেকে ১টি কপি
   S ══(100 কপি)══ R1                   S ──(1)── R1
                  ╱  ╲                            ╱  ╲
          (60 কপি)    (40 কপি)                 (1)    (1)
               R2      R3                      R2      R3
             60 জন    40 জন                  60 জন    40 জন

বাস্তবে multicast চলে যেখানে একই ডেটা একই মুহূর্তে অনেকের দরকার:

• IPTV: অনেক দেশে ISP নিজের নেটওয়ার্কে সরাসরি সম্প্রচারের চ্যানেল multicast-এ পাঠায় — চ্যানেল বদলানো মানে এক দল ছেড়ে আরেক দলে যোগ দেওয়া। (চাহিদামতো ভিডিও একেকজন একেক সময়ে দেখে — তাই সেটি unicast আর CDN, পর্ব ৩৮ ও ৪০।)
• শেয়ারবাজারের ডেটা আর OS imaging: অনেক এক্সচেঞ্জ দামের হালনাগাদ multicast feed-এ ছাড়ে, আর অনেক ল্যাব-টুল একসাথে বহু কম্পিউটারে একই disk image পাঠাতে multicast ব্যবহার করতে পারে।
• নেটওয়ার্কের নিজের কাজ: OSPF 224.0.0.5/6-এ কথা বলে (পর্ব ২৪), mDNS 224.0.0.251-এ প্রিন্টার খোঁজে, IPv6-এর neighbor discovery চলে multicast-এ।

Multicast প্রায় সবসময় UDP-র ওপর চলে: TCP দুজনের সংযোগ, আর হাজার জনের ACK ফিরে এলে প্রেরক ডুবে যেত (ACK implosion). হারানো packet সামলায় অ্যাপ্লিকেশন — যেমন FEC দিয়ে (পর্ব ০৯)।

২ · Multicast ঠিকানা — পরিসর আর MAC-এ রূপান্তর

IPv4-এ multicast ঠিকানা মানে প্রথম চার bit 1110 — অর্থাৎ 224.0.0.0/4, পুরোনো ভাষায় Class D (পর্ব ১৬)। একটি multicast ঠিকানা কোনো যন্ত্রের নয়, একটি দলের। প্রেরক সাধারণ unicast উৎস ঠিকানা দিয়ে গন্তব্যে দলের ঠিকানা লেখে; multicast ঠিকানা কখনো উৎস হয় না। পরিসরের ভেতরে কয়েকটি গুরুত্বপূর্ণ ভাগ:

IPv6-এ multicast ঠিকানা ff00::/8, আর ঠিকানার ভেতরেই একটি scope-এর ঘর (যেমন ff02 = link-local, ff05 = site-local) — পর্ব ২১-এ দেখেছেন। বাকিটা এখানে IPv4 ধরে।

IP দল থেকে Ethernet MAC — শুধু ২৩ bit

LAN-এ packet যায় frame-এ, আর frame-এর গন্তব্য MAC চাই। Unicast-এ MAC খুঁজতে ARP লাগে (পর্ব ১৮); multicast-এ ARP নেই — MAC সরাসরি দলের ঠিকানা থেকে হিসাব করা হয় (RFC 1112):

• প্রথম ২৫ bit স্থির: 01:00:5e আর তারপর একটি ০ bit. প্রথম byte-এর সবচেয়ে কম মানের bit ১ — অর্থাৎ group ঠিকানা (I/G bit, পর্ব ১২)।
• বাকি ২৩ bit = IP দলের ঠিকানার শেষ ২৩ bit.

কিন্তু IP দলের ঠিকানায় চলমান bit আছে ২৮টি (প্রথম চারটি সবসময় 1110). ২৮ − ২৩ = ৫টি bit MAC-এ হারিয়ে যায়, তাই ২^৫ = ৩২টি আলাদা IP দল একই MAC পায়. হাতে করে দেখি — 239.1.1.1:

239.1.1.1  = 1110 1111 . 0000 0001 . 0000 0001 . 0000 0001
              ^^^^ ^^^^   ^
              স্থির  হারানো ৫ bit (প্রথম byte-এর শেষ ৪ + দ্বিতীয় byte-এর প্রথম ১)
শেষ ২৩ bit  =               000 0001 . 0000 0001 . 0000 0001  = 01 . 01 . 01
MAC         = 01:00:5e  +  01:01:01   = 01:00:5e:01:01:01

দ্বিতীয় byte থেকে শুধু শেষ ৭ bit নেওয়া হয় (দ্বিতীয় byte & 0x7f). তাই 224.1.1.1, 225.129.1.1 (129 = 10000001), 238.129.1.1 — সবাই একই MAC 01:00:5e:01:01:01. প্রথম byte ২২৪ থেকে ২৩৯ — ১৬ রকম, দ্বিতীয় byte-এর প্রথম bit ০ বা ১ — ২ রকম: ১৬ × ২ = ৩২.

নিচের simulator দুটি কাজ করে। প্রথম অংশ কয়েকটি দলের MAC হিসাব করে আর গুনে দেখায় 239.1.1.1-এর MAC আর কতগুলো দল ভাগ করে। দ্বিতীয় অংশ একটি IGMP snooping switch-এর টেবিল চালায় — পরের অংশের বিষয়, তবে MAC আর port একসাথে দেখতে এখানেই রাখা হলো। Switch-এর port 1-এ router (stream সেখান দিয়ে ঢোকে), port 2–6-এ host.

// Part 1: IPv4 group -> Ethernet MAC (RFC 1112): 01:00:5e + the low 23 bits of the group.
const hex = n => n.toString(16).padStart(2, "0");
function groupMac(ip) {
  const o = ip.split(".").map(Number);
  return ["01", "00", "5e", hex(o[1] & 0x7f), hex(o[2]), hex(o[3])].join(":");
}
for (const g of ["224.0.0.1", "224.0.0.251", "239.1.1.1", "224.1.1.1", "225.129.1.1", "238.129.1.1"])
  console.log(g.padEnd(12), "->", groupMac(g));
let same = 0;                         // how many groups share the MAC of 239.1.1.1?
for (let first = 224; first <= 239; first++)
  for (const second of [1, 129])
    if (groupMac(`${first}.${second}.1.1`) === groupMac("239.1.1.1")) same++;
console.log("groups sharing 01:00:5e:01:01:01 =", same);

// Part 2: an IGMP snooping switch. The stream for each group enters on port 1 (router).
const members = new Map();            // group -> Set of host ports
function step(what, type, port, group) {
  if (!members.has(group)) members.set(group, new Set());
  if (type === "join") members.get(group).add(port);
  if (type === "leave") members.get(group).delete(port);
  const out = g => [...(members.get(g) || [])].sort().join(",") || "none";
  console.log(what.padEnd(36), "| 239.1.1.1 ->", out("239.1.1.1").padEnd(5),
    "| 239.2.2.2 ->", out("239.2.2.2"));
}
console.log("\nevent (switch ports 2-6 have hosts)   | ports that get each stream");
step("port 5 TV: Report 239.1.1.1", "join", 5, "239.1.1.1");
step("port 3 PC: Report 239.1.1.1", "join", 3, "239.1.1.1");
step("port 4 PC: Report 239.2.2.2", "join", 4, "239.2.2.2");
step("port 3 PC: Leave 239.1.1.1", "leave", 3, "239.1.1.1");
step("general query; ports 4, 5 report", "none", 0, "239.1.1.1");
step("port 5 unplugged, 260 s no report", "leave", 5, "239.1.1.1");
console.log("without snooping every stream -> 2,3,4,5,6");

224.0.0.1    -> 01:00:5e:00:00:01
224.0.0.251  -> 01:00:5e:00:00:fb
239.1.1.1    -> 01:00:5e:01:01:01
224.1.1.1    -> 01:00:5e:01:01:01
225.129.1.1  -> 01:00:5e:01:01:01
238.129.1.1  -> 01:00:5e:01:01:01
groups sharing 01:00:5e:01:01:01 = 32

event (switch ports 2-6 have hosts)   | ports that get each stream
port 5 TV: Report 239.1.1.1          | 239.1.1.1 -> 5     | 239.2.2.2 -> none
port 3 PC: Report 239.1.1.1          | 239.1.1.1 -> 3,5   | 239.2.2.2 -> none
port 4 PC: Report 239.2.2.2          | 239.1.1.1 -> 3,5   | 239.2.2.2 -> 4
port 3 PC: Leave 239.1.1.1           | 239.1.1.1 -> 5     | 239.2.2.2 -> 4
general query; ports 4, 5 report     | 239.1.1.1 -> 5     | 239.2.2.2 -> 4
port 5 unplugged, 260 s no report    | 239.1.1.1 -> none  | 239.2.2.2 -> 4
without snooping every stream -> 2,3,4,5,6

IPv6-এ একই ধারণা, অন্য সংখ্যা: MAC = 33:33 আর দলের ঠিকানার শেষ ৩২ bit (RFC 2464) — এখানেও বাকি bit হারায়, তবে অনেক কম সংঘর্ষ।

৩ · IGMP — “আমি এই দলে আছি” আর switch-এর কান পাতা

কে চায় — প্রেরক জানে না, জানার দরকারও নেই। জানতে হয় প্রাপকের কাছের router-কে: তার LAN-এ কোনো দলের অন্তত একজন সদস্য আছে কি না। এই খবরের protocol IGMP (IP protocol নম্বর ২)। IPv6-এ একই কাজ করে MLD, ICMPv6-এর অংশ হিসেবে।

IGMPv2-এর কাজের ধারা, সংক্ষেপে:

• যোগ দেওয়া: host নিজে থেকেই দলের ঠিকানায় Report পাঠায় (TTL ১)।
• নিয়মিত প্রশ্ন: querier router ডিফল্টে প্রতি ১২৫ সেকেন্ডে 224.0.0.1-এ General Query পাঠায়; সদস্যরা ১০ সেকেন্ডের মধ্যে Report দেয় (v2-তে অন্যের Report শুনলে নিজেরটি চেপে যায়)।
• ছাড়া: host 224.0.0.2-এ Leave পাঠায়; router group-specific query পাঠিয়ে দেখে আর কেউ আছে কি না।
• নিঃশব্দে চলে যাওয়া: Leave ছাড়া বন্ধ হলে ২ × ১২৫ + ১০ = ২৬০ সেকেন্ড Report না এলে সদস্যপদ শেষ।

IGMP snooping — switch যখন কান পাতে

Switch MAC শেখে frame-এর উৎস দেখে (পর্ব ১২), কিন্তু 01:00:5e:… কখনো উৎস হয় না — তাই switch অজানা গন্তব্যের মতো সব port-এ ছড়িয়ে দেয়। একটি ২০ Mbps-এর stream তখন যে চায়নি তার port-এও যায়, Wi-Fi access point-এ গেলে বাতাসের সময়ও খায় (পর্ব ১৪)।

সমাধান IGMP snooping (নির্দেশিকা RFC 4541): switch IGMP বার্তায় উঁকি দিয়ে টেবিল রাখে কোন port-এ কোন দলের সদস্য, আর router-এর port (mrouter port) মনে রাখে, যাতে Report সেখানে পৌঁছায়। Snooping চলে VLAN ধরে (পর্ব ১৩)।

নিজের যন্ত্র কোন দলে আছে, Linux-এ দেখায় ip maddr show আর /proc/net/igmp (উল্টো byte ক্রমের hex, পর্ব ০৬)। একটি সাধারণ Linux ল্যাপটপে এমন — সংখ্যা যন্ত্রভেদে আলাদা:

$ ip maddr show dev eth0
2:	eth0
	link  33:33:00:00:00:01
	link  01:00:5e:00:00:01
	link  01:00:5e:00:00:fb
	inet  224.0.0.251
	inet  224.0.0.1
	inet6 ff02::1
$ cat /proc/net/igmp
Idx	Device    : Count Querier	Group    Users Timer	Reporter
2	eth0      :     2      V3
				FB0000E0     1 0:00000000		0
				010000E0     1 0:00000000		0

FB0000E0 উল্টে পড়ুন: E0.00.00.FB = 224.0.0.251 (mDNS); আর V3 মানে interface-টি IGMPv3 মোডে আছে (পুরোনো সংস্করণের কোনো querier শোনা যায়নি)। Windows-এ একই তথ্য দেখায় netsh interface ipv4 show joins.

৪ · Multicast routing — গাছ, RPF check আর PIM

IGMP শুধু শেষ LAN-টুকুর খবর দেয়। বাকি প্রশ্ন router-দের: উৎস থেকে সব সদস্য-LAN পর্যন্ত কোন কোন link দিয়ে কপি যাবে? উত্তর একটি গাছ (tree) — উৎস বা একটি কেন্দ্র থেকে শাখা মেলে সব সদস্যের দিকে, কোনো চক্র (loop) ছাড়া। চক্র থাকলে multicast packet ঘুরতে ঘুরতে অসংখ্য কপি হতো, যেমন পর্ব ১২-এর broadcast storm.

RPF check — উল্টো পথ দিয়ে যাচাই

Unicast-এ router দেখে গন্তব্য. Multicast-এ গন্তব্য একটি দল — সবাই। তাই multicast router দেখে উৎস, আর একটি সরল নিয়ম মানে — Reverse Path Forwarding (RPF) check:

যুক্তি: S থেকে আমার কাছে সবচেয়ে ছোট পথের কপিটি আসবে S-এর দিকের interface দিয়েই। অন্য দিক দিয়ে আসা কপি হয় ঘুরপথের duplicate, নয়তো চক্রের ফল। কুমিল্লার শাখা জানে, “ঢাকার সার্কুলার আসে মহাসড়কের দিক থেকে” — নোয়াখালী ঘুরে আসা কপি সে ফেলে দেয়। লক্ষ করুন, RPF-এর জন্য আলাদা কোনো multicast routing table লাগে না — unicast table-ই যথেষ্ট (OSPF, BGP বা static যা দিয়েই বানানো)। এ কারণেই নাম Protocol Independent Multicast.

নিচের নেটওয়ার্কে উৎস S বসে router A-র পেছনে। প্রতিটি link-এর খরচ দেওয়া; প্রাপক আছে শুধু D আর F-এর LAN-এ (IGMP থেকে জানা)। প্রথমে দেখি প্রতিটি router S-এর দিকে কোন প্রতিবেশী দিয়ে যায় (RPF neighbour), তারপর flood-and-prune.

             S  (উৎস)
             │
             A
        (1) ╱ ╲ (3)
           B ─(1)─ C ─(1)─ G
           │       │       │
          (2)     (1)      │
           │       │       │
           D ─(1)─ E       │    D-তে প্রাপক
           │ │     │       │
           │ │    (1)      │
           │ │     │       │
           │ └(3)─ F ← প্রাপক
           └──────(2)──────┘   (D–G link)

ছবিটি সরল করে আঁকা; সব link একসাথে: A–B ১, A–C ৩, B–C ১, B–D ২, C–E ১, D–E ১, D–F ৩, E–F ১, C–G ১, D–G ২.

এই হিসাব কোডে — Dijkstra দিয়ে S-এর দিকে সবচেয়ে ছোট পথ (পর্ব ২৪-এর algorithm; আরও বিস্তারিত DSA-র Dijkstra পর্বে), তারপর flooding-এ প্রতিটি router-এ কোন কপি এলো আর RPF-এ টিকল কি না, শেষে prune:

// Routers and link costs. The multicast source S is attached to router A.
const links = [["A","B",1], ["A","C",3], ["B","C",1], ["B","D",2], ["C","E",1],
               ["D","E",1], ["D","F",3], ["E","F",1], ["C","G",1], ["D","G",2]];
const receivers = new Set(["D", "F"]);          // routers that heard IGMP Reports
const nb = {};
for (const [u, v, c] of links) { (nb[u] ??= []).push([v, c]); (nb[v] ??= []).push([u, c]); }
// Unicast shortest paths towards S (Dijkstra from A) give each router its RPF neighbour.
const dist = { A: 0 }, rpf = {}, done = new Set();
while (done.size < Object.keys(nb).length) {
  const u = Object.keys(dist).filter(x => !done.has(x)).sort((x, y) => dist[x] - dist[y])[0];
  done.add(u);
  for (const [v, c] of nb[u])
    if (!(v in dist) || dist[u] + c < dist[v]) { dist[v] = dist[u] + c; rpf[v] = u; }
}
// Flooding: every router forwards one copy on every link except the one towards S.
let dropped = 0;
console.log("router  dist  RPF-nbr  copies arriving from neighbours");
for (const r of Object.keys(nb).sort()) {
  if (r === "A") { console.log("A       0     (S)      source router: sends to B, C"); continue; }
  const from = nb[r].map(([n]) => n).filter(n => rpf[n] !== r).sort();
  dropped += from.length - 1;
  const txt = from.map(n => n + (n === rpf[r] ? ":ACCEPT" : ":drop")).join("  ");
  console.log(r.padEnd(8) + String(dist[r]).padEnd(6) + rpf[r].padEnd(9) + txt);
}
console.log("copies dropped by the RPF check:", dropped);
// Prune: keep a branch only if the router has receivers or a child on the tree needs it.
const needed = r => receivers.has(r) || Object.keys(rpf).some(c => rpf[c] === r && needed(c));
const all = Object.keys(rpf).sort();
console.log("tree after pruning:", all.filter(needed).map(c => rpf[c] + "->" + c).join("  "));
console.log("pruned routers:", all.filter(r => !needed(r)).join(" ") || "none");

router  dist  RPF-nbr  copies arriving from neighbours
A       0     (S)      source router: sends to B, C
B       1     A        A:ACCEPT
C       2     B        A:drop  B:ACCEPT
D       3     B        B:ACCEPT  E:drop  F:drop  G:drop
E       3     C        C:ACCEPT  D:drop
F       4     E        D:drop  E:ACCEPT
G       3     C        C:ACCEPT  D:drop
copies dropped by the RPF check: 7
tree after pruning: A->B  B->C  B->D  C->E  E->F
pruned routers: G

দুই ঘরানা — flood-and-prune বনাম explicit join

Flood-and-prune সহজ, কিন্তু পুরো ইন্টারনেট ধরে flood অসম্ভব। PIM-SM-এ সদস্যের LAN-এর router (last-hop) RP-র দিকে RPF পথ বেয়ে hop ধরে ধরে (*,G) Join পাঠায়; পথের প্রতিটি router মনে রাখে কোন interface-এ পাঠাতে হবে — এভাবে shared tree. উৎসের কাছের router (first-hop) প্রথম packet-গুলো Register বার্তায় মুড়িয়ে RP-তে পাঠায়, RP উৎসের দিকে (S,G) Join পাঠায়। এরপর last-hop router চাইলে নিজেই (S,G) Join পাঠিয়ে shortest-path tree-তে সরে যায়। RP তাই মূলত পরিচয় করিয়ে দেওয়ার জায়গা — ঘটকের মতো।

SSM আরও সরল: প্রাপক আগে থেকেই উৎস জানলে IGMPv3-এ বলে “(S, G) চাই”, আর router সোজা S-এর দিকে Join পাঠায় — RP, Register, shared tree কিছুই নেই (232.0.0.0/8). অন্য কেউ একই দলে পাঠালেও পৌঁছায় না, কারণ গাছটি শুধু S-এর।

ইন্টারনেট-জুড়ে multicast কেন জমল না

Steve Deering-এর কাজ থেকে IP multicast-এর নকশা আসে (RFC 1112, ১৯৮৯), আর ১৯৯২ সালে IETF-এর একটি সভার অডিও multicast-এ সম্প্রচার দিয়ে শুরু হয় পরীক্ষামূলক MBone. তবু ইন্টারনেট-জুড়ে multicast জমেনি। প্রচলিত ব্যাখ্যা: পথের প্রতিটি ISP-কে multicast চালু রাখতে আর RP-র খবর ভাগ করতে হতো, অথচ খরচ কে বহন করবে তার মডেল ছিল না; প্রতিটি দলের state প্রতিটি router-এ; যে কেউ দলে পাঠাতে পারত বলে অপব্যবহারের ঝুঁকি; আর মানুষ “যখন খুশি” দেখতে শুরু করল, যেখানে multicast কাজে আসে না (বিস্তারিত ভাবনার প্রশ্ন ১-এ)।

তাই multicast টিকে আছে এক মালিকের নেটওয়ার্কে — প্রতিষ্ঠানের LAN আর WAN, ISP-র নিজস্ব IPTV, আর্থিক নেটওয়ার্ক, কিছু data center-এর overlay আর link-local নিয়ন্ত্রণ-বার্তায়। ইন্টারনেট-জুড়ে কাজটি নিয়েছে application-layer multicast: CDN-এর সার্ভার বা ব্যবহারকারীরা নিজেরাই কপি বানিয়ে পাঠায় (পর্ব ৩৮)। চালু করা সহজ, কিন্তু একই link-এ কয়েকটি কপি যেতে পারে।

৫ · QoS কেন — best effort যেখানে যথেষ্ট নয়

পর্ব ১৫-এ দেখেছেন, ইন্টারনেট best effort: ভিড়ে delay বাড়ে, buffer ভরলে packet হারায় (tail drop). ফাইল ডাউনলোডে ক্ষতি সামান্য — TCP আবার পাঠাবে। ভয়েস কল আলাদা জিনিস।

ভয়েসের বাজেট — কত দেরি সহ্য হয়

কথা বলার সময় একদিকের delay বেশি হলে দুজন একসাথে বলে ফেলেন, তারপর দুজনেই থামেন — কথোপকথন জট পাকায়। ITU-T-র G.114 সুপারিশে সাধারণভাবে বলা হয়, একদিকের delay প্রায় ১৫০ ms-এর মধ্যে থাকলে বেশিরভাগ ব্যবহারকারী সন্তুষ্ট থাকেন, আর এর বেশি হলে মান ক্রমে খারাপ হয় (এটি নির্দেশনা, কঠোর সীমা নয়)। Jitter আর loss-এর জন্যও vendor-দের নকশা-নির্দেশিকায় প্রচলিত লক্ষ্য দেখা যায় — যেমন jitter কয়েক দশ ms-এর মধ্যে আর loss এক শতাংশের কম — তবে এগুলো codec আর ব্যবস্থাভেদে বদলায়।

একটি সাধারণ বাজেট, হিসাব করে দেখি (সংখ্যাগুলো উদাহরণ):

পর্ব ১৫-এর bufferbloat মনে করুন: ১০ Mbps upload-এ ১ MB ভরা buffer মানে ৮০০ ms queuing — বাজেটের পাঁচ গুণ। দরকার অগ্রাধিকার: ভয়েসকে আলাদা লাইনে আগে পাঠানো, আর তার পরিমাণ সীমায় রাখা।

Bandwidth-এর হিসাব: G.711 codec প্রতি ২০ ms-এ ১৬০ byte কণ্ঠ; সাথে RTP (১২), UDP (৮) আর IPv4 (২০) header — ২০০ byte, সেকেন্ডে ৫০টি: ৫০ × ২০০ × ৮ = ৮০ kbps (IP স্তরে)। সামান্য, কিন্তু ভিড়ের মুহূর্তে এটুকুকেই আগে যেতে দিতে হবে।

৬ · শ্রেণি ঠিক করা আর চিহ্ন দেওয়া — DSCP, 802.1p আর trust boundary

প্রতিটি router প্রতিটি packet গভীরে দেখে “ভয়েস না ফাইল” বুঝতে গেলে ধীর হবে। তাই কাজটি দুই ভাগে:

• Classification (প্রান্তে, একবার): নেটওয়ার্কে ঢোকার মুখে packet দেখে শ্রেণি ঠিক করা — port নম্বর, ঠিকানা, কোন VLAN (যেমন voice VLAN, পর্ব ১৩), বা যন্ত্রটি নিজে কী বলছে।
• Marking: শ্রেণিটি header-এ লিখে দেওয়া, যাতে পরের প্রতিটি যন্ত্র শুধু চিহ্নটুকু দেখেই কাজ করতে পারে। IP-তে DSCP (IPv4-এর পুরোনো TOS byte বা IPv6-এর traffic class-এর প্রথম ৬ bit; ঘরগুলো পর্ব ১৬ আর ২১-এ), Ethernet-এ VLAN tag-এর ৩ bit PCP বা 802.1p (পর্ব ১৩)।

ঠিক যেমন হাসপাতালের জরুরি বিভাগের রিসেপশনে একবার রোগী দেখে কার্ডে লাল, হলুদ বা সবুজ দাগ দেওয়া হয় — এরপর প্রতিটি ডেস্ক শুধু কার্ডের রং দেখে।

 পুরোনো IPv4 TOS byte (৮ bit)
 ┌───┬───┬───┬───┬───┬───┬───┬───┐
 │ 7 │ 6 │ 5 │ 4 │ 3 │ 2 │ 1 │ 0 │
 ├───┴───┴───┴───┴───┴───┼───┴───┤
 │      DSCP (৬ bit)     │  ECN  │
 └───────────────────────┴───────┘
 TOS byte = DSCP × 4 + ECN     যেমন EF: 46 × 4 = 184 = 0xB8

প্রচলিত DSCP শ্রেণি

কোন অ্যাপ কোন শ্রেণি পাবে, তার একটি বহুল ব্যবহৃত নির্দেশিকা RFC 4594 — তবে এটি পরামর্শ; প্রতিটি প্রতিষ্ঠান নিজের নীতি ঠিক করে। DSCP-র মানে বাধ্যতামূলক নয়; প্রতিটি নেটওয়ার্ক (প্রতিটি DiffServ domain) নিজে ঠিক করে কোন চিহ্নে কী আচরণ — একে বলে per-hop behaviour (PHB).

Trust boundary — কার কথা বিশ্বাস করবেন

DSCP যে কেউ বসাতে পারে। সবাই নিজেকে “ভয়েস” বললে priority queue ভরে যায়, আর আসল ভয়েসেরই ক্ষতি। তাই একটি trust boundary টানা হয়, যতটা সম্ভব প্রান্তে (access switch-এর port-এ): ভেতরের চেনা যন্ত্রের (যেমন প্রতিষ্ঠানের IP phone) চিহ্ন বিশ্বাস, বাইরের চিহ্ন মুছে ০ বা নিজের নিয়মে নতুন করে। অনেক ISP-ও অন্য নেটওয়ার্কের DSCP মুছে বা বদলে দেয়।

নিচের simulator কয়েকটি TOS byte decode করে, তারপর একটি access switch-এর trust boundary চালায় — port 1-এ IP phone (trusted), port 2-এ সাধারণ PC (untrusted). লক্ষ করুন re-marking-এর সময় শেষের ২টি ECN bit রাখতে হয় — ECN আলাদা কাজের জিনিস (অংশ ৮)।

// The old IPv4 TOS byte = DSCP (6 bits) + ECN (2 bits).  tos = dscp << 2 | ecn
const ECN = ["Not-ECT", "ECT(1)", "ECT(0)", "CE"];
function dscpName(d) {
  if (d === 46) return "EF";
  if (d === 0) return "default (BE)";
  const x = d >> 3, y = (d >> 1) & 3;
  if (x >= 1 && x <= 4 && y >= 1 && (d & 1) === 0) return `AF${x}${y}`;  // AFxy = 8x + 2y
  if (d % 8 === 0) return `CS${d / 8}`;
  return "unknown/local";
}
function decode(tos) {
  const d = tos >> 2, e = tos & 3;
  return `0x${tos.toString(16).padStart(2, "0")}  dscp=${String(d).padStart(2)}` +
    ` (${d.toString(2).padStart(6, "0")}) ${dscpName(d).padEnd(12)} ecn=${ECN[e]}`;
}
console.log("TOS   DSCP decimal/binary  class        ECN");
for (const tos of [0x00, 0xb8, 0x88, 0x28, 0x4a, 0xc0, 0x20, 0xba, 0x03]) console.log(decode(tos));

// Trust boundary on an access switch: only the IP-phone port is trusted.
// Re-marking clears the DSCP of untrusted traffic but must keep the 2 ECN bits.
const ports = { 1: "IP phone (trusted)", 2: "PC (untrusted)" };
const arrivals = [[1, 0xb8], [2, 0xb8], [2, 0x2a], [2, 0x03]];
console.log("\nport  in-TOS  out-TOS  meaning");
for (const [p, tos] of arrivals) {
  const out = p === 1 ? tos : tos & 0x03;
  console.log(`${p}     0x${tos.toString(16).padStart(2, "0")}    0x${out.toString(16).padStart(2, "0")}` +
    `     ${ports[p]}: ${dscpName(tos >> 2)} -> ${dscpName(out >> 2)}, ecn ${ECN[out & 3]}`);
}

TOS   DSCP decimal/binary  class        ECN
0x00  dscp= 0 (000000) default (BE) ecn=Not-ECT
0xb8  dscp=46 (101110) EF           ecn=Not-ECT
0x88  dscp=34 (100010) AF41         ecn=Not-ECT
0x28  dscp=10 (001010) AF11         ecn=Not-ECT
0x4a  dscp=18 (010010) AF21         ecn=ECT(0)
0xc0  dscp=48 (110000) CS6          ecn=Not-ECT
0x20  dscp= 8 (001000) CS1          ecn=Not-ECT
0xba  dscp=46 (101110) EF           ecn=ECT(0)
0x03  dscp= 0 (000000) default (BE) ecn=CE

port  in-TOS  out-TOS  meaning
1     0xb8    0xb8     IP phone (trusted): EF -> EF, ecn Not-ECT
2     0xb8    0x00     PC (untrusted): EF -> default (BE), ecn Not-ECT
2     0x2a    0x02     PC (untrusted): AF11 -> default (BE), ecn ECT(0)
2     0x03    0x03     PC (untrusted): default (BE) -> default (BE), ecn CE

Layer 2-তে একই কাজ 802.1p-এর (০–৭); অনেক switch DSCP আর PCP-র মধ্যে রূপান্তরের টেবিল রাখে। Tag থাকে শুধু trunk বা voice VLAN-এ (পর্ব ১৩)।

৭ · Policing, shaping আর token bucket — হার মাপার যন্ত্র

অগ্রাধিকার দিলেই হবে না, পরিমাণও সীমায় রাখতে হয়। ISP আপনার সাথে চুক্তি করেছে ২০ Mbps; ভয়েসের priority queue-কে বলা হয়েছে ১ Mbps পর্যন্ত। কেউ বেশি পাঠালে কী হবে? দুটি উত্তর:

ঢাকার ফ্লাইওভারের মুখে দুই ট্রাফিক পুলিশ: একজন বাড়তি গাড়ি ফিরিয়ে দেন (policing), অন্যজন পাশে দাঁড় করিয়ে একটি একটি করে ছাড়েন (shaping).

Token bucket — হার r, বালতি b

দুজনেরই একটি মাপার যন্ত্র লাগে — “এই packet সীমার মধ্যে কি না”. সবচেয়ে প্রচলিতটি token bucket:

• একটি বালতিতে প্রতি সেকেন্ডে rটি token জমে (এখানে ১ token = ১ byte). বালতিতে সর্বোচ্চ bটি token ধরে; ভরা থাকলে নতুন token উপচে নষ্ট হয়।
• L byte-এর packet এলে বালতিতে কমপক্ষে L token থাকলে সে conform — L token তুলে নিয়ে পাঠানো। না থাকলে exceed — policer হলে ফেলে দেয় (token নেয় না), shaper হলে token জমা পর্যন্ত অপেক্ষা করায়।

r হলো দীর্ঘমেয়াদি গড় হার (চুক্তির হার, অনেক সময় CIR বলা হয়), আর b হলো সর্বোচ্চ ঝাপটা — কিছুক্ষণ চুপ থাকলে জমানো token দিয়ে একবারে কতটা পাঠানো যায়।

প্রমাণ: যেকোনো t সময়ে সর্বোচ্চ b + rt

যেকোনো একটি সময়-ব্যবধান [s, s + t] নিন। শুরুর মুহূর্তে বালতিতে সর্বোচ্চ b token থাকতে পারে। এই t সময়ে নতুন token জমে সর্বোচ্চ rt. প্রতিটি পাঠানো byte একটি token খরচ করে, আর token ছাড়া কিছু যায় না। তাই এই সময়ে বের হওয়া মোট byte ≤ শুরুর token + নতুন token ≤ b + rt. এটিই token bucket-এর মূল নিশ্চয়তা — একে বলে (r, b) arrival curve, আর এর ওপর ভিত্তি করে router-এর queue-তে সর্বোচ্চ কত জমবে আর সর্বোচ্চ delay কত হবে, তা হিসাব করা যায় (network calculus).

সর্বোচ্চ ঝাপটার দৈর্ঘ্য: link-এর নিজের গতি R (R > r) হলে, পূর্ণ বালতি নিয়ে প্রেরক R গতিতে কতক্ষণ পাঠাতে পারে? T সময় পরে পাঠানো R·T, আর বালতি অনুমতি দেয় b + r·T. R·T = b + r·T থেকে T = b ÷ (R − r). উদাহরণ: r = ২ Mbps, b = ১০০ KB = ৮০০,০০০ bit, R = ১০ Mbps → T = ৮০০,০০০ ÷ (৮ × ১০^৬) = ০.১ সেকেন্ড; এই সময়ে যায় ১০ Mbps × ০.১ s = ১ Mbit = ১২৫,০০০ byte. যাচাই: b + rT = ৮০০,০০০ + ২০০,০০০ = ১০,০০,০০০ bit — মিলেছে।

Leaky bucket — নিচে ছিদ্রওয়ালা বালতি

Leaky bucket-এ packet জমে একটি বালতিতে (queue), আর ছিদ্র দিয়ে বের হয় স্থির হারে — যত ঝাপটাই আসুক; বালতি ভরলে নতুন packet ফেলা হয়। Token bucket b পর্যন্ত ঝাপটা অনুমতি দেয়, leaky bucket (queue হিসেবে) দেয় না। (“মাপার নিয়ম” হিসেবে দুটি একই সীমা দেয় — ATM-এর GCRA তেমন একটি; বইভেদে নামের ব্যবহার আলাদা।)

এবার একটি policer-কে একটি ঝাপটার ওপর চালাই। r = ১০০ byte/ms (= ০.৮ Mbps), b = ৩,০০০ byte, শুরুতে বালতি ভরা। ০, ১, ২, ৩ ms-এ চারটি ১,৫০০ byte-এর packet একসাথে, তারপর ২০, ২১ আর ৪০ ms-এ আরও তিনটি।

একই আগমনে policer আর shaper পাশাপাশি — shaper কোনো packet ফেলে না (buffer যথেষ্ট বড় ধরে), বরং প্রতিটি packet কখন বের হলো আর কত অপেক্ষা করল, তা দেখায়:

// Token bucket: r = 100 bytes/ms (0.8 Mbps), bucket size b = 3000 bytes, starts full.
const r = 100, b = 3000;
const pkts = [[0, 1500], [1, 1500], [2, 1500], [3, 1500], [20, 1500], [21, 1000], [40, 1500]];

console.log("POLICER  t(ms) size  tokens-before  decision  tokens-after");
let tok = b, last = 0;
for (const [t, size] of pkts) {
  tok = Math.min(b, tok + r * (t - last)); last = t;      // refill since last arrival
  const before = tok, ok = tok >= size;
  if (ok) tok -= size;                                      // exceed: drop, take no tokens
  console.log(`         ${String(t).padStart(5)} ${String(size).padStart(5)}` +
    `  ${String(before).padStart(13)}  ${(ok ? "conform" : "EXCEED").padEnd(8)}  ${tok}`);
}

console.log("\nSHAPER   t(ms) size  leaves-at(ms)  delay(ms)");
tok = b; last = 0;
let free = 0;                         // FIFO: a packet cannot leave before the one ahead
for (const [t, size] of pkts) {
  let go = Math.max(t, free);
  tok = Math.min(b, tok + r * (go - last)); last = go;
  if (tok < size) { const wait = (size - tok) / r; go += wait; tok = size; last = go; }
  tok -= size; free = go;
  console.log(`         ${String(t).padStart(5)} ${String(size).padStart(5)}` +
    `  ${String(go).padStart(13)}  ${go - t}`);
}
const T = 50;
console.log(`\nbound: in any ${T} ms at most b + r*T = ${b + r * T} bytes leave`);

POLICER  t(ms) size  tokens-before  decision  tokens-after
             0  1500           3000  conform   1500
             1  1500           1600  conform   100
             2  1500            200  EXCEED    200
             3  1500            300  EXCEED    300
            20  1500           2000  conform   500
            21  1000            600  EXCEED    600
            40  1500           2500  conform   1000

SHAPER   t(ms) size  leaves-at(ms)  delay(ms)
             0  1500              0  0
             1  1500              1  0
             2  1500             15  13
             3  1500             30  27
            20  1500             45  25
            21  1000             55  34
            40  1500             70  30

bound: in any 50 ms at most b + r*T = 8000 bytes leave

Linux-এ একই যন্ত্র আছে, tc দিয়ে (root লাগে, তাই এখানে চালানো নয়)। tbf (token bucket filter) একটি shaper; আর অনেক বাসার router-এর firmware-এ থাকা CAKE বা fq_codel একসাথে shaping, শ্রেণি আর AQM করে:

$ sudo tc qdisc add dev eth0 root tbf rate 8mbit burst 32kbit latency 50ms
#   rate = r, burst = b; latency = buffer-এ সর্বোচ্চ কতক্ষণ অপেক্ষা, তার বেশি হলে drop
$ sudo tc qdisc replace dev eth0 root cake bandwidth 18mbit diffserv4
#   upload-এর আসল গতির একটু নিচে shaping, DSCP দেখে ৪টি শ্রেণি, ভেতরে AQM
$ tc -s qdisc show dev eth0      # কত byte গেল, কত drop — পরিসংখ্যান

৮ · সব একসাথে — LLQ, IntServ বনাম DiffServ, ECN আর বাসার Wi-Fi

Scheduling-এর প্রয়োগ — LLQ

পর্ব ১৫-এ priority আর WFQ দেখেছেন, আর কঠোর priority-র বিপদ — নিম্ন শ্রেণি না খেয়ে থাকে। বাস্তবের QoS দুটিকে মেলায়: LLQ (Low Latency Queuing). ভয়েসের জন্য কঠোর priority queue, সাথে একটি policer (অংশ ৭-এর token bucket) যাতে ভয়েস নির্ধারিত হারের বেশি না নেয়; বাকি শ্রেণি WFQ-র মতো ভাগ পায়, আর best effort-এ AQM.

class-map match-any VOICE
 match dscp ef
class-map match-any VIDEO
 match dscp af41
policy-map WAN-EDGE
 class VOICE
  priority 512              ! কঠোর priority, ভিড়ের সময় 512 kbps-এর বেশি হলে police
 class VIDEO
  bandwidth percent 30      ! ভিড়ের সময় ন্যূনতম ৩০%
 class class-default
  fair-queue                ! বাকি সব: flow-ভিত্তিক ন্যায্য ভাগ
interface GigabitEthernet0/1
 service-policy output WAN-EDGE

এখানে কাজের ক্রমটি লক্ষ করুন: classification (DSCP দেখে class-map) → প্রতিটি শ্রেণির জন্য নীতি (policy-map) → interface-এর বের হওয়ার দিকে প্রয়োগ। QoS কাজ করে শুধু যেখানে ভিড় হয় — সাধারণত দ্রুত LAN থেকে ধীর WAN-এ নামার মুখে। ১০ Gbps-এর ফাঁকা LAN link-এ এই নীতির প্রায় কোনো প্রভাব নেই।

IntServ বনাম DiffServ — প্রতিটি flow, না কয়েকটি শ্রেণি?

১৯৯০-এর দশকে IETF ইন্টারনেটে টেলিফোনের মতো নিশ্চয়তা আনার দুটি পথ চেষ্টা করেছিল।

IntServ টেকেনি মূলত scale-এর জন্য (কারণ বিস্তারিত ভাবনার প্রশ্ন ৩-এ)। DiffServ-এ জটিলতা প্রান্তে, মাঝখান সরল — তবে সেটিও সাধারণত এক প্রতিষ্ঠান বা এক ISP-র ভেতরে কাজ করে; সীমা পেরোলে চিহ্ন সাধারণত মানা হয় না, তাই ইন্টারনেট মোটের ওপর best effort-ই থেকে গেছে।

MPLS-TE (সংক্ষেপে): ISP-র ভেতরে RSVP-TE (RFC 3209) দিয়ে নির্দিষ্ট bandwidth-সহ MPLS-এর পথ বানানো হয় — flow প্রতি নয়, বড় traffic-গুচ্ছ প্রতি। এতে traffic সবচেয়ে ছোট পথের বাইরেও পরিকল্পনামতো ছড়ানো যায়, আর link নষ্ট হলে আগে বানানো বিকল্প পথে দ্রুত সরানো যায়। কিছু নেটওয়ার্ক segment routing-এর মতো নতুন পদ্ধতিও ব্যবহার করে।

ECN আর AQM — packet না ফেলে সতর্ক করা

পর্ব ১৫-এ AQM (RED, CoDel) দেখেছেন — buffer ভরার আগেই কিছু packet ফেলে প্রেরককে ভিড়ের সংকেত দেওয়া। ECN (RFC 3168) একই সংকেত দেয় কোনো packet না হারিয়ে: প্রেরক IP header-এর দুই bit-এ ECT বসায় (“আমি ECN বুঝি”), ভিড়ের router ফেলার বদলে সেখানে CE (Congestion Experienced) লেখে, প্রাপক TCP-তে খবরটি প্রেরককে ফেরত পাঠায়, আর প্রেরক যেন packet হারিয়েছে এমনভাবে গতি কমায় (পর্ব ৩২)। ভয়েস আর ভিডিওর জন্য একটি দাগ একটি হারানো packet-এর চেয়ে অনেক কম ক্ষতিকর। ঘরগুলো পর্ব ১৬-এ।

Net neutrality আর QoS — সংক্ষেপে

অফিস নিজের নেটওয়ার্কে ভয়েসকে আগে রাখলে কারো আপত্তি নেই। কিন্তু ISP টাকার বিনিময়ে বা নিজের স্বার্থে কোনো সাইট বা অ্যাপকে দ্রুত বা ধীর করলে ওঠে net neutrality-র প্রশ্ন। সাধারণত traffic-এর ধরন অনুযায়ী স্বচ্ছ ব্যবস্থাপনা অনেক জায়গায় গ্রহণযোগ্য, আর কে পাঠাচ্ছে বা কে টাকা দিয়েছে অনুযায়ী অগ্রাধিকার বিতর্কিত; দেশভেদে আইন আলাদা (আলোচনা পর্ব ১৫-এর ভাবনার প্রশ্নে)।

বাসার router আর Wi-Fi-তে QoS

বাসায় সবচেয়ে সাধারণ ভিড়ের জায়গা দুটি: ISP-র দিকের upload link আর Wi-Fi-র বাতাস।

• Upload link: অনেক router-এ “QoS”, “SQM” বা “Smart Queue” সেটিং থাকে। সাধারণত গতি ISP-র আসল গতির একটু নিচে বেঁধে দেওয়া হয় (shaping), যাতে queue জমে router-এর fq_codel বা CAKE-এ, মডেমের বড় buffer-এ নয় (পর্ব ১৫)।
• Wi-Fi-তে WMM: সবাই একই বাতাস ভাগ করে (পর্ব ১৪)। 802.11e-র ভিত্তিতে Wi-Fi Alliance-এর WMM চারটি access category রাখে — ভয়েস, ভিডিও, best effort, background — আর ভয়েসকে বাতাসে কম অপেক্ষার সুযোগ দেয় (ছোট contention window). 802.11n আর পরের উচ্চ গতির জন্য WMM সাধারণত চালু রাখতেই হয়।

৯ · AI-এর যুগে multicast আর QoS

“IPTV-র জন্য multicast সেটআপ” বা “ভিডিও কলের QoS কনফিগ” চাইলে AI লম্বা, আত্মবিশ্বাসী উত্তর দেয় — কিন্তু কয়েকটি ভুল খুব প্রচলিত:

AI-এর উত্তর মানার আগে — চেকলিস্ট

• Multicast MAC নিজে বাইনারিতে হিসাব করে মিলিয়েছি (শেষ ২৩ bit)
• DSCP আর TOS byte-এর মান আলাদা রেখেছি, আর capture-এ ঘরটি দেখে যাচাই করেছি
• Priority queue-র সাথে policer বা সীমা আছে কি না দেখেছি
• কমান্ডগুলো আমার vendor বা OS-এর ডকুমেন্টেশন আর man page-এ আছে, আর আগে ল্যাবে চালিয়েছি
• RFC নম্বরগুলো rfc-editor.org-এ খুলে শিরোনাম মিলিয়েছি
• পরিবর্তনের আগে-পরে লোডের সময় ping, jitter আর throughput মেপেছি — শুধু নিজের বা অনুমতিপ্রাপ্ত নেটওয়ার্কে