Dịch vụ Internet L4S cung cấp độ trễ thấp, mất gói thấp và thông lượng có thể mở rộng: RFC 9330

 (datatracker.ietf.org)
1 điểm bởi GN⁺ 2023-12-12 | 1 bình luận | Chia sẻ qua WhatsApp

Tổng quan về kiến trúc dịch vụ Internet L4S

  • Mục tiêu của kiến trúc L4S: đạt được độ trễ thấp, mất mát do tắc nghẽn thấp và khả năng kiểm soát thông lượng có thể mở rộng cho các ứng dụng Internet
  • Nhận định cốt lõi: nguyên nhân gốc rễ của độ trễ không nằm ở bản thân hàng đợi mà nằm ở bộ điều khiển tắc nghẽn dò tìm dung lượng của phía gửi
  • Thuật toán điều khiển tắc nghẽn mới: thay vì các thuật toán điều khiển tắc nghẽn hiện có gây ra độ trễ lớn, có thể áp dụng các thuật toán mới có khả năng dò tìm dung lượng với độ trễ rất thấp
  • Dạng ECN được điều chỉnh: được hỗ trợ thông qua một dạng Thông báo tắc nghẽn tường minh (ECN) đã được điều chỉnh trong mạng, cho phép đồng thời đạt được độ trễ thấp và thông lượng cao
  • Tập trung vào triển khai dần dần: định nghĩa cơ chế để lớp điều khiển tắc nghẽn mới và điều khiển tắc nghẽn 'cổ điển' có thể cùng tồn tại trong mạng dùng chung

Các thành phần của kiến trúc L4S

  • Host: các thuật toán điều khiển tắc nghẽn có thể mở rộng đã tồn tại; khác với các thuật toán điều khiển tắc nghẽn cổ điển hiện có, thời gian phục hồi vẫn giữ ổn định ngay cả khi tốc độ luồng tăng lên
  • Mạng: đảm bảo lưu lượng L4S được cách ly khỏi độ trễ của lưu lượng cổ điển, sử dụng hai hàng đợi để tách biệt độ trễ nhưng không tách biệt băng thông
  • Giao thức: sử dụng định danh để host có thể phân biệt gói L4S và gói cổ điển, đồng thời cho phép mạng xử lý riêng từng loại gói

Ý kiến của GN⁺

Điểm quan trọng nhất của bài viết này là kiến trúc L4S đưa ra một cách tiếp cận mới nhằm đạt được độ trễ thấp, mất gói thấp và thông lượng có thể mở rộng cho dịch vụ Internet. Kiến trúc này vượt qua các giới hạn của các thuật toán điều khiển tắc nghẽn hiện có và cho phép truyền thông hiệu quả bằng cách tận dụng ECN. Đây có thể là một chủ đề thú vị đối với các nhà thiết kế mạng, nhà vận hành và người dùng, đồng thời có thể tạo ra ảnh hưởng quan trọng đối với sự phát triển tương lai của Internet.

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-12-12
Ý kiến trên Hacker News

  • Thắc mắc về cách bên nhận thông báo cho bên gửi về tình trạng tắc nghẽn mạng

    • Có thể xem chi tiết trong tài liệu RFC 3168
    • Có ba cờ hỗ trợ ECN (Efficient Congestion Notification)
      • Cờ ECT (Echo Congestion Experienced) cho biết bên gửi có thể hỗ trợ ECN
      • Cờ CE (Congestion Experienced) để router thông báo cho bên nhận rằng đang có tắc nghẽn
      • Cờ ECN-Echo được bên nhận thiết lập khi gửi gói ACK cho bên gửi
      • Bên gửi nhận cờ ECN-Echo và giả định rằng đã có mất gói, rồi phản ứng với tắc nghẽn
      • Bên gửi thiết lập cờ CWR (Congestion Window Reduced) để thông báo cho bên nhận rằng đã nhận biết và phản ứng với cờ ECN-Echo

  • Trải nghiệm xem bản demo thực tế của công nghệ ECN

    • Đã xem bản demo trực tiếp về công nghệ ECN tại IETF 118
    • Loại bỏ hoàn toàn buffer bloat, nên rất hữu ích cho gọi video
    • Đây là công nghệ chèn thêm bit vào gói IP để báo rằng bộ đệm đã đầy, tạo cảm giác như một công nghệ của tương lai

  • Gợi ý đọc các nghiên cứu liên quan của Bob Briscoe

    • Đề xuất các bài báo kinh điển của Bob Briscoe, người đã dành nhiều năm nghiên cứu về ECN

  • Thử nghiệm L4S trên mạng Comcast

    • Chia sẻ bộ slide chứa kết quả thử nghiệm L4S trên hạ tầng cáp
    • Suy đoán rằng ISP có thể sẽ thu phí cho một "làn ưu tiên tốc độ cao"

  • Tìm thấy bản demo luồng video xe RC sử dụng công nghệ L4S

    • Chia sẻ liên kết tới video demo dùng công nghệ L4S cho luồng video của xe RC

  • Giới thiệu chuỗi webinar về L4S

    • Nếu muốn tìm hiểu thêm về L4S, có thể bắt đầu với chuỗi webinar tại understandinglatency.com
    • Các diễn giả gồm tác giả của L4S, người phụ trách thử nghiệm thực địa L4S của Comcast, và cả những tiếng nói phản biện

  • Gợi ý hài hước về cách phát âm L4S

    • Một bình luận bày tỏ mong muốn phát âm L4S là "L-Force"

  • Vấn đề công bằng của L4S và cách giải quyết

    • Vấn đề phát sinh khi có những tác nhân "ác ý" phớt lờ phản hồi tắc nghẽn để chiếm phần băng thông lớn hơn
    • Giải pháp là bổ sung cho L4S bằng fair queuing, và để cơ chế điều khiển tắc nghẽn có thể phát hiện fair queuing
    • Chia sẻ liên kết GitHub về cơ chế điều khiển tắc nghẽn nhận biết fair queuing

  • Giải thích về việc L4S rút ngắn vòng phản hồi độ trễ

    • Chia sẻ liên kết video giải thích cách L4S giảm vòng phản hồi độ trễ

  • Sự bối rối về cải thiện cho hội nghị video và streaming

    • Bày tỏ sự bối rối về việc hội nghị video và streaming dùng UDP, vậy L4S dựa trên TCP đóng góp cải thiện như thế nào