이 글은 2011년 2월에 LWN에 올라온 'reasing the TCP initial congestion window'를 번역(이라고 썼지만 직역 중에도 발로 한 직역)한 글이다. 참고만 하시길.
아래는 간단한 요약과 감상
<요약>
- slow start 알고리듬 도입 초기와 달리 현재는 망상태가 훨씬 좋아졌으므로 init_cw를 큰 값으로 해도 된다.
- linux는 기본적으로 receive windows도 작기 때문에 이 값 역시 적어도 init_cw 만큼은 되어야 한다.
- 원문을 뒤져야 하겠지만, google이 network 테스트를 하면서 linux를 빼고 했다는 게 특이.
<감상>
- linux에서 당연히 설정가능한 값일 줄 알았던 init_cw가 2.6.39 이전에는 하드 코딩된 값이었다는 점이 놀라움
- proc_fs 등으로 값이 설정가능하도록 init_cw 변수를 추가하면 좋겠다는 생각.
- 왜냐하면, 각 route별 init_cw는 route 세부 설정으로 가능한데 비해 default 값은 10으로 고정되어 있기 때문
원문 : https://lwn.net/Articles/427104/
jonathan corbet, Feb/9/2011
van jacobson이 처음 도입한 TCP slow start 알고리듬은 TCP/IP가 인터넷에서 실제로 동작하게 하는데 결정적인 역할을 한 프로토콜 수정 사항 중 하나다. slow start는 새로운 connection의 시작시 데이터의 양을 제한하고, 전송 속도를 점차 늘려 connection의 전달 한계까지 도달하게 동작한다. 이런 방식으로 TCP는 실망의 현재 상태에 맞춰 동작할 수 있게 되고 수용가능한 양보다 많은 데이터를 처리할 때 발생하는 라우터의 과부하를 피할 수 있게 되었다. slow star의 핵심 요소는 initial congestion window이며, 전송 초기에 얼마나 많은 양의 데이터를 보낼지 한계를 결정하는 값이다.
이 값은 초기(RFC 3390)에 4개의 세그먼트(4KB 약간 넘는)로 결정되어 근 10년간 사용되었다. 그 동안 connection 속도는 발전하여 - connection live time 주기가 짧아지는데도 불구하고- 한 connection을 통해 전송할 수 있는 데이터의 양은 이전보다 커졌다. 이런 연유(life time 감소, 데이터 전송단위량 증가)로 많은 connection이 최고 속도에 도달하기 전에 이미 종료된다. 따라서 4개의 초기 전송 세그먼트 제한은 현 상황에선 일반적인 connection의 latency를 증가(역주 : 최고 속도에 도달하지 못하고 종료되므로 최고 속도에 비해)시키는 병목의 원인이 되었다. HTTP 스펙이 두 개의 connection 만 사용하도록 제한하고 있음에도 불구하고 최신의 브라우저는 동시에 2개 이상의 connection을 사용하는 이유가 여기에 있다.
구글의 몇몇 개발자들이 initial congestion window의 증가를 잠시동안(for a while) 주장하였다. 2010년 7월에 그들은 init_cw의 변경과 그 동기에 관한 IEFT draft를 제출했다. 구글은 대규모의 테스트를 통해 init_cw를 증가시킴으로써 congestion 문제를 추가로 만들지 않고 사용자 측면의 latency가 10% 정도 감소되는 것을 확인하였고, 이에 따라 initial cw를 10개 세그먼트로 증가하시키도록 권고했다. draft는 16개 세그먼트로 증가시 실질적으로 더 좋은 수치를 낼 수 있다고 제안했으나, 테스트가 추가로 필요한 상황이다.
David Miller는 init_cw를 10으로 증가시키는 패치(1)를 제출했다. 이 패치는 아직 mainline에 반영되지는 않았고, 2.6.39에 반영될 것으로 추정된다.
흥미롭게도 구글의 테스트는 몇 개의 OS를 이용해 진행되었지만, 상대적으로 작은 initial receive window(6KB)를 가진 linux는 빠져 있었다. 최소한 congestion window와 비슷하게 큰 receive window 없이는 init_cw가 큰 효과를 보기 어렵다. 이 문제는 initial receive window를 10개 segment로 늘린 Nandita Dukkipati의 패치(2)에 의해 2.6.38에서 해결될 예정이다.
patch 2개 참조.
1) https://lwn.net/Articles/426883/
2) http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=356f039822b8d802138f7121c80d2a9286976dbd
reply:
2개의 패치가 더 적용되어야 한다.
1) minimum retry timeout이 대략 1ms 혹은 timer 정확도가 허용하는 이하로 줄어야 한다. LAN 환경에서 1초의 MIN_RTO는 터무니없다.
2) syn retry timeout이 1초에서 200ms 정도로 줄어야 한다. 이 값을 크게 유지해야 하는 경우는 병목인 link가 56kbps의 모뎀과 비슷한 성능(느린)일 때 뿐이다.
만약 경로 특성에 따라 이 값이 변경가능하도록 -특수하게 느린 링크에서는 이값을 증가시키고, LAN 환경에서는 이값을 감소시키는 방법으로- 라우터의 설정(혹은 유도)이 가능하다면, 획기적인 일이다.
-> TCP_RTO_MIN은 커널에 200ms로 하드코딩된 걸로 알고 있음. 내가 테스트해 본 바로는 이 값을 10ms로만 바꾸더라도 큰 이득이 있었음.
200ms도 몇몇 상황에서는 실제적인 병목이 되는 것으로 보이므로 이 값이 설정 가능하거나, 적은 값으로 유도가능하다면 획기적인 일이 될 것임.
... (이하 생략)