Stanford 교수가 TCP를 대체할 새 프로토콜을 주장하다
Homa: The end of TCP for AI clusters [video]
Stanford 교수가 AI 클러스터를 위해 TCP를 대체할 새로운 프로토콜 Homa를 제안한다. USENIX ATC 2021 논문과 LWN, The Register 기사를 통해 소개된 이 프로토콜은 기존 TCP의 한계를 극복하고 AI 학습에 최적화된 성능을 목표로 한다. Hacker News에서 관련 비디오와 논의가 공유되었다.
Stanford 교수가 TCP를 대체할 새 프로토콜을 위해 북을 두드리고 있다.
HN 토론
23- Animats
Homa는 꽤 오래전부터 있었습니다. 2018년 논문이 여기 있습니다.[1]
핵심 아이디어: 메시지가 송신자의 트랜스포트 모듈에 도착하면, Homa는 메시지를 두 부분으로 나눕니다: 초기 비스케줄 부분(첫 RTTbytes 바이트)과 그 뒤의 스케줄 부분입니다.
송신자는 비스케줄 바이트를 즉시 하나 이상의 DATA 패킷을 사용해 전송합니다. 스케줄된 바이트는 수신자가 GRANT 패킷을 사용해 명시적으로 요청할 때까지 전송되지 않습니다.
따라서 짧은 요청에는 블라인드로 보내고, 그 다음 수신자로부터 승인을 받아야 합니다.
주 애플리케이션이 원격 프로시저 호출일 때 이는 합리적입니다. 이는 QNX의 네트워킹 프로토콜을 연상시키는데, 역시 단일 패킷 메시지 요청/응답이지만 임의로 긴 메시지도 처리할 수 있습니다.
오늘날 이게 작동하게 만드는 것은 하드웨어 스위치에서 패킷당 처리 오버헤드가 바이트당 오버헤드에 비해 낮다는 점입니다. 초기 소프트웨어 기반 스위치에서는 패킷당 오버헤드가 지배적이어서 작은 패킷을 보내는 것이 매우 비효율적이었습니다. FPGA가 처리를 담당하는 현대 하드웨어 스위치에서는 패킷당 오버헤드가 충분히 낮아서 작은 패킷이 비효율적이지 않습니다.
오늘날 웹 관련 것들이 너무 비대해져서 1MB 미만의 트랜잭션이 "작은" 것으로 간주된다는 게 재미있습니다.
따라서 이것은 개방형 웹 사용에 적합한 프로토콜이 아닙니다.
[1] https://people.csail.mit.edu/alizadeh/papers/homa-sigcomm18....
- Veserv
Homa는 좋은 설계가 아닙니다. [1]
1. 전체 RPC 손실을 감지할 방법이 없습니다. 외부 연결 상태가 없기 때문에 RPC의 송신 측 패킷이 모두 손실되면 서버가 재전송을 해야 함을 감지할 방법이 없습니다. RPC는 그냥 허공으로 사라집니다. 이는 단일 패킷에 들어가는 메시지처럼 송신 측 패킷 수가 적은 작은 메시지에 더 큰 영향을 미칩니다.
2. 위와 관련하여, 내장 암호화 지원이 없습니다. 따라서 암호화를 원하면 위나 아래에 계층으로 쌓아야 합니다.
3. 벤치마크 성능이 끔찍합니다. [2] 표 4의 60 kB 평균 메시지 경우는 평균 20 Gbit/s를 내는 데 5(!)개의 하이퍼스레드가 필요합니다. 이는 하이퍼스레드당 4 Gbit/s에 불과합니다. 완전히 순진한 시스템 콜당 한 패킷 네트워크 프로토콜 설계 및 구현조차 하이퍼스레드당 약 8 Gbit/s는 나와야 합니다. 성능에 조금만 집중하면 하이퍼스레드당 30 Gbit/s는 쉽습니다.
4. QUIC의 모든 성능 설계 문제에도 불구하고(그래도 Homa보다 빠름) 이미 Homa가 해결하려는 거의 모든 문제를 훨씬 더 깔끔한 방식으로 해결합니다. 스트림 ID는 RPC ID에 대응합니다. 스트림 Max는 Grants에 대응합니다. 단일 Client 아래 여러 스트림은 우선순위 지정을 가능하게 합니다.
다만 전체 메시지를 무작위로 잃지 않습니다. 작은 메시지를 패킷으로 압축할 수 있습니다. 더 정밀한 RTT 시간을 얻어 더 정확한 페이싱/혼잡 계산이 가능합니다. 내장 암호화를 얻습니다. 고착된 미들박스에서도 살아남습니다. 여러 ack 프레임/패킷이 있어 ac […]를 줄입니다