Transport Layer Services

TCP Fairness

TCP는 네트워크의 상황을 추측. throughput을 결정하는 bottleneck에서 bandwidth를 얼마나 공정하게 share하고 있을까?

만약, TCP Connection1이 먼저 연결 되어있어서 cwnd가 100MSS이였다고 하고, 그 이후에 TCP Connection2가 연결되었다고 한다면, 무조건 cwnd는 1MSS로 시작하게 될 것이다.
그렇다면 TCP Connection2가 막 연결되었다고 했을때, 각각의 Utilization은 100/101, 그리고 1/101일 것이다. -> fair하지 않다.

하지만 TCP는 Fair하다.

Why is TCP fair?

connection 1이 connection을 더 먼저 시작하여 cwnd가 훨씬 커 bandwidth를 더 많이 차지하고 있는 상황

그런 상황에서 connection2가 연결되면서 connection2의 cwnd가 점점 증가하게 되고, 파란 선(R, router의 bandwidth)을 넘게 되고, loss가 발생하면서 congestion avoidance를 진행하게 되고, cwnd가 반으로 줄어들게 된다.

물론 packet loss 자체는 connection1과 connection2 둘다 발생하게 되겠지만, 절반으로 만들기 때문에 결론적으로는 점점 R/2씩, 즉 fair하게 bandwidth를 나눠서 사용하게 된다.

Fairness

TCP에서 congestion control을 구현하면 fairness가 꽤 보장된다.
하지만, UDP는 congestion control을 구현하지 않는다.

UDP, 그 중에서도 multrimedia app에서 사용하는 UDP는 congestion control로 인해서 sending rate이 줄어들길 바라지 않는다. -> congestion control을 사용했을때, three duplicate ack에 걸리지 않는다면 1MSS부터 다시 시작할텐데, 그렇다면 음성 및 비디오와 같은 전송속도가 중요한 곳에는 사용하지 못하게 된다. -> 따라서 packet loss가 발생하더라도 무시함

Fairness, parallel TCP connections -> TCP는 fair 하긴 하지만, connection 측면에서 fair한 것이다.

만약 한 app에서 여러 개의 connections을 만들게 된다면, connection 기준으로 fair한 것이기 때문에 app 측면에서 본다면 unfair하다고 볼 수 있다.

Explicit Congestion Notification (ECN)

이전까지는 sender가 timeout이나, three duplicate ACKs 통해서 congestion을 추론하였지만, ECN에서는 router가 sender에게 congestion 정도에 대해서 보내는 방식을 통해 congestion을 명시적으로 알 수 있게 한다.

IP Header의 ToS field(잘 사용되지 않음)에 2개의 비트를 사용하여 알린다.

처음에는 ECN = 00으로 Sender가 보내게 되고 congestion 있는 router를 지나게 된다면 11로 변형하여 destination으로 보내게 되고, destination에서는 ECE라고 하는 비트(TCP Header)에 1로 보내게 된다. 해당 방식으로 source가 congestion을 인식하여 cwnd를 줄이게 된다.

이를 nework-assisted congestion control이라고 한다.