Homa бросает вызов TCP в кластерах для AI
Homa: The end of TCP for AI clusters [video]
Профессор Stanford предлагает протокол Homa, чтобы заменить TCP в кластерах для AI. Обсуждение на Hacker News ссылается на статью USENIX ATC 2021 и материалы LWN и The Register о том, почему традиционный TCP плохо подходит для современных нагрузок машинного обучения.
Homa: The end of TCP for AI clusters
- Animats
Homa существует уже довольно давно. Вот статья 2018 года.[1]
Основная идея: когда сообщение прибывает в транспортный модуль отправителя, Homa
делит сообщение на две части: начальную незапланированную часть (первые RTTbytes байт), за которой следует запланированная часть.
Отправитель передаёт незапланированные байты немедленно, используя
один или несколько пакетов DATA. Запланированные байты не передаются до тех пор, пока получатель явно не запросит их с помощью пакетов GRANT.
Таким образом, для коротких запросов он отправляет вслепую, а затем ему нужно разрешение от получателя.
Это разумно, когда основное приложение — это удалённый вызов процедур. Это напоминает сетевой протокол QNX, который также использует запрос/ответ одним пакетом, но может обрабатывать и сколь угодно длинные сообщения.
То, что делает это работоспособным сегодня, — это низкие накладные расходы на обработку одного пакета в аппаратных коммутаторах по сравнению с накладными расходами на байт. В ранних коммутаторах с программным управлением накладные расходы на пакет, как правило, доминировали, и отправка маленьких пакетов была очень неэффективной. В современных аппаратных коммутаторах, где обработкой занимаются FPGA, накладные расходы на пакет достаточно низки, чтобы маленькие пакеты не были неэффективными.
Забавно, что веб-технологии сегодня настолько раздуты, что любая транзакция размером менее 1 МБ считается "маленькой".
Так что это не подходящий протокол для открытого веба.
[1] https://people.csail.mit.edu/alizadeh/papers/homa-sigcomm18....
- Veserv
Homa — не лучший дизайн. [1]
1. Нет способа обнаружить полную потерю RPC. Поскольку нет внешнего состояния соединения, если каждый пакет на стороне отправки RPC потерян, то у сервера нет способа обнаружить, что ему следует выполнить повторную отправку. RPC просто теряется в эфире. Это сильнее сказывается на маленьких сообщениях, например, сообщениях, умещающихся в один пакет, так как на стороне отправки меньше пакетов.
2. Связано с вышесказанным: нет встроенной поддержки шифрования. Так что если вы хотите шифрование, вам нужно добавить его либо выше, либо ниже.
3. Измеренная производительность ужасна. В случае среднего сообщения размером 60 кБ в [2] Таблица 4 требуется 5(!) гиперпотоков, чтобы в среднем достичь 20 Гбит/с. Это всего 4 Гбит/с на гиперпоток. Даже полностью наивный дизайн и реализация сетевого протокола с одним пакетом на системный вызов должны давать ~8 Гбит/с на гиперпоток. 30 Гбит/с на гиперпоток легко достичь, если хоть немного сосредоточиться на производительности.
4. Несмотря на все проблемы с производительностью в QUIC (хотя он всё ещё быстрее Homa), он уже решает практически все проблемы, которые пытается решить Homa, гораздо более чистым способом. Идентификаторы потоков соответствуют идентификаторам RPC. Stream Max соответствует Grants. Несколько потоков под одним Client позволяют расставлять приоритеты.
Кроме того, вы не теряете целые сообщения случайным образом. Вы можете упаковывать маленькие сообщения в пакеты. Вы получаете более точное время RTT, что позволяет более точно рассчитывать темп и перегрузку. Вы получаете встроенное шифрование. Он выживает в окостеневших middlebox'ах. У него есть несколько ack-фреймов/пакетов, уменьшающих ac […]