요약
- RFC 2414는 더 큰 초기 TCP 윈도우를 허용했으나 강제하지는 않았다:
min(4*MSS, max(2*MSS, 4380 bytes)). 이 규칙은 새 연결의 첫 전송에 적용되었고, 비활성 상태 재개나 손실 이후의 모든 재시작에는 적용되지 않았다. - 두 개의 세그먼트는 지연 확인 타이머가 만료되기 전에 확인 응답을 유발할 수 있었다. RFC 2415의 ns-2 시뮬레이션은 해당 시나리오에서 다수 페이지의 중앙값 지연 감소를 측정했다.
- 혼합 그룹은 하나의 결론을 내지 않았다: 중간 부하에서는 IW=3이 IW=1 그룹에 불이익을 주지 않았고, 32/32 웹 클라이언트의 극단적 시나리오에서는 더 큰 윈도우를 쓰는 그룹 자체가 손해를 보았다.
- 이는 인터넷 배포에 대한 연구가 아니라 시뮬레이션이었다. 한 연결의 이득과 공유 경로에서의 효과 분포는 여전히 별개의 문제다.
첫 확인 응답이 쟁점이었다
아이디어는 소박해 보였다: 새 TCP 연결 시작 시 데이터 세그먼트를 하나보다 더 보내는 것. 그 이익은 큰 전송이 시작되기도 전에 나타날 수 있었다. 전송 중 세그먼트가 하나뿐이면, 확인 응답을 지연하는 수신 측은 자신의 타이머가 만료되기를 기다릴 수 있다. 두 개 이상이 되면, 두 번째 세그먼트의 도착이 더 이른 확인 응답을 유발할 수 있다. 작은 이메일이나 웹 오브젝트의 경우, 이 지연 회피 덕분에 전송이 단일 왕복 안에 끝날 수 있었다. RFC 2414는 혼잡 윈도우를 확대할 수 있는 연결이 초기 slow start 동안 최대 세 번의 왕복과 하나의 지연 ACK 타이머까지 절약할 수 있다고 추정했다.
RFC 2414는 모든 연결에 네 개의 세그먼트를 규정하지는 않았다. 1998년 9월에 실험적 RFC로 발표된 이 문서는 허용 상한을min(4*MSS, max(2*MSS, 4380 bytes))로 올리고, TCP가 이 더 큰 값을 사용해도좋다(MAY)고 명시했다. MSS가 중요했다: 세그먼트 크기에 따라 이 상한은 두, 세, 네 개의 세그먼트에 해당했다. 이 제안은 3-way 핸드셰이크 이후의 초기 윈도우에 관한 것이었다. 손실 이후의 윈도우는 한 세그먼트로 유지했고, 긴 비활성 기간 이후의 재개는 선택 사항으로 별도로 다뤘다. 따라서 '더 넓은 시작'은 경계가 있는 실험이었지, 정지 후 모든 혼잡 윈도우를 확대할 권한은 아니었다.
단말은 첫 전송을 선택할 수 있었지만, 자신의 패킷이 들어가는 큐를 예약할 수는 없었다. RFC 2414는 이 트레이드오프의 양면을 드러냈다. 버스트는 발신 연결에 손실이나 타임아웃을 초래할 수 있었고, 다른 플로우들은 공유 병목에서 손실과 불공정을 겪을 수 있었다. 저자들은 또한 여러 브라우저 연결이 동시에 열리면 각각이 더 큰 윈도우로 시작할 경우 문제가 악화된다고 경고했다. 쟁점은 추상적이지 않았다: 플로우 단위의 개선은 자신에게 속하지 않은 큐에 제시되는 부하를 바꾼다.
시뮬레이션은 하나 이상의 결과를 담고 있었다
RFC 2415는 배포 보고서가 아닌 정보성 연구로서 ns-2로 이 논쟁을 검토했다. 그 모델은 더 빠른 링크 사이에 1.5 Mbit/s, 50 ms의 병목을 배치했다. 8, 16, 32명의 웹 클라이언트를 변화시키고, 최대 세 개의 장기 FTP 전송을 추가했으며, 1,460 바이트 세그먼트 1~4개의 초기 윈도우를 테스트했다. 웹 모델은 세 개의 내장 URL을 가진 작은 페이지를 사용했고 무작위 지연 후 새 요청을 보냈으며, FTP는 1메가바이트 파일을 전송했다. 이러한 선택은 비교를 통제 가능하게 만들었지만, 동시에 그 범위를 고정하기도 했다.
모델링된 많은 시나리오에서 더 큰 윈도우를 쓰는 웹 클라이언트는 대체로 약 30% 낮은 중앙값 지연을 얻었다. 저자들은 1에서 2 세그먼트 사이의 상당 부분의 이득을 사용된 URL 크기 분포와 연관 지었다: 중앙값 기준 주 오브젝트와 내장 오브젝트가 두 패킷 안에 들어갔기 때문이다. 다른 분포에서는 곡선이 달라질 수 있었다. 이는 정밀한 모델에서 메커니즘이 낸 결과였지, 브라우저나 링크에 대한 보편적 백분율이 아니었다.
분리된 그룹들은 문제를 더 선명하게 만들었다. IW=1과 IW=3 사이에서 8/8, 그다음 16/16 클라이언트를 공유할 때, 저자들은 한 세그먼트 그룹에 어떤 부정적 효과도 관찰하지 못했고, 더 큰 윈도우 그룹은 자신의 우위를 유지했다. 32/32에서, 기사가 '병리적'이라고 부른 혼잡 상황에서는 IW=3 클라이언트가 불리했다. 저자들은 이 경우를 동시에 열린 연결들과 다중 손실로 돌렸다. 이 실험은 더 넓은 시작이 항상 이웃에 해롭다는 것을 증명하지 않았다; 어떤 부하 모델에서도 전체 중앙값이 모든 그룹의 경험을 설명하지 못한다는 것을 보여주었을 뿐이다.
이 연구는 단일 연결과 세 개의 버퍼를 가진 큐에 초점을 맞춘 이미 발표된 RFC 2416 기사와는 다르다. RFC 2415의 근거는 하나의 병목을 공유하는 다수의 시뮬레이션된 플로우에 관한 것이며, 그 조합에 따라 달라진다. 두 시뮬레이션 중 어느 것도 인터넷 규모의 실제 기기 행동이나 보편적 공정성 측정을 확립하지 않았다. 이후 RFC 3390이 표준 트랙의 선택적 상한으로 RFC 2414를 대체했고, RFC 5681이 그 규칙을 반영했으며, RFC 6928이 열 세그먼트 시작을 실험적으로 도입했다. 이 연대기는 1998년의 모델을 소급하여 배포 실태 조사로 바꾸지는 않는다.
Lu Heng의running-code primacy(실제 코드 우선)는 여기서 근거 규율로서만 유용하다: 실제로 테스트된 메커니즘과 시스템을 염두에 두는 것.현실의 층은 제한된 두 번째 기준점을 제공한다: 페이지의 지연, 큐의 손실, 그리고 전체 네트워크에 대한 결론을 혼동하지 않는 것. 이 노트들은 TCP에 관한 역사적 근거를 제공하지 않는다; 그것을 제공하는 것은 RFC 2414와 RFC 2415다.
출처
- RFC 2414 — Increasing TCP’s Initial Window
- RFC 2415 — Simulation Studies of Increased Initial TCP Window Size
- RFC 2416 — When TCP Starts Up With Four Packets Into Only Three Buffers
- RFC 2001 — TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
- RFC 3390 — Increasing TCP’s Initial Window
- RFC 5681 — TCP Congestion Control
- RFC 6928 — Increasing TCP’s Initial Window
- Lu Heng — Running-Code Primacy
- Lu Heng — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





