3.5 TCP Fairness

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

1. 링크를 통과하는 데이터들은 모두 TCP로 연결된 것
2. 링크를 통과하는 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개 사용)