두 호스트가 링크하나를 공유해서 서버로 데이터를 보내고 있다.
이때 가정은 infinite buffer
output link capacity : R
Iin(밀어넣는 속도), Iout(내보내는 속도)
throughput은 R/2까지는 선형으로 증가하지만
딜레이는 기하급수적으로 증가한다.
이번에는 finite buffer이기에 packet loss가 발생할 수 있다.
이때는 공간이 있을때만 보내기 때문에 R/2를 넘지 않을 것이다.
패킷 loss가 발생할 수 있는데 내가 그걸 알고 잃어버린 패킷만 다시 보내는 방식이다. 그래서 duplicated packet이 안간다.
이렇게 된다면 throughput은 R/2가 아닐 수도 있다.
실재로는 duplicated packet을 보낼 수 밖에 없다.
congestion의 댓가는 goodput 에 대한 방법들이 필요함.
재전송이 필요없어질 수 있다.
sender는 transmission rate를 증가(윈도우 사이즈를 제어해서 컨트롤한다), 조금씩 올리다가 loss가 오면 줄이는 것이다. => 이걸로 usable bandwidth를 알아보기
- additive increase : lose 전까지 cwnd를 1 MSS(Maximum Segment Size)만큼 증가시키기
- multiplicative decreate : loss 발생하면 절반으로 줄여버림
loss가 발생한경우 cwnd를 1 MSS로 바꾸어버리기
ACK 가 중복 3개가 온 경우
- RENO : cwnd를 절반으로 줄이기, 선형 증가
- Tahoe : cwnd를 1로 바꾸고 지수 증가, ssthresh부터는 선형증가
avg window size가 3/4 * W 정도된다면
avg TCP thruput = 3/4 * W/RTT bytes/sec
될거라고 예상할 수 있다.
congestion avoidance phase가 일정하게 진행
segment loss probability에서 throughput을 표현해보면 아래와 같은 공식을 쓰게 된다.
TCP throughput = 1.22 * MSS / (RTT * root(L))
세그먼트 loss probability가 작을 수록 window 사이즈가 더 커질 수 밖에 없는 공식이다.
이것도 AIMD를 가정하고 작성한 공식이다.
TCP Fairness문제
fairness goal : 같은 bottleneck router을 공유하는 k개의 TCP 세션이 존재할때 각각의 average는 R/K로 가저가야한다.
이것도 계속 진행하다보면 위와같이 언제가 loss가 발생하는 시점에서 둘다 절반으로 줄이게 된다.
그러다보면 결국 equal bandwidth share에 도달한다는 것이다.
