QoS Network: จัดลำดับ Traffic ให้ Voice และ Video ไม่สะดุด
เมื่อ bandwidth มีจำกัด traffic ทุกประเภทต้องแย่งกันใช้ ถ้าไม่มีการจัดลำดับ file download ขนาดใหญ่อาจกิน bandwidth จนหมด ทำให้ voice call กระตุก video conference ภาพแตก QoS (Quality of Service) เป็นเทคนิคที่จัดลำดับความสำคัญของ traffic ให้ applications ที่ sensitive ต่อ delay อย่าง voice และ video ได้ bandwidth และ priority ก่อน
สำหรับองค์กรที่ใช้ IP Phone, Microsoft Teams, Zoom หรือ video surveillance QoS ไม่ใช่ option แต่เป็น requirement ถ้าไม่มี QoS ผู้ใช้จะ complain เรื่อง call quality ตลอดเวลา บทความนี้จะอธิบายหลักการ QoS, วิธี classify และ mark traffic, queuing mechanisms และวิธี implement บน network จริง
ทำไม Voice และ Video ต้องการ QoS
Voice และ video เป็น real-time traffic ที่ sensitive ต่อ 3 ปัจจัย
Latency (Delay)
Latency คือ delay จากต้นทางถึงปลายทาง Voice ต้องการ one-way latency ไม่เกิน 150 ms ถ้าเกินจะเริ่มรู้สึกได้ว่า “delay” เกิน 300 ms จะคุยกันลำบากมาก Video conference ต้องการ latency ไม่เกิน 200 ms
Jitter (Delay Variation)
Jitter คือความแปรปรวนของ delay packets ที่มาถึงไม่สม่ำเสมอ ทำให้เสียงขาดๆ หายๆ ภาพกระตุก Voice ต้องการ jitter ไม่เกิน 30 ms จitter buffer ใน IP Phone ช่วยลด jitter ได้ระดับหนึ่ง แต่ถ้า jitter สูงเกินไป buffer ก็ช่วยไม่ได้
Packet Loss
Packet loss ที่มากกว่า 1% จะเริ่มส่งผลต่อคุณภาพเสียงอย่างเห็นได้ชัด มากกว่า 3% แทบจะคุยไม่ได้ ต่างจาก data traffic ที่ TCP retransmit ได้ voice ใช้ UDP ที่ไม่ retransmit packet ที่หายไปหายเลย
QoS Mechanisms
QoS ทำงานใน 3 ขั้นตอนหลัก
1. Classification และ Marking
ระบุว่า traffic นี้เป็นประเภทไหน แล้ว mark ด้วย DSCP (Differentiated Services Code Point) ใน IP header ตัวอย่าง voice media mark เป็น EF (Expedited Forwarding, DSCP 46), voice signaling mark เป็น CS3 (DSCP 24), video conferencing mark เป็น AF41 (DSCP 34), business critical data mark เป็น AF21 (DSCP 18), best effort (internet browsing) เป็น default (DSCP 0) classification ทำที่จุดที่ใกล้ต้นทางที่สุด เช่น access switch port ที่ต่อกับ IP Phone
2. Queuing
จัดเรียง packets ใน queue ตาม priority ที่ mark ไว้ อุปกรณ์ network มีหลาย queue สำหรับ traffic ประเภทต่างๆ Priority Queue (PQ) หรือ Strict Priority สำหรับ voice ส่งก่อนเสมอ Weighted Fair Queue (WFQ) แบ่ง bandwidth ตาม weight ที่กำหนด CBWFQ (Class-Based Weighted Fair Queuing) กำหนด minimum bandwidth guarantee ให้แต่ละ class
3. Policing และ Shaping
Policing drop packets ที่เกิน rate limit ทันที (ใช้ที่ ingress) Shaping buffer packets ที่เกิน rate limit แล้วค่อยๆ ส่งอย่างสม่ำเสมอ (ใช้ที่ egress) ทำให้ traffic ไม่ burst เกินไป shaping เหมาะสำหรับ WAN links ที่ bandwidth จำกัด
ตาราง DSCP Marking ที่แนะนำ
| Traffic Type | DSCP Value | DSCP Name | Priority Queue | Bandwidth Allocation |
|---|---|---|---|---|
| Voice Media (RTP) | 46 | EF | Strict Priority | 10-15% |
| Voice Signaling | 24 | CS3 | Queue 2 | 5% |
| Video Conference | 34 | AF41 | Queue 3 | 15-25% |
| Business Critical | 18 | AF21 | Queue 4 | 25% |
| Network Management | 48 | CS6 | Queue 5 | 5% |
| Best Effort | 0 | Default | Default Queue | 25% |
| Scavenger (P2P, etc.) | 8 | CS1 | Low Priority | 5% |
วิธี Implement QoS บน Network
Step 1: Trust Boundary
กำหนด trust boundary ว่าจะเชื่อ DSCP marking จากอุปกรณ์ไหน โดยปกติ trust marking จาก IP Phone (เพราะ phone mark voice เป็น EF อยู่แล้ว) แต่ไม่ trust marking จาก PC (เพราะ PC อาจ mark traffic ผิดเพื่อได้ priority สูง) access switch re-mark traffic จาก PC เป็น default (DSCP 0) ยกเว้นจะมี application-aware marking
Step 2: Classification ที่ Access Layer
บน access switch ตั้ง QoS policy classify traffic จาก Voice VLAN เป็น EF trust CoS marking จาก IP Phone re-mark traffic จาก Data VLAN ตาม ACL หรือ NBAR (Network-Based Application Recognition)
Step 3: Queuing บน Uplinks
บน uplink ports ทั้ง access-to-distribution และ distribution-to-core ตั้ง queuing policy ที่มี strict priority queue สำหรับ EF (voice) CBWFQ สำหรับ traffic class อื่นๆ ตาม bandwidth allocation ที่กำหนด
Step 4: QoS บน WAN
WAN links เป็นจุดที่ QoS สำคัญที่สุด เพราะ bandwidth จำกัดมากกว่า LAN ตั้ง shaping ที่ WAN interface ให้ตรงกับ bandwidth ที่ ISP ให้ ภายใน shaped rate จัด queuing ตาม priority voice ได้ strict priority video และ business apps ได้ bandwidth guarantee best effort และ scavenger ใช้ bandwidth ที่เหลือ
QoS สำหรับ Microsoft Teams / Zoom
Microsoft Teams ใช้ DSCP marking ดังนี้ Audio = EF (46), Video = AF41 (34), Application Sharing = AF21 (18) ตั้ง GPO (Group Policy) ให้ Windows clients mark Teams traffic ด้วย DSCP ที่ถูกต้อง ตั้ง trust boundary ที่ access switch ให้ trust DSCP จาก PCs ที่ verified Zoom mark Audio เป็น EF (46), Video เป็น AF41 (34) เช่นกัน ตั้งค่าใน Zoom admin panel
Monitoring QoS
ตั้ง monitoring เพื่อดูว่า QoS ทำงานได้ผล ดู queue statistics บน switch/router ว่ามี drops ใน queue ไหนบ้าง ถ้า voice queue drop = bandwidth ไม่พอสำหรับ voice ใช้ IP SLA (Cisco) หรือ similar tools วัด latency, jitter, packet loss ระหว่าง sites เทียบกับ KPI (latency < 150ms, jitter < 30ms, loss < 1%) monitor application performance ด้วย Teams Admin Center หรือ Zoom Dashboard
ทิ้งท้าย: QoS ทำให้ Network ใช้งานได้จริง
QoS เป็นสิ่งที่ user ไม่รู้ว่ามีอยู่ แต่จะรู้ทันทีเมื่อไม่มี voice call ที่กระตุก video ที่ภาพแตก จะหายไปเมื่อ QoS ทำงานอย่างถูกต้อง เริ่มจาก classify traffic ให้ถูก mark ด้วย DSCP ที่เหมาะสม ตั้ง queuing บนทุก hop และ monitor ว่าทำงานได้ตาม KPI
อ่านเพิ่มเติมเกี่ยวกับ VoIP Systems และ VLAN Configuration ที่ siamlancard.com หรือจาก icafeforex.com และ siam2r.com
