MPTCP에 대해 2013년에 처음 들었을 때 모바일 앱의 네트워크 변경에 대한 대응력이 약했기 때문에 사용자 경험 개선에 큰 도움이 될 것이라 생각했으나, 10년이 지나도록 거의 주목받지 못한 것이 매우 실망스러움
IPv4의 32비트 주소 공간과 TCP가 연결 튜플에 출발지/목적지 IP 주소를 사용하는 것 중 어느 것이 더 슬픈지 모르겠음. 타임머신이 있다면 과거로 돌아가 이 두 가지를 바꾸고 싶음
MPTCP의 실용적 사용은 모바일과 Wi-Fi 네트워크를 함께 사용해 속도를 높이는 것이나, 모바일 데이터 요금제 때문에 개인적으로는 항상 끄고 있어 쓸모없음
OpenWrt 파생 프로젝트 등 MPTCP를 사용하는 프로젝트 링크가 없는 것이 아쉬움. 2년간 GSOC에서 OpenWrt에 MPTCP 지원을 패치하는 학생을 멘토링함
투명한 폴백이 있다면 애플리케이션의 명시적 옵트인이 왜 필요한지 의문. 커널이 모든 TCP 연결에 대해 투명하게 처리하여 경로 집계/링크 선호도에 대한 전역적 결정을 내리는 것이 가장 합리적일 것 같음
리눅스 네트워크 스택과 드라이버를 지원/디버깅/수정하는 일을 하면서 MPTCP의 낮은 채택률에 놀라움. SCTP처럼 기존 TCP를 대체하려 했던 모든 것들이 소수의 개발자들에게만 사용되고 나머지 세계는 잊혀지는 운명인 듯함
MPTCP와 QUIC의 아키텍처 차이, 그리고 저자들이 제안한 MPQUIC 프로토콜을 설명하는 논문을 찾음. QUIC은 단일 UDP 흐름에 애플리케이션 스트림을 다중화하고, MPTCP는 단일 스트림을 여러 TCP 하위 흐름으로 분할함. MPQUIC은 여러 UDP 하위 흐름에 애플리케이션 스트림을 다중화하여 두 기능을 결합함
Apple도 MPTCP를 지원하며 Siri에 사용 중
중간의 미들박스가 MPTCP 옵션을 지원하지 않으면 SYN+ACK 패킷에 MPTCP 옵션이 포함되지 않는다는 점이 꽤 제한적으로 보임. 미들박스의 유일한 요구사항은 MPTCP 옵션을 그대로 전달하는 것인가?
MPTCP는 보안/프라이버시 설정에 도움이 될 수 있음. 예를 들어 여러 업링크 채널에 트래픽을 분할하면 중국 정부 방화벽이 차단을 위해 트래픽을 결합하기 어려워짐
Hacker News 의견