1 คะแนน โดย GN⁺ 2023-12-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ภาพรวมสถาปัตยกรรมบริการอินเทอร์เน็ต L4S

  • เป้าหมายของสถาปัตยกรรม L4S: บรรลุการควบคุมปริมาณงานของแอปพลิเคชันอินเทอร์เน็ตที่มีค่าหน่วงต่ำ การสูญเสียจากความแออัดต่ำ และขยายตัวได้
  • อินไซต์หลัก: สาเหตุรากของค่าหน่วงไม่ใช่ตัวคิวเอง แต่เป็นตัวควบคุมความแออัดแบบสำรวจความจุของฝั่งผู้ส่ง
  • อัลกอริทึมควบคุมความแออัดแบบใหม่: สามารถนำอัลกอริทึมควบคุมความแออัดแบบใหม่มาใช้แทนอัลกอริทึมเดิมที่ทำให้เกิดค่าหน่วงสูง โดยอัลกอริทึมใหม่นี้สามารถสำรวจความจุได้ด้วยค่าหน่วงที่น้อยมาก
  • รูปแบบ ECN ที่ปรับปรุงแล้ว: รองรับผ่านรูปแบบที่ปรับปรุงแล้วของ Explicit Congestion Notification (ECN) ในเครือข่าย ทำให้บรรลุทั้งค่าหน่วงต่ำและปริมาณงานสูงได้พร้อมกัน
  • มุ่งเน้นการปรับใช้แบบค่อยเป็นค่อยไป: กำหนดกลไกให้คลาสการควบคุมความแออัดแบบใหม่และการควบคุมความแออัดแบบ 'คลาสสิก' อยู่ร่วมกันได้บนเครือข่ายที่ใช้ร่วมกัน

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

  • โฮสต์: มีอัลกอริทึมควบคุมความแออัดแบบขยายตัวได้อยู่แล้ว และต่างจากอัลกอริทึมควบคุมความแออัดแบบคลาสสิกเดิมตรงที่แม้อัตราการไหลจะเพิ่มขึ้น เวลาฟื้นตัวก็ยังคงที่
  • เครือข่าย: ทำให้ทราฟฟิก L4S ถูกแยกจากค่าหน่วงของทราฟฟิกแบบคลาสสิก โดยใช้คิวสองชุดเพื่อแยกค่าหน่วง แต่ไม่แยกแบนด์วิดท์
  • โปรโตคอล: ใช้ตัวระบุเพื่อให้โฮสต์แยกแพ็กเก็ต L4S และแพ็กเก็ตแบบคลาสสิกออกจากกันได้ และทำให้เครือข่ายสามารถจัดการแพ็กเก็ตแต่ละประเภทแยกกันได้

ความเห็นของ GN⁺

สิ่งที่สำคัญที่สุดในบทความนี้คือ สถาปัตยกรรม L4S นำเสนอแนวทางใหม่ในการทำให้บริการอินเทอร์เน็ตมีค่าหน่วงต่ำ การสูญเสียต่ำ และปริมาณงานที่ขยายตัวได้ สถาปัตยกรรมนี้ช่วยก้าวข้ามข้อจำกัดของอัลกอริทึมควบคุมความแออัดแบบเดิม และทำให้การสื่อสารมีประสิทธิภาพได้ด้วยการใช้ ECN ซึ่งอาจเป็นหัวข้อที่น่าสนใจสำหรับผู้ออกแบบเครือข่าย ผู้ดูแลระบบ และผู้ใช้งาน และอาจส่งผลสำคัญต่อการพัฒนาอินเทอร์เน็ตในอนาคต

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

 
GN⁺ 2023-12-12
ความเห็นจาก Hacker News
  • สงสัยว่าฝั่งผู้รับแจ้งผู้ส่งเกี่ยวกับความแออัดของเครือข่ายอย่างไร

    • ดูข้อมูลโดยละเอียดได้ในเอกสาร RFC 3168
    • มีแฟลก 3 ตัวที่รองรับ ECN(Efficient Congestion Notification)
      • แฟลก ECT(Echo Congestion Experienced) ที่บอกว่าฝั่งผู้ส่งรองรับ ECN ได้
      • แฟลก CE(Congestion Experienced) ที่เราเตอร์ใช้แจ้งผู้รับว่าเครือข่ายกำลังแออัด
      • แฟลก ECN-Echo ที่ผู้รับตั้งค่าเมื่อส่งแพ็กเก็ต ACK กลับไปยังผู้ส่ง
      • ผู้ส่งเมื่อได้รับแฟลก ECN-Echo จะถือเสมือนว่าเกิดการสูญหายของแพ็กเก็ตและตอบสนองต่อความแออัด
      • ผู้ส่งจะตั้งค่าแฟลก CWR(Congestion Window Reduced) เพื่อแจ้งผู้รับว่ารับรู้และตอบสนองต่อแฟลก ECN-Echo แล้ว
  • ประสบการณ์จากการชมเดโมจริงของเทคโนโลยี ECN

    • ได้ชมเดโมสดของเทคโนโลยี ECN ที่งาน IETF 118
    • ช่วยกำจัด buffer bloat ได้อย่างหมดจด จึงมีประโยชน์มากกับวิดีโอแชต
    • เป็นเทคโนโลยีที่ใส่บิตเพิ่มเติมในแพ็กเก็ต IP เพื่อบอกว่าบัฟเฟอร์เต็มแล้ว ให้ความรู้สึกล้ำยุค
  • แนะนำงานวิจัยที่เกี่ยวข้องของ Bob Briscoe

    • แนะนำให้อ่านบทความคลาสสิกของ Bob Briscoe ผู้ทุ่มเทเวลาศึกษาเรื่อง ECN มาอย่างยาวนาน
  • การทดสอบ L4S บนเครือข่ายของ Comcast

    • แชร์ชุดสไลด์ที่สรุปผลการทดสอบ L4S บนเคเบิลแพลนต์
    • คาดเดาว่า ISP อาจเก็บค่าผ่านทางสำหรับเลนความเร็วสูง
  • พบเดโมวิดีโอฟีดของรถ RC ที่ใช้เทคโนโลยี L4S

    • แชร์ลิงก์วิดีโอเดโมที่ใช้เทคโนโลยี L4S กับวิดีโอฟีดของรถ RC
  • แนะนำซีรีส์เว็บบินาร์เกี่ยวกับ L4S

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

    • มีคอมเมนต์อยากให้ออกเสียง L4S ว่า "L-Force"
  • ปัญหาเรื่องความเป็นธรรมของ L4S และแนวทางแก้ไข

    • อาจเกิดปัญหาเมื่อมีผู้ใช้งาน 'ไม่หวังดี' ที่เมินสัญญาณตอบกลับเรื่องความแออัดและพยายามยึดแบนด์วิดท์ส่วนใหญ่ไป
    • แนวทางแก้คือเสริม L4S ด้วย fair queuing และทำให้การควบคุมความแออัดสามารถตรวจจับ fair queuing ได้
    • แชร์ลิงก์ GitHub เกี่ยวกับการควบคุมความแออัดแบบรับรู้ fair queuing
  • แชร์วิดีโออธิบายการลดวงจรป้อนกลับของ latency ใน L4S

    • แชร์ลิงก์วิดีโอที่อธิบายว่า L4S ลดวงจรป้อนกลับของ latency อย่างไร
  • ความสับสนเกี่ยวกับการปรับปรุงวิดีโอคอนเฟอเรนซ์และสตรีมมิง

    • แสดงความสับสนว่าวิดีโอคอนเฟอเรนซ์และสตรีมมิงใช้ UDP แล้ว L4S ที่อิงกับ TCP จะช่วยปรับปรุงได้อย่างไร