Dịch vụ Internet L4S cho độ trễ thấp, tổn thất thấp và thông lượng có khả năng mở rộng: RFC 9330
(datatracker.ietf.org)- RFC 9330 định nghĩa kiến trúc L4S nhằm giảm độ trễ hàng đợi và mất mát do tắc nghẽn của các ứng dụng Internet, và xem nguyên nhân gốc rễ của độ trễ nằm ở cơ chế kiểm soát tắc nghẽn kiểu dò tìm dung lượng của bên gửi hơn là ở bản thân hàng đợi
- L4S kết hợp Scalable congestion control ở host gửi, AQM tại điểm nghẽn và giao thức dựa trên ECN; để nhận diện gói L4S, nó sử dụng codepoint ECT(1) trong trường IP-ECN
- Độ trễ hàng đợi mục tiêu là trung bình dưới 1ms và phân vị 99 khoảng dưới 2ms; trong ví dụ DCTCP và Dual-Queue Coupled AQM, ngay cả khi quá tải, độ trễ hàng đợi ở phân vị 99 cũng ở mức khoảng 1~2ms
- Để cùng tồn tại với kiểm soát tắc nghẽn Classic thuộc họ Reno/CUBIC hiện có, L4S được thiết kế để tách biệt độ trễ của lưu lượng Classic và lưu lượng L4S, nhưng không chia cố định băng thông mà chia sẻ về dài hạn
- L4S bổ trợ hơn là thay thế Diffserv, FQ-CoDel, PIE và BBR; TCP cần phản hồi chính xác như AccECN, còn QUIC và DCCP đã cung cấp phản hồi ECN cần thiết cho L4S
Vấn đề độ trễ mà L4S muốn giải quyết
- Ngày càng có nhiều tình huống trong đó lưu lượng ưu tiên độ trễ thấp như web, thoại, hội nghị video, game, desktop từ xa, ứng dụng đám mây, AR/VR và điều khiển từ xa lấp đầy liên kết nghẽn
- Việc đặt cache và server gần người dùng đã giảm độ trễ truyền lan, nhưng hàng đợi vẫn là một thành phần chính và xuất hiện từng lúc của độ trễ
- Ngay cả khi có AQM hiện đại, các spike độ trễ hàng trăm ms không phải là hiếm
- Classic AQM thường được cấu hình để đệm biến động hàng đợi dạng răng cưa của một flow dài hạn đơn lẻ, nên trong các flow dài hạn, đỉnh độ trễ toàn mạng có thể xấp xỉ gấp đôi độ trễ đường đi cơ bản
- Mục tiêu của L4S là độ trễ hàng đợi rất thấp, mất mát rất thấp và thông lượng có khả năng mở rộng
- Độ trễ hàng đợi rất thấp nghĩa là trung bình dưới 1ms, phân vị 99 khoảng dưới 2ms
- Các ứng dụng tương tác khắt khe hơn bắt đầu tạo cảm giác không tự nhiên khi độ trễ đầu cuối vượt quá 50ms hoặc 20ms
- Vì mất gói dẫn đến độ trễ truyền lại trong các ứng dụng tương tác, mất mát thấp cũng là mục tiêu cốt lõi
Nguyên nhân độ trễ: kiểm soát tắc nghẽn Classic hơn là hàng đợi
- L4S xem nguyên nhân gốc rễ của độ trễ hàng đợi nằm ở kiểm soát tắc nghẽn kiểu dò tìm dung lượng của bên gửi hơn là ở bản thân hàng đợi
- Kiểm soát tắc nghẽn Classic như Reno, CUBIC làm mức chiếm dụng hàng đợi thay đổi theo dạng răng cưa lớn
- Nếu AQM đặt hàng đợi quá nông, kiểm soát tắc nghẽn Classic không thể tận dụng đúng mức liên kết ở mỗi đáy của răng cưa
- Khi tốc độ flow tăng, thời gian phục hồi của kiểm soát tắc nghẽn Classic dài hơn, khiến việc kiểm soát hàng đợi và mức sử dụng trở nên lỏng lẻo
- Scalable congestion control giữ thời gian trung bình giữa các tín hiệu tắc nghẽn, tức thời gian phục hồi, ở mức không đổi ngay cả khi tốc độ flow tăng
- DCTCP là ví dụ được dùng rộng rãi trong môi trường được kiểm soát
- Nó đã được triển khai và phân phối trong Windows Server Editions, Linux và FreeBSD
- Prague over TCP/QUIC, SCReAM cho L4S và phần L4S ECN của BBRv2 cũng nằm trong các ví dụ về Scalable congestion control
Ba thành phần của kiến trúc L4S
- L4S gồm ba thành phần
- Scalable congestion control ở host gửi
- AQM tại điểm nghẽn mạng
- Giao thức dựa trên ECN chịu trách nhiệm nhận diện gói và tín hiệu tắc nghẽn giữa hai thành phần trên
- Độ trễ thấp không do mạng trực tiếp cung cấp, mà đến từ hành vi Scalable congestion control cẩn trọng của bên gửi L4S
- Vai trò chính của mạng là cô lập độ trễ thấp của lưu lượng L4S khỏi độ trễ hàng đợi lớn hơn mà lưu lượng Classic cần
- Mạng dùng ECN để báo ngay cho tầng truyền tải về những dấu hiệu rất sớm của việc hàng đợi tăng
- Không đợi làm trơn mạnh biến động hàng đợi rồi mới phát tín hiệu như Classic AQM
- Hỗ trợ ECN là bắt buộc đối với L4S
- Bên gửi dùng trường ECN để giúp mạng phân biệt gói L4S với gói Classic
ECN và codepoint ECT(1)
- L4S cần tín hiệu tắc nghẽn tinh vi hơn, thoát khỏi ràng buộc của Classic ECN rằng “tín hiệu ECN phải được xử lý tương đương với drop”
- Tín hiệu phải có thể xuất hiện thường xuyên hơn
- Phải có thể phát tín hiệu ngay lập tức mà không cần độ trễ lớn để làm trơn biến động hàng đợi
- RFC8311 nới lỏng một số yêu cầu của RFC3168, cho phép thử nghiệm L4S
- RFC9331 quy định dùng ECT(1) làm định danh gói L4S
- Codepoint CE được dùng để biểu thị Congestion Experienced trong cả xử lý L4S và Classic
- Nếu Classic AQM ở phía trước đường đi đánh dấu gói ECT(0) thành CE, có nguy cơ gói bị phân loại nhầm vào hàng đợi L4S
- Theo Phụ lục B của RFC9331, để phát sinh tác động có hại, năm điều kiện hiếm gặp phải đồng thời xảy ra; ngay cả khi đó, khả năng truyền lại sai cũng cực nhỏ
- Nhà vận hành có thể muốn đưa lưu lượng không phải L4S đủ thấp và mượt để không tạo hàng đợi vào hàng đợi L4S
- Ví dụ gồm VoIP, datagram tốc độ thấp để đồng bộ game trực tuyến, DNS, LDAP, v.v.
- Trong trường hợp này cần dấu hiệu riêng như EF, NQB hoặc định danh theo nhà vận hành
Dual-Queue Coupled AQM
- L4S hướng tới việc thành phần mạng cung cấp độ trễ thấp mà không nhất thiết phải xử lý theo từng flow
- Thiết kế tiêu biểu Dual-Queue Coupled AQM dùng hai hàng đợi
- Hàng đợi L4S duy trì độ trễ thấp
- Hàng đợi Classic có thể có hàng đợi lớn hơn cần thiết để lưu lượng Classic duy trì mức sử dụng liên kết
- DualQ được thiết kế để hoạt động như một màng bán thấm, tách độ trễ nhưng không chia cố định băng thông
- Classic AQM tạo xác suất drop/mark dựa trên tắc nghẽn của hàng đợi của mình, rồi liên kết nó với tín hiệu của hàng đợi Classic và hàng đợi L4S
- Tín hiệu tắc nghẽn đã liên kết khiến các flow L4S giảm tốc độ để chừa lại dung lượng cần thiết cho các flow Classic
- Scheduler có thể ưu tiên hàng đợi L4S
- Ở thang thời gian ngắn, nó nhanh chóng giải tỏa burst L4S để bảo vệ độ trễ thấp
- Ở thang thời gian dài hơn một round-trip time, việc liên kết tín hiệu tắc nghẽn của hàng đợi Classic triệt tiêu ưu thế băng thông và tạo ra sự công bằng xấp xỉ theo từng flow
- Khi chỉ có lưu lượng L4S, AQM của hàng đợi L4S bắt đầu đánh dấu tắc nghẽn ở hàng đợi rất nông để duy trì độ trễ hàng đợi thấp
Khác biệt giữa hàng đợi theo từng flow và DualQ
- Hàng đợi theo từng flow như FQ-CoDel, FQ-PIE cũng có thể dùng cho L4S
- Trên Linux, chúng đã được sửa để có thể chỉ áp dụng ngưỡng đánh dấu ECN nông cho các gói ECT(1)
- Classic AQM được áp dụng cho flow Not-ECT hoặc ECT(0), còn flow ECT(1) thường áp dụng ngưỡng nông dưới ms
- Cách tiếp cận theo từng flow tách hàng đợi của mỗi flow, nhưng không loại bỏ được việc xếp hàng do chính flow đó tạo ra
- Cách DualQ không yêu cầu kiểm tra sâu hơn tầng IP vì định danh L4S nằm trong trường IP-ECN
- Có thể dùng cả trong môi trường nơi định danh tầng truyền tải bị mã hóa, như IPsec hoặc tunnel VPN mã hóa
- Cách theo từng flow khiến mạng đảm nhiệm việc kiểm soát tốc độ tương đối giữa các flow ứng dụng
- DualQ tách vấn đề cung cấp độ trễ thấp khỏi vấn đề kiểm soát tốc độ flow, và có thể bổ sung policing tốc độ flow riêng nếu cần
Yêu cầu phía host
- Bên gửi phải triển khai Scalable congestion control
- DCTCP là ví dụ được dùng rộng rãi nhất, nhưng cần cải thiện an toàn và hiệu năng để dùng trên Internet công cộng
- Các phần trong yêu cầu Prague L4S liên quan đến nguy cơ gây hại cho người khác được đưa vào các yêu cầu chuẩn tắc của RFC9331
- TCP Prague được triển khai làm bản tham chiếu trên Linux
- Các giao thức truyền tải ngoài TCP cũng phải triển khai phản ứng tắc nghẽn Scalable và biểu thị nó bằng codepoint ECT(1) để dùng dịch vụ L4S
- Biến thể Scalable cho QUIC đang được xem xét
- Phần L4S ECN của BBRv2 được đề xuất như Scalable congestion control cho TCP, QUIC, v.v.
- Biến thể L4S của SCReAM cho media RTP cũng đã được triển khai
- Trạng thái phản hồi ECN khác nhau theo từng giao thức
- DCCP và QUIC cung cấp phản hồi ECN đủ chi tiết cho L4S
- Phản hồi ECN hiện có của TCP dựa trên giả định xem ECN mark tương đương với drop, nên không thể dùng cho Scalable TCP
- Bên nhận TCP cần hỗ trợ AccECN, tức phản hồi ECN chính xác hơn
- SCTP cần triển khai và phân phối thiết kế ECN mới để hỗ trợ L4S
- RTP đã định nghĩa phản hồi ECN đủ dùng trong RFC6679 và RFC8888
Vì sao cần tín hiệu tắc nghẽn tường minh
- L4S dùng tín hiệu tắc nghẽn tường minh làm phương tiện cốt lõi thay vì mất gói
- Drop vừa là suy giảm hiệu năng vừa là tín hiệu, tạo ra căng thẳng giữa “hư hại càng ít càng tốt” và “tín hiệu càng nhiều càng tốt”
- Tín hiệu tường minh dựa trên ECN có thể dùng nhiều lần mỗi round-trip time mà không gây hư hại, nên có lợi cho việc giữ hàng đợi ngắn
- L4S chuyển việc làm trơn từ mạng sang host
- Mạng không biết RTT của từng flow, nên trong cách Classic phải giả định RTT tệ nhất
- Vì vậy tín hiệu tắc nghẽn Classic có thể bị trễ 100~200ms
- Mỗi host biết RTT của mình nên có thể chỉ làm trơn ở mức cần thiết, thường ở mức vài ms
- Hàng đợi L4S dùng biến thể L4S ECN mới không tương đương với drop, còn hàng đợi Classic dùng Classic ECN hoặc drop
Cơ sở của khả năng mở rộng thông lượng
- Kiểm soát tắc nghẽn Classic Reno có thời gian phục hồi dài hơn khi bước vào môi trường có tích băng thông-độ trễ cao
- Điều kiện ví dụ là RTT tối đa 30ms tại đỉnh răng cưa
- Khi tốc độ gói Reno tăng 8 lần từ 1.250packet/s lên 10.000packet/s, tương ứng tăng từ khoảng 15Mb/s lên 120Mb/s với gói 1500B, thời gian phục hồi tăng từ 422ms lên 3,38s
- CUBIC hoạt động ở chế độ Reno-friendly tại 120Mb/s và mất khoảng 4,3s để phục hồi
- Ở 960Mb/s, nó chuyển sang true CUBIC mode và thời gian phục hồi là 12,2s
- Ở 7,68Gb/s, thời gian phục hồi tăng tới 24,3s
- Scalable congestion control như DCTCP hay Prague trung bình tạo ra 2 tín hiệu tắc nghẽn mỗi RTT, và đặc tính này được duy trì bất kể tốc độ flow
- Năm 2020, dung lượng truy cập cố định trung bình toàn cầu là 103Mb/s, và năm 2019 RTT cơ bản trung bình tới CDN là 25~34ms
- Một flow tải xuống CUBIC đơn lẻ, ngay cả trong trường hợp tốt nhất, có thể mất khoảng 200 RTT, tức 5 giây, để phục hồi sau khi cửa sổ tắc nghẽn giảm
Quan hệ với các công nghệ hiện có
- Diffserv xử lý phân bổ băng thông cho lưu lượng quan trọng và độ trễ hàng đợi của lưu lượng nhạy cảm với độ trễ, nhưng L4S chỉ xử lý vấn đề độ trễ hàng đợi
- Diffserv hiệu quả khi chỉ một phần lưu lượng tại điểm nghẽn yêu cầu độ trễ thấp
- Nếu toàn bộ lưu lượng tại điểm nghẽn đều muốn độ trễ thấp, lợi thế phân biệt của Diffserv biến mất
- Định danh L4S không biểu thị yêu cầu chất lượng, mà biểu thị cam kết hành vi là phản ứng tắc nghẽn Scalable
- Classic AQM như PIE, FQ-CoDel giảm đáng kể độ trễ hàng đợi so với khi không có AQM
- L4S bổ trợ cho chúng và không thay thế nhu cầu triển khai rộng rãi chúng
- Chỉ AQM khó loại bỏ căng thẳng giữa độ trễ và mức sử dụng liên kết do răng cưa lớn của kiểm soát tắc nghẽn Classic
- ABE thay đổi phản ứng của host với ECN marking để tăng mức sử dụng liên kết và thông lượng flow ECN, nhưng giả định rằng mạng vẫn xử lý ECN và drop như nhau
- BBR kiểm soát độ trễ hàng đợi theo kiểu đầu cuối mà không cần logic mạng đặc biệt
- BBR giữ độ trễ hàng đợi ở mức hợp lý thấp, nhưng không thấp như L4S
- BBRv2 có thể dùng L4S ECN và hành vi kiểm soát tắc nghẽn Scalable L4S nếu có thể
Ứng dụng có thể áp dụng
- L4S có thể cải thiện đáng kể chất lượng của các ứng dụng hiện có trong điều kiện tải
- Game và cloud gaming
- VoIP
- Hội nghị video
- Duyệt web
- Streaming video thích ứng
- Nhắn tin tức thời
- Độ trễ hàng đợi thấp hơn mở ra các khả năng như video tương tác dựa trên đám mây và VR/AR dựa trên đám mây
- Trong demo L4S, video tương tác dựa trên đám mây và VR cùng hoạt động trong tình huống nhiều ứng dụng nhạy cảm với độ trễ và tải xuống cùng chia sẻ một hàng đợi nghẽn trên liên kết truy cập băng rộng 40Mb/s
- Với độ trễ cơ bản đầu cuối 7ms, độ trễ hàng đợi bổ sung ở mức khoảng 1ms
- Với AQM thay thế, video bám theo cử chỉ ngón tay và chuyển động đầu một cách rõ rệt
- Tác vụ pan video bằng thao tác vuốt ngón tay hoặc chuyển động đầu có yêu cầu độ trễ nghiêm ngặt hơn nhiều so với VoIP
- Telepresence tương tác từ xa và điều khiển từ xa có hỗ trợ video cho máy móc/quy trình công nghiệp khó đáng tin cậy nếu không có độ trễ hàng đợi rất thấp
Mô hình triển khai và đưa vào từng bước
- L4S AQM không phải là cấu trúc chỉ phát huy tác dụng khi được triển khai trên toàn bộ Internet
- Mạng truy cập Internet công cộng thường được thiết kế để điểm nghẽn phát sinh trên một liên kết logic đã biết theo từng site
- Site bao gồm hộ gia đình, thiết bị di động, mạng campus/doanh nghiệp vừa và nhỏ, v.v.
- Đây là khái quát áp dụng cho nhiều công nghệ truy cập như xDSL, cáp, PON, cellular, không dây, vệ tinh
- Với downstream, có thể thu được phần lớn lợi ích bằng cách triển khai L4S AQM tại điểm vào của liên kết nghẽn; với upstream, điều tương tự áp dụng nếu triển khai tại điểm vào của liên kết upstream
- Để một flow L4S được hưởng lợi, thường cần ba yếu tố
- Kiểm soát tắc nghẽn của bên gửi
- AQM tại điểm nghẽn
- Với các truyền tải cũ như TCP, phản hồi bên nhận đã được nâng cấp
- Thứ tự triển khai có thể đa dạng
- Có thể tận dụng DCTCP đã tồn tại trong môi trường thử nghiệm được kiểm soát
- Khi triển khai TCP Prague và AccECN, có thể dùng L4S trong môi trường Internet công cộng
- Vì QUIC ngay từ đầu đã hỗ trợ phản hồi ECN cần thiết cho L4S, việc triển khai kiểm soát tắc nghẽn Prague phía gửi đơn giản hơn
Ràng buộc theo từng công nghệ liên kết
- Wi-Fi, PON và cáp gom nhiều dữ liệu gói thành burst và đệm các gói đến trong lúc tạo burst
- Ethernet và DSL không thực hiện kiểu gom gói này
- Việc đệm để gom gói này không thể được bên gửi giảm bớt, nên không nên tính là hàng đợi do AQM kiểm soát
- Các liên kết không dây như cellular, Wi-Fi và vệ tinh có dung lượng có thể thay đổi nhanh và lớn, nên hàng đợi thường trú để tận dụng đột biến tăng dung lượng được xem là điều đáng muốn
- Mạng cellular phức tạp hơn do yêu cầu đệm để làm cho handover không bị nhận thấy
- L4S không thể loại bỏ mọi nhu cầu đệm như vậy
- Nếu loại bỏ “cột trụ dài nhất” là việc đệm cho răng cưa lớn của kiểm soát tắc nghẽn Classic, sẽ có động lực giảm thêm các yếu tố đệm khác như kích thước burst gom gói hoặc khoảng lập lịch MAC
Điểm nghẽn không phải L4S và xử lý mất mát
- Ngay cả khi L4S được kích hoạt giữa hai host, nếu điểm nghẽn không hỗ trợ ECN, bên gửi L4S phải cùng tồn tại an toàn với Reno khi gặp drop
- Quy tắc này bảo vệ lưu lượng Classic nhưng làm suy giảm dịch vụ L4S khi có mất gói
- Mất gói tại điểm nghẽn tạm thời do burst của hàng đợi nông
- Lỗi truyền dẫn như nhiễu điện
- Policing tốc độ
- Ba cách tiếp cận để xử lý việc này hiện là lĩnh vực nghiên cứu
- Bỏ qua một số mất mát ít có khả năng do tắc nghẽn trong kiểm soát tắc nghẽn Prague
- Phục hồi lỗi truyền dẫn bằng tổ hợp RACK, L4S và truyền lại trên liên kết không tái sắp xếp
- Policer tốc độ lai ECN/drop
- Các kịch bản triển khai ít gặp vấn đề này, như mạng có dây, có thể được tiến hành song song với nghiên cứu đó
Bảo mật và policing lưu lượng
- Internet hiện nay thường xử lý việc tách dung lượng liên kết chia sẻ giữa các site bằng scheduler, và không phổ biến policing tốc độ của từng flow ứng dụng riêng lẻ
- L4S được thiết kế để không phá vỡ trạng thái này
- DualQ được thiết kế để không đem lại lợi thế tốc độ lớn hơn cho flow không phản hồi so với AQM một hàng đợi
- Nếu cần policing tốc độ theo từng flow, có thể bổ sung độc lập với phân biệt L4S/Classic
- L4S được thiết kế để giảm độ trễ mà không làm hại độ trễ hoặc tốc độ của lưu lượng Classic, nên không cần policing tốc độ quyền truy cập dịch vụ L4S chỉ để bảo vệ Classic
- Một số nhà vận hành có thể chỉ cung cấp dịch vụ L4S cho nhóm giới hạn như khách hàng premium
- Khi đó có thể dùng thêm định danh cục bộ như dải địa chỉ nguồn cùng với trường ECN
- Nếu định danh cục bộ không khớp, có thể gửi vào hàng đợi Classic ngay cả khi có ECT(1)
- Dịch vụ L4S không chỉ cần tiết chế về tốc độ mà còn về tính burst
- Hàm bảo vệ hàng đợi độ trễ thấp cho DOCSIS là cách chuyển hướng một phần các flow tạo hàng đợi sang hàng đợi Classic để duy trì độ trễ thấp
- Chức năng bảo vệ một hàng đợi không phải là thành phần bắt buộc của kiến trúc L4S; một phần của thử nghiệm L4S là xác định có cần chức năng như vậy hay không
Tunnel và quyền riêng tư
- Vì L4S AQM phát tín hiệu tắc nghẽn bằng trường ECN, khi hoạt động bên trong tunnel hoặc ở tầng thấp hơn, trường ECN phải được truyền giữa các tầng theo đúng tiêu chuẩn
- Kiến trúc L4S không loại trừ cách kiểm tra định danh tầng truyền tải
- Ví dụ là FQ-CoDel đã được bổ sung hỗ trợ L4S
- Đổi mới cốt lõi là DualQ AQM không yêu cầu kiểm tra sâu hơn header IP ngoài cùng
- Người dùng không cần từ bỏ độ trễ thấp ngay cả khi mã hóa định danh flow ứng dụng bằng IPsec hoặc tunnel VPN mã hóa
- Vì L4S có thể cung cấp độ trễ thấp cho một tập ứng dụng rộng, nhu cầu phân biệt từng ứng dụng hoặc lớp chi tiết khi đi qua mạng sẽ giảm đi
1 bình luận
Ý kiến trên Hacker News
Cái này thực sự rất hay. Tháng trước tôi đã xem demo trực tiếp tại IETF 118 ở Prague, và nó dường như loại bỏ hoàn toàn bufferbloat, nên có vẻ cực kỳ phù hợp cho trò chuyện video
Có vẻ như cần thêm một bit để mang thông tin kiểu như bộ đệm IP packet đã đầy hay chưa, nhưng nó thực sự hoạt động, và tạo cảm giác kiểu “không ngờ chuyện này lại khả thi”
Ai không dùng được liên kết theo mốc thời gian thì là tại phút 1 giờ 21. Chỉnh sửa: không phải, đây là phần tổng kết hackathon, và không dễ tìm được bài trình bày
Tôi tò mò không biết bên nhận báo cho bên gửi về tình trạng tắc nghẽn như thế nào nên đã tìm thử, nhưng khó tìm hơn tôi nghĩ. Điểm mấu chốt được ghi lại trong https://www.rfc-editor.org/info/rfc3168
Nói đơn giản thì không chỉ có một cờ mà cỡ ba cờ. Có cờ để bên gửi báo cho router biết là có hỗ trợ ECN, cờ để router báo cho bên nhận biết có tắc nghẽn, và cờ mà bên nhận đặt khi gửi ACK packet
Bên gửi biểu thị hỗ trợ ECN bằng codepoint ECT, và router có hỗ trợ ECN sẽ không loại bỏ packet mà thay vào đó đặt codepoint CE trong IP header rồi chuyển tiếp. Bên nhận sẽ đặt ECN-Echo trong TCP ACK kế tiếp, còn bên gửi sẽ phản ứng với tắc nghẽn giống như khi mất packet rồi đặt cờ CWR trong TCP header của packet tiếp theo
Bob Briscoe đã theo đuổi hướng tư duy này từ rất lâu. Tôi đề xuất các bài kinh điển liên quan dưới đây
http://www.sigcomm.org/sites/default/files/ccr/papers/2007/A...
https://dl.acm.org/doi/pdf/10.1145/1080091.1080124
Một số thử nghiệm đã được tiến hành trên mạng cáp của Comcast, và bộ slide dưới đây giải thích điều đó
https://datatracker.ietf.org/meeting/118/materials/slides-11...
Tôi không biết nó sẽ đi đến đâu, nhưng có cảm giác ISP có thể sẽ bắt đầu thu phí cho làn tốc độ cao
Ý kiến cá nhân thôi, nhưng tôi làm ở Comcast
Nếu muốn tìm hiểu thêm về L4S, chuỗi webinar trên understandinglatency.com bắt đầu từ hôm nay. Một số tác giả của L4S, người phụ trách thử nghiệm L4S ngoài thực địa của Comcast, và cả những tiếng nói chỉ trích cũng sẽ trình bày
Tôi tìm được một demo ngắn cho thấy việc sử dụng thực tế với luồng video từ xe RC: https://www.youtube.com/watch?v=RZmS10djDEg
Đây là một bước tiến theo đúng hướng, nhưng sẽ có vấn đề nếu chỉ cần một tác nhân xấu muốn bỏ qua phản hồi tắc nghẽn để giành phần băng thông lớn hơn. Khi đó những bên khác sẽ lùi lại và phía chơi không công bằng sẽ lấy được thứ họ muốn
Những bên chơi đẹp rất khó biết những bên khác có tuân thủ quy tắc hay không, và họ cần biết có fair queuing thì mới tin rằng L4S sẽ xử lý công bằng
Có thể giải quyết vấn đề này bằng cách bổ sung cho L4S bằng fair queuing như fq_codel, rồi để cơ chế kiểm soát tắc nghẽn có thể phát hiện sự tồn tại của fair queuing: https://github.com/muxamilian/fair-queuing-aware-congestion-...
Tranh luận về fair queuing là một phần của cuộc tranh luận lớn hơn. Nếu không có fair queuing thì bất kể có L4S hay không, tính công bằng vốn đã do host đầu cuối triển khai, và các host đầu cuối như server có thể phớt lờ phản ứng với tắc nghẽn để lấy nhiều hơn phần công bằng. Đây không phải vấn đề mới do L4S tạo ra, nhưng cũng có quan điểm cho rằng L4S khiến việc chiếm phần lớn hơn trở nên dễ hơn
Những người ủng hộ fair queuing cho rằng mạng phải đảm bảo việc chia sẻ công bằng, nhưng không phải ai cũng đồng ý với thước đo công bằng mà họ chọn. Đặc biệt, một trong những người ủng hộ chính của L4S không đồng ý, và có thể xem điều đó trong bài báo được liên kết ở đây: https://news.ycombinator.com/item?id=38598023
Tôi tò mò từ góc nhìn người dùng thì thực tế sẽ khác đi thế nào. Ví dụ, gọi video có trở nên gần với thời gian thực hơn không? Thường vẫn có độ trễ khoảng 0,5~1 giây nên hay bị ngắt nhịp và chồng lời khi nói chuyện. Còn ứng dụng nào khác sẽ được cải thiện đáng kể?
Để giữ bitrate dưới 3Mbps cần những đánh đổi khó khăn giữa chất lượng, bitrate, thời gian CPU và độ trễ. Laptop phổ thông thì CPU chậm, hoặc dù có CPU 6 lõi thì khi dùng pin cũng giữ xung nhịp thấp. Mã hóa video tăng tốc phần cứng cũng chưa phổ biến nên chất lượng và độ trễ đều bị hy sinh
Wi‑Fi cũng làm tăng độ trễ, đặc biệt là khi laptop chạy bằng pin. Để xử lý NAT, nhiều dịch vụ chat video dùng server đám mây làm relay, càng làm tăng thêm độ trễ
https://hpbn.co/wifi/#measuring-and-optimizing-wifi-performa...
Các tính năng có tính tương tác cao như game và hội nghị video cũng sẽ tốt hơn rất nhiều mà không có độ trễ. Hiện tại cần rất nhiều lượt khứ hồi để render trang web, stream video hoặc xử lý tương tác với trợ lý AI như Alexa, nên gần như mọi thứ mà người dùng và thiết bị tương tác đều có thể được cải thiện
Về bản chất, L4S là công nghệ giúp rút ngắn vòng phản hồi độ trễ. Phần sau của video này giải thích khá tốt: https://youtu.be/tAVwmUG21OY?si=lydbqfNL80Y8Uxvp