Quality of Service in IP Networks

อินเทอร์เน็ตโพรโทคอลในปัจจุบัน

โพรโทคอลหลักที่ใช้งานใน เครือข่ายอินเทอร์เน็ตก็คือ Internet Protocol หรือที่เราเรียกสั้นๆ ว่า IP ทุกวันนี้ IP ที่เราใช้อยู่เป็น IP version 4 ซึ่งใช้งานกันมาตั้งแต่ปี 1981 การทำงานของ IP เป็นการส่งข้อมูลที่เรียกกันว่า “best-effort” หมายความว่าตัวโปรโคคอลจะพยายามทำหน้าที่ส่งข้อมูลไปยังปลายทางที่ระบุไว้ ให้ดีที่สุดเท่าที่จะทำได้ แต่ในทางกลับกันมันก็หมายความว่า IP ไม่สามารถรับประกันได้ว่าข้อมูลที่ส่งจะไปถึงปลายทางอย่างแน่นอน และแม้ว่าจะส่งไปถึงปลายทางได้ ก็ไม่ได้รับประกันว่าข้อมูลจะมีความถูกต้อง 100% … ดังนั้นความจำเป็นสูงสุดของเครือข่ายอินเทอร์เน็ตยุคแรกก็คือการทำให้ เครือข่ายมีความน่าเชื่อถือในการส่งข้อมูล .. ผลก็คือต้องมีโพรโทคอลอีกอันนึงที่ทำหน้าที่รักษาความน่าเชื่อถือในการส่ง ข้อมูลบนอินเทอร์เน็ตนั่นก็คือ Transmission Control Protocol (TCP) และทำให้เราเรียกชุดโพรโทคอลนี้ว่าเป็น TCP/IP นั่นเอง..

ในปัจจุบัน ความน่าเชื่อถือในการส่งข้อมูลเพียงอย่างเดียวไม่สามารถตอบสนองความต้องการ ของผู้ใช้ได้ สาเหตุเกิดมาจากข้อมูลในอินเทอร์เน็ตมีหลากหลายมากขึ้น อินเทอร์เน็ตไม่ได้เป็นเครือข่ายที่ใช้เพียง e-mail หรือ FTP เหมือนแต่ก่อน ปัจจุบันเรามีแอพพลิเคชันบนอินเทอร์เน็ตสารพัดแบบ ซึ่งมีการส่งข้อมูลที่ต่างๆ กันไปทั้ง ที่กำลังนิยมเวลานี้ก็คือแอพพลิเคชันประเภทมัลติมีเดีย และเกมส์ ซึ่งมีการส่งข้อมูล ออดิโอสตรีม วิดีโอสตรีม ข้อมูลแบบอินเตอร์แอคทีฟ ฯลฯ ธรรมชาติของข้อมูลเหล่านี้แตกต่างกัน จึงต้องการการส่งข้อมูลในรูปแบบที่ต่างกันไปด้วย ตัวอย่างเช่น

  • เกมส์ แบบอินเตอร์แอคทีฟมีการส่งข้อมูลอยู่ตลอดเวลา แม้ว่าข้อมูลจะมีปริมาณไม่มาก แต่ต้องส่งได้อย่างรวดเร็ว และไม่มีการสูญหาย เพื่อให้เกมส์สามารถดำเนินได้อย่างต่อเนื่อง ดังนั้นการส่งข้อมูลจึงต้องการดีเลย์ที่ต่ำมากๆ ต้องการความน่าเชื่อถือในการส่งข้อมูลสูงถึงจะทำงานได้ดี แต่ไม่ต้องการแบนด์วิดธ์เยอะเพราะข้อมูลที่ส่งแต่ละครั้งมีน้อย
  • ออ ดิโอสตรีมอย่าง RealAudio MP3 หรือ WMA ใช้แบนด์วิดธ์ตั้งแต่ 16 ถึง 64 kbps ไม่ต้องการความน่าเชื่อถือสูงมากเพราะสตรีมถูกออกแบบให้ทนต่อ loss และ error ได้ในระดับนึงอยู่แล้ว ไม่จำเป็นต้องมีดีเลย์น้อยเหมือนพวกอินเตอร์แอคทีฟ เพราะถ้ารู้ดีเลย์ที่แน่นอน มันสามารถคำนวณหาบัฟเฟอร์ที่จำเป็นเพื่อลดปัญหาเรื่องดีเลย์ได้ แต่อย่างไรก็ตามสตรีมพวกนี้ก็ยังต้องการให้มีการส่งข้อมูลอย่างต่อเนื่อง จึงต้องจำเป็นต้องบังคับให้การเปลี่ยนแปลงของดีเลย์มีน้อยๆ
  • สตรีม ของวิดีโอ หรือพวก Video-on-demand จะคล้ายกับสตรีมของเสียงแต่ต้องมีแบนด์วิดธ์ที่กว้างกว่าเพราะปริมาณข้อมูล มีเยอะกว่า (320 kbps – 5 Mbps)
  • วิดีโอคอนเฟอเรนซ์ Internet Telephony และ Internet Virtual Reality จำเป็นต้องทำงานแบบ real-time จึงไม่สามารถแก้ปัญหาของดีเลย์ด้วยบัฟเฟอร์ได้ ต้องการดีเลย์ที่ต่ำ มีการเปลี่ยนแปลงของดีเลย์น้อยๆ แต่ไม่จำต้องมีคุณภาพของภาพหรือเสียงที่ดีเท่ากับพวก Video-on-demand จึงใช้แบนด์วิดธ์น้อยกว่า

ฯลฯ

เพราะความต้องการที่ไม่ เหมือนกันนี้เองทำให้เกิดแนวความคิดในการส่งข้อมูลให้เหมาะสมกับชนิดของ ข้อมูลนั้นๆ และเพราะ TCP/IP หรือ UDP/IP ไม่สามารถรองรับการทำงานอย่างนี้ได้ ก็มีการคิดการส่งข้อมูลที่เรียกว่า “Quality-of-Service Routing” หรือ QoS routing นั่นล่ะครับ

คำนิยาม กว้างๆ ของ QoS routing คือการส่งข้อมูลในเครือข่ายโดยรับประกันว่าการส่งข้อมูลจะเป็นไปตามคุณภาพ หรือเงื่อนไขที่ต้องการ เงื่อนไขที่ว่านี่ก็คือเงื่อนไขในเชิง ‘เมตริก’ ของเครือข่าย เช่น ดีเลย์ แบนด์วิดธ์ การเปลี่ยนแปลงของดีเลย์ (delay variation หรือ jitter) อัตราการสูญหายของข้อมูล (loss) ฯลฯ หลักการทั่วไปของ QoS routing จึงเป็นการตรวจวัดและควบคุมการไหลของข้อมูลให้เป็นไปตามเงื่อนไขที่กำหนด ฟังดูเหมือนไม่ค่อยมีอะไรมาก แต่ที่จริงแล้ว QoS routing เป็นเรื่องซับซ้อนมาก มันประกอบไปด้วยกลไก อัลกอริทึม และโพรโทคอลเยอะแยะไปหมด เรียกว่าเป็นเฟรมเวิร์กเลยล่ะครับ แล้วแต่ละอันก็จะมีเทคนิคที่ใช้ต่างๆ กันไปอีก และทำให้เกิดศัพท์เทคนิคใหม่ๆ มากมาย .. แต่สำหรับบทความนี้คงอธิบายแค่พื้นฐานของ QoS บนอินเทอร์เน็ตเป็นหลักครับ

เอา ล่ะครับ ตอนนี้เรารู้แล้วว่าเป้าหมายของเราก็คือการควบคุมการส่งแพคเก็ตผ่าน เครือข่ายให้ได้ตามเงื่อนไข วิธีการพื้นฐานของ QoS มีอยู่สองแบบครับ คือ Reservation และ Prioritization ดูจากศัพท์แล้วหลายคนอาจจะเดาได้ไม่ยากว่าทำงานอย่างไร แต่เรามาดูรายละเอียดกันอีกซักหน่อยครับ

Reservation

หลักการ ของ reservation คือการรับประกันด้วยวิธีจองทรัพยากรของเครือข่าย ก่อนที่จะเริ่มส่งข้อมูล ทรัพยากรตัวหลักที่จำเป็นต้องจองก็คือ บัฟเฟอร์และแบนด์วิดธ์ แต่โดยมากแล้วเราจะห่วงเรื่องของดีเลย์มากที่สุด เพราะแอพพลิเคชันส่วนมากจะอ่อนไหวกับดีเลย์ การคำนวณจึงเน้นไปที่การหาขนาดของบัฟเฟอร์และแบนด์วิดธ์ที่เหมาะสมที่จะ รักษาดีเลย์ระหว่างต้นทางไปยังปลายทางไม่ให้เกินที่กำหนดได้ ซึ่งซับซ้อนเอาเรื่องเหมือนกัน ลองดูรายละเอียดซักหน่อยนะครับ ในแต่ละ hop เราสามารถแยกดีเลย์ออกมาได้ 4 ส่วน ดังนี้ครับ

  1. Queueing delay – ดีเลย์ที่เกิดจากการรอคิวส่ง สำหรับในเราท์เตอร์ก็คือช่วงเวลาที่แพคเก็ตถูกบัฟเฟอร์ไว้หน่วยความจำ มากหรือน้อยขึ้นกับการจัดคิว และขนาดของคิว ถ้าคิวขนาดใหญ่จะมีโอกาสบัฟเฟอร์ข้อมูลได้มากทำให้ค่าเฉลี่ยของดีเลย์สูง ถ้าคิวสั้นค่าเฉลี่ยของดีเลย์จะน้อยกว่าแต่ทำให้อัตราการสูญเสียมีมากขึ้น เพราะแพคเก็ตจะถูกตัดออกจากระบบ
  2. Processing delay – ดีเลย์ที่เกิดจากการประมวลผลของเราท์เตอร์ เช่น การ lookup routing table การ load/transfer memory การติดต่อ I/O ระหว่าง CPU กับ network interface
  3. Transmission delay – ดีเลย์ที่เกิดจากอัตราการส่งข้อมูล ค่านี้จะมีความสัมพันธ์กับแบนด์วิดธ์ครับ ถ้าแบนด์วิดธ์กว้าง transmission delay ก็จะน้อย
  4. Propagation delay – ดีเลย์ของสื่อที่ใช้ส่งข้อมูล เป็นคุณสมบัติเฉพาะตัวของสื่อนั้นๆ เช่น optical fiber ก็จะมี propagation delay ราว (2/3 ความเร็วแสง x ระยะทาง) หรือดาวเทียมอยู่ห่างจากโลกมากๆ ก็จะมี propagation delay มากตามไปด้วย

จะเห็นว่าเรามีตัวแปร สองตัวที่ปรับค่าแล้วส่งผลต่อดีเลย์คือ ขนาดของบัฟเฟอร์ และ ขนาดของแบนด์วิดธ์ การหาค่าที่เหมาะสมเวลานี้ยังไม่มีกฏตายตัวว่าต้องใช้วิธีไหน เราอาจจะใช้ optimization technique มาช่วยคำนวณร่วมกับ หลักของ Queueing Theory ได้ ซึ่งจะได้ผลลัพธ์ที่สามารถรับประกันการส่งข้อมูลในเชิงสถิติ แต่ทั้งหมดนี้เป็นการคำนวณเพียงแค่ hop เดียวเท่านั้นนะครับ การจะหาดีเลย์ทั้งหมดต้องคำนวณจากทุกๆ hop ที่เป็นทางผ่านของแพคเก็ต ถ้าจะให้ดีต้องคำนวณทุกๆ hop พร้อมกันภายใต้เงื่อนไขและข้อจำกัดในการทำงานของแต่ละ hop แต่การทำเช่นนั้นเป็นเรื่องที่ยุ่งยากมากและเสียเวลา อีกทั้งการใช้งานทุกวันนี้ยังไม่จริงจังมากนัก จึงตัดการ optimization ออก และใช้วิธีเลือกค่าที่ทำให้ระบบทำงานได้ก็พอ..

ปัจจุบันมีเฟรมเวิร์ก ที่ใช้หลักการของ reservation ในเครือข่ายอินเทอร์เน็ตเรียกว่า “Integrated Services” หรือเรียกสั้นๆ ว่า IntServ เฟรมเวิร์กของ IntServ ใช้ Resource Reservation Protocol (RSVP) ในการจองทรัพยากรเครือข่าย เส้นทางของการส่งข้อมูลระหว่างต้นทางไปยังปลายทางจะไม่แตกต่างจากการส่ง ข้อมูลแบบ best-effort แต่ IntServ สามารถรับประกันได้ว่าดีเลย์ในการส่งจากต้นทางไปถึงปลายทางจะไม่เกินค่าๆ หนึ่งแน่นอน (ยกเว้นกรณีที่เส้นทางมีการเปลี่ยนแปลง) ปัญหาใหญ่ของ IntServ คือ scalability เพราะเครือข่ายต้องแบ่งทรัพยากรบางส่วนไปใช้กับ QoS routing โดยเฉพาะ ถ้าใช้งาน QoS routing กันมากๆ ทรัพยากรก็จะหมดไป นอกนี้ การจองทรัพยากรด้วย RSVP ไม่ได้กระทำอย่างถาวร จึงต้องมีการส่งแพคเก็ตของ RSVP ไปยังเราท์เตอร์เพื่อรีเฟรชการจองทรัพยากรตลอดเวลา จึงมี processing overhead สูง ปกติแล้ว IntServ จึงจำกัดให้ใช้งานเฉพาะใน Autonomous System (AS) เดียวกันเท่านั้น

Prioritization

แปลตามตัวเลยครับ prioritization เป็นการจัดลำดับความสำคัญ ในกรณีนี้เราพยายามแบ่งระดับความสำคัญของข้อมูลที่ต้องการส่ง อันไหนมีความสำคัญมากก็ส่งก่อน อันไหนมีความสำคัญน้อยกว่าก็ส่งทีหลัง การเลือกระดับความสำคัญจะเป็นไปตามชนิดของข้อมูลเป็นหลักครับ อย่างที่บอกว่าเราห่วงเรื่องของดีเลย์มากกว่าสิ่งอื่น ดังนั้นการส่งข้อมูลที่ต้องการดีเลย์น้อยๆ ก็จะมีระดับความสำคัญสูง ข้อดีของวิธีการนี้คือไม่ต้องมีการจองทรัพยากรของเครือข่าย จึงสามารถใช้งานได้ในวงกว้าง บางครั้งการทำงานแบบ prioritization จะเรียกว่าเป็น Class-of-Service routing (CoS routing) มากกว่าที่จะเป็น QoS routing เพราะแพคเก็ตจะถูกแบ่งออกมาเป็นคลาส (คลาส = ระดับความสำคัญ) ข้อมูลในคลาสเดียวกันจะมีความสำคัญเท่ากัน ใช้ทรัพยากรทั้งหมดร่วมกัน ซึ่งเป็นข้อเสียของมัน เนื่องจากวิธีนี้ไม่สามารถรับประกันได้ 100% ว่าการจัดส่งจะเป็นไปตามเงื่อนไน ในขณะที่ reservation จะมีความแน่นอนมากกว่า เพราะกันทรัพยากรส่วนนึงมาใช้งานโดยเฉพาะ

ใน อินเทอร์เน็ตก็มีเฟรมเวิร์กที่เป็น prioritization เหมือนกันครับ เรียกว่า “Differentiated Services” หรือ DiffServ (มี Integrated ก็ต้องมี Diff – -“) แต่วิธีการของ DiffServ ถือว่าเหนือขึ้นไปอีกขั้นนึงครับ คือแทนที่จะระบุระดับความสำคัญมาก-น้อย แล้วส่งข้อมูลเรียงตามลำดับความสำคัญ DiffServ จะใช้วิธีการแบ่งคลาสของข้อมูลว่าแต่ละคลาสต้องการการส่งข้อมูลอย่างไร จะใช้ทรัพยากรของเราท์เตอร์มาน้อยแค่ไหน แพคเก็ตในคลาสเดียวกันจะถูกจัดส่งด้วยวิธีการแบบเดียวกัน ทำให้ควบคุมการส่งได้ดีกว่าและตรงกับความต้องการของข้อมูลมากกว่าการจัด ระดับความสำคัญ นอกจากนี้แล้วเฟรมเวิร์กของ DiffServ ยังพิจารณาถึงระดับนโยบายการใช้งานข้าม AS ด้วย เหตุผลก็คือ AS แต่ละ AS เป็นของหน่วยงานต่างๆ กัน มีนโยบายในการใช้งานไม่เหมือนกัน และอาจจะกำหนดวิธีการจัดส่งในแต่ละคลาสต่างจาก AS อื่นๆ ดังนั้นการใช้งาน DiffServ ข้าม AS จึงต้องมีการตกลงกันระหว่าง AS ด้วยว่าจะยอมให้มีการส่งหรือไม่ ถ้ายอมจะแมพแต่ละคลาสเข้าหากันได้อย่างไร

Path Computation

การ คำนวณเส้นทางสำหรับ QoS routing จำเป็นต้องพิจารณาเมตริกหลายๆ ตัวพร้อมกันเพื่อให้ได้เส้นทางที่ตรงตามเงื่อนไข หากสามารถคำนวณเส้นทางได้ก็มีความเป็นไปได้ที่จะส่งข้อมูลได้ตามเงื่อนไขที่ ร้องขอ แต่ถ้าคำนวณแล้วไม่พบเส้นทางที่ตรงตามเงื่อนไขเลย ก็จะถือว่าเครือข่ายไม่สามารถส่งข้อมูลตามเงื่อนไขดังกล่าวได้

การ คำนวณเส้นทางสำหรับ QoS routing มีข้อจำกัดอยู่มาก และอาจจะเป็นเรื่องที่ยากที่สุดในเฟรมเวิร์กเลยล่ะครับ เข้ารายละเอียกซักนิดดีกว่า เราสามารถแยกแยะเมตริกของเครือข่ายได้เป็น 3 ประเภทดังนี้ครับ ให้ d(i, j) เป็นเมตริกของ link ที่เชื่อม node i และ node j และ P เป็นเส้นทางที่ผ่าน node i, i, k, … l, m ตามลำดับ เราเรียกเมตริก d ว่าเป็น

additive if d(P) = d(i, j) + d(j, k) + ... + d(l, m)
multiplicative if d(P) = d(i, j) * d(j, k) * ... * d(l, m)
concave if d(P) = min{d(i, j), d(j, k),  ... ,d(l, m)}

ถ้าพิจารณาดูเราจะได้ว่า ดีเลย์ การเปลี่ยนแปลงของดีเลย์ จำนวน hop และ cost เป็นเมตริกแบบ additive ส่วน loss เป็นเมตริกแบบ multiplicative และแบนด์วิดธ์เป็นเมตริกแบบ concave ทีนี้ปัญหามันเกิดขึ้นตรงที่ การคำนวณเส้นทางด้วยเมตริกที่เป็น additive และ/หรือ multiplicative สองตัวหรือมากกว่ามันเป็น NP-complete problem ทุกวันนี้การคำนวณเส้นทางจึงพิจารณาได้เพียงแค่แบนด์วิดธ์ และ เมตริกอื่นอีกหนึ่งตัวเท่านั้น การใช้งาน QoS routing ที่ผ่านมาจึงยังไม่มีการคำนวณเส้นทางอัตโนมัติครับ ทุกครั้งที่จะใช้ admin จำต้องเลือกเส้นทางและเซตอัพเส้นทางเอง

การคำนวณเส้นทางสำหรับ QoS routing สามารถทำได้สองแบบ คือ แบบ pre-compute ซึ่งจะคำนวณเส้นทางเตรียมไว้ก่อน เมื่อมีการขอใช้ QoS routing ก็จะเลือกเส้นทางที่เหมาะสมไปใช้งาน อีกแบบคือแบบ on-demand ซึ่งจะคำนวณเส้นทางเมื่อมีการขอใช้ ทั้งสองแบบนี้มีข้อดีข้อเสียตรงข้ามกันครับ คือ pre-compute มีข้อดีที่การคำนวณจะเกิดขึ้นเมื่อเส้นทางมีการเปลี่ยนแปลงเท่านั้น จึงมี processing overhead น้อย แต่ผลของการคำนวณอาจจะไม่เหมาะสมกับเงื่อนไขเลยก็ได้ ส่วนแบบ on-demand จะให้ผลลัพธ์ที่ตรงกับเงื่อนไขมากกว่า และสามารถ optimize ทรัพยากรเครือข่ายได้ดีกว่า แต่ก็ต้องเสีย processing overhead มากกว่า .. จะเลือกใช้แบบไหน ? พิจารณาจากปริมาณหรือความถี่ในการใช้งาน QoS routing กับความถี่ในการเปลี่ยนแปลงของเส้นทางครับ

เรื่องนี้ยังไม่จบ.. แต่..

บทความ นี้ ผมตั้งใจให้เป็น intro เล็กๆ ให้เห็นภาพกว้างๆ กันก่อน ถ้าจะลงรายละเอียดล่ะก็เรียนเป็นเทอมๆ เลยล่ะครับ .. เวลานี้ยังเดาได้ยากว่าจะมี QoS ใช้บนอินเทอร์เน็ตเมื่อไหร่ QoS ส่วนมากยังเป็นทฤษฎี และยังไม่ใกล้เคียงกับการใช้งานจริงๆ จังๆ แม้หลักการจะชัดเจนแล้ว แต่ปัญหาทางเทคนิคยังคงมีอยู่เยอะ อย่างเช่น การ optimization การคำนวณเส้นทาง ดังนั้นทุกอย่างมีโอกาสเปลี่ยนแปลงได้ แม้ว่าจะมี IntServ และ DiffServ ประกาศเป็นมาตรฐานแต่นั่นก็เป็นแค่กรอบของการทำงานเท่านั้น ซอฟต์แวร์หรืออุปกรณ์ยังแทบจะไม่มีใช้กันเลยครับ routing protocol ยังไม่สนับสนุน มาตรฐานยังไม่ชัดเจน อนาคตอาจจะไม่ได้ใช้ทั้ง IntServ และ DiffServ เลยก็ได้ครับ เพราะเวลานี้สิ่งที่นักวิจัยกำลังให้ความสนใจคือการใช้ Constraint-Based Routing ร่วมกับ Multi-Protocol Label Switching ในการทำ QoS routing ซึ่งเป็นอีกเฟรมเวิร์คที่เกิดขึ้นมาไม่นาน และกำลังมีความพยายามจะทำให้เป็นมาตรฐานสำหรับอินเทอร์เน็ตด้วย.. เอาไว้ผมศึกษาเรื่องนี้ชัวร์ๆ แล้วจะเขียนมาให้อ่านในฉบับต่อๆ ไปครับ..