Facebook kết quả thử nghiệm với thuật toán kiểm soát tắc nghẽn mới - , được tối ưu hóa để truyền tải nội dung video. Thuật toán được đề xuất bởi các nhà nghiên cứu từ Viện Công nghệ Massachusetts. Nguyên mẫu COPA được đề xuất để thử nghiệm được viết bằng C++, được cấp phép theo MIT và được đưa vào - việc triển khai giao thức QUIC đang được phát triển tại Facebook.
Thuật toán COPA tập trung vào việc giải quyết các vấn đề phát sinh khi truyền video qua mạng. Tùy thuộc vào loại video, các yêu cầu gần như trái ngược nhau được đặt ra đối với thuật toán kiểm soát tắc nghẽn - đối với video tương tác, cần đảm bảo độ trễ tối thiểu, ngay cả khi phải trả giá bằng chất lượng và khi phát video chất lượng cao được chuẩn bị trước, ưu tiên được ưu tiên để duy trì chất lượng. Trước đây, các nhà phát triển ứng dụng bị giới hạn khả năng áp dụng các thuật toán khác nhau tùy thuộc vào yêu cầu về chất lượng hoặc độ trễ. Các nhà nghiên cứu đã phát triển COPA đã cố gắng tạo ra một thuật toán phổ quát để quản lý tắc nghẽn video TCP có thể được tùy chỉnh dựa trên yêu cầu video.
Công việc của thuật toán kiểm soát tắc nghẽn là xác định sự cân bằng tối ưu khi gửi gói - gửi quá nhiều gói có thể dẫn đến mất gói và suy giảm hiệu suất do cần phải gửi lại và gửi quá chậm dẫn đến độ trễ, điều này cũng ảnh hưởng tiêu cực đến hiệu suất . Giao thức QUIC được chọn cho các thử nghiệm vì nó cho phép thực hiện các thuật toán kiểm soát tắc nghẽn trong không gian người dùng mà không can thiệp vào kernel.
Để ngăn ngừa tắc nghẽn kênh liên lạc, COPA sử dụng mô hình hóa các đặc điểm kênh dựa trên phân tích các thay đổi về độ trễ trong quá trình phân phối gói (COPA giảm kích thước của cửa sổ tắc nghẽn khi độ trễ tăng lên, thao tác để độ trễ bắt đầu tăng ngay cả ở giai đoạn trước khi xảy ra mất gói) . Sự cân bằng giữa độ trễ và thông lượng được điều chỉnh bằng tham số delta đặc biệt. Việc tăng delta làm tăng độ nhạy với độ trễ nhưng làm giảm thông lượng, trong khi giảm delta cho phép thông lượng cao hơn nhưng phải trả giá bằng độ trễ tăng lên. Delta=0.04 được định nghĩa là sự cân bằng tối ưu giữa chất lượng và độ trễ.
Dựa trên dịch vụ phát trực tuyến Facebook Live, COPA đã được thử nghiệm so với các thuật toán CUBIC và BBR phổ biến. Thuật toán CUBIC mặc định trên Linux là tăng dần kích thước của cửa sổ tắc nghẽn cho đến khi xảy ra mất gói, sau đó kích thước cửa sổ được khôi phục về giá trị trước khi bắt đầu mất gói.
CUBIC còn nhiều hạn chế trong việc đệm gói trên thiết bị mạng hiện đại, giúp làm chậm quá trình rớt gói. Thuật toán điều khiển tắc nghẽn không biết đến bộ đệm và tiếp tục tăng tốc độ ngay cả khi kênh đã bị tắc nghẽn vật lý. Các gói chưa gửi được lưu vào bộ đệm thay vì bị loại bỏ và thuật toán kiểm soát tắc nghẽn của TCP chỉ hoạt động khi bộ đệm đầy và không thể cân bằng tốc độ luồng với tốc độ của liên kết vật lý. Để giải quyết vấn đề này, Google đã đề xuất một thuật toán BBR cải tiến nhằm dự đoán băng thông khả dụng thông qua kiểm tra tuần tự và ước tính thời gian khứ hồi (RTT).
Với delta=0.04, các chỉ báo COPA hóa ra gần với CUBIC và BBR. Trong các thử nghiệm được thực hiện qua kết nối mạng tốc độ cao với độ trễ truyền gói thấp, COPA đạt được độ trễ thấp hơn (479 ms) so với CUBIC (499 ms), nhưng kém hơn một chút so với BBR (462 ms). Khi chất lượng kết nối giảm, COPA cho kết quả tốt nhất - độ trễ thấp hơn 27% so với khi sử dụng CUBIC và BBR.
Đồng thời, trên kênh liên lạc kém, COPA và BBR có thể đạt được thông lượng cao hơn đáng kể so với CUBIC. Mức tăng của BBR so với CUBIC là 4.8% và 5.5%, và COPA - 6.2% và 16.3%.
Nguồn: opennet.ru