Transport Layer - (6)

보내는 TCP에서 받는 양을 조절한다. 파이프마다 굵기가 다 다른데 가장 얇은 파이프에서 병목현상이 발생할 확률이 높기 때문에 그 부분이 critical point이다. 하지만 그 부분을 우리가 알 순 없다.
처음에 1방울, 2방울 이렇게 천천히 늘려가본다. 그러다가 한계를 느끼게 되는 구간에 오면 그 구간에서 비슷하게 유지해본다.



TCP가 처음에 연결이 되면 Send Buffer, Receive Buffer 2개가 생긴다. 이걸로 데이터를 주고받고 하는것이다. 여기서 전송하는 데이터 양을 결정하는 것은 Window Size(ACK를 받지 않고 한번에 보낼 수 있는 데이터 양) 이다.
그래서 Slow Start가 1, 2, 4 인 것은 MSS가 1, 2, 4개라는 것을 의미.
1, 2, 4, 8, 16, 32, 64, 128, ...

Q : 이렇게 왔다갔다 안하고 최적의 구간을 쭉 보내면 안될까?
A : 불가능해서 이렇게 하는 것이다. 그 최적의 전송 양도 일정한게 아니라 네트워크 상황이나 라우터 등 여러 조건과 상황에 따라 달라지기 때문에 항상 변동되어야 한다. 최적의 구간을 찾기위해 이 3단계를 무한 반복 해야만 하는 상황.

RTT는 전송 후 왔다갔다 시간. 그 시간만큼 Window Size만큼 보내니까 Rate를 계산가능.
RTT에 비해 CongWin 크기가 변동이 심하다. 1부터 거듭제곱으로 커지고 다시 줄어들고 반복하기 때문이다. 따라서 전송속도는 결국 Congestion Window Size에 의해 결정된다고 볼 수 있다. Congestion Window Size는 네트워크 상황이 결정한다. 즉, 네트워크가 전송속도를 결정한다!


처음에 CongWin은 1 MSS 부터 2의 거듭제곱으로 개수를 키우면서 보낸다.
처음 Threshold는 매우 큰 값으로 설정한다. 그 이후 Loss/2로 변경한다.

X 축은 시간, Y축은 CongWin Size다.
버전 1(Tahoe), 버전 2(Reno) 라고 볼 수 있다.
Tahoe에서는 1부터 Slow start를 다시 했었다. 패킷 유실이 탐지되는 경우는 2가지다.
네트워크 관점에서 보면 먼저 2번 3 Duplicate ACK는 운이 없이 다 잘 전달하는데 특정 ACK만 문제가 생긴 상황. 네트워크는 잘 운영되는 중이다. 1번인 Time out은 특정 ACK 이후 전부 전송 안되기 때문에 더 큰 문제이다. 그렇기 때문에 1번과 2번에 대해 다르게 대응해주어야한다.
이것이 바로 TCP Reno 버전이다.
Window Size가 1000비트고, MSS가 10이라면, 나는 100개 크기 세그먼트를 연속으로 전송할 수 있는 것이다.

답은 YES

1이 더 많이 쓰는 상황이라고 해보자. k만큼, 2는 R-k 만큼 사용할 것이고 k > R-k이다.
=> 분산적으로 동작함에도 불구하고 TCP가 Fair하게 동작하게 된다.