지난 시간 배운 내용
TCP: switching from SS to CA
TCP는 UDP와 다르게 네트워크 안의 라우터 버퍼가 오버플로우 되지 않게 하기 위해 congestion control을 한다. congestion control의 목적은 2가지.
- NW에 가용한 bandwidth를 가능한 많이 써 utilization을 높여 응용의 처리율을 증가시킴
- NW의 router 버퍼에서 심각한 지연 혹은 overflow로 인한 loss가 발생하지 않도록 함
congestion control의 방법 중 Tahoe와 Reno 모두 Slow Start 방식으로 시작. Slow Start는 1 MSS로 세그먼트를 보내기 시작해, 가용한 network의 bandwidth를 모두 사용하지 못 할 수 있음. congestion control의 목적 중 하나는 가용한 network의 bandwidth를 가능한 많이 쓰는 것.
ACK을 받을 때마다 하나의 ACK 당 하나의 MSS씩 증가(2배씩 double로 증가), ssthresh까지 증가시 혼잡 회피로 변경하여 linear하게 1 MSS씩 증가. 진행하면서 Timeout값을 점점 증가. 만약 loss가 발생했다고 판단되면, cwnd 값을 loss가 생긴 시점의 cwnd 값의 절반으로 cwnd 를 갱신. Tahoe는 SlowStart를 다시 시작 (1MSS 전송 부터), RENO의 경우 ACK을 한 번 더 받은 후 3 dup ack이 오면 현재 cwnd 의 절반으로 cwnd를 갱신한 후 혼잡 회피(CA)로 linear하게 1MSS씩 증가 (3 dup ACK은 한 번 ACK 받은 후 3번 더 오면 3 dup ACK이라고 판단
TCP throughput (AIMD only)
AIMD 방식으로 congestion control을 할 때, (AIMD 방식에서 sender는 loss가 발생할 때까지 transmission rate(Window size)를 1 MSS 단위로 증가시키다, loss 감지 시 cwnd를 loss가 발생한 시점의 절반으로 줄인다. W/RTT와 W/2RTT의 평균은 3W/4RTT 로 계산할 수 있다.
TCP Futures: TCP over "long, fat pipes"
링크의 에러율을 포함해 throughput을 계산하는 것이 맞다!
TCP Fairness
TCP는 네트워크의 상황을 추측. throughput을 결정하는 bottleneck에서 bandwidth를 얼마나 공정하게 share하고 있을까?
RTT(A~R) = # hop(A~R), propagation delay는 크지 X, 라우터를 몇 개 거쳐 가느냐가 RTT RTT(A~R) = RTT(B~R) 이란 것은 A~R과 B~R 사이의 라우터 개수가 같다는 것
가정) 1. 첫번째 라우터와 두번째 라우터 사이 링크의 transmission rate은 R
-
링크를 통과하는 데이터들은 모두 TCP로 연결된 것
-
링크를 통과하는 TCP connection이 N개로 늘어난다면
→ 각 호스트가 R값을 동일하게 사용하게 되어 R/N의 속도로 데이터를 보낼 수 있다!
Why is TCP fair?
connection 1이 connection을 더 먼저 시작했을 수도, cwnd가 훨씬 커 bandwidth를 더 많이 차지하고 있는 상황
connection 2의 cwnd가 점점 증가하면서 파란 선(R)을 넘고 loss가 생김.
loss가 생기면 각 cwnd를 loss가 생긴 시점의 반으로 줄임
결국 두 connection은 R/2만큼의 bandwidth를 쓰게 된다.
→ 모두 TCP connection을 사용, 경쟁하는 bottleneck link와 host사이의 # of RTT (hops)가 똑같다고 가정하면, 그 TCP connection들은 경쟁하는 R값을 공평하게 나눠 갖게 된다.
Fairness 과연?
- Not fair because of UDP
UDP도 그 link를 지나감. 버퍼 오버플로우시 TCP는 보내는 데이터 양을 절반으로 줄이나 UDP는 congestion control을 하지 않기에 그렇지 않음.
→ TCP와 UDP가 같은 경로를 공유할 때, 만약 경로가 busy해 output buffer에서 congestion이 발생하면 TCP만 데이터 양을 줄임, 남은 bandwidth를 UDP가 쓰게 됨 → TCP가 불리
- Unfair allocation of R due to parallel TCP connections
TCP connection을 쓰는 HTTP는 baseHTML을 가져온 후 object만큼을 더 가져와야 함
이 때, 3가지 종류의 TCP connection을 사용할 수 있음. non persistent with parallel로 연결을 한다면, TCP connection을 동시에 여러 개 열 수 있는 어플리케이션들이 있기 때문에, 특정 bottleneck을 보면, TCP 입장에서 봤을 땐 공평하나(모든 소켓은 공평하게 bandwidth를 나눠 가짐), 5계층의 어플리케이션 입장에서 봤을 땐 공평하지 않음(어떤 app은 11개 사용, 어떤 app은 9개 사용)
Quiz
(84) TCP가 사용 되는 망에서 application user가 느끼는 서비스 불공정성 두 가지 예를 설명하시오.
⇒
(1) UDP와 TCP가 bottleneck link를 공유하는 경우 TCP는 congestion control을 위해 전송율을 낮추는 반면, UDP는 응용이 내려보내는 속도 그대로 전송하므로 UDP user가 TCP user보다 해당 링크 대역폭을 더 많이 사용하게되는 불공정성이 있다.
(2) Bottleneck link를 TCP user만 사용하는 경우에도 응용이 TCP connection을 non-persistent with parallel 옵션으로 동시에 다중의 TCP 소켓을 연다면 persistent TCP connection을 여는 응용보다 어느 시점에 더 많은 링크 대역폭 사용하게된다.
