Congestion Control & Resource Allocation / Quality of Service

1ปัญหาการจัดสรรทรัพยากร (Resource Allocation)

Congestion control และ resource allocation เป็นเหรียญสองด้านของปัญหาเดียวกัน: ถ้าเครือข่ายจัดสรรทรัพยากรเชิงรุกได้ดีตั้งแต่ต้น (เช่น การจอง/reservation) ก็อาจไม่เกิด congestion เลย แต่การจัดสรรล่วงหน้าอย่างแม่นยำทำได้ยากเพราะทรัพยากรกระจายอยู่ทั่วเครือข่าย ทางเลือกที่ใช้กันจริงคือปล่อยให้ต้นทางส่งได้ตามต้องการ แล้ว "แก้ปัญหาเมื่อเกิด congestion" — ง่ายกว่าแต่อาจทำให้แพ็กเก็ตถูกทิ้งจำนวนมากก่อนควบคุมได้ทัน

งานนี้เกี่ยวข้องกับทั้งสองฝั่ง: ที่ router ใช้ queuing discipline ควบคุมลำดับส่ง/ทิ้งแพ็กเก็ต ส่วนที่ host ใช้กลไก congestion control ควบคุมอัตราการส่งของ source

Network Model และ Connectionless Flows

พิจารณาเครือข่าย packet-switched ที่ต้นทางอาจมี capacity เหลือเฟือบน outgoing link ของตัวเอง แต่กลางทางอาจเจอ router คอขวด (bottleneck) ที่ถูกหลายๆ ต้นทางแชร์ใช้พร้อมกัน แม้เครือข่ายจะเป็น connectionless (แต่ละ datagram ถูก switch อย่างอิสระ) แต่ในทางปฏิบัติ datagram ชุดหนึ่งระหว่างคู่ host มักไหลผ่าน router ชุดเดียวกันซ้ำๆ เรียกกลุ่มนี้ว่า flow ซึ่งนิยามได้หลายระดับ (host-to-host หรือ process-to-process/channel)

Taxonomy ของแนวทางแก้ปัญหา

เกณฑ์ประเมิน: ประสิทธิภาพ (Effective Resource Allocation)

เป้าหมายพื้นฐานคือ throughput สูง delay ต่ำ — แต่สองอย่างนี้ขัดแย้งกัน เพราะการดัน utilization ของทุก link ให้ถึง 100% (เพื่อไม่ให้ link ว่างเสียโอกาส) จะทำให้คิวที่ router ยาวขึ้น ทำให้ delay สูงขึ้นตามไปด้วย

เกณฑ์ประเมิน: ความเป็นธรรม (Fair Resource Allocation)

คำถามคือ "แบ่งเท่ากัน" เท่ากับ "แบ่งอย่างเป็นธรรม" เสมอหรือไม่ — เช่น flow ที่วิ่งผ่าน 4-hop ควรได้ share เท่ากับ flow ที่วิ่งแค่ 1-hop หรือไม่ (เพราะ flow ยาวใช้ทรัพยากรของหลาย link พร้อมกัน)

2Queuing Disciplines

FIFO และ Tail Drop

FIFO (First-Come-First-Served): แพ็กเก็ตที่มาถึง router ก่อนถูกส่งก่อน — เมื่อ buffer เต็ม แพ็กเก็ตใหม่ที่มาถึงถูกทิ้งทันที เรียกว่า tail drop โดยไม่สนว่าแพ็กเก็ตเป็นของ flow ไหนหรือสำคัญแค่ไหน

Priority Queuing: ส่วนขยายง่ายๆ ของ FIFO — แต่ละแพ็กเก็ตถูก mark priority (เช่นใน IP header) router มีหลายคิว FIFO แยกตาม priority และส่งจากคิว priority สูงสุดที่ไม่ว่างก่อนเสมอ ภายในแต่ละ priority ยังคงเป็น FIFO

Fair Queuing (FQ)

ปัญหาของ FIFO คือไม่แยกแยะระหว่าง traffic source — FQ แก้ด้วยการให้แต่ละ flow มีคิวแยกของตัวเอง แล้ว router ให้บริการแบบ round-robin ระหว่างคิว ทำให้แต่ละ flow ได้ share ใกล้เคียงกันไม่ว่า flow อื่นจะส่งเยอะแค่ไหน

ปัญหาที่ซับซ้อนขึ้น: แพ็กเก็ตแต่ละ flow ยาวไม่เท่ากัน — ถ้า round-robin ตาม "จำนวนแพ็กเก็ต" เฉยๆ flow ที่ใช้แพ็กเก็ตใหญ่กว่าจะได้ bandwidth มากกว่าโดยไม่เป็นธรรม (เช่น flow ที่ใช้แพ็กเก็ต 1000 byte จะได้ 2/3 ของ bandwidth เทียบกับ flow ที่ใช้ 500 byte)

สิ่งที่ต้องการจริงคือ bit-by-bit round-robin (ส่งทีละ bit สลับ flow) ซึ่งทำจริงไม่ได้ (แพ็กเก็ตต้อง atomic) — FQ จึงจำลองพฤติกรรมนี้ด้วยการคำนวณว่าแพ็กเก็ตแต่ละใบ "จะเสร็จเมื่อไรถ้าส่งแบบ bit-by-bit round-robin" แล้วใช้เวลานั้นจัดลำดับส่งจริง

เมื่อคำนวณ Fᵢ ของทุกแพ็กเก็ตจากทุก flow แล้ว ปฏิบัติ Fᵢ เป็น timestamp — แพ็กเก็ตที่มี timestamp ต่ำสุด (ควรเสร็จก่อนใคร) ถูกส่งก่อนเสมอ (ถ้ากำลังส่งแพ็กเก็ตอื่นอยู่ ปล่อยให้เสร็จก่อนแล้วค่อยแทรก)

3TCP Congestion Control

เพิ่มเข้าสู่ Internet ปลายทศวรรษ 1980 โดย Van Jacobson หลังเกิดปัญหา congestion collapse — host ส่งเร็วเท่าที่ advertised window อนุญาต จน router คอขวด drop แพ็กเก็ต host timeout แล้ว retransmit ซ้ำ ยิ่งซ้ำเติม congestion หนักขึ้นไปอีก

แนวคิดคือให้แต่ละ source ประมาณว่าเครือข่ายมี capacity เหลือเท่าไร แล้วใช้การมาถึงของ ACK เป็นสัญญาณว่า "แพ็กเก็ตหนึ่งใบออกจากเครือข่ายไปแล้ว ปลอดภัยที่จะส่งใบใหม่เข้าไปแทน" — เรียกว่า TCP เป็น self-clocking

Additive Increase / Multiplicative Decrease (AIMD)

TCP เก็บตัวแปร CongestionWindow ต่อ connection ควบคู่กับ AdvertisedWindow (flow control)

ปัญหาคือไม่มีใครบอก "ค่าที่เหมาะสม" ของ CongestionWindow ให้ฝั่งส่งเหมือนที่ AdvertisedWindow ถูกส่งมาจากฝั่งรับ — TCP จึงต้องประเมินระดับ congestion เอง แล้วปรับ CongestionWindow: ลดเมื่อ congestion สูงขึ้น เพิ่มเมื่อ congestion ลดลง รวมเรียกกลไกนี้ว่า AIMD

สัญญาณว่าเครือข่าย congested คือ timeout (สาเหตุหลักของแพ็กเก็ตหายคือ congestion ไม่ใช่ transmission error) — เมื่อ timeout เกิดขึ้น: CongestionWindow ถูกหาร 2 (multiplicative decrease)

Additive Increase: ทุกครั้งที่ส่ง CongestionWindow เต็มชุดสำเร็จ (ได้ ACK ครบใน 1 RTT) เพิ่ม CongestionWindow อีก 1 packet ในทางปฏิบัติ TCP ไม่รอครบ window แต่เพิ่มทีละเศษส่วนทุกครั้งที่ ACK มาถึง:

Slow Start

Additive increase เหมาะเมื่อใกล้ capacity จริงแล้ว แต่ช้าเกินไปสำหรับการเริ่มต้น connection ใหม่ (cold start) — TCP จึงใช้ slow start เพิ่ม CongestionWindow แบบ exponential แทน linear

เริ่มจาก CongestionWindow = 1 packet → ได้ ACK แรก เพิ่มเป็น 2 → ส่ง 2 แพ็กเก็ต ได้ 2 ACK เพิ่มเป็น 4 → ผลคือ เพิ่มเป็นสองเท่าทุก RTT

Slow start เกิดขึ้นได้ 2 สถานการณ์: (1) ตอนเริ่ม connection ใหม่ (ยังไม่รู้ capacity) วิ่ง double ไปเรื่อยจนเจอ loss ครั้งแรก แล้ว timeout ทำ multiplicative decrease; (2) เมื่อ connection "ตาย" ระหว่างรอ timeout — sliding window บล็อกเพราะไม่มี ACK ใหม่เข้ามา clock ต่อ พอ timeout เกิดขึ้นจะได้ cumulative ACK เปิด window ทั้งชุด แต่ TCP เลือกใช้ slow start restart การไหลใหม่แทนที่จะทุ่มทั้ง window รวดเดียว

if (cw > CongestionThreshold)
    incr = MSS * MSS / cw;   // additive (linear)
else
    incr = MSS;              // slow start (exponential)
CongestionWindow = MIN(cw + incr, TCP_MAXWIN);

Fast Retransmit และ Fast Recovery

ปัญหาของกลไกเดิม: TCP timeout แบบหยาบ (coarse-grained) ทำให้ connection "ตาย" นานระหว่างรอ timer หมดเวลา — Fast Retransmit แก้ปัญหานี้: ทุกครั้งที่แพ็กเก็ตมาถึงแบบไม่เรียงลำดับ (out of order) receiver จะส่ง ACK ซ้ำของ sequence number ล่าสุดที่ต่อเนื่องได้ เรียกว่า duplicate ACK

เมื่อฝั่งส่งเห็น duplicate ACK 3 ครั้ง (threshold ที่ใช้จริง) จะสรุปว่าแพ็กเก็ตก่อนหน้าน่าจะหาย แล้ว retransmit ทันทีโดยไม่ต้องรอ timeout

4Congestion Avoidance Mechanism

กลยุทธ์ของ TCP ข้างต้นคือ "ควบคุมเมื่อเกิด congestion แล้ว" (congestion control) — TCP จงใจเพิ่ม load ไปเรื่อยๆ จนกว่าจะเจอจุดที่ congestion เกิดขึ้น แล้วค่อยถอยกลับ ทางเลือกอื่นคือ congestion avoidance: ทำนายว่า congestion กำลังจะเกิดขึ้น แล้วลดอัตราส่ง ก่อน ที่แพ็กเก็ตจะเริ่มถูกทิ้งจริง

DECbit

พัฒนาสำหรับ DECnet — router มอนิเตอร์ load ของตัวเอง แล้วแจ้งเตือน end node ล่วงหน้าด้วยการ set บิต congestion หนึ่งบิต ในแพ็กเก็ตที่ผ่าน router นั้น destination จะ copy บิตนี้กลับไปใน ACK ให้ source ปรับอัตราส่ง

Source เก็บสถิติว่ากี่ % ของแพ็กเก็ตใน window ล่าสุดถูก set บิต:

Random Early Detection (RED)

คิดค้นโดย Sally Floyd และ Van Jacobson ต้นทศวรรษ 1990 — ต่างจาก DECbit สองจุดหลัก: (1) RED แจ้ง congestion แบบ implicit ด้วยการ ทิ้งแพ็กเก็ต (ให้ TCP ตรวจจับผ่าน timeout/duplicate ACK เอง) แทนที่จะส่งข้อความแจ้งเตือนตรงๆ; (2) RED ทิ้งแพ็กเก็ต ก่อน buffer จะเต็มจริง (early) เพื่อบอก source ให้ชะลอก่อนที่จะต้องทิ้งจำนวนมากทีหลัง

Source-based Congestion Avoidance

แนวทางอื่น: ให้ source สังเกตสัญญาณจากเครือข่ายเอง เช่น RTT ที่เพิ่มขึ้นเรื่อยๆ บ่งบอกว่าคิวที่ router กำลังก่อตัว

• อัลกอริทึมที่ 1: ทุกๆ 2 RTT ตรวจว่า RTT ปัจจุบันมากกว่าค่าเฉลี่ยของ (RTT ต่ำสุด, RTT สูงสุด) ที่เคยเห็นหรือไม่ ถ้าใช่ ลด CongestionWindow ลง 1/8
• อัลกอริทึมที่ 2: ตัดสินใจจากผลคูณ (CurrentWindow − OldWindow) × (CurrentRTT − OldRTT) — ถ้าผลบวก ลด window ลง 1/8, ถ้าผลลบหรือ 0 เพิ่ม window ขึ้น 1 MSS (window จะแกว่งรอบจุด optimal เสมอ)

5Quality of Service (QoS)

Real-Time Applications และ Playback Buffer

แอปพลิเคชัน real-time (เสียง วิดีโอ ควบคุมหุ่นยนต์อุตสาหกรรม) ต้องการความ "ตรงเวลา" ไม่ใช่แค่ความถูกต้อง — ข้อมูลที่มาถึงหลัง playback time ของมันถือว่าไร้ประโยชน์ ต่างจากแอป non-real-time ที่ใช้ retransmission แก้ปัญหาได้

Taxonomy ของ Real-Time Applications

สองแนวทางหลักของ QoS Support

Integrated Services (RSVP)

Service Classes: Guaranteed Service (การันตี delay สูงสุดที่กำหนดไว้) และ Controlled Load Service (จำลองสภาพเครือข่ายที่ไม่แออัด แม้เครือข่ายจริงจะโหลดหนัก)

กลไกหลัก 4 ส่วน:

1. Flowspec = TSpec (ลักษณะ traffic ที่ flow จะส่ง) + RSpec (บริการที่ขอจากเครือข่าย — สำหรับ controlled load แทบไม่มีพารามิเตอร์ แต่ guaranteed service ต้องระบุ delay target)
2. Admission Control — เครือข่ายตัดสินใจว่าจะรับคำขอ flow ใหม่ได้หรือไม่ โดยดูจาก flowspec เทียบกับทรัพยากรคงเหลือ โดยไม่ทำให้ flow ที่ยอมรับไปแล้วเสียบริการที่เคยรับปาก
3. Resource Reservation — โปรโตคอลแลกเปลี่ยนคำขอบริการ/flowspec/ผลการตัดสินใจ ระหว่าง user กับ router
4. Packet Scheduling — จัดคิว/ส่งแพ็กเก็ตให้ตรงตามที่ตกลงไว้จริง

Reservation Protocol (RSVP) ออกแบบให้คง robustness แบบ connectionless ไว้ด้วยแนวคิด soft state และรองรับ multicast: ผู้ส่งส่ง PATH message พาข้อมูล TSpec ไปหาผู้รับ (router ระหว่างทางจำ reverse path ไว้) ผู้รับตอบกลับด้วย RESV message (มี TSpec + RSpec) ไล่ทวนย้อนขึ้นไปจองทรัพยากรที่ทุก router ตลอดเส้นทาง — ต้องส่ง RESV ซ้ำทุก ~30 วินาทีเพื่อรักษาการจอง (soft state)

Differentiated Services (DiffServ)

แทนที่จะจองทรัพยากรระดับ flow ด้วย RSVP DiffServ แบ่ง traffic เป็น class เล็กๆ (บางระบบมีแค่ 2 class) ระบุด้วยบิตใน header (ไม่ต้องมี state ต่อ flow ที่ทุก router) — คำถามหลักคือใคร set บิต (มักตั้งที่ administrative boundary เช่น router ขอบของ ISP) และ router แต่ละตัวทำอะไรกับแพ็กเก็ตที่มีบิตนี้ — พฤติกรรมมาตรฐานเรียกว่า Per-Hop Behavior (PHB)

6Congestion เป็นวงจร ไม่ใช่เหตุการณ์ Packet หายครั้งเดียว

Congestion เกิดเมื่อข้อมูลพยายามเข้าทรัพยากรหนึ่งเร็วกว่าที่ทรัพยากรนั้นระบายออกได้ต่อเนื่อง ทรัพยากรอาจเป็นลิงก์ขาออก queue ใน router, buffer ของ switch หรือ CPU ของ middlebox Packet loss เป็นเพียงอาการหนึ่ง หลายระบบยังไม่ทิ้ง packet เลย แต่ latency เพิ่มจน application ใช้งานแทบไม่ได้แล้ว

วงจร Feedback ของ Congestion

1. Flow หลายชุดเริ่มส่งพร้อมกันหรือเกิด burst
2. Packet เข้าเร็วกว่าที่ link ส่งออก Queueing delay จึงเพิ่ม
3. Sender เห็น delay, ECN mark หรือ loss หลังเหตุการณ์ผ่านไปแล้วอย่างน้อยหนึ่งช่วง
4. Sender ปรับอัตรา หากลดเร็วพอ queue ยุบ หากตอบสนองช้า retransmission อาจเพิ่มภาระซ้ำ

Sender จึงตัดสินใจจากภาพอดีตเสมอ หากเพิ่มอัตราเร็วเกินไปจะ overshoot แต่ถ้าระแวงเกินไป link จะว่างทั้งที่ยังส่งได้ Congestion control จึงเป็นปัญหา feedback control พอ ๆ กับปัญหา protocol

Throughput กับ Goodput

Throughput นับ bit ทั้งหมดที่ผ่านจุดหนึ่ง ส่วน goodput นับเฉพาะข้อมูลใหม่ที่ application ใช้ได้ หาก packet หายแล้วส่งซ้ำ ลิงก์อาจเต็ม 100% แต่ goodput ต่ำ การบอกว่า “ใช้ bandwidth เต็มแล้ว” จึงไม่เพียงพอ ต้องถามว่าข้อมูลที่มีประโยชน์ถึงปลายทางจริงเท่าใด

Congestion Collapse: ยิ่งส่งมากกลับยิ่งได้น้อย

ถ้า sender ส่งซ้ำโดยไม่ลดอัตรา Packet หลายสำเนาจะแย่ง queue กับข้อมูลใหม่ Router ใช้ทรัพยากรขนข้อมูลที่ปลายทางได้รับแล้วหรือหมดประโยชน์ Offered load เพิ่ม แต่ goodput กลับลด ภาวะนี้คือ congestion collapse เหตุผลเชิงสถาปัตยกรรมของ congestion control จึงไม่ใช่เพียงทำให้ flow ของตนเร็ว แต่รักษาทรัพยากรร่วมไม่ให้พัง

7Queueing Delay, Bufferbloat และ Tail Latency

เวลาของ packet ประกอบด้วย processing, queueing, transmission และ propagation delay ส่วนที่แกว่งแรงเมื่อ congestion มักเป็น queueing delay เมื่อโหลดเข้าใกล้ capacity Queue อาจโตเร็ว แม้อัตราส่งเพิ่มเพียงเล็กน้อย

ต่อให้ packet ไม่หาย การประชุมก็พูดทับกันแล้ว การเพิ่ม buffer จึงแก้ loss แต่ทำลาย latency ได้ อาการ download ไฟล์แล้วเกมหรือการประชุมหน่วง ทั้งที่ speed test ยังได้ความเร็วเต็ม มักเกี่ยวข้องกับ bufferbloat

ค่าเฉลี่ยไม่พอ ต้องดู Percentile

Application แบบ interactive ไวต่อ packet ที่ช้าที่สุดบางส่วน ค่าเฉลี่ย 30 ms อาจดูดี แต่ถ้า 1% ของ packet รอ 1 วินาที ผู้ใช้ยังรู้สึกกระตุก ควรดู median, p95, p99 และ distribution ของ delay ควบคู่กับ throughput เพราะ tail latency มักเป็นตัวกำหนดประสบการณ์จริง

8Active Queue Management และ ECN

Tail Drop รอจน buffer เต็มแล้วทิ้ง packet วิธีนี้ส่งสัญญาณช้าและอาจทำให้ TCP หลาย flow ลดหน้าต่างพร้อมกัน จากนั้นเพิ่มพร้อมกันและชนเพดานพร้อมกันอีก RED จึงเริ่มสุ่ม drop หรือ mark ก่อน buffer เต็ม เพื่อส่ง feedback เร็วขึ้นและลด global synchronization

ECN: แจ้ง Congestion โดยไม่ต้องทิ้ง Packet

Explicit Congestion Notification ให้ router mark packet เมื่อ queue เริ่มแน่น Receiver ส่งสัญญาณกลับให้ sender ลดอัตรา ข้อดีคือไม่ต้องใช้ loss เป็นภาษาหลักของ congestion แต่ endpoint และอุปกรณ์ระหว่างทางต้องรองรับและรักษาความหมายของ bit เหล่านี้

CoDel และ PIE สนใจเวลารอ

Queue 100 packet อาจมากหรือไม่มากขึ้นกับ link speed และ packet size แนวทางสมัยใหม่จึงประเมิน delay ที่ packet พบ CoDel ตรวจเวลาที่ packet อยู่ใน queue ส่วน PIE ปรับ probability เพื่อรักษา delay ใกล้เป้าหมาย อย่างไรก็ตาม AQM ไม่ได้สร้าง bandwidth หาก demand สูงกว่า capacity ตลอดเวลา สุดท้ายยังต้องลด demand เพิ่ม capacity หรือกำหนดว่าใครควรรอ

9Scheduling: ใครได้ส่งก่อน

Fairness ไม่มีนิยามเดียว Equal packet, equal byte, equal rate และ weighted share ให้ผลต่างกัน เสียงใช้ bandwidth น้อยแต่ต้องการ latency ต่ำ ส่วน backup ต้องการ throughput แต่รอได้ Scheduler ต้องเริ่มจาก objective ไม่ใช่เริ่มจากชื่อ algorithm

10Policing กับ Shaping

Policing ตรวจ traffic ที่เกินข้อตกลงแล้ว drop หรือ remark ส่วนเกินทันที ส่วน shaping หน่วง packet เพื่อทำให้อัตราส่งเรียบขึ้น Policing เหมือนยามปฏิเสธคนเกินโควตา Shaping เหมือนจัดแถวให้เข้าอาคารตามจังหวะ ทั้งสองใช้ token bucket อธิบาย burst และอัตราเฉลี่ยได้

11QoS จากมุมของ Application

QoS เป็นชุดเป้าหมาย เช่น bandwidth ขั้นต่ำ latency สูงสุด jitter, loss และ availability งานแต่ละชนิดต้องการคนละรูปแบบ File transfer สนใจ goodput กับความครบถ้วน การประชุมสนใจ latency กับ jitter ส่วนระบบควบคุมอาจต้องการ deadline และความน่าเชื่อถือพร้อมกัน

Jitter Buffer แลกความเรียบกับความหน่วง

Receiver เก็บ packet เสียงไว้ชั่วคราวแล้วเล่นตามเวลา Buffer ใหญ่ลดโอกาสเสียงขาดเพราะ packet มาช้า แต่เพิ่ม end-to-end delay แบบ adaptive จึงปรับขนาดตาม jitter ที่วัดได้ หากเครือข่ายนิ่งก็ลด หากแกว่งก็เพิ่ม โดยต้องไม่ทำให้เสียงกระโดด

Adaptive Bitrate คือ Application ช่วยทำ QoS

วิดีโอเลือก segment หลายระดับคุณภาพตาม throughput และ buffer หาก bandwidth ลดอาจลด bitrate หรือ resolution แทนการหยุดเล่น งานประชุมอาจลด frame rate เลือก simulcast layer หรือรักษาเสียงไว้ก่อนภาพ เพราะเสียงขาดทำให้บทสนทนาเสียมากกว่าภาพไม่คมชั่วคราว

DSCP ไม่ได้เป็นบัตรผ่านด่วนทั่วโลก

DiffServ มีผลเมื่อ domain บนเส้นทางมี policy รองรับ ผู้ให้บริการหนึ่งอาจ remap หรือล้างค่า และลิงก์ปลายทางอาจยังเป็นคอขวด การ mark EF จึงไม่ทำให้ Internet ทั้งโลกให้ latency แบบรับประกันโดยอัตโนมัติ QoS ต้องมี provisioning, admission และ policy รองรับ

12กรณีศึกษา: ประชุมออนไลน์ระหว่าง Backup

1. Backup เปิด TCP หลาย flow จน uplink เต็ม
2. Router มี buffer ใหญ่ Queueing delay เพิ่มจาก 20 ms เป็น 800 ms แม้ packet ยังไม่หายมาก
3. เสียงประชุมมาช้า ผู้ใช้พูดทับกัน วิดีโอลด bitrate แต่ latency ยังสูง
4. แนวทางหนึ่งคือ shape อัตรารวมต่ำกว่า bottleneck เล็กน้อย ใช้ fair queue/AQM แยก flow และให้ traffic real-time มี latency ต่ำภายในโควตา

ถ้า demand เฉลี่ยสูงกว่า capacity จริงตลอดเวลา การจัดคิวทำได้เพียงเลือกว่าจะให้ใครรอ ไม่สามารถให้ทุกคนได้มากกว่าทรัพยากรที่มี นี่คือขอบเขตที่ QoS มักถูกคาดหวังเกินจริง

13การวัดผลและวินิจฉัย

ถ้าดูแต่ utilization เราอาจเห็น 100% ทั้งที่ครึ่งหนึ่งเป็น retransmission หากดูแต่ loss เราอาจไม่พบ bufferbloat เพราะ queue ใหญ่จนยังไม่ทิ้ง packet การวินิจฉัยที่ดีต้องเชื่อม metric กับกลไกและประสบการณ์ของผู้ใช้

14Worked Example: AIMD แบ่งลิงก์ร่วมกันอย่างไร

สมมุติ Flow A และ B ใช้ bottleneck 20 Mbps ร่วมกัน เริ่มต้นที่ 2 และ 8 Mbps ตามลำดับ หากทั้งคู่เพิ่มแบบ additive รอบละ 1 Mbps จะได้ (3,9), (4,10), (5,11) จนผลรวมเกิน 20 Mbps เมื่อพบ congestion แล้วลดครึ่งแบบ multiplicative จะได้ประมาณ (2.5,5.5) จากนั้นค่อยเพิ่มเท่ากันอีกครั้ง

การเพิ่มเท่ากันทำให้ส่วนต่างของอัตราเดิมยังอยู่ แต่การลดเป็นสัดส่วนทำให้ flow ที่ส่งมากเสียอัตรามากกว่า เมื่อเกิดซ้ำ จุดทำงานจึงค่อย ๆ เข้าใกล้เส้น fairness และแกว่งรอบ capacity หากใช้ additive decrease Flow ใหญ่อาจยังครอบครองส่วนแบ่งมาก หากใช้ multiplicative increase ระบบอาจพุ่งชน capacity รุนแรงเกินไป AIMD จึงเป็นคู่กลไกที่ได้ทั้ง efficiency และแนวโน้มเข้าสู่ fairness ภายใต้สมมุติฐานที่เหมาะสม

อย่างไรก็ตาม RTT ต่างกันทำให้ TCP fairness ไม่สมบูรณ์ Flow RTT สั้นได้รับ ACK เร็วและเพิ่มหน้าต่างบ่อยกว่า Flow RTT ยาว นอกจากนี้ flow ที่เปิดหลาย connection อาจได้ส่วนแบ่งมากกว่าผู้ใช้ที่เปิด connection เดียว ความเป็นธรรมของ algorithm จึงขึ้นกับคำจำกัดความของหน่วยที่แบ่ง: ต่อ flow, ต่อ user, ต่อ host หรือ ต่อ service

Jain's Fairness Index

ค่าใกล้ 1 หมายถึงแบ่งค่อนข้างเท่า หากมี flow สองรายได้ 10 Mbps เท่ากัน ค่าเป็น 1 แต่ถ้าได้ 19 กับ 1 Mbps ค่าเหลือประมาณ 0.55 ตัวเลขนี้บอกความเท่า ไม่ได้บอกว่าการแบ่งนั้นตรงกับ business priority หรือไม่ ถ้าเสียงกับ backup มีน้ำหนักต่างกัน เราอาจต้องใช้ weighted fairness แทน equality

15Little's Law ช่วยอ่าน Queue ได้อย่างไร

ถ้าลิงก์ส่งได้ 5,000 packet ต่อวินาทีและ packet อยู่ใน queue เฉลี่ย 20 ms จำนวน packet เฉลี่ยใน queue ใกล้ 100 ก้อน หากวัดได้ 1,000 packet ภายใต้อัตราเดิม เวลาเฉลี่ยจะใกล้ 200 ms ความสัมพันธ์นี้ช่วยแปลง queue occupancy ให้เป็นประสบการณ์ด้านเวลา

Little's Law ไม่บอก distribution และไม่รับรองว่า arrival เป็น Poisson มันเป็นความสัมพันธ์เฉลี่ยภายใต้ระบบที่เสถียร แต่ถ้าระบบรับงานเร็วกว่าระบายในระยะยาว Queue จะโตไม่หยุดและค่าเฉลี่ยไม่มี steady state การใช้สูตรกับช่วง congestion collapse จึงต้องระวัง

Bandwidth-Delay Product กับขนาด Buffer

Bandwidth-delay product (BDP) คือข้อมูลที่สามารถอยู่ระหว่างทางได้ หากเส้นทาง 100 Mbps มี RTT 40 ms จะมีข้อมูลราว 4 Mb หรือ 500 KB อยู่ใน flight เพื่อใช้ลิงก์เต็ม Sender window ต้องใหญ่พอ แต่การนำ BDP ไปตั้ง buffer แบบตายตัวโดยไม่ดูจำนวน flow และ AQM อาจสร้าง bufferbloat

16TCP Variant และความหมายของสัญญาณ

TCP แบบ loss-based เช่น Reno หรือ CUBIC เพิ่มอัตราจนพบ loss แล้วลดลง CUBIC ใช้ฟังก์ชันทรง cubic เพื่อเติบโตเหมาะกับลิงก์ bandwidth สูงและ RTT ยาวกว่า Reno ส่วน delay-based approach พยายามเห็น queue จาก RTT ที่เพิ่มก่อน loss แต่ต้องแยกให้ได้ว่า RTT เพิ่มจาก congestion หรือเส้นทางเปลี่ยน

BBR: สร้างแบบจำลอง Bandwidth กับ RTT

BBR พยายามประเมิน bottleneck bandwidth และ minimum RTT เพื่อส่งใกล้จุดที่ใช้ลิงก์เต็มโดยไม่ต้องสร้าง queue ใหญ่ตลอดเวลา มันไม่ได้รอ loss เป็นสัญญาณหลัก แต่ model อาจประเมินผิด แข่งขันกับ loss-based flow ซับซ้อน และแต่ละรุ่นมีพฤติกรรมต่างกัน ไม่มี congestion control ตัวเดียวดีที่สุดกับทุก topology, queue และ workload

Loss บน Wireless ไม่ได้หมายถึง Congestion เสมอ

TCP ดั้งเดิมมักตีความ packet loss เป็น congestion แล้วลดอัตรา แต่ wireless loss อาจมาจากสัญญาณรบกวนหรือการเคลื่อนที่ Link-layer retransmission ช่วยซ่อน loss บางส่วน แต่เพิ่ม delay และ jitter หากซ่อนมากเกินไป TCP อาจไม่รู้ว่า link คุณภาพตกจน queue สะสมอยู่ข้างล่าง Cross-layer information ช่วยได้ แต่ทำให้ abstraction ซับซ้อนขึ้น

ACK Compression และ Reverse Path

Data path อาจว่าง แต่ ACK path แออัด ACK ที่ควรมาสม่ำเสมออาจถูกรวมเป็น burst ทำให้ sender ปล่อย data burst ตามมา Congestion analysis จึงต้องดูสองทิศทาง ไม่ควรตรวจเพียงลิงก์ที่ส่ง payload มาก การ upload เต็มในบ้านสามารถทำให้ download และการประชุมหน่วงผ่าน ACK queue ได้

17รูปแบบ Traffic ที่ทำให้ระบบล้มคนละแบบ

Elephant Flow กับ Mice Flow

Elephant flow ส่งข้อมูลมากและอยู่นาน เช่น backup หรือ replication ส่วน mice flow สั้น เช่น API request หรือ DNS query Elephant ต้องการ throughput และ fairness ระยะยาว Mice ต้องการ completion time ต่ำ หากใช้ FIFO ร่วมกัน mice อาจติดหลัง burst ใหญ่ แม้ใช้ bandwidth นิดเดียว Fair queue แยกผลกระทบได้ดีกว่า

Incast

Incast เกิดเมื่อ worker จำนวนมากตอบกลับ aggregator พร้อมกัน ลิงก์สุดท้ายและ buffer ที่ receiver รับ burst ไม่ทัน Packet หลาย flow หายพร้อมกันและ timeout ทำให้ job ทั้งชุดรอ tail flow การเพิ่ม bandwidth เฉลี่ยอาจไม่แก้ เพราะปัญหาเกิดจาก synchronization ของ burst แนวทางแก้มีทั้ง pacing, จำกัด concurrency, ECN/AQM และกระจายเวลาตอบ

Microburst

Traffic เฉลี่ยหนึ่งวินาทีอาจต่ำ แต่ packet จำนวนมากมาถึงภายในไม่กี่ไมโครวินาทีจน buffer switch เต็ม Monitoring ที่ sample ห่างเกินไปเห็น utilization เพียง 40% และสรุปว่าไม่ congestion ทั้งที่ packet loss เกิดเป็นช่วงสั้น การวัดต้องมี resolution ตรงกับเวลาของปัญหา

Many-to-One และ Fan-In

ระบบ distributed มักให้ service หลายตัวส่งผลกลับ coordinator พร้อมกัน Bottleneck จึงไม่ได้อยู่ที่ source เดียว แต่รวมตัวใกล้ปลายทาง การกำหนด rate limit แยกแต่ละ sender อาจยังทำให้ผลรวมเกิน capacity ต้องมี admission หรือ coordination ในระดับงานด้วย

18QoS Design Playbook

1. จำแนกงาน: แยก interactive, streaming, transactional และ bulk ไม่ใช้ชื่อแผนกเป็น traffic class โดยอัตโนมัติ
2. วัด baseline: หา bottleneck, utilization, delay distribution, loss และ burst ก่อนเปลี่ยน policy
3. กำหนด objective: เช่นเสียง p99 one-way delay, API completion time หรือ backup deadline
4. ควบคุมทางเข้า: ใช้ admission, rate limit, policing หรือ shaping ไม่ให้ priority class รับงานเกิน capacity
5. เลือก scheduler/AQM: ให้ตรงกับ fairness และ latency ที่ต้องการ
6. ทดสอบ overload: Policy ที่ดูดีตอนโหลด 30% อาจพังเมื่อ 110%
7. ตรวจ end-to-end: DSCP และ queue หนึ่งจุดไม่พอถ้า bottleneck อยู่ที่อีก domain

อย่าสร้าง Priority Class มากเกินไป

Class จำนวนมากดูละเอียด แต่เพิ่มโอกาส mark ผิด policy ขัดกัน และวินิจฉัยยาก หลายระบบใช้เพียงไม่กี่ class ที่มีพฤติกรรมชัด เช่น network control, real-time, transactional และ best-effort/bulk ความชัดของ contract สำคัญกว่าจำนวนสีใน dashboard

Admission Control คือการกล้าปฏิเสธ

ถ้ารับ video call ใหม่ทุกสายทั้งที่ capacity ไม่พอ สุดท้ายทุกสายเสียคุณภาพ Admission control ปฏิเสธหรือ downgrade งานใหม่เพื่อรักษาสัญญาของงานเดิม แนวคิดนี้ขัดกับความรู้สึกว่า availability คือรับทุก request แต่บางครั้งปฏิเสธ 5% อย่างชัดเจนดีกว่ารับ 100% แล้วใช้งานไม่ได้ทั้งหมด

19แบบฝึกวิเคราะห์สถานการณ์

20TCP Pacing และ Burst Control

แม้ congestion window อนุญาตให้มีข้อมูลจำนวนหนึ่งอยู่ระหว่างทาง ไม่ได้แปลว่าควรปล่อยทั้งหมดติดกันทันที Pacing กระจาย packet ตามเวลาเพื่อลด burst ที่ทำให้ queue เต็มชั่วขณะ โดยเฉพาะหลัง ACK จำนวนมากมาถึงพร้อมกันหรือ application เขียนข้อมูลก้อนใหญ่

Pacing rate ต้องสัมพันธ์กับ estimated bandwidth และ congestion state หากช้าเกินไปใช้ลิงก์ไม่เต็ม หากเร็วเกินไปก็กลับเป็น burst เพียงแต่ย้ายตำแหน่งที่เกิด การใช้ pacing ร่วมกับ fair queue และ AQM มักให้ผลดีกว่าหวังให้กลไกใดกลไกหนึ่งแก้ทุกอย่าง

Application-Level Backpressure

Network congestion control คุม byte บนเส้นทาง แต่ queue อาจก่อตัวก่อนถึง socket เช่น task queue, message broker หรือ thread pool หาก producer สร้างงานเร็วกว่าที่ consumer ประมวลผล การเพิ่ม network buffer เพียงย้ายกองงานไปอีกจุด ระบบต้องส่ง backpressure กลับถึง producer ลด concurrency หรือปฏิเสธงานใหม่

21Retry Storm และ Self-Inflicted Congestion

เมื่อ request timeout Client มัก retry แต่หาก timeout เกิดเพราะ server หรือ network แออัด Retry จะเพิ่มโหลดในช่วงที่ระบบอ่อนแอที่สุด หากหลาย client ใช้ timeout และ backoff เท่ากัน ทุกคนอาจ retry พร้อมกันเป็นคลื่น เรียกว่า thundering herd

Retry เป็น reliability mechanism ระดับ application แต่สร้าง congestion ได้ จึงเป็นตัวอย่างว่าการแก้ปัญหาหนึ่งชั้นโดยไม่เห็นทั้งระบบอาจทำให้อีกชั้นพัง การเพิ่ม timeout ให้ยาวอย่างเดียวก็อาจทำให้ queue งานเก่าค้างและใช้ทรัพยากรนานขึ้น ต้องกำหนด deadline จากมุมผู้ใช้แล้วแบ่ง budget ให้แต่ละ hop

22Datacenter Congestion: Latency สั้นแต่ Burst ใหญ่

ใน datacenter RTT ต่ำและลิงก์เร็ว แต่ server จำนวนมากส่งพร้อมกันได้ ทำให้ microburst และ incast รุนแรง Buffer switch อาจมีเวลารองรับเพียงไม่กี่ไมโครวินาที Workload แบบ RPC ต้องการ tail latency ต่ำ ขณะที่ storage replication ส่ง flow ใหญ่บน fabric เดียวกัน

ECN และ DCTCP

DCTCP ใช้สัดส่วน packet ที่ได้รับ ECN mark ประเมินระดับ congestion แล้วลด window ตามความรุนแรง ไม่ได้ลดครึ่งทุกครั้งเหมือนการตอบ loss แบบหยาบ เมื่อ switch mark ก่อน queue โต ระบบรักษา queue ต่ำและ throughput สูงได้ใน environment ที่ตั้ง threshold กับ endpoint สอดคล้องกัน

Priority Flow Control: หยุด Loss แต่เสี่ยงกระจายการหยุด

PFC สามารถ pause traffic บาง priority บน Ethernet เพื่อลด loss แต่ pause อาจลามย้อนกลับและสร้าง head-of-line blocking หรือ deadlock หากออกแบบไม่ดี Lossless fabric จึงไม่ได้แปลว่าไม่มี failure mode เพียงเปลี่ยน failure จาก packet loss ไปเป็นการหยุดและ queue propagation

23Cellular และ Shared Wireless Capacity

Wireless capacity เปลี่ยนตามสัญญาณ การรบกวน จำนวนผู้ใช้ และ scheduler ของสถานีฐาน อัตราที่ application เห็นจึงแกว่งมากกว่าลิงก์สาย การตั้ง bitrate จากค่าเฉลี่ยยาวอาจตามไม่ทันเมื่อผู้ใช้เคลื่อนที่ ส่วนการตอบสนองเร็วเกินไปทำให้คุณภาพวิดีโอขึ้นลงตลอด

Buffer อาจอยู่หลายจุดทั้งอุปกรณ์ สถานีฐาน และ core network Packet loss ต่ำไม่ได้แปลว่า radio link ดี เพราะ link-layer retransmission ซ่อน loss ด้วย delay เพิ่ม QoE monitoring จึงต้องดู radio metric, RTT, jitter, retransmission และ application buffer ร่วมกัน

24QoS ใน Wi-Fi

Wi-Fi ใช้สื่อร่วมและหลีกเลี่ยง collision แต่ละสถานีแข่งขันขอเวลาออกอากาศ การแบ่ง throughput เท่ากันไม่เท่ากับแบ่ง airtime เท่ากัน Station ที่ modulation ต่ำใช้เวลานานเพื่อส่ง byte เท่ากันและลด capacity ที่เหลือ ระบบจึงอาจใช้ airtime fairness มากกว่า throughput fairness

802.11e/WMM

WMM แบ่ง access category เช่น voice, video, best effort และ background โดยปรับ contention parameter ให้ traffic สำคัญมีโอกาสเข้าถึงสื่อเร็วกว่า แต่ถ้า mark ทุกอย่างเป็น voice การแข่งขันกลับมาเหมือนเดิมและ background อาจอด QoS บน Wi-Fi ต้องควบคุมทั้ง marking และ admission ไม่ต่างจากเครือข่ายสาย

25QoS กับ Encryption และ Tunnel

เมื่อ traffic ถูกเข้ารหัส อุปกรณ์กลางมอง application ภายในได้น้อยลง อาจยังเห็น outer header, DSCP, endpoint และรูปแบบ traffic แต่ deep packet inspection ใช้ไม่ได้เหมือนเดิม Tunnel ยังรวบหลาย flow ไว้ใน outer flow เดียว ทำให้ fair queue ภายนอกแยกผู้ใช้ข้างในไม่ได้

นโยบายจึงควร classify ที่ trusted edge ก่อนเข้ารหัส แล้ว copy หรือกำหนดค่า DSCP ของ outer header ตามกติกา โดยระวังไม่ให้ผู้ใช้ mark priority เองอย่างไร้ขอบเขต หาก tunnel provider ไม่รักษา marking การรับประกันภายในก็สิ้นสุดที่ tunnel edge

26Admission Control เชิงตัวเลข

สมมุติลิงก์ 100 Mbps กันไว้สำหรับเสียง 20 Mbps แต่ละ call ใช้ codec payload 64 kbps เมื่อรวม RTP/UDP/IP, link overhead และ safety margin อาจคิด 100 kbps ต่อ call ดังนั้นรับได้เชิงทฤษฎี 200 call แต่ถ้าต้องรักษา headroom 20% จะรับเพียง 160 call โดยประมาณ

การใช้ average bitrate อาจรับ call มากเกินไปหากทุก call burst พร้อมกัน TSpec และ token bucket จึงอธิบายทั้ง rate กับ burst Admission control ต้องคิด failure ด้วย หากลิงก์หนึ่งล้มแล้ว traffic ย้ายมาอีกลิงก์ capacity หลัง failure ยังพอหรือไม่ การรับเต็ม 100% ในภาวะปกติอาจไม่มีพื้นที่ให้ redundancy ทำงาน

27End-to-End Delay Budget

การตั้งเป้า “latency ต่ำ” ควรแตกเป็น budget เช่น capture/encode 20 ms, network 50 ms, jitter buffer 40 ms และ decode/playout 20 ms หาก network ใช้เกิน budget Application ต้องลดส่วนอื่นหรือยอมผิดเป้า การวัดเฉพาะ ping ไม่รวม codec และ buffer จึงอธิบายประสบการณ์ประชุมไม่ได้ทั้งหมด

28QoE Metric สำหรับ Multimedia

วิดีโอไม่ควรวัดเพียง bitrate เพราะ bitrate สูงแต่หยุดบ่อยให้ประสบการณ์แย่ ตัวเลขสำคัญได้แก่ startup delay, rebuffer ratio, quality switch, dropped frame และ live latency งานเสียงดู concealment, late loss, jitter buffer, echo และช่วงเงียบผิดปกติ

Metric ต้องสัมพันธ์กับเนื้อหา Screen sharing ต้องรักษาตัวอักษรคมและอาจยอม frame rate ต่ำ กล้องผู้พูดต้องการ motion ต่อเนื่องกว่า ระบบจึงเลือก allocation ระหว่าง track ตามบทบาท ไม่ใช่แบ่ง bandwidth เท่ากันทุก stream

29Network Neutrality กับ QoS

QoS ทางวิศวกรรมแยก traffic ตาม requirement เช่น voice latency ต่ำ แต่การให้สิทธิ์ตามผู้ให้บริการหรือคู่ค้าสร้างคำถามเรื่องความเป็นธรรมและการแข่งขัน กลไกเดียวกันสามารถรักษาคุณภาพบริการฉุกเฉินหรือใช้กีดกันคู่แข่งได้ การออกแบบ policy จึงมีทั้งมิติเทคนิค กฎหมาย และธรรมาภิบาล

การอธิบายว่า priority “ดีกว่า” ต้องตอบว่าใครตั้ง ใครตรวจ ใครเสียสิทธิ์ และผู้ใช้มองเห็นหรือโต้แย้งได้หรือไม่ Technical mechanism ไม่ตัดสินคุณค่าทางสังคมแทนเรา แต่ทำให้ผลของนโยบายเกิดขึ้นจริง

30Lab: สร้าง Congestion แล้วสังเกต

Lab ที่ดีต้องคุมตัวแปรทีละอย่าง หากเปลี่ยน capacity, queue และจำนวน flow พร้อมกัน เราไม่รู้ว่าอะไรทำให้ผลดีขึ้น ควรเก็บ configuration, เวลา และ workload เพื่อทำซ้ำได้ และไม่ใช้ speed test ครั้งเดียวแทนการทดลอง

31Anti-Patterns ที่พบบ่อย

32Congestion Control กับ Control Theory

Sender เป็น controller เครือข่ายเป็น plant ส่วน ACK, delay, ECN และ loss เป็น feedback เป้าหมายคือรักษา operating point ที่ใช้ capacity สูงแต่ queue ไม่โต การเพิ่ม congestion window คือการเร่ง input ส่วนการลดคือการตอบความคลาดเคลื่อน แต่ feedback มี delay และ noise จึงเกิด oscillation ได้ง่าย

Stability

ระบบ stable เมื่อ disturbance แล้วกลับมาใกล้จุดทำงาน ไม่ใช่แกว่งแรงขึ้นเรื่อย ๆ Gain สูงตอบเร็วแต่ overshoot มาก Gain ต่ำเรียบแต่ใช้ capacity ช้า RTT ที่ต่างกันทำให้ loop delay ต่างกัน Parameter เดียวจึงไม่ให้พฤติกรรมเหมือนกันทุกเส้นทาง

Observability

Sender มองไม่เห็น queue ทุก router โดยตรง จึงอนุมานจาก RTT, delivery rate และ loss สัญญาณเดียวมีหลายสาเหตุ RTT เพิ่มอาจมาจาก route ใหม่ Loss อาจมาจาก wireless error Delivery rate ลดอาจมาจาก receiver จำกัด ระบบจึงต้องสร้าง estimator และยอมรับ uncertainty ไม่ใช่ถือ metric หนึ่งเป็นความจริงทั้งหมด

33Network Calculus แบบเข้าใจแนวคิด

Token bucket กำหนด upper bound ของข้อมูลที่ flow ส่งในช่วงเวลา t ได้ใกล้เคียง r·t + B โดย r เป็นอัตราระยะยาวและ B เป็น burst หาก server ให้ service rate R ที่มากกว่า r เราสามารถประมาณ backlog กับ delay bound ภายใต้สมมุติฐานที่กำหนด แนวคิดนี้เป็นฐานของ guaranteed service แม้ระบบจริงต้องรวมหลาย hop และ scheduler

สมการไม่ได้บอกว่า flow ส่งคงที่ r แต่บอกว่าในช่วงใดก็ตามส่งเกินเส้น envelope ไม่ได้ Burst B อนุญาตให้พัก token แล้วส่งเร็วชั่วคราว หากหลาย flow ที่มี burst ใหญ่ synchronize กัน aggregate queue ยังสูงได้ Admission control จึงรวม worst-case หรือใช้ statistical multiplexing ตามระดับ guarantee ที่ยอมรับ

34Statistical Multiplexing

ถ้าจอง peak rate ให้ทุก flow ผลรวมอาจใช้ทรัพยากรต่ำ เพราะผู้ใช้ไม่ได้ peak พร้อมกัน Statistical multiplexing รับ flow มากขึ้นจาก distribution ของ demand แต่มีโอกาส overload QoS แบบ guarantee ต้อง conservative ส่วนบริการ best-effort ใช้ประโยชน์จากค่าเฉลี่ยได้มากกว่า

35Multi-Bottleneck และ Parking-Lot Topology

Flow บางชุดผ่าน bottleneck หนึ่ง ส่วน flow ยาวผ่านหลาย bottleneck ใน topology แบบ parking lot Flow ที่เดินไกลอาจแข่งขันซ้ำหลายจุดและได้ throughput ต่ำกว่าความคาดหมาย Fairness ต่อ link ไม่จำเป็นต้องให้ fairness end-to-end แบบที่ผู้ใช้รู้สึก

การเพิ่ม capacity จุดหนึ่งอาจย้าย bottleneck ไปจุดถัดไป Queue เดิมยุบแต่ queue ใหม่โต การวิเคราะห์ต้องตาม path ของ flow และ matrix ของ traffic ไม่ใช่ดู utilization ของอุปกรณ์ที่ร้องเรียนเพียงตัวเดียว

36Application Deadline และ Cancellation

Request ที่หมด deadline แล้วอาจยังวิ่งและใช้ CPU/Network ต่อ หาก caller timeout แต่ไม่ cancel งาน downstream ระบบจะทำงานที่ไม่มีใครรอผล เกิด zombie work ระหว่าง overload Deadline ควรถูกส่งต่อและ service ตรวจเป็นระยะว่าเหลือเวลาพอทำงานหรือไม่

Timeout แต่ละ hop ที่ตั้งแยกโดยไม่เห็น end-to-end budget อาจรวมกันยาวเกิน SLA หรือสั้นจน retry ทั้งที่ปลายทางใกล้เสร็จ Context propagation จึงเป็น QoS ของ distributed application แม้ไม่ได้อยู่ใน router

37Load Balancing กับ Congestion

ECMP กระจาย flow ตาม hash เพื่อไม่ให้ packet ใน flow สลับลำดับ แต่ elephant flow หลายชุดอาจ hash ไป link เดียวโดยบังเอิญ ขณะที่ link อื่นว่าง Flowlet switching ใช้ช่องว่างระหว่าง burst เป็นจุดย้ายทางเพื่อลด reorder ส่วน adaptive routing ใช้ congestion signal แต่ต้องระวัง oscillation เมื่อทุกคนย้ายหนีเส้นเดียวกันพร้อมกัน

Load Balancer ระดับ Application

Round robin แจก request เท่ากันแต่ server อาจมีกำลังหรือ request cost ต่างกัน Least connections ดีขึ้นบางกรณีแต่ connection ยาวไม่เท่ากับงานหนักเสมอ Queue-aware balancing ใช้ load ปัจจุบันแต่ metric มี delay หาก scale out ช้า request ยังสะสมก่อน instance ใหม่พร้อม

38Cost, Energy และ QoS

การเพิ่ม headroom ลด congestion แต่เพิ่มต้นทุนและพลังงาน การ consolidate traffic ประหยัดอุปกรณ์แต่ failure หรือ burst กระทบมากขึ้น Cloud autoscaling เพิ่ม capacity ได้แต่ใช้เวลาและมีค่าใช้จ่าย การเลือก utilization target จึงเป็น economic decision ร่วมกับ reliability target

39SLA, SLO และ Error Budget

SLA เป็นข้อตกลงกับผู้ใช้หรือธุรกิจ SLO เป็นเป้าหมายภายใน ส่วน SLI เป็นสิ่งที่วัด เช่น p99 latency หรือ success rate Error budget คือส่วนที่ยอมผิดเป้าได้ QoS policy ควรเชื่อมกับ SLI มิฉะนั้นทีม network อาจ optimize packet loss ทั้งที่ผู้ใช้ติด application queue

การรับประกันค่าเฉลี่ยรายเดือนอาจซ่อน outage 30 นาทีที่รุนแรง ควรกำหนด window และ percentile ให้ตรงกับผลกระทบ เช่น voice loss ต่อช่วงสั้นหรือ API availability ต่อ request การเขียน SLO ที่วัดไม่ได้เป็นเพียงความปรารถนา ไม่ใช่ข้อกำหนดทางวิศวกรรม

40Capacity Planning

1. เก็บ demand ตามเวลา แยก baseline, trend, seasonality และ event
2. แยก average จาก peak และ burst ใน resolution ที่เหมาะ
3. คาด growth พร้อม confidence range ไม่ใช้ตัวเลขเดียว
4. เผื่อ failure scenario เช่นลิงก์เหลือครึ่งหนึ่งหลัง failover
5. กำหนด lead time ของการเพิ่มวงจรหรือ instance
6. ทดสอบ policy เมื่อ demand เกิน forecast

การวาง capacity จาก peak ที่เคยเห็นสูงสุดอย่างเดียวอาจแพงเกินหรือยังไม่พอสำหรับเหตุการณ์ใหม่ ควรเข้าใจ driver เช่นผู้ใช้พร้อมกัน ขนาด object จำนวน camera track หรือ fan-out แล้วสร้าง model ที่อธิบายเหตุผลของ demand

41คำถามตรวจความเข้าใจเชิงระบบ

42Glossary ที่ต้องแยกความหมาย

43จาก Metric ไปสู่การตัดสินใจ

RTT สูงแต่ queue ต่ำอาจมาจากระยะทางหรือ route อ้อม การเพิ่ม AQM ไม่ช่วย Loss สูงพร้อม RSSI ต่ำชี้ไปที่ wireless link มากกว่า core congestion Goodput ต่ำพร้อม retransmission สูงอาจเป็น loss ส่วน goodput ต่ำแต่ loss ต่ำและ receiver window เล็กอาจเป็น receiver bottleneck Metric ต้องถูกตีความเป็น pattern ไม่ใช่ threshold เดี่ยว

44การสื่อสารผลวิเคราะห์

รายงานว่า “Network ช้า” แก้ต่อไม่ได้ ควรระบุช่วงเวลา flow เส้นทาง metric และเงื่อนไข เช่น “เมื่อ uplink เกิน 90 Mbps ค่า RTT p95 จาก client ถึง gateway เพิ่มจาก 8 เป็น 420 ms โดย loss ต่ำกว่า 0.1%” ข้อความนี้ชี้ว่า queueing เป็นผู้ต้องสงสัยและทำซ้ำการทดลองได้

ควรแยกข้อเท็จจริง สมมุติฐาน และการทดลองถัดไป ข้อเท็จจริงคือ queue delay เพิ่ม สมมุติฐานคือ bufferbloat การทดลองคือใช้ shaping/AQM แล้วทำ workload เดิม หากผลไม่เปลี่ยนต้องยอมทิ้งสมมุติฐาน ไม่ใช่ปรับเรื่องเล่าให้ metric ตรงกับคำตอบเดิม

45Decision Table เลือกกลไกให้ตรงอาการ

ตารางนี้เป็นจุดเริ่ม ไม่ใช่สูตรสำเร็จ กลไกหนึ่งอาจแก้อาการแล้วสร้างผลข้างเคียง เช่น shaping ลด queue ใน modem แต่ตั้งต่ำเกินไปทำให้เสีย capacity Priority ลด latency ของเสียงแต่ไม่มี policing แล้วงานอื่นอด การเปลี่ยนทุกครั้งจึงต้องมี hypothesis, baseline และ rollback

46สรุปและขั้นตอนถัดไป

เมื่อวิเคราะห์ปัญหา อย่าเริ่มจากเลือกคำตอบว่าเพิ่ม bandwidth, เพิ่ม buffer หรือให้ priority ก่อนเห็นหลักฐาน ควรเริ่มจากหาว่า demand เข้าที่ไหน ระบายออกได้เท่าใด queue อยู่ตรงไหน feedback กลับช้าเพียงใด และ application มี deadline แบบใด จากนั้นจึงเลือกกลไกที่แก้คอขวดจริง พร้อมวัดผลกระทบต่อ flow อื่นด้วย

เป้าหมายสุดท้ายไม่ใช่ทำให้กราฟทุกเส้นสวย แต่ทำให้ระบบใช้ทรัพยากรได้คุ้มโดยยังรักษางานที่ผู้ใช้ต้องทำให้สำเร็จ

และต้องทำซ้ำได้เมื่อสภาพเครือข่ายเปลี่ยนไป