TCP congestion control — slow start, AIMD, CUBIC আর BBR

১ · Congestion কী — ঢাকার মোড়ের জ্যাম আর তার দাম

সন্ধ্যায় ফার্মগেটের মোড়ের কথা ভাবুন। রাস্তা প্রতি মিনিটে হয়তো ১০০টি গাড়ি পার করাতে পারে। ৮০টি এলে সবাই চলে যায়। ১২০টি এলে প্রতি মিনিটে ২০টি করে লাইন বাড়তেই থাকে — যতক্ষণ না মোড়টি আটকে যায়। নেটওয়ার্কেও তা-ই: কোনো link-এ তার ক্ষমতার চেয়ে বেশি ডেটা এলে router-এর buffer-এ queue জমে। এই অবস্থার নাম congestion, বাংলায় নেটওয়ার্কের জ্যাম।

Congestion-এর দাম তিনটি, আর তিনটিই পরপর আসে:

1. Delay বাড়ে: পাঠানোর হার link-এর ক্ষমতার কাছে গেলে গড় queuing delay খাড়া হয়ে ওঠে — ρ/(১ − ρ)-এর বক্ররেখা, যা পর্ব ০৫-এ (Delay, loss আর throughput) হিসাব করেছেন।
2. Packet হারায়: Buffer সসীম; ভরে গেলে router নতুন packet ফেলে দেয় (tail drop) — পর্ব ১৫-এর router-এর ভেতরে দেখেছেন।
3. ক্ষমতা নষ্ট হয়: প্রেরক হারানো packet আবার পাঠায়। ফলে link-এর একটি অংশ যায় একই ডেটার দ্বিতীয় কপিতে। Timer আগেভাগে ফুরালে যে packet আসলে হারায়নি, তারও কপি যায়। আর যে packet শেষ hop-এ গিয়ে ফেলা হলো, তার জন্য আগের সব link-এর খাটুনি বৃথা। প্রাপকের অ্যাপের কাছে পৌঁছানো কাজের ডেটার হার — goodput — তখন পাঠানোর হারের চেয়ে অনেক কম।

Flow control বনাম congestion control

দুটিই প্রেরককে থামায়, কিন্তু কারণ আলাদা। পর্ব ৩১-এ (TCP flow control) দেখেছেন, flow control প্রাপককে বাঁচায় — প্রাপকের buffer যেন উপচে না পড়ে। Congestion control বাঁচায় পথের নেটওয়ার্ককে — মাঝের router-দের।

২ · ১৯৮৬-এর ধস আর দুই পথ — end-to-end বনাম নেটওয়ার্কের সাহায্য

Jacobson-এর মূল ধারণা ছিল packet সংরক্ষণ: স্থিতিশীল অবস্থায় একটি packet নেটওয়ার্ক থেকে বের হলে (ACK ফিরলে) তবেই নতুন একটি ঢোকানো। ফলে ACK-এর ছন্দই পাঠানোর ছন্দ ঠিক করে — একে বলে ACK clocking. Bottleneck যত ধীর, ACK তত ফাঁকে ফাঁকে ফেরে, প্রেরকও তত ধীরে পাঠায়।

জ্যাম টের পাওয়ার দুই পথ

ECN-এর দাগ দিতে router-এর লাগে AQM — RED বা CoDel-এর মতো নিয়ম, যা buffer ভরার আগেই সংকেত দেয়। এগুলোর কাজ পর্ব ১৫-এ, আর DSCP-র পাশের ECN-এর দুই bit পর্ব ২৬-এ দেখেছেন; এখানে শুধু TCP-র দিকটা।

৩ · Congestion window — গতির একটি সংখ্যা

TCP প্রেরক একটি চলক রাখে: cwnd (congestion window) — ACK পাওয়ার আগে নেটওয়ার্কে একসাথে সর্বোচ্চ কত বাইট ভাসমান রাখা যাবে, প্রেরকের নিজের অনুমানে। প্রাপকের দেওয়া সীমা rwnd-ও আছে, তাই আসল নিয়ম:

প্রতি RTT-তে প্রায় এক window পাঠানো যায়, তাই পাঠানোর হার ≈ cwnd ÷ RTT. উদাহরণ: cwnd = ২০ MSS, MSS = ১,৪৬০ byte, RTT ৪০ ms → ২০ × ১,৪৬০ × ৮ ÷ ০.০৪ = ৫.৮৪ Mbps. অর্থাৎ গতি বাড়াতে-কমাতে TCP শুধু cwnd বদলায়। বইয়ের অঙ্কে cwnd প্রায়ই MSS-এর এককে লেখা হয় (“cwnd = ২০”); kernel-এর ভেতরে Linux-ও segment গোনে।

Link পুরো ব্যবহার করতে হলে cwnd অন্তত পথের bandwidth-delay product-এর সমান হতে হবে (পর্ব ০৫)। ১০০ Mbps আর ৫০ ms-এ BDP = ৫ Mbit = ৬,২৫,০০০ byte — প্রায় ৪২৮টি ১,৪৬০ byte-এর segment. কিন্তু প্রেরক পথের bandwidth জানে না। তাই প্রশ্ন দাঁড়ায়: শুরুতে কত, আর কীভাবে বাড়াব-কমাব? নিচের তিনটি অংশ সেই উত্তর।

৪ · Slow start আর congestion avoidance — দ্রুত খোঁজা, তারপর সাবধানে

Slow start: সংযোগের শুরুতে cwnd ছোট — একটি initial window (IW). তারপর প্রতিটি নতুন ACK-এ cwnd বাড়ে ১ MSS করে। এক RTT-তে cwnd-সংখ্যক segment যায়, ফেরে ততগুলো ACK — তাই প্রতি RTT-তে cwnd দ্বিগুণ: ১, ২, ৪, ৮… নামে “slow”, কারণ আগের TCP শুরুতেই পুরো window ছেড়ে দিত; তার তুলনায় ১ থেকে শুরু করা ধীর। বৃদ্ধি আসলে exponential.

ssthresh: দ্বিগুণ হতে হতে cwnd যখন slow start threshold-এ পৌঁছায়, TCP সাবধানী মোডে যায় — congestion avoidance. এখানে প্রতিটি ACK-এ cwnd বাড়ে MSS × MSS ÷ cwnd, অর্থাৎ পুরো এক RTT-তে মোট মাত্র +১ MSS — রৈখিক বৃদ্ধি। শুরুতে ssthresh সাধারণত খুব বড় (কার্যত অসীম), তাই প্রথম loss পর্যন্ত slow start চলে; loss-এর পর ssthresh হয় তখনকার window-এর অর্ধেক।

শুরুর window — IW10

পুরোনো নিয়মে IW ছিল ১ segment, পরে RFC 3390 (২০০২) প্রায় ৪ KB পর্যন্ত (২–৪ segment) অনুমতি দেয়। Google-এর পরীক্ষার পর RFC 6928 (২০১৩, experimental) প্রস্তাব করে IW = min(১০·MSS, max(২·MSS, ১৪,৬০০ byte)) — সাধারণত ১০টি segment. Linux ২০১১ সালের দিকে (২.৬.৩৯ সংস্করণ) থেকে IW10 ব্যবহার করে; অন্য OS-এ ও CDN-এ মান আলাদা হতে পারে। ছোট ফাইলে এর প্রভাব বড়: ১,০০,০০০ byte-এর একটি ফাইল ≈ ৬৯টি segment. Loss না হলে আর rwnd বাধা না দিলে IW1-এ লাগে ৭ RTT (১, ৩, ৭, ১৫, ৩১, ৬৩, ১২৭ জমা), IW3-এ ৫ RTT, IW10-এ মাত্র ৩ RTT (১০, ৩০, ৭০)। ১০০ ms RTT-তে এটি ৪০০ ms-এর পার্থক্য — বেশিরভাগ ওয়েবপেজের ফাইল ছোট, তাই এই অংশই অনুভূত গতি ঠিক করে।

৫ · Loss-এর জবাব — fast retransmit, fast recovery আর timeout

TCP loss টের পায় দুইভাবে — বিস্তারিত পর্ব ৩০-এ (TCP-র নির্ভরযোগ্যতা)। এখানে প্রশ্ন শুধু: loss টের পেলে cwnd-এর কী হবে?

• তিনটি duplicate ACK: প্রাপক একটি segment পায়নি, কিন্তু পরের segment-গুলো পাচ্ছে — তাই বারবার একই ACK নম্বর পাঠাচ্ছে। মানে, packet এখনো চলছে; জ্যাম হালকা. প্রেরক timer-এর অপেক্ষা না করে হারানোটি আবার পাঠায় — fast retransmit. তিনটির অপেক্ষা কারণ এক-দুটি duplicate ACK শুধু packet-এর ক্রম উল্টে যাওয়া (reordering) থেকেও আসতে পারে।
• Timeout: RTO ফুরিয়ে গেল, কোনো খবরই নেই — হয়তো পুরো ঝাঁক হারিয়েছে। জ্যাম গুরুতর.

RFC 5681-এর ভাষায় নতুন ssthresh = max(FlightSize/২, ২·MSS), যেখানে FlightSize = ACK-না-পাওয়া ডেটা। “+৩” কেন? তিনটি duplicate ACK মানে তিনটি segment নেটওয়ার্ক ছেড়ে প্রাপকের কাছে পৌঁছেছে — packet সংরক্ষণের হিসাবে তাদের জায়গা খালি। একই কারণে fast recovery-র সময় প্রতিটি বাড়তি duplicate ACK-এ cwnd +১ (inflation), যাতে ACK-এর ছন্দ না থামে।

এক window-এ কয়েকটি segment হারালে মূল Reno একাধিকবার cwnd অর্ধেক করে বা timeout-এ পড়ে। NewReno (RFC 6582) “partial ACK” দেখে fast recovery-র ভেতরেই পরের ফাঁক পাঠায়, আর SACK ঠিক কোন কোন অংশ পৌঁছেছে জানিয়ে দেয় — আজকের Linux, Windows আর macOS সাধারণত SACK ব্যবহার করে। নিয়মের মূল কাঠামো (অর্ধেক করা, তারপর রৈখিক বৃদ্ধি) একই থাকে।

৬ · পরীক্ষার ক্লাসিক অঙ্ক — cwnd বনাম transmission round

বিশ্ববিদ্যালয়, চাকরি বা ইন্টারভিউর পরীক্ষায় প্রায়ই একটি গ্রাফ দেওয়া থাকে: x-অক্ষে transmission round (প্রতিটি এক RTT), y-অক্ষে cwnd (segment-এ)। প্রশ্ন: কোথায় slow start, কোথায় congestion avoidance, কোন loss কোন ধরনের, আর ssthresh কত। নিচের গ্রাফটি একটি TCP Reno সংযোগের।

পুরো সমাধান

1. Slow start কোথায়? যেখানে cwnd দ্বিগুণ হয়: round ১–৫ (১ → ১৬) আর round ১৯–২২ (১ → ৮)। যে round-এ cwnd ssthresh ছোঁয় (৫ আর ২২), বইভেদে সেটিকে slow start-এর শেষ round বা congestion avoidance-এর প্রথম round ধরা হয় — উত্তরে নিজের নিয়মটি লিখে দিন।
2. Congestion avoidance কোথায়? যেখানে প্রতি round-এ +১: round ৫–১৩, ১৪–১৮ আর ২২–২৪.
3. শুরুর ssthresh? দ্বিগুণ হওয়া থামল ১৬-তে (৩২ হয়নি) — তাই ssthresh = ১৬.
4. Loss A (round ১৩) কোন ধরনের? পরের round-এ cwnd ২৪ থেকে ১২ — অর্ধেক, ১ নয়। তাই তিনটি duplicate ACK, Reno-র fast recovery. নতুন ssthresh = ২৪/২ = ১২.
5. Loss B (round ১৮) কোন ধরনের? cwnd ১৬ থেকে ১-এ — timeout. ssthresh = ১৬/২ = ৮; তাই round ২২-এ ৮ ছুঁয়ে আবার রৈখিক।
6. Round ১৫ আর ২০-এ ssthresh? ১২ আর ৮.
7. ৭০তম segment কোন round-এ যায়? জমা যোগফল: ১, ৩, ৭, ১৫, ৩১, ৪৮ (round ৬), ৬৬ (round ৭), ৮৫ (round ৮) — তাই round ৮.
8. Round ২৪-এ তিনটি duplicate ACK হলে? cwnd ছিল ১০ → ssthresh = ৫, round ২৫-এ cwnd = ৫.
9. এটি Tahoe হলে? Loss A-র পরেও cwnd ১-এ নামত — round ১৪-তে ১.

এক নিয়মে নজর রাখুন: অঙ্কের round-ভিত্তিক গ্রাফে fast recovery শেষে cwnd সাধারণত ssthresh ধরা হয় (এখানে ১২)। কিছু বইয়ের গ্রাফে ssthresh + ৩ (এখানে ১৫) দেখানো হয়, কারণ inflation-এর হিসাব ধরে। প্রশ্নে যে নিয়ম দেওয়া, সেটিই মানুন।

এবার একই অঙ্ক simulator-এ। Loss কোন round-এ কী ধরনের, তা আগে থেকে লেখা; প্রতিটি round-এ cwnd, এ পর্যন্ত মোট segment, পরের round-এর নিয়ম আর ssthresh ছাপা হয়, পাশে # দিয়ে ছোট একটি গ্রাফ। শেষে একই loss-এ Tahoe কী করত:

// TCP cwnd per transmission round (unit: MSS). Loss events are scripted.
const ROUNDS = 24, SSTHRESH0 = 16;
const loss = { 13: "3dup", 18: "timeout" };    // loss detected during this round
function run(flavour) {
  let cwnd = 1, ssthresh = SSTHRESH0, sent = 0;
  const rows = [];
  for (let r = 1; r <= ROUNDS; r++) {
    sent += cwnd;
    const ev = loss[r];
    if (ev) {                                    // both kinds: ssthresh = half the window
      ssthresh = Math.max(Math.floor(cwnd / 2), 2);
      rows.push([r, cwnd, sent, ev === "3dup" ? "3 dupACK" : "TIMEOUT", ssthresh]);
      cwnd = (ev === "3dup" && flavour === "Reno") ? ssthresh : 1;   // Reno: fast recovery
      continue;
    }
    rows.push([r, cwnd, sent, cwnd < ssthresh ? "x2 (slow start)" : "+1 (cong. avoid)", ssthresh]);
    cwnd = cwnd < ssthresh ? Math.min(2 * cwnd, ssthresh) : cwnd + 1;
  }
  return rows;
}
console.log(`TCP Reno, initial ssthresh = ${SSTHRESH0} MSS`);
console.log("round cwnd  sent-so-far  next step         ssthresh-after  plot");
for (const [r, w, s, rule, th] of run("Reno"))
  console.log(String(r).padStart(5), String(w).padStart(4), String(s).padStart(12),
    " " + rule.padEnd(17), String(th).padStart(14), " " + "#".repeat(w));
console.log("\nTCP Tahoe, same losses - cwnd per round:");
console.log(run("Tahoe").map(x => x[1]).join(" "));

TCP Reno, initial ssthresh = 16 MSS
round cwnd  sent-so-far  next step         ssthresh-after  plot
    1    1            1  x2 (slow start)               16  #
    2    2            3  x2 (slow start)               16  ##
    3    4            7  x2 (slow start)               16  ####
    4    8           15  x2 (slow start)               16  ########
    5   16           31  +1 (cong. avoid)              16  ################
    6   17           48  +1 (cong. avoid)              16  #################
    7   18           66  +1 (cong. avoid)              16  ##################
    8   19           85  +1 (cong. avoid)              16  ###################
    9   20          105  +1 (cong. avoid)              16  ####################
   10   21          126  +1 (cong. avoid)              16  #####################
   11   22          148  +1 (cong. avoid)              16  ######################
   12   23          171  +1 (cong. avoid)              16  #######################
   13   24          195  3 dupACK                      12  ########################
   14   12          207  +1 (cong. avoid)              12  ############
   15   13          220  +1 (cong. avoid)              12  #############
   16   14          234  +1 (cong. avoid)              12  ##############
   17   15          249  +1 (cong. avoid)              12  ###############
   18   16          265  TIMEOUT                        8  ################
   19    1          266  x2 (slow start)                8  #
   20    2          268  x2 (slow start)                8  ##
   21    4          272  x2 (slow start)                8  ####
   22    8          280  +1 (cong. avoid)               8  ########
   23    9          289  +1 (cong. avoid)               8  #########
   24   10          299  +1 (cong. avoid)               8  ##########

TCP Tahoe, same losses - cwnd per round:
1 2 4 8 16 17 18 19 20 21 22 23 24 1 2 4 8 12 1 2 4 6 7 8

৭ · AIMD — করাতের দাঁত, ন্যায্যতা আর throughput-এর সূত্র

Loss বাদ দিলে স্থিতিশীল অবস্থায় Reno দুটি কাজই করে: প্রতি RTT-তে +১ (additive increase), loss-এ অর্ধেক (multiplicative decrease) — সংক্ষেপে AIMD. cwnd-এর গ্রাফ তাই করাতের দাঁতের মতো: W/২ থেকে W পর্যন্ত ঢালু ওঠা, তারপর হঠাৎ পতন।

কেন AIMD ন্যায্য — phase plot-এর যুক্তি

১৯৮৯ সালে Dah-Ming Chiu আর Raj Jain একটি সরল ছবিতে দেখান কেন এই নিয়মই ঠিক। ধরুন দুটি প্রবাহ A আর B একটি bottleneck ভাগ করে, যার ক্ষমতা C. x-অক্ষে A-র হার, y-অক্ষে B-র। দুটি রেখা গুরুত্বপূর্ণ:

• দক্ষতার রেখা x + y = C: এর ওপরে জ্যাম (loss), নিচে link-এর ক্ষমতা অব্যবহৃত।
• ন্যায্যতার রেখা x = y: দুজন সমান পায়। লক্ষ্য দুটি রেখার ছেদবিন্দু (C/২, C/২)।

এখন দুই নড়াচড়া দেখুন। Additive increase-এ দুজনেই +১, তাই বিন্দু ৪৫° কোণে সরে — ন্যায্যতার রেখার সমান্তরালে; পার্থক্য x − y একই থাকে। Multiplicative decrease-এ দুজনেই অর্ধেক, তাই বিন্দু মূলবিন্দুর দিকে সোজা রেখায় সরে — পার্থক্যও অর্ধেক হয়। প্রতিটি চক্রে পার্থক্য অর্ধেক: d, d/২, d/৪ … → ০. বিন্দু ঘুরতে ঘুরতে ছেদবিন্দুর কাছে দোল খায়।

অন্য নিয়ম কেন ব্যর্থ: AIAD-এ (যোগে বাড়া, বিয়োগে কমা) দুই নড়াচড়াই ৪৫°-এ, পার্থক্য কখনো কমে না। MIMD-এ দুটিই মূলবিন্দুর দিকের রেখায়, অনুপাত x/y কখনো বদলায় না। শুধু AIMD একসাথে দক্ষতা আর ন্যায্যতার দিকে যায়।

একই যুক্তি simulator-এ। দুটি প্রবাহ একটি bottleneck ভাগ করে, যার ক্ষমতা প্রতি RTT-তে ৬০ MSS; যোগফল ৬০ পেরোলে দুজনেই একই RTT-তে loss দেখে (synchronised loss — সরলীকরণ)। ন্যায্যতা মাপা হয় Jain's fairness index দিয়ে: (x + y)² ÷ (২(x² + y²)) — সমান হলে ১, একজন সব নিলে ০.৫.

// Two TCP flows share one bottleneck. Capacity = 60 MSS per RTT (sum of windows).
// Each RTT: both +1 (additive increase). If the sum exceeds capacity,
// both see a loss in the same RTT (synchronised) and halve (multiplicative decrease).
const CAP = 60;
const jain = (x, y) => (x + y) ** 2 / (2 * (x * x + y * y));   // 1 = perfectly fair
function simulate(decrease) {
  let a = 4, b = 50, losses = 0;
  const log = [];
  for (let rtt = 1; rtt <= 400; rtt++) {
    if (a + b > CAP) {
      losses++;
      if (losses <= 6) log.push(`  RTT ${String(rtt).padStart(3)}: loss at ${a.toFixed(1)} + ${b.toFixed(1)} = ` +
        `${(a + b).toFixed(1)}  gap at loss ${(b - a).toFixed(1)}  Jain ${jain(a, b).toFixed(3)}`);
      [a, b] = decrease(a, b);
    } else { a += 1; b += 1; }
  }
  log.push(`  after 400 RTTs: A = ${a.toFixed(1)}, B = ${b.toFixed(1)}, gap ${(b - a).toFixed(2)}, ` +
    `Jain ${jain(a, b).toFixed(3)}`);
  return log;
}
console.log(`start: A = 4, B = 50 (gap 46), Jain ${jain(4, 50).toFixed(3)}`);
console.log("AIMD (+1, x1/2):");
simulate((a, b) => [a / 2, b / 2]).forEach(l => console.log(l));
console.log("AIAD (+1, -4) for comparison:");
simulate((a, b) => [Math.max(a - 4, 1), Math.max(b - 4, 1)]).slice(-1).forEach(l => console.log(l));

start: A = 4, B = 50 (gap 46), Jain 0.579
AIMD (+1, x1/2):
  RTT   5: loss at 8.0 + 54.0 = 62.0  gap at loss 46.0  Jain 0.645
  RTT  21: loss at 19.0 + 42.0 = 61.0  gap at loss 23.0  Jain 0.876
  RTT  37: loss at 24.5 + 36.0 = 60.5  gap at loss 11.5  Jain 0.965
  RTT  53: loss at 27.3 + 33.0 = 60.3  gap at loss 5.8  Jain 0.991
  RTT  69: loss at 28.6 + 31.5 = 60.1  gap at loss 2.9  Jain 0.998
  RTT  85: loss at 29.3 + 30.8 = 60.1  gap at loss 1.4  Jain 0.999
  after 400 RTTs: A = 26.0, B = 26.0, gap 0.00, Jain 1.000
AIAD (+1, -4) for comparison:
  after 400 RTTs: A = 4.0, B = 50.0, gap 46.00, Jain 0.579

Throughput-এর সূত্র — Mathis সূত্র

করাতের দাঁতে window W/২ থেকে W-তে ওঠে, প্রতি RTT-তে ১ — তাই একটি চক্রে W/২ RTT. গড় window ৩W/৪, তাই গড় throughput ≈ ০.৭৫ · W · MSS ÷ RTT — পরীক্ষার প্রিয় ফল। এবার loss-এর হার p যোগ করি:

1. এক চক্রে পাঠানো segment = গড় window × RTT-র সংখ্যা = (৩W/৪) × (W/২) = ৩W²/৮.
2. প্রতিটি চক্রে একটি loss, তাই p = ১ ÷ (৩W²/৮) → W = √(৮ ÷ ৩p).
3. Throughput = (৩W/৪) · MSS ÷ RTT = (৩/৪)·√(৮/৩p) · MSS ÷ RTT = √(৩/২p) · MSS ÷ RTT.

এটি Mathis, Semke, Mahdavi আর Ott-এর ১৯৯৭ সালের মডেল — Mathis সূত্র. ১.২২ = √(৩/২) এসেছে প্রতিটি ACK একটি segment স্বীকার করে আর loss নিয়মিত ধরে নিয়ে; অনুমান বদলালে ধ্রুবকটিও বদলায় — যেমন delayed ACK-এ (প্রতি দুই segment-এ একটি ACK) √(৩/৪) ≈ ০.৮৭, আর এলোমেলো loss ধরলে প্রায় ১.৩১, আর timeout-এর প্রভাব ধরা আরও বিস্তারিত মডেল (Padhye ও অন্যান্য, ১৯৯৮) আছে। তাই এটিকে আনুমানিক ধরুন।

উদাহরণ: MSS = ১,৪৬০ byte = ১১,৬৮০ bit, RTT = ১০০ ms, p = ১০^−৪ (প্রতি ১০,০০০-এ একটি loss). ১.২২৪৭ × ১১,৬৮০ ÷ (০.১ × ০.০১) ≈ ১৪.৩ Mbps. Link ১ Gbps হলেও এই সংযোগ এর বেশি পাবে না। p = ১০^−২ হলে ১.৪৩ Mbps — loss ১০০ গুণ বাড়লে গতি ১০ গুণ কমে।

উচ্চ গতির সমস্যা: উল্টো হিসাব করুন — RTT ১০০ ms-এ ১০ Gbps চাইলে (MSS ১,৫০০ byte) লাগে p ≈ ২.২ × ১০^−১০, অর্থাৎ প্রায় ৪৬০ কোটি segment-এ একটির বেশি loss নয়; window প্রায় ৮৩,৩৩৩ segment, আর একটি loss-এর পর অর্ধেক থেকে ফিরতে ৪১,৬৬৭ RTT ≈ ৪,১৬৭ সেকেন্ড — এক ঘণ্টার বেশি। এই হিসাব (RFC 3649-এ HighSpeed TCP-র প্রেরণা) থেকেই CUBIC-এর মতো নতুন algorithm-এর জন্ম (অংশ ৮)।

RTT-র অন্যায্যতা আর সমান্তরাল সংযোগ

সূত্রে RTT হর-এ। একই bottleneck আর একই p (১০^−৪)-তে সূত্রের হিসাবে RTT ২০ ms-এর প্রবাহ প্রায় ৭১.৫ Mbps, আর ১০০ ms-এর প্রবাহ ১৪.৩ Mbps — মোটামুটি ৫ গুণ পার্থক্য। কারণ ছোট-RTT প্রবাহ প্রতি সেকেন্ডে বেশিবার +১ করে। ঢাকার কাছের সার্ভার থেকে ডাউনলোড আর দূর মহাদেশের সার্ভার থেকে ডাউনলোড একই লাইনে চললে, কাছেরটি বেশি ভাগ পায় — এটাই RTT unfairness.

TCP-র ন্যায্যতা আবার প্রতি সংযোগে, প্রতি ব্যবহারকারী বা প্রতি অ্যাপে নয়। ১০০ Mbps-এর একটি link-এ আগে থেকে ৯টি সংযোগ; নতুন অ্যাপ ১টি খুললে পায় প্রায় ১০০/১০ = ১০ Mbps, কিন্তু ১১টি খুললে ১১/২০ × ১০০ = ৫৫ Mbps. Download manager আর কিছু টুল এজন্যই একসাথে অনেক সংযোগ খোলে।

৮ · CUBIC, Vegas আর BBR — Reno-র পরের প্রজন্ম

CUBIC — সময়ের ঘড়িতে বাড়া

উচ্চ-BDP পথে Reno-র +১/RTT খুব ধীর (অংশ ৭-এর হিসাব)। CUBIC (Sangtae Ha, Injong Rhee আর Lisong Xu, ২০০৮) window-কে শেষ loss থেকে কেটে যাওয়া সময় t-এর ফাংশন বানায়, RTT-র সংখ্যার নয়:

• Wmax = শেষ loss-এর মুহূর্তের window; loss-এ window নামে β·Wmax-এ, যেখানে β = ০.৭ (৩০% কমানো, Reno-র ৫০% নয়)। ধ্রুবক C = ০.৪.
• t = ০-এ W = C·(−K)³ + Wmax = Wmax − Wmax(১ − β) = β·Wmax. ঠিক K সেকেন্ড পরে W আবার Wmax.
• বক্ররেখার আকার: শুরুতে দ্রুত ওঠা (concave), Wmax-এর কাছে প্রায় সমতল — যেখানে আগে loss হয়েছিল সেখানে সাবধানে থাকা — তারপর Wmax পেরিয়ে আবার দ্রুত ওঠা (convex), নতুন ক্ষমতা খোঁজা।

Wmax = ১,০০০ MSS হলে K = ∛(১,০০০ × ০.৩ ÷ ০.৪) = ∛৭৫০ ≈ ৯.০৯ সেকেন্ড — RTT যা-ই হোক। Reno-র লাগে ৫০০ RTT. নিচের হিসাব দুটিকে পাশাপাশি রাখে:

// CUBIC after a loss (RFC 9438): W(t) = C*(t - K)^3 + Wmax,  K = cbrt(Wmax*(1 - beta)/C)
// Reno after the same loss: starts at Wmax/2, grows +1 MSS every RTT.
const C = 0.4, beta = 0.7, Wmax = 1000;            // window unit: MSS
const RTT = 0.1;                                    // seconds
const K = Math.cbrt(Wmax * (1 - beta) / C);
const cubic = t => C * (t - K) ** 3 + Wmax;
const reno = t => Wmax / 2 + t / RTT;
console.log(`Wmax = ${Wmax} MSS, RTT = ${RTT * 1000} ms, K = ${K.toFixed(2)} s`);
console.log("t(s)   CUBIC  Reno");
for (const t of [0, 1, 2, 4, 6, 8, K, 10, 12, 15, 20])
  console.log(t.toFixed(t === K ? 2 : 0).padStart(5), cubic(t).toFixed(0).padStart(6),
    reno(t).toFixed(0).padStart(5));
console.log("\ntime to climb back to Wmax:");
for (const rtt of [0.01, 0.1, 0.2])
  console.log(`  RTT ${String(rtt * 1000).padStart(3)} ms: CUBIC ${K.toFixed(1)} s, ` +
    `Reno ${(Wmax / 2 * rtt).toFixed(0)} s (${Wmax / 2} RTTs)`);
const MSS = 1460 * 8;                               // bits
console.log(`\nat Wmax: rate = Wmax*MSS/RTT = ${(Wmax * MSS / RTT / 1e6).toFixed(1)} Mbps`);

Wmax = 1000 MSS, RTT = 100 ms, K = 9.09 s
t(s)   CUBIC  Reno
    0    700   500
    1    789   510
    2    858   520
    4    947   540
    6    988   560
    8    999   580
 9.09   1000   591
   10   1000   600
   12   1010   620
   15   1083   650
   20   1520   700

time to climb back to Wmax:
  RTT  10 ms: CUBIC 9.1 s, Reno 5 s (500 RTTs)
  RTT 100 ms: CUBIC 9.1 s, Reno 50 s (500 RTTs)
  RTT 200 ms: CUBIC 9.1 s, Reno 100 s (500 RTTs)

at Wmax: rate = Wmax*MSS/RTT = 116.8 Mbps

CUBIC Linux-এ ২.৬.১৯ সংস্করণ (২০০৬-এর দিকে) থেকে ডিফল্ট, তার আগে ছিল BIC; IETF মানদণ্ড RFC 8312 (২০১৮), হালনাগাদ RFC 9438 (২০২৩)। Windows-এর নতুন সংস্করণ আর Apple-এর OS-ও এখন সাধারণত CUBIC ব্যবহার করে। ইন্টারনেটের TCP traffic-এর বড় অংশ তাই CUBIC — Reno আজ মূলত পাঠ্যবইয়ের মডেল।

Delay-ভিত্তিক ধারণা — Vegas

Loss-ভিত্তিক algorithm জ্যাম টের পায় buffer উপচে পড়ার পরে। TCP Vegas (Brakmo আর Peterson, ১৯৯৪) আগেই টের পেতে চেয়েছিল: প্রত্যাশিত হার = cwnd ÷ BaseRTT (দেখা ন্যূনতম RTT), আসল হার = cwnd ÷ RTT. পার্থক্য × BaseRTT = queue-তে জমা আমার packet. উদাহরণ: cwnd ৩০, BaseRTT ১০০ ms, RTT ১২০ ms → (৩০০ − ২৫০) × ০.১ = ৫টি packet queue-তে। দুটি ছোট সীমা α আর β (কয়েকটি packet, যেমন ২ আর ৪) ধরে Vegas α-র কম হলে বাড়ায়, β-র বেশি হলে কমায় — এখানে ৫ > β, তাই কমায়। সমস্যা: loss-ভিত্তিক প্রবাহের পাশে Vegas আগে পিছিয়ে যায়, তাই ইন্টারনেটে ব্যাপকভাবে চলেনি। তবে “queue বাড়ছে = RTT বাড়ছে” ধারণাটি BBR, LEDBAT (ব্যাকগ্রাউন্ড আপডেট) আর অনেক আধুনিক algorithm-এ টিকে আছে।

BBR — মডেল দিয়ে চলা

Google-এর BBR (Neal Cardwell ও সহকর্মী, ২০১৬; Linux ৪.৯ থেকে) প্রশ্নটিই বদলে দেয়: loss-এর অপেক্ষা না করে পথের দুটি সংখ্যা মেপে নেওয়া। BtlBw — bottleneck-এর হার, সাম্প্রতিক প্রায় ১০ RTT-র delivery rate নমুনার সর্বোচ্চ; আর RTprop — queue-ছাড়া RTT, সাম্প্রতিক প্রায় ১০ সেকেন্ডের RTT নমুনার সর্বনিম্ন. আদর্শ চলার বিন্দু: হার = BtlBw, ভাসমান ডেটা = BtlBw × RTprop = BDP — link ভরা, queue খালি। BBR pacing করে pacing_gain × BtlBw হারে, আর cwnd ≈ ২ × BDP রাখে বাড়তি সীমা হিসেবে। চার ধাপ: Startup, Drain, ProbeBW, ProbeRTT.

বিতর্ক: BBR v1 loss-কে প্রায় উপেক্ষা করত। গবেষণায় দেখা গেছে, ছোট buffer-এর bottleneck-এ এটি অনেক retransmission ঘটাতে পারে আর CUBIC-এর চেয়ে অনেক বেশি ভাগ নিতে পারে; আবার বড় buffer-এ উল্টোটাও দেখা গেছে — ফল পরিস্থিতিভেদে আলাদা। BBR v2 আর v3 (২০১৯–২০২৩) loss আর ECN-কেও সংকেত হিসেবে নেয় আর ভাসমান ডেটার একটি ওপরের সীমা রাখে, যাতে CUBIC-এর পাশে আচরণ ভালো হয়; তবে এ নিয়ে মাপজোখ ও আলোচনা চলমান। Google জানিয়েছে, তাদের নিজেদের সার্ভিসে BBR throughput আর latency-তে উন্নতি এনেছে; QUIC-এর ভেতরেও BBR বা CUBIC বাছাই করা যায় (পর্ব ৩৩, QUIC).

৯ · ECN, DCTCP, L4S আর Linux-এ নিজে দেখা

Loss-ভিত্তিক TCP আর bufferbloat

Reno আর CUBIC loss না পাওয়া পর্যন্ত window বাড়ায় — অর্থাৎ bottleneck-এর buffer ভরে না যাওয়া পর্যন্ত। Buffer বড় হলে loss আসে দেরিতে, আর ততক্ষণ queue-তে শত শত ms জমে: এটাই bufferbloat (পর্ব ১৫)। বাসায় কেউ বড় ফাইল upload করলে ভিডিও কল আটকে যাওয়ার পেছনে প্রায়ই এই ঘটনা। প্রতিকার দুই দিক থেকে: router-এ AQM (CoDel, fq_codel) queue ছোট রাখে, আর প্রেরকের দিকে BBR-এর মতো algorithm queue না ভরেই চলতে চায়।

ECN — ফেলার বদলে দাগ

ECN চালু থাকলে (দুই প্রান্ত handshake-এ রাজি হলে) AQM packet না ফেলে CE দাগ দেয়। প্রাপক ACK-এ ECE flag দেয়, আর প্রেরক এক RTT-তে একবার loss-এর মতো প্রতিক্রিয়া করে (Reno-তে অর্ধেক), তারপর CWR পাঠায়। লাভ: retransmission নেই, timeout-এর ঝুঁকি নেই। Linux-এ ডিফল্টে tcp_ecn = 2 — অন্য পক্ষ চাইলে ECN মেনে নেয়, নিজে চায় না; কারণ পুরোনো কিছু middlebox ECN-যুক্ত packet ফেলে দিত। Apple-এর OS-এর মতো কিছু সিস্টেম নিজে থেকেও চায়।

DCTCP — data center-এর জন্য সূক্ষ্ম কমানো

Data center-এ RTT মাইক্রোসেকেন্ডে, switch-এর buffer ছোট, আর অনেক সার্ভার একসাথে একজনকে উত্তর দেয় (incast). DCTCP (Alizadeh ও সহকর্মী, ২০১০; RFC 8257) চালাকি করে: switch queue একটি ছোট সীমা K পেরোলেই দাগ দেয়, আর প্রেরক মাপে দাগের অনুপাত α (চলমান গড়: α ← (১ − g)·α + g·F, g = ১/১৬)। প্রতি RTT-তে cwnd ← cwnd × (১ − α/২). অল্প দাগ (α = ০.১) → মাত্র ৫% কমানো; সব দাগ (α = ১) → অর্ধেক, Reno-র মতো। ফল: queue খুব ছোট, throughput বেশি। কিন্তু এই আগ্রাসী দাগের নিয়ম সাধারণ ইন্টারনেটে Reno বা CUBIC-এর পাশে চালানো যায় না — তাই শুধু নিজের নিয়ন্ত্রিত নেটওয়ার্কে।

L4S — সংক্ষেপে

L4S (RFC 9330–9332, ২০২৩) DCTCP-র ধারণা ইন্টারনেটে আনার IETF-এর চেষ্টা: ECN-এর ECT(1) মান দিয়ে চিহ্নিত “scalable” প্রবাহ (যেমন TCP Prague) একটি আলাদা ছোট queue-তে যায়, আর পুরোনো প্রবাহ থাকে সাধারণ queue-তে — দুটির মধ্যে সমন্বয় করে DualQ Coupled AQM. লক্ষ্য প্রায় শূন্য queuing delay-তে পূর্ণ throughput. কিছু ISP আর যন্ত্র-নির্মাতা পরীক্ষামূলকভাবে চালু করছে বলে জানা যায়; কতটা ছড়াবে, তা এখনো দেখার বিষয়।

Linux-এ — কোন algorithm চলছে, আর বদলানো

Linux-এ congestion control আলাদা আলাদা module; প্রতিটি socket নিজের algorithm বেছে নিতে পারে। sysctl-এর তিনটি ফাইল (/proc/sys-এর নিচে) বলে দেয়: নতুন socket-এর ডিফল্ট, kernel-এ লোড করা algorithm, আর সাধারণ ব্যবহারকারী কোনগুলো বাছতে পারে। নিচের C প্রোগ্রাম ফাইল তিনটি পড়ে, তারপর একটি TCP socket-এ getsockopt(TCP_CONGESTION) দিয়ে নাম পড়ে আর setsockopt() দিয়ে পাঁচটি algorithm বসানোর চেষ্টা করে — কোনটি সফল, কোনটি কেন নয়:

#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <sys/socket.h>

static void show(const char *file) {              /* print one line of a sysctl file */
    char path[128], buf[256] = "(cannot read)\n";
    snprintf(path, sizeof path, "/proc/sys/net/ipv4/%s", file);
    FILE *f = fopen(path, "r");
    if (f) { if (!fgets(buf, sizeof buf, f)) strcpy(buf, "(empty)\n"); fclose(f); }
    printf("%-34s %s", file, buf);
}
int main(void) {
    show("tcp_congestion_control");               /* default for new sockets */
    show("tcp_available_congestion_control");     /* algorithms loaded in the kernel */
    show("tcp_allowed_congestion_control");       /* what a normal user may choose */
    int s = socket(AF_INET, SOCK_STREAM, 0);
    char name[16] = ""; socklen_t len = sizeof name - 1;
    getsockopt(s, IPPROTO_TCP, TCP_CONGESTION, name, &len);
    printf("\nnew TCP socket starts with: %s\n", name);
    const char *want[] = {"reno", "cubic", "bbr", "vegas", "dctcp"};
    for (int i = 0; i < 5; i++) {
        int r = setsockopt(s, IPPROTO_TCP, TCP_CONGESTION, want[i], strlen(want[i]));
        const char *why = r == 0 ? "OK" : strerror(errno);
        memset(name, 0, sizeof name); len = sizeof name - 1;
        getsockopt(s, IPPROTO_TCP, TCP_CONGESTION, name, &len);
        printf("set %-6s -> %-26s socket now uses: %s\n", want[i], why, name);
    }
    close(s);
    return 0;
}

tcp_congestion_control             bbr
tcp_available_congestion_control   reno cubic bbr
tcp_allowed_congestion_control     reno cubic bbr

new TCP socket starts with: bbr
set reno   -> OK                         socket now uses: reno
set cubic  -> OK                         socket now uses: cubic
set bbr    -> OK                         socket now uses: bbr
set vegas  -> No such file or directory  socket now uses: bbr
set dctcp  -> No such file or directory  socket now uses: bbr

নিজের Linux যন্ত্রে (root লাগে এমন কমান্ড শুধু নিজের যন্ত্রে বা ল্যাবে) একই কাজ কমান্ডে, আর একটি চলমান সংযোগের cwnd দেখা:

$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic
$ sudo modprobe tcp_bbr                                  # module লোড
$ sudo sysctl -w net.ipv4.tcp_congestion_control=bbr     # নতুন সংযোগের ডিফল্ট
$ echo 'net.ipv4.tcp_congestion_control=bbr' | sudo tee /etc/sysctl.d/90-cc.conf   # reboot-এর পরেও
$ ss -tin state established '( dport = :443 )'
Recv-Q Send-Q  Local Address:Port    Peer Address:Port
0      0       192.168.0.105:51234   203.0.113.10:443
	 cubic wscale:7,7 rto:232 rtt:31.2/4.8 mss:1448 pmtu:1500 cwnd:10 ssthresh:7 send 3.7Mbps

ss -i-এর লাইনে সবই এই পর্বের ভাষা: algorithm cubic, cwnd ১০ segment, ssthresh ৭ (অর্থাৎ slow start আগেই শেষ হয়েছে — loss-এর কারণে, বা CUBIC-এর HyStart আগেভাগে থামানোয়), RTT ৩১.২ ms, আর send 3.7Mbps = ১০ × ১,৪৪৮ × ৮ ÷ ০.০৩১২ — ঠিক cwnd ÷ RTT. Windows-এ PowerShell-এ Get-NetTCPSetting | Select SettingName, CongestionProvider দেখায় কোন প্রোফাইলে কোন algorithm (নতুন সংস্করণে সাধারণত CUBIC).

১০ · AI-এর যুগে congestion control

“আমার সার্ভার ধীর, TCP tune করে দাও” — এমন প্রশ্নে AI প্রায়ই একগাদা sysctl ধরিয়ে দেয়। কিছু ভুল খুব প্রচলিত:

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

• cwnd, ssthresh-এর প্রতিটি মান নিজে বা simulator-এ আবার হিসাব করেছি
• সূত্রে একক (bit, byte, MSS, ms) মিলিয়েছি
• sysctl-গুলো আমার kernel-এর ডকুমেন্টেশনে আছে, আর আগে ল্যাব বা VM-এ চালিয়েছি
• পরিবর্তনের আগে-পরে throughput, RTT আর retransmission মেপেছি — শুধু নিজের বা অনুমতিপ্রাপ্ত নেটওয়ার্কে
• RFC নম্বরগুলো rfc-editor.org-এ খুলে শিরোনাম মিলিয়েছি