> То есть, после повсеместного внедрения стандарта, придётся переносить реализацию в ядро?
> Но Гугл не обязательно этим со всеми поделится.Соль была в том, чтобы иметь реализацию в пользовательском пространстве. Мол, так алгоритм управления потоком Google сможет апдейтить просто обновляя Chrome (например). Этим алгоритмом был BBR, который не очень взлетел. Да, у него есть интересные моменты, но нет, например поддержки ECN, и проблемы с честностью (он склонен душить другие соединения). Алгоритм не взлетел, но сама идея вынести всё в userspace осталась. В теории можно перенести в ядро, но это потянет целый ворох ненужного в ядро. Только каких-нибудь подгружаемых сертификатов извне там не хватало. Вон, wireguard тащит всё в ядро, мол, управлять потоком там сподручнее и это ВОООН какой профит даёт, а google тащит аналогичные вещи в userspace и поёт о том, какой профит им это даёт.
В реальности всё проще, изначальная идея вообще для Google не очень актуальная. Им обновить веб-сервер одинаково просто с обновлением tcp_uber_protocol.ko, т.к. только обновление серверного ПО и имеет смысл из-за того, что отправитель управляет потоком, а не принимающая сторона. Мобильный же клиент особо исходящий трафик, критичный по решаемым задачам, не генерирует. Единственная интересная новая вещь - прозрачная миграция трафика между интерфейсами.
P.S. вообще на самом деле нынешний CUBIC+HYSTART+SACK+ECN почти богоподобен. Да, оно плохо подстраивается под внезапные увеличения в доступной пропуской способности беспроводных сетей, но я бы решал эту проблему пробросом информации из более низкого уровня. Например, расширить концепцию ECN сигналом явно уведомляющим об освобождении полосы. Даже в поле ECN есть неиспользующийся сигнал ECT1, который сейчас интерпретируется как равный ECT0. А городить сложные алгоритмы (BBR - самый сложный из congestion control'ов) в userspace... — ну такое себе.
