บริการอินเทอร์เน็ต L4S เพื่อความหน่วงต่ำ การสูญเสียต่ำ และ throughput ที่ขยายตัวได้: RFC 9330

 (datatracker.ietf.org)
1 คะแนน โดย GN⁺ 2023-12-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • RFC 9330 กำหนด สถาปัตยกรรม L4S เพื่อลด ความหน่วงจากการเข้าคิวและการสูญเสียจากความคับคั่ง ของแอปพลิเคชันอินเทอร์เน็ต โดยมองว่าสาเหตุรากของความหน่วงอยู่ที่การควบคุมความคับคั่งแบบค้นหาความจุของฝั่งผู้ส่ง มากกว่าตัวคิวเอง
  • L4S ผสาน Scalable congestion control ของโฮสต์ผู้ส่ง, AQM ที่จุดคอขวด และโปรโตคอลที่อิง ECN เข้าด้วยกัน และใช้ codepoint ECT(1) ในฟิลด์ IP-ECN เพื่อระบุแพ็กเก็ต L4S
  • เป้าหมายความหน่วงจากการเข้าคิวคือค่าเฉลี่ยต่ำกว่า 1ms และเปอร์เซ็นไทล์ที่ 99 ประมาณต่ำกว่า 2ms โดยในตัวอย่าง DCTCP และ Dual-Queue Coupled AQM แม้มีโหลดเกิน ความหน่วงจากการเข้าคิวที่เปอร์เซ็นไทล์ที่ 99 ก็อยู่ราว 1~2ms
  • เพื่อให้อยู่ร่วมกับ Classic congestion control ตระกูลเดิมอย่าง Reno/CUBIC ได้ L4S ถูกออกแบบให้แยกความหน่วงของทราฟฟิก Classic กับทราฟฟิก L4S ออกจากกัน แต่ไม่แบ่งแบนด์วิดท์แบบตายตัว และให้แชร์กันในระยะยาว
  • L4S ไม่ได้มาแทนที่ Diffserv, FQ-CoDel, PIE หรือ BBR แต่เป็นส่วนเสริม โดย TCP ต้องการ feedback ที่ละเอียดอย่าง AccECN ส่วน QUIC และ DCCP ให้ ECN feedback ที่ L4S ต้องการอยู่แล้ว

ปัญหาความหน่วงที่ L4S ต้องการแก้

  • มีสถานการณ์เพิ่มขึ้นเรื่อย ๆ ที่ทราฟฟิกซึ่งต้องการ ความหน่วงต่ำ เช่น เว็บ เสียง วิดีโอคอนเฟอเรนซ์ เกม เดสก์ท็อประยะไกล แอปพลิเคชันคลาวด์ AR/VR และการควบคุมระยะไกล เข้าไปเติมลิงก์คอขวดจนเต็ม
  • แม้การวางแคชและเซิร์ฟเวอร์ไว้ใกล้ผู้ใช้จะลดความหน่วงจากการแพร่สัญญาณลงแล้ว แต่การเข้าคิวยังคงเป็นองค์ประกอบหลักและเกิดเป็นระยะของความหน่วง
    • แม้มี AQM สมัยใหม่ สไปก์ความหน่วงระดับหลายร้อย ms ก็ยังไม่ใช่เรื่องหายาก
    • Classic AQM มักถูกตั้งค่าให้บัฟเฟอร์ความผันผวนของคิวแบบฟันเลื่อยของโฟลว์ระยะยาวเดี่ยว ทำให้พีคของความหน่วงทั้งเครือข่ายระหว่างโฟลว์ระยะยาวอาจสูงราวสองเท่าของความหน่วงพื้นฐานของเส้นทาง
  • เป้าหมายของ L4S คือ ความหน่วงจากการเข้าคิวที่ต่ำมาก การสูญเสียต่ำมาก และ throughput ที่ขยายตัวได้
    • ความหน่วงจากการเข้าคิวที่ต่ำมากหมายถึงค่าเฉลี่ยต่ำกว่า 1ms และเปอร์เซ็นไทล์ที่ 99 ประมาณต่ำกว่า 2ms
    • แอปพลิเคชันแบบโต้ตอบที่ต้องการมากขึ้นจะเริ่มรู้สึกไม่เป็นธรรมชาติเมื่อความหน่วงปลายทางถึงปลายทางเกิน 50ms หรือ 20ms
  • เนื่องจากการสูญเสียทำให้เกิดความหน่วงจากการส่งซ้ำในแอปพลิเคชันแบบโต้ตอบ การสูญเสียต่ำ จึงเป็นเป้าหมายสำคัญเช่นกัน

สาเหตุของความหน่วง: Classic congestion control มากกว่าคิว

  • L4S มองว่าสาเหตุรากของความหน่วงจากการเข้าคิวอยู่ที่ การควบคุมความคับคั่งแบบค้นหาความจุ ของผู้ส่ง มากกว่าตัวคิวเอง
  • Classic congestion control อย่าง Reno และ CUBIC ทำให้อัตราการครอบครองคิวเปลี่ยนแปลงเป็นรูปฟันเลื่อยขนาดใหญ่
    • หาก AQM ตั้งคิวให้ตื้นเกินไป Classic congestion control จะใช้ลิงก์ได้ไม่เต็มที่ในทุก ๆ จุดต่ำสุดของฟันเลื่อย
    • ยิ่งความเร็วของโฟลว์เพิ่มขึ้น เวลากู้คืนของ Classic congestion control ก็ยิ่งนานขึ้น ทำให้การควบคุมคิวและการใช้งานลิงก์หลวมลง
  • Scalable congestion control ทำให้เวลาเฉลี่ยระหว่างสัญญาณความคับคั่ง หรือ เวลากู้คืน คงที่ แม้ความเร็วของโฟลว์จะเพิ่มขึ้น
    • DCTCP เป็นตัวอย่างที่ใช้กันอย่างแพร่หลายในสภาพแวดล้อมที่ควบคุมได้
    • มีการอิมพลีเมนต์และใช้งานใน Windows Server Editions, Linux และ FreeBSD
    • Prague over TCP/QUIC, SCReAM สำหรับ L4S และส่วน L4S ECN ของ BBRv2 ก็รวมอยู่ในตัวอย่างของ Scalable congestion control ด้วย

องค์ประกอบสามส่วนของสถาปัตยกรรม L4S

  • L4S ประกอบด้วยองค์ประกอบสามอย่าง
    • Scalable congestion control ของโฮสต์ผู้ส่ง
    • AQM ที่คอขวดของเครือข่าย
    • โปรโตคอลที่อิง ECN ซึ่งรับผิดชอบการระบุแพ็กเก็ตและสัญญาณความคับคั่งระหว่างสองฝ่าย
  • ความหน่วงต่ำไม่ได้เกิดจากเครือข่ายจัดให้โดยตรง แต่เกิดจากพฤติกรรม Scalable congestion control อย่างระมัดระวังของผู้ส่ง L4S
  • บทบาทหลักของเครือข่ายคือ แยก ความหน่วงต่ำของทราฟฟิก L4S ออกจากความหน่วงจากการเข้าคิวที่มากกว่าซึ่งทราฟฟิก Classic ต้องการ
  • เครือข่ายใช้ ECN เพื่อแจ้งสัญญาณเริ่มต้นมาก ๆ ของการเพิ่มขึ้นของคิวไปยังชั้น transport ทันที
    • ไม่รอให้ทำให้ความผันผวนของคิวเรียบในระดับมากก่อนค่อยส่งสัญญาณเหมือน Classic AQM
    • การรองรับ ECN เป็นสิ่งจำเป็นสำหรับ L4S
  • ผู้ส่งใช้ฟิลด์ ECN เพื่อให้เครือข่ายแยกแพ็กเก็ต L4S ออกจากแพ็กเก็ต Classic ได้

ECN และ codepoint ECT(1)

  • L4S ต้องการ สัญญาณความคับคั่งที่ละเอียดกว่า ซึ่งหลุดจากข้อจำกัดของ Classic ECN ที่ว่า “สัญญาณ ECN ต้องถูกปฏิบัติเสมือนเทียบเท่ากับการ drop”
    • ต้องสามารถเกิดสัญญาณได้บ่อยขึ้น
    • ต้องส่งสัญญาณได้ทันทีโดยไม่ต้องมีความหน่วงมากเพื่อทำให้ความผันผวนของคิวเรียบ
  • RFC8311 ผ่อนคลายข้อกำหนดบางส่วนของ RFC3168 ทำให้การทดลอง L4S เป็นไปได้
  • RFC9331 กำหนดให้ใช้ ECT(1) เป็นตัวระบุแพ็กเก็ต L4S
  • codepoint CE ใช้เพื่อระบุ Congestion Experienced ทั้งในการประมวลผล L4S และ Classic
    • หาก Classic AQM ที่อยู่ต้นเส้นทางทำเครื่องหมายแพ็กเก็ต ECT(0) เป็น CE อาจมีความเสี่ยงที่จะถูกจัดเข้าคิว L4S ผิด
    • ตามภาคผนวก B ของ RFC9331 ผลกระทบที่เป็นอันตรายจะเกิดขึ้นได้ก็ต่อเมื่อเงื่อนไขที่พบได้ยากห้าข้อเกิดพร้อมกันทั้งหมด และแม้ในกรณีนั้น โอกาสเกิดการส่งซ้ำผิดพลาดก็ต่ำมาก
  • ผู้ปฏิบัติการอาจต้องการใส่ทราฟฟิกที่ไม่ใช่ L4S ซึ่งต่ำและเรียบพอจนไม่สร้างคิว เข้าไปในคิว L4S
    • ตัวอย่างคือ VoIP, ดาตาแกรมอัตราต่ำสำหรับการซิงก์เกมออนไลน์, DNS, LDAP เป็นต้น
    • ในกรณีนี้จำเป็นต้องมีเครื่องหมายแยกต่างหาก เช่น EF, NQB หรือตัวระบุเฉพาะของผู้ปฏิบัติการ

Dual-Queue Coupled AQM

  • L4S มีเป้าหมายให้คอมโพเนนต์เครือข่ายมอบความหน่วงต่ำได้โดยไม่จำเป็นต้องประมวลผลแยกตามโฟลว์
  • แบบออกแบบตัวแทนคือ Dual-Queue Coupled AQM ซึ่งใช้สองคิว
    • คิว L4S รักษาความหน่วงต่ำ
    • คิว Classic สามารถมีคิวที่ใหญ่กว่าซึ่งจำเป็นต่อการที่ทราฟฟิก Classic จะรักษาการใช้งานลิงก์
  • DualQ ถูกออกแบบให้ทำงานเหมือน เยื่อกึ่งซึมผ่านได้ ที่แยกความหน่วงออกจากกัน แต่ไม่แบ่งแบนด์วิดท์แบบตายตัว
    • Classic AQM สร้างความน่าจะเป็นในการ drop/mark ตามความคับคั่งของคิวตนเอง แล้วนำไป coupling กับสัญญาณของคิว Classic และคิว L4S
    • สัญญาณความคับคั่งที่ถูก coupling จะทำให้โฟลว์ L4S ลดความเร็วลงเพื่อเหลือความจุที่โฟลว์ Classic ต้องการ
  • scheduler สามารถให้ลำดับความสำคัญกับคิว L4S ได้
    • ในสเกลเวลาสั้น ๆ จะระบาย burst ของ L4S ได้อย่างรวดเร็วเพื่อปกป้องความหน่วงต่ำ
    • ในสเกลเวลาระยะยาวตั้งแต่ระดับ round-trip time ขึ้นไป การ coupling สัญญาณความคับคั่งของคิว Classic จะชดเชยสิทธิ์แบนด์วิดท์ ทำให้เกิดความเป็นธรรมโดยประมาณในระดับต่อโฟลว์
  • เมื่อมีแต่ทราฟฟิก L4S AQM ของคิว L4S จะเริ่ม marking ความคับคั่งในคิวที่ตื้นมากเพื่อรักษาความหน่วงจากการเข้าคิวให้ต่ำ

ความแตกต่างระหว่างวิธีคิวต่อโฟลว์กับ DualQ

  • คิวต่อโฟลว์ อย่าง FQ-CoDel และ FQ-PIE ก็สามารถใช้กับ L4S ได้
    • ใน Linux มีการปรับแก้ให้ใช้ threshold การ mark ECN แบบตื้นเฉพาะกับแพ็กเก็ต ECT(1) ได้
    • โฟลว์ Not-ECT หรือ ECT(0) จะใช้ Classic AQM ส่วนโฟลว์ ECT(1) โดยทั่วไปจะใช้ threshold ตื้นระดับต่ำกว่า ms
  • แนวทางต่อโฟลว์แยกคิวของแต่ละโฟลว์ แต่ไม่ได้กำจัดการเข้าคิวที่โฟลว์นั้นสร้างขึ้นเอง
  • วิธี DualQ ไม่ต้องตรวจลึกกว่าชั้น IP เพราะตัวระบุ L4S อยู่ในฟิลด์ IP-ECN
    • ใช้ได้แม้ในสภาพแวดล้อมที่ตัวระบุชั้น transport ถูกเข้ารหัส เช่น IPsec หรือ VPN tunnel ที่เข้ารหัส
  • วิธีต่อโฟลว์ทำให้เครือข่ายรับหน้าที่ควบคุมความเร็วสัมพัทธ์ระหว่างโฟลว์ของแอปพลิเคชัน
  • DualQ แยกปัญหาการให้ความหน่วงต่ำออกจากการควบคุมความเร็วของโฟลว์ และหากจำเป็นก็สามารถเพิ่มการ policing ความเร็วของโฟลว์แยกต่างหากได้

ข้อกำหนดฝั่งโฮสต์

  • ผู้ส่งต้องอิมพลีเมนต์ Scalable congestion control
    • DCTCP เป็นตัวอย่างที่ใช้กว้างที่สุด แต่หากจะใช้บนอินเทอร์เน็ตสาธารณะ ต้องปรับปรุงด้านความปลอดภัยและประสิทธิภาพ
    • ส่วนของข้อกำหนด Prague L4S ที่เกี่ยวข้องกับความเสี่ยงในการก่อผลเสียต่อผู้อื่นถูกบรรจุเป็นข้อกำหนดเชิง normative ใน RFC9331
    • TCP Prague ถูกอิมพลีเมนต์เป็น reference implementation บน Linux
  • โปรโตคอล transport อื่นนอกจาก TCP หากต้องการใช้บริการ L4S ก็ต้องอิมพลีเมนต์การตอบสนองต่อความคับคั่งแบบ Scalable และระบุด้วย codepoint ECT(1)
    • กำลังมีการพิจารณา variant แบบ Scalable สำหรับ QUIC
    • ส่วน L4S ECN ของ BBRv2 ถูกเสนอเป็น Scalable congestion control สำหรับ TCP และ QUIC เป็นต้น
    • variant L4S ของ SCReAM สำหรับสื่อ RTP ก็ถูกอิมพลีเมนต์แล้ว
  • สถานะของ ECN feedback แตกต่างกันตามแต่ละโปรโตคอล
    • DCCP และ QUIC ให้ ECN feedback ที่ละเอียดเพียงพอสำหรับ L4S
    • ECN feedback เดิมของ TCP มีสมมติฐานว่า ECN mark เทียบเท่ากับการ drop จึงใช้กับ Scalable TCP ไม่ได้
    • receiver ของ TCP ต้องรองรับ AccECN ซึ่งเป็น ECN feedback ที่แม่นยำกว่า
    • SCTP ต้องอิมพลีเมนต์และ deploy การออกแบบ ECN ใหม่เพื่อรองรับ L4S
    • RTP มีการกำหนด ECN feedback ที่เพียงพอไว้ใน RFC6679 และ RFC8888

ทำไมจึงต้องมีสัญญาณความคับคั่งแบบชัดแจ้ง

  • L4S ใช้ สัญญาณความคับคั่งแบบชัดแจ้ง แทนการสูญเสียเป็นกลไกหลัก
  • การ drop เป็นทั้งความเสียหายต่อประสิทธิภาพและเป็นสัญญาณในเวลาเดียวกัน จึงสร้างความตึงเครียดระหว่าง “ความเสียหายที่ยิ่งน้อยยิ่งดี” กับ “สัญญาณที่ยิ่งมากยิ่งดี”
  • สัญญาณแบบชัดแจ้งที่อิง ECN ใช้ได้หลายครั้งต่อหนึ่ง round-trip time โดยไม่ก่อความเสียหาย จึงได้เปรียบในการรักษาคิวให้สั้น
  • L4S ย้ายการทำให้เรียบจากเครือข่ายไปยังโฮสต์
    • เครือข่ายไม่รู้ RTT ของแต่ละโฟลว์ ดังนั้นวิธี Classic จึงต้องสมมติ RTT ที่แย่ที่สุด
    • ด้วยเหตุนี้ สัญญาณความคับคั่งแบบ Classic จึงอาจล่าช้า 100~200ms
    • โฮสต์แต่ละตัวรู้ RTT ของตนเอง จึงทำให้เรียบเท่าที่จำเป็นได้ โดยทั่วไปอยู่ระดับไม่กี่ ms
  • คิว L4S ใช้ variant ใหม่ของ L4S ECN ที่ไม่เทียบเท่ากับการ drop ส่วนคิว Classic ใช้ Classic ECN หรือการ drop

เหตุผลด้าน throughput scalability

  • Classic Reno congestion control มี เวลากู้คืน ยาวขึ้นเมื่อเข้าสู่สภาพแวดล้อมที่มีผลคูณแบนด์วิดท์-ความหน่วงสูง
  • เงื่อนไขตัวอย่างคือ RTT สูงสุดที่ยอดฟันเลื่อย 30ms
    • เมื่อ packet rate ของ Reno เพิ่มจาก 1,250packet/s เป็น 10,000packet/s หรือเพิ่ม 8 เท่า เทียบกับแพ็กเก็ต 1500B จะเพิ่มจากราว 15Mb/s เป็น 120Mb/s และเวลากู้คืนเพิ่มจาก 422ms เป็น 3.38s
    • CUBIC ทำงานในโหมด Reno-friendly ที่ 120Mb/s และใช้เวลาราว 4.3s ในการกู้คืน
    • ที่ 960Mb/s จะเข้าสู่โหมด true CUBIC และเวลากู้คืนกลายเป็น 12.2s
    • ที่ 7.68Gb/s เวลากู้คืนเพิ่มขึ้นถึง 24.3s
  • Scalable congestion control อย่าง DCTCP หรือ Prague โดยเฉลี่ยจะกระตุ้นสัญญาณความคับคั่ง 2 ครั้งต่อ RTT และคุณสมบัตินี้คงอยู่ไม่ขึ้นกับความเร็วของโฟลว์
  • ในปี 2020 ความจุเฉลี่ยของการเชื่อมต่อ fixed access ทั่วโลกอยู่ที่ 103Mb/s และในปี 2019 RTT พื้นฐานเฉลี่ยไปยัง CDN อยู่ที่ 25~34ms
  • โฟลว์ดาวน์โหลด CUBIC เดี่ยวอาจใช้เวลาฟื้นตัวหลังลด congestion window ราว 200 RTT หรือ 5 วินาที แม้ในกรณีที่ดีที่สุด

ความสัมพันธ์กับเทคโนโลยีเดิม

  • Diffserv จัดการการจัดสรรแบนด์วิดท์ของทราฟฟิกสำคัญและความหน่วงจากการเข้าคิวของทราฟฟิกที่ไวต่อความหน่วง แต่ L4S จัดการเฉพาะปัญหาความหน่วงจากการเข้าคิว
    • Diffserv มีประสิทธิผลเมื่อมีเพียงทราฟฟิกบางส่วนที่คอขวดต้องการความหน่วงต่ำ
    • หากทราฟฟิกทั้งหมดที่คอขวดต้องการความหน่วงต่ำ ประโยชน์ของการแยกประเภทด้วย Diffserv จะหายไป
    • ตัวระบุ L4S ไม่ได้บ่งบอกข้อกำหนดด้านคุณภาพ แต่บ่งบอกคำมั่นด้านพฤติกรรมว่าจะตอบสนองต่อความคับคั่งแบบ Scalable
  • Classic AQM อย่าง PIE และ FQ-CoDel ลดความหน่วงจากการเข้าคิวได้มากเมื่อเทียบกับกรณีที่ไม่มี AQM เลย
    • L4S เป็นส่วนเสริมของสิ่งเหล่านี้ และไม่ได้มาแทนความจำเป็นในการ deploy อย่างกว้างขวาง
    • AQM เพียงอย่างเดียวทำให้ความตึงเครียดระหว่างความหน่วงกับการใช้งานลิงก์หมดไปได้ยาก เพราะฟันเลื่อยขนาดใหญ่ของ Classic congestion control
  • ABE เปลี่ยนการตอบสนองของโฮสต์ต่อ ECN marking เพื่อเพิ่มการใช้งานลิงก์และ throughput ของโฟลว์ ECN แต่ยังสมมติว่าเครือข่ายปฏิบัติต่อ ECN และการ drop เหมือนกัน
  • BBR ควบคุมความหน่วงจากการเข้าคิวแบบ end-to-end โดยไม่ต้องมีลอจิกเครือข่ายพิเศษ
    • BBR รักษาความหน่วงจากการเข้าคิวให้อยู่ในระดับต่ำอย่างสมเหตุสมผล แต่ไม่ต่ำเท่า L4S
    • BBRv2 สามารถใช้ L4S ECN และพฤติกรรม Scalable L4S congestion control ได้หากเป็นไปได้

แอปพลิเคชันที่ใช้ได้

  • L4S สามารถปรับปรุงคุณภาพของแอปพลิเคชันเดิมได้อย่างมากในสภาวะมีโหลด
    • เกมและคลาวด์เกม
    • VoIP
    • วิดีโอคอนเฟอเรนซ์
    • การท่องเว็บ
    • การสตรีมวิดีโอแบบปรับอัตรา
    • ข้อความโต้ตอบแบบทันที
  • ความหน่วงจากการเข้าคิวที่ต่ำลงทำให้ฟังก์ชันอย่างวิดีโอแบบโต้ตอบบนคลาวด์และ VR/AR บนคลาวด์เป็นไปได้
  • ในเดโม L4S วิดีโอแบบโต้ตอบบนคลาวด์และ VR ทำงานร่วมกันในสถานการณ์ที่แอปพลิเคชันที่ไวต่อความหน่วงหลายตัวและการดาวน์โหลดแชร์คิวคอขวดเดียวกันบนลิงก์บรอดแบนด์ 40Mb/s
    • จากความหน่วงพื้นฐานปลายทางถึงปลายทาง 7ms ความหน่วงจากการเข้าคิวเพิ่มเติมอยู่ราว 1ms
    • ใน AQM ทางเลือก วิดีโอตามหลังท่าทางนิ้วและการเคลื่อนไหวศีรษะอย่างสังเกตได้
  • งานอย่างการแพนวิดีโอด้วยการปัดนิ้วหรือการเคลื่อนไหวศีรษะมีข้อกำหนดด้านความหน่วงเข้มงวดกว่า VoIP มาก
  • telepresence ระยะไกลแบบโต้ตอบ และการควบคุมระยะไกลแบบมีวิดีโอช่วยสำหรับเครื่องจักรและกระบวนการอุตสาหกรรม ยากที่จะเชื่อถือได้หากไม่มีความหน่วงจากการเข้าคิวที่ต่ำมาก

โมเดลการ deploy และการนำมาใช้แบบค่อยเป็นค่อยไป

  • L4S AQM ไม่ได้เป็นโครงสร้างที่ต้อง deploy ทั่วทั้งอินเทอร์เน็ตจึงจะเห็นผล
  • เครือข่ายเข้าถึงอินเทอร์เน็ตสาธารณะมักถูกออกแบบให้คอขวดเกิดบนลิงก์เชิงตรรกะหนึ่งเส้นที่ทราบได้ตามแต่ละไซต์
    • ไซต์รวมถึงบ้าน อุปกรณ์มือถือ และเครือข่ายแคมปัส/องค์กรขนาดเล็กถึงกลาง
    • เป็นการสรุปทั่วไปที่ใช้กับเทคโนโลยีเข้าถึงหลากหลาย เช่น xDSL, เคเบิล, PON, cellular, wireless และดาวเทียม
  • ฝั่ง downstream จะได้ประโยชน์ส่วนใหญ่หาก deploy L4S AQM ที่จุดเข้า link คอขวด และฝั่ง upstream ก็ใช้หลักเดียวกันหาก deploy ที่จุดเข้า upstream link
  • โดยทั่วไป โฟลว์ L4S หนึ่งโฟลว์จะได้ประโยชน์ต้องมีสามองค์ประกอบ
    • congestion control ของผู้ส่ง
    • AQM ที่คอขวด
    • feedback ของ receiver ที่อัปเกรดแล้วสำหรับ transport เก่าอย่าง TCP
  • ลำดับการ deploy อาจหลากหลาย
    • สามารถใช้ DCTCP ที่มีอยู่แล้วในสภาพแวดล้อมทดสอบที่ควบคุมได้
    • เมื่อ deploy TCP Prague และ AccECN ก็จะใช้ L4S ในสภาพแวดล้อมอินเทอร์เน็ตสาธารณะได้
    • QUIC รองรับ ECN feedback ที่ L4S ต้องการตั้งแต่แรกอยู่แล้ว จึง deploy Prague congestion control ฝั่งผู้ส่งได้ง่าย

ข้อจำกัดตามเทคโนโลยีลิงก์

  • Wi-Fi, PON และเคเบิลจะ aggregate ข้อมูลหลายแพ็กเก็ตเป็น burst และบัฟเฟอร์แพ็กเก็ตที่เข้ามาระหว่างสร้าง burst
    • Ethernet และ DSL ไม่ทำ packet aggregation แบบนี้
    • บัฟเฟอร์เพื่อการ aggregate นี้ผู้ส่งลดไม่ได้ จึงไม่ควรนับเป็นคิวที่ AQM ควบคุม
  • ลิงก์ไร้สายอย่าง cellular, Wi-Fi และดาวเทียมอาจมีความจุเปลี่ยนแปลงอย่างรวดเร็วและมาก จึงมองว่าคิวคงค้างเพื่อใช้ประโยชน์จากความจุที่เพิ่มขึ้นอย่างฉับพลันเป็นสิ่งพึงประสงค์
  • เครือข่าย cellular ซับซ้อนขึ้นเพราะมีข้อกำหนดด้านบัฟเฟอร์เพื่อให้ handover ไม่เป็นที่สังเกต
  • L4S ไม่สามารถกำจัดความจำเป็นในการบัฟเฟอร์ทั้งหมดเหล่านี้ได้
  • หากกำจัด “เสาหลักที่ยาวที่สุด” อย่างบัฟเฟอร์สำหรับฟันเลื่อยขนาดใหญ่ของ Classic congestion control ได้ ก็จะเกิดแรงจูงใจให้ลดองค์ประกอบบัฟเฟอร์อื่น ๆ ต่อ เช่น ขนาด burst จาก packet aggregation หรือช่วงเวลา scheduling ของ MAC

คอขวดที่ไม่ใช่ L4S และการจัดการ loss

  • แม้ L4S จะเปิดใช้งานระหว่างโฮสต์สองตัว หากคอขวดไม่รองรับ ECN ผู้ส่ง L4S ต้องอยู่ร่วมกับ Reno อย่างปลอดภัยเมื่อเกิดการ drop
  • กฎนี้ปกป้องทราฟฟิก Classic แต่ทำให้บริการ L4S แย่ลงเมื่อมี loss
    • loss ที่คอขวดชั่วคราวจาก burst ของคิวตื้น
    • ข้อผิดพลาดการส่ง เช่น การรบกวนทางไฟฟ้า
    • rate policing
  • แนวทางสามอย่างในการจัดการเรื่องนี้ยังเป็นพื้นที่วิจัยในปัจจุบัน
    • การละเลย loss บางส่วนใน Prague congestion control ที่ไม่น่าจะเกิดจากความคับคั่ง
    • การกู้คืนข้อผิดพลาดการส่งด้วยการผสาน RACK, L4S และการส่งซ้ำของลิงก์แบบไม่มี reordering
    • hybrid ECN/drop rate policer
  • สถานการณ์ deploy ที่มีปัญหาเหล่านี้น้อย เช่น เครือข่ายมีสาย สามารถดำเนินไปควบคู่กับงานวิจัยดังกล่าวได้

ความปลอดภัยและการ policing ทราฟฟิก

  • ปัจจุบันอินเทอร์เน็ตมักจัดการการแบ่งความจุของลิงก์ที่แชร์ระหว่างไซต์ด้วย scheduler และไม่ได้ policing ความเร็วของโฟลว์แอปพลิเคชันรายตัวโดยทั่วไป
  • L4S ถูกออกแบบไม่ให้ทำลายสภาพนี้
    • DualQ ถูกออกแบบไม่ให้ให้ข้อได้เปรียบด้านความเร็วแก่โฟลว์ที่ไม่ตอบสนองมากไปกว่า AQM แบบคิวเดียว
    • หากต้องการ policing ความเร็วต่อโฟลว์ ก็สามารถเพิ่มได้อย่างเป็นอิสระจากการแยก L4S/Classic
  • L4S ถูกออกแบบให้ลดความหน่วงโดยไม่ทำร้ายความหน่วงหรือความเร็วของทราฟฟิก Classic ดังนั้นจึงไม่จำเป็นต้อง policing การเข้าถึงบริการ L4S ด้วยความเร็วเพียงเพื่อปกป้อง Classic
  • ผู้ปฏิบัติการบางรายอาจให้บริการ L4S เฉพาะกลุ่มจำกัด เช่น ลูกค้าพรีเมียม
    • ในกรณีนี้สามารถใช้ตัวระบุภายใน เช่น ช่วงที่อยู่ต้นทาง ร่วมกับฟิลด์ ECN ได้
    • หากตัวระบุภายในไม่ตรง แม้มี ECT(1) ก็สามารถส่งไปยังคิว Classic ได้
  • บริการ L4S ต้องการการยับยั้งไม่ใช่แค่ด้านความเร็ว แต่รวมถึง ความเป็น burst ด้วย
    • ฟังก์ชันปกป้องคิวความหน่วงต่ำสำหรับ DOCSIS ใช้วิธี redirect โฟลว์ที่สร้างคิวบางส่วนไปยังคิว Classic เพื่อรักษาความหน่วงต่ำ
    • ฟังก์ชันปกป้องคิวเดี่ยวไม่ใช่องค์ประกอบจำเป็นของสถาปัตยกรรม L4S และส่วนหนึ่งของการทดลอง L4S คือการตรวจสอบว่าจำเป็นต้องมีฟังก์ชันแบบนี้หรือไม่

Tunnel และความเป็นส่วนตัว

  • L4S AQM ส่งสัญญาณความคับคั่งผ่านฟิลด์ ECN ดังนั้นเมื่อทำงานภายใน tunnel หรือชั้นล่าง ฟิลด์ ECN ต้องถูกส่งต่อระหว่างชั้นตามมาตรฐาน
  • สถาปัตยกรรม L4S ไม่ได้排除วิธีที่ตรวจตัวระบุชั้น transport
    • ตัวอย่างคือ FQ-CoDel ที่เพิ่มการรองรับ L4S
  • นวัตกรรมหลักอย่าง DualQ AQM ไม่ต้องตรวจลึกกว่า IP header ชั้นนอกสุด
  • แม้ผู้ใช้เข้ารหัสตัวระบุโฟลว์ของแอปพลิเคชันด้วย IPsec หรือ VPN tunnel ที่เข้ารหัส ก็ไม่จำเป็นต้องสละความหน่วงต่ำ
  • เนื่องจาก L4S สามารถให้ความหน่วงต่ำแก่ชุดแอปพลิเคชันที่กว้าง จึงลดความจำเป็นที่ต้องแยกแยะรายแอปพลิเคชันหรือคลาสย่อยระหว่างทางผ่านเครือข่าย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-12
ความคิดเห็นจาก Hacker News

  • อันนี้เจ๋งมากจริง ๆ เดือนที่แล้วได้ดูเดโมสดที่ IETF 118 ใน Prague ดูเหมือนจะกำจัด bufferbloat ได้หมดเลย เหมาะกับวิดีโอแชตมาก
    ดูเหมือนว่าจะต้องใส่บิตเพิ่มเติมในแพ็กเก็ต IP เพื่อบอกข้อมูลอย่างเช่นบัฟเฟอร์เต็มหรือไม่ แต่ของจริงมันทำงานได้ และให้ความรู้สึกว่า “ไม่คิดเลยว่าจะทำแบบนี้ได้”

    • จริง ๆ แล้วยังไปได้ไกลกว่านั้น คือทำให้ปรับ rate control ของตัวเข้ารหัสวิดีโอได้โดยตรง ผลคือไม่ได้แค่ความเป็นธรรมด้านแบนด์วิดท์ธรรมดา แต่เป็น ความเป็นธรรมตามเกณฑ์คุณภาพที่รับรู้ได้
    • บิตนั้นมีอยู่แล้ว L4S คือการเปลี่ยนความหมายของบิตนั้น เพื่อให้ส่งสัญญาณได้แม่นยำขึ้น
    • ลองค้นดูนิดหน่อย เหมือนจะใช่อันนี้ไหม? https://youtube.com/watch?t=4900&v=RWjbrXxpzVU
      ถ้าลิงก์เวลาไม่ทำงาน ให้ไปที่ 1 ชั่วโมง 21 นาที แก้ไข: ไม่ใช่ อันนี้เป็นสรุปแฮกกาธอน และหาพรีเซนเทชันจริงค่อนข้างยาก

  • สงสัยว่าฝั่งรับแจ้งความคับคั่งกลับไปยังฝั่งส่งอย่างไร เลยลองค้นดู แต่หาได้ยากกว่าที่คิด ประเด็นหลักมีเอกสารอยู่ที่ https://www.rfc-editor.org/info/rfc3168
    พูดง่าย ๆ คือไม่ได้มีแค่แฟล็กเดียว แต่มีราว ๆ สามแฟล็ก มีแฟล็กที่ฝั่งส่งใช้บอกเราเตอร์ว่า รองรับ ECN ได้ แฟล็กที่เราเตอร์ใช้บอกฝั่งรับว่ามีความคับคั่ง และแฟล็กที่ฝั่งรับตั้งค่าเมื่อส่งแพ็กเก็ต ACK
    ฝั่งส่งระบุการรองรับ ECN ด้วย ECT codepoint และเราเตอร์ที่รองรับ ECN จะตั้งค่า CE codepoint ใน IP header แล้วส่งต่อ แทนที่จะทิ้งแพ็กเก็ต ฝั่งรับจะตั้งค่า ECN-Echo ใน TCP ACK ถัดไป และฝั่งส่งจะตอบสนองต่อความคับคั่งเหมือนกรณีแพ็กเก็ตสูญหาย จากนั้นตั้งค่าแฟล็ก CWR ใน TCP header ของแพ็กเก็ตถัดไป

  • Bob Briscoe คิดในแนวทางนี้มานานแล้ว แนะนำบทความคลาสสิกที่เกี่ยวข้องด้านล่าง
    http://www.sigcomm.org/sites/default/files/ccr/papers/2007/A...
    https://dl.acm.org/doi/pdf/10.1145/1080091.1080124

  • มีการทดสอบบางส่วนบนเครือข่ายเคเบิลของ Comcast และสไลด์ด้านล่างอธิบายไว้
    https://datatracker.ietf.org/meeting/118/materials/slides-11...
    ไม่รู้ว่าจะนำไปสู่อะไร แต่เริ่มคิดว่า ISP อาจเริ่มเก็บค่าผ่านทางสำหรับช่องทางด่วนก็ได้

    • L4S จริง ๆ แล้วไม่ใช่ช่องทางด่วน มันทำให้แอปพลิเคชันรู้ว่าทราฟฟิกของตัวเองเริ่มคับคั่งหรือไม่ แล้วลดทราฟฟิกให้เหมาะสมเพื่อบรรเทาความคับคั่ง เมื่อความคับคั่งลดลง latency ก็ลดลงด้วย
    • ไม่รู้มาก่อนว่านี่อยู่เบื้องหลัง การทดสอบ latency ต่ำ ที่เคยเห็นใน dslreports
    • สงสัยว่า ISP จะเก็บค่าผ่านทางช่องทางด่วนจริงหรือไม่ latency น่าจะกลายเป็น ปัจจัยสร้างความแตกต่างในการแข่งขัน อีกอย่างหนึ่ง เหมือน throughput หรือความเร็วในปัจจุบัน
      ความเห็นส่วนตัว แต่ผมทำงานที่ Comcast

  • ถ้าอยากรู้จัก L4S เพิ่มเติม ซีรีส์เว็บบินาร์ที่ understandinglatency.com เริ่มตั้งแต่วันนี้ มีทั้งผู้เขียน L4S บางคน ผู้รับผิดชอบการทดสอบภาคสนาม L4S ของ Comcast และเสียงวิจารณ์เข้าร่วมบรรยาย

  • เจอเดโมสั้น ๆ ที่ใช้งานจริงกับฟีดวิดีโอของรถ RC: https://www.youtube.com/watch?v=RZmS10djDEg

  • เป็นความคืบหน้าในทิศทางที่ถูกต้องก็จริง แต่ถ้ามี ผู้ร่วมระบบที่ประสงค์ร้าย แม้เพียงรายเดียวที่เพิกเฉยต่อ feedback เรื่องความคับคั่งและต้องการแค่ส่วนแบ่งแบนด์วิดท์ที่มากขึ้น ก็จะเกิดปัญหา จากนั้นผู้ร่วมระบบรายอื่นจะถอย และฝ่ายที่ไม่เป็นธรรมก็จะได้สิ่งที่ต้องการไป
    ผู้ร่วมระบบที่ดีมักรู้ได้ยากว่ารายอื่นทำตามกฎหรือไม่ และต้องรู้ว่ามี fair queuing อยู่ จึงจะเชื่อได้ว่า L4S จะจัดการอย่างเป็นธรรม
    ปัญหานี้แก้ได้ด้วยการเสริม L4S ด้วย fair queuing อย่าง fq_codel และทำให้ congestion control ตรวจจับการมีอยู่ของ fair queuing ได้: https://github.com/muxamilian/fair-queuing-aware-congestion-...

    • ISP ส่วนใหญ่มีการจัดสรรแบนด์วิดท์แยกตามลูกค้าอยู่แล้ว ดังนั้นผู้ร่วมระบบที่ประสงค์ร้ายจึงยากจะเอาส่วนแบ่งของลูกค้ารายอื่นไป
      ข้อถกเถียงเรื่อง fair queuing เป็นส่วนหนึ่งของข้อถกเถียงที่ใหญ่กว่า หากไม่มี fair queuing ความเป็นธรรมก็ถูก implement โดย end host อยู่แล้ว ไม่ว่าจะเกี่ยวกับ L4S หรือไม่ และ end host อย่างเซิร์ฟเวอร์ก็สามารถเพิกเฉยต่อการตอบสนองต่อความคับคั่งเพื่อเอามากกว่าส่วนแบ่งที่เป็นธรรมได้ นี่ไม่ใช่ปัญหาใหม่ที่ L4S สร้างขึ้น แต่ก็มีฝ่ายที่มองว่า L4S ทำให้เอาส่วนแบ่งที่มากขึ้นได้ง่ายกว่า
      ผู้สนับสนุน fair queuing มองว่าเครือข่ายควรรับประกันการแบ่งปันอย่างเป็นธรรม แต่ไม่ใช่ทุกคนจะเห็นด้วยกับตัวชี้วัดความเป็นธรรมที่พวกเขาเลือก โดยเฉพาะหนึ่งในผู้สนับสนุนหลักของ L4S ไม่เห็นด้วย และดูได้จากบทความที่ลิงก์ไว้ตรงนี้: https://news.ycombinator.com/item?id=38598023

  • ในมุมผู้ใช้ อยากรู้ว่าในทางปฏิบัติจะเปลี่ยนอะไรบ้าง เช่น วิดีโอคอลจะใกล้เคียง real-time มากขึ้นไหม? ปกติมีดีเลย์ประมาณ 0.5~1 วินาที เลยพูดทับและขัดจังหวะกันบ่อย ๆ ยังมีแอปพลิเคชันอะไรอีกที่ดีขึ้นมาก?

    • อันนี้แก้แค่สาเหตุหนึ่งของ latency ภายในเครือข่ายของ ISP รายเดียว วิดีโอแชตผ่านอินเทอร์เน็ตซับซ้อน เพราะทุกเลเยอร์เป็นแบบ best-effort
      หากต้องการให้บิตเรตต่ำกว่า 3Mbps ต้องแลกกันยากระหว่างคุณภาพ บิตเรต เวลา CPU และ latency แล็ปท็อปทั่วไป CPU ช้า หรือแม้มี CPU 6 คอร์ แต่เมื่อใช้แบตเตอรี่ก็มักคง clock ไว้ต่ำ การเข้ารหัสวิดีโอแบบ hardware acceleration ก็ยังไม่แพร่หลาย ทำให้ต้องเสียคุณภาพและ latency ไป
      Wi-Fi ก็เพิ่ม latency โดยเฉพาะเมื่อแล็ปท็อปทำงานด้วยแบตเตอรี่ บริการวิดีโอแชตจำนวนมากใช้เซิร์ฟเวอร์คลาวด์เป็นตัว relay เพื่อจัดการ NAT ซึ่งเพิ่ม latency เข้าไปอีก
      https://hpbn.co/wifi/#measuring-and-optimizing-wifi-performa...
    • ทำให้ แอปพลิเคชันบนคลาวด์ แบบใหม่ทำงานได้จริงและเสถียร ลองนึกถึง cloud gaming หรือ cloud AR
      ฟังก์ชันที่มีการโต้ตอบสูงอย่างเกมและวิดีโอคอนเฟอเรนซ์ก็ดีขึ้นมากโดยไม่มี latency การเรนเดอร์เว็บเพจ การสตรีมวิดีโอ หรือการจัดการปฏิสัมพันธ์กับ AI assistant อย่าง Alexa ตอนนี้ต้องใช้ round trip จำนวนมาก ดังนั้นแทบทุกอย่างที่ผู้ใช้กับอุปกรณ์โต้ตอบกันก็น่าจะดีขึ้นได้

  • โดยเนื้อแท้แล้ว L4S คือเทคโนโลยีที่ลด latency feedback loop ช่วงท้ายของวิดีโอนี้อธิบายได้ค่อนข้างดี: https://youtu.be/tAVwmUG21OY?si=lydbqfNL80Y8Uxvp