TCP Congestion Control - 편집 역사

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 네트워크(\|[^\]]+)?\]\] +분류:컴퓨터 네트워킹\1)

2026-01-15T13:03:33Z

봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 네트워크(\|[^\]]+)?\]\] +분류:컴퓨터 네트워킹\1)

← 이전 판		2026년 1월 15일 (목) 13:03 판
71번째 줄:		71번째 줄:

	==각주==		==각주==
	[[분류:컴퓨터 ~~네트워크~~]]		[[분류:컴퓨터 네트워킹]]

2025년 4월 18일 (금) 19:52에 Pinkgo님의 편집

2025-04-18T19:52:08Z

Pinkgo: /* Parallel TCP Connections */

2025-04-07T04:06:09Z

Parallel TCP Connections

← 이전 판		2025년 4월 7일 (월) 04:06 판
67번째 줄:		67번째 줄:

	===Parallel TCP Connections===		===Parallel TCP Connections===
			만약 각각의 UDP 연결이 link capacity가 균등하게 link capacity를 배분받도록 강제할 수 있다 해도, 공정성 문제는 완전히 해결되지 않는다. 왜냐하면, TCP 기반 애플리케이션은 종종 병렬 연결(pararell connection)을 사용하기 때문이다. 예를 들어, 웹 브라우저는 하나의 웹 페이지에 있는 여러 object를 전송하기 위해 다수의 병렬 TCP 연결을 사용하며, 이를 통해 congestion link에서도 더 많은 link capacity를 확보할 수 있다. 예를 들어, transmission rate가 R인 링크에서 9개의 클라이언트-서버 애플리케이션이 각자 하나의 TCP 연결을 사용한다고 하자. 이때 새로운 애플리케이션이 1개의 TCP 연결만 추가하면, 각 애플리케이션은 대략 R/10씩 나누어 갖는다. 하지만 이 새 애플리케이션이 11개의 병렬 TCP 연결을 사용하면,
			이 애플리케이션은 전체 bandwidth의 절반 이상을 차지한다. 즉, 병렬 연결을 사용하면 공정성이 깨지는 현상이 발생한다.

	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]

Pinkgo: /* Fairness and UDP */

2025-04-07T04:02:12Z

Fairness and UDP

← 이전 판		2025년 4월 7일 (월) 04:02 판
62번째 줄:		62번째 줄:

	===Fairness and UDP===		===Fairness and UDP===
			TCP는 congestion control을 활용하여 네트워크의 congestion을 효과적으로 줄임은 물론 각각의 TCP 연결들에 대해 공정한 link capacity를 배분한다. 하지만 많은 멀티미디어 애플리케이션<ref>VoIP, 화상 회의 등...</ref>들은 오히려 이런 이유 때문에 TCP 위에서 실행되지 않는다. 이러한 앱들은 congestion이 증가하더라도 transmission rate가 줄어드는 것을 원하지 않기 때문이다. 따라서 이런 앱들은 UDP 프로토콜을 이용하여 실행된다. UDP는 congestion control이 없기 때문에 오디오나 비디오 데이터를 일정한 속도로 지속적으로 전송할 수 있고, 가끔 패킷이 손실되더라도 transmission rate를 줄이지 않는다.

			TCP 입장에서 보면, UDP는 비협력적이다. 다른 TCP 연결들이 서로 협력하여 congestion을 줄이고자 할 때, UDP는 congestion이 일어나더라도 그 전송 속도를 줄이지 않기 때문에 UDP 트래픽이 TCP 트래픽을 밀어내는 현상이 발생할 수 있다.

	===Parallel TCP Connections===		===Parallel TCP Connections===

Pinkgo: /* Fairness and UDP */

2025-04-07T03:54:53Z

Fairness and UDP

← 이전 판		2025년 4월 7일 (월) 03:54 판
62번째 줄:		62번째 줄:

	===Fairness and UDP===		===Fairness and UDP===


	===Parallel TCP Connections===		===Parallel TCP Connections===

Pinkgo: /* Fairness */

2025-04-07T03:54:23Z

Fairness

← 이전 판		2025년 4월 7일 (월) 03:54 판
60번째 줄:		60번째 줄:
	이런 상황에서 TCP가 link capacity를 두 연결에 공정하게 나눈다면, throughput은 원점에서 45도 각도로 뻗는 직선 상에 위치해야 한다. 또한 두 연결의 throughput의 합이 R이 되어야 이상적이다. 즉, 이상적인 목표는 equal bandwidth share선과 full bandwidth utilization선이 교차하는 지점 근처에 연결의 throughput이 수렴하는 것이다.<br>		이런 상황에서 TCP가 link capacity를 두 연결에 공정하게 나눈다면, throughput은 원점에서 45도 각도로 뻗는 직선 상에 위치해야 한다. 또한 두 연결의 throughput의 합이 R이 되어야 이상적이다. 즉, 이상적인 목표는 equal bandwidth share선과 full bandwidth utilization선이 교차하는 지점 근처에 연결의 throughput이 수렴하는 것이다.<br>
	이제, 위에서 한 가정과 그래프를 바탕으로 두 TCP 연결이 어떻게 진행되는지 살펴보자. 처음에 두 TCP 연결의 throughput은 그래프의 점 A와 같다. 이 경우, TCP의 congestion avoidance 알고리즘에 따라 매 RTT마다 cwnd를 1MSS 씩 증가시키고, 이에 따라 두 연결의 throughput은 점 A를 시점으로하는 45도 선을 따라 증가한다. 결국은 어느 시점에서 패킷 손실이 일어나게 되는데, 그 시점의 throughput이 점 B라고 하자. 이때 TCP는 이 손실에 반응해 각 연결의 cwnd를 반으로 줄인다. 그 결과 throughput은 점 C에 해당하는 값이 된다. 이러한 과정을 반복하여, 두 연결의 throughput은 결국 equal bandwidth share선 근처에서 진동하게 된다. 또한 처음 위치가 어디든지 그 결과는 이러하다. 이는 TCP 연결이 위의 가정을 만족할 경우 일정한 성능을 보장하며 각 연결들에게 균등한 link capacity를 제공한다는 것을 알려준다.<ref>만약 RTT가 더 짧은 연결이 존재한 다면, 해당 연결은 cwnd가 더욱 빠르게 증가하므로 상대적으로 더 높은 throughput을 누릴 수 있다.</ref>		이제, 위에서 한 가정과 그래프를 바탕으로 두 TCP 연결이 어떻게 진행되는지 살펴보자. 처음에 두 TCP 연결의 throughput은 그래프의 점 A와 같다. 이 경우, TCP의 congestion avoidance 알고리즘에 따라 매 RTT마다 cwnd를 1MSS 씩 증가시키고, 이에 따라 두 연결의 throughput은 점 A를 시점으로하는 45도 선을 따라 증가한다. 결국은 어느 시점에서 패킷 손실이 일어나게 되는데, 그 시점의 throughput이 점 B라고 하자. 이때 TCP는 이 손실에 반응해 각 연결의 cwnd를 반으로 줄인다. 그 결과 throughput은 점 C에 해당하는 값이 된다. 이러한 과정을 반복하여, 두 연결의 throughput은 결국 equal bandwidth share선 근처에서 진동하게 된다. 또한 처음 위치가 어디든지 그 결과는 이러하다. 이는 TCP 연결이 위의 가정을 만족할 경우 일정한 성능을 보장하며 각 연결들에게 균등한 link capacity를 제공한다는 것을 알려준다.<ref>만약 RTT가 더 짧은 연결이 존재한 다면, 해당 연결은 cwnd가 더욱 빠르게 증가하므로 상대적으로 더 높은 throughput을 누릴 수 있다.</ref>

			===Fairness and UDP===


			===Parallel TCP Connections===

	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]

Pinkgo: /* Fairness */

2025-04-07T03:53:17Z

Fairness

← 이전 판		2025년 4월 7일 (월) 03:53 판
53번째 줄:		53번째 줄:
	각각의 연결들은 큰 파일을 전송 중이며, 병목 링크를 통과하는 UDP 트래픽은 없다고 하자. 이때, 혼잡 제어 메커니즘이 '''공정하다(fair)''' 고 말하려면, 각 연결의 '''평균 transmission rate가 R/K에 근접'''해야 한다. 즉, 각각의 연결이 link capacity를 동일하게 나누어 가져야 한다.		각각의 연결들은 큰 파일을 전송 중이며, 병목 링크를 통과하는 UDP 트래픽은 없다고 하자. 이때, 혼잡 제어 메커니즘이 '''공정하다(fair)''' 고 말하려면, 각 연결의 '''평균 transmission rate가 R/K에 근접'''해야 한다. 즉, 각각의 연결이 link capacity를 동일하게 나누어 가져야 한다.
	[[파일:Throughput realized by TCP connections 1 and 2.png\|대체글=Figure 4. Throughput realized by TCP conn. 1 and 2\|섬네일\|Figure 4. Throughput realized by TCP conn. 1 and 2]]		[[파일:Throughput realized by TCP connections 1 and 2.png\|대체글=Figure 4. Throughput realized by TCP conn. 1 and 2\|섬네일\|Figure 4. Throughput realized by TCP conn. 1 and 2]]
	TCP는 각각의 연결들이 서로 다른 시점에 시작될 수 있고, 어떤 시점에서는 서로 다른 window size를 가질 수도 있음에도 공정하다고 할 수 있다. 이는 figure 4로 주어진 그래프가 잘 설명해주고 있는데, 이를 이해하기 위해서 다음과 같은 상황을 가정하자:		TCP는 각각의 연결들이 서로 다른 시점에 시작될 수 있고, 어떤 시점에서는 서로 다른 window size를 가질 수도 있음에도 공정하다고 할 수 있다. 이는 figure 4로 주어진 그래프가 잘 설명해주고 있는데, 이를 이해하기 위해서 다음과 같은 상황을 가정하자:<br>
	1) Link capacity가 R인 하나의 링크를 두개의 TCP 연결이 공유하며, 다른 TCP 연결이나 UDP 패킷은 간섭하지 않는다.<br>		1) Link capacity가 R인 하나의 링크를 두개의 TCP 연결이 공유하며, 다른 TCP 연결이나 UDP 패킷은 간섭하지 않는다.<br>
	2) 두 연결은 같은 MSS와 RTT를 가진다. 즉, cwnd가 같다면 처리량도 같다.<br>		2) 두 연결은 같은 MSS와 RTT를 가진다. 즉, cwnd가 같다면 처리량도 같다.<br>

Pinkgo: /* Fairness */

2025-04-07T03:52:56Z

Fairness

← 이전 판		2025년 4월 7일 (월) 03:52 판
52번째 줄:		52번째 줄:
	K개의 TCP 연결이 각각 end-to-end 경로를 가지고 있지만, 모두 전송 속도가 R bps인 병목 링크(bottleneck link)를 통과한다고 가정하자.<ref>여기서 병목 링크란, 각 연결 경로에 있는 다른 링크들은 혼잡하지 않고, 병목 링크보다 충분한 전송 용량을 가진다는 의미다.</ref>		K개의 TCP 연결이 각각 end-to-end 경로를 가지고 있지만, 모두 전송 속도가 R bps인 병목 링크(bottleneck link)를 통과한다고 가정하자.<ref>여기서 병목 링크란, 각 연결 경로에 있는 다른 링크들은 혼잡하지 않고, 병목 링크보다 충분한 전송 용량을 가진다는 의미다.</ref>
	각각의 연결들은 큰 파일을 전송 중이며, 병목 링크를 통과하는 UDP 트래픽은 없다고 하자. 이때, 혼잡 제어 메커니즘이 '''공정하다(fair)''' 고 말하려면, 각 연결의 '''평균 transmission rate가 R/K에 근접'''해야 한다. 즉, 각각의 연결이 link capacity를 동일하게 나누어 가져야 한다.		각각의 연결들은 큰 파일을 전송 중이며, 병목 링크를 통과하는 UDP 트래픽은 없다고 하자. 이때, 혼잡 제어 메커니즘이 '''공정하다(fair)''' 고 말하려면, 각 연결의 '''평균 transmission rate가 R/K에 근접'''해야 한다. 즉, 각각의 연결이 link capacity를 동일하게 나누어 가져야 한다.
			[[파일:Throughput realized by TCP connections 1 and 2.png\|대체글=Figure 4. Throughput realized by TCP conn. 1 and 2\|섬네일\|Figure 4. Throughput realized by TCP conn. 1 and 2]]
	TCP는 각각의 연결들이 서로 다른 시점에 시작될 수 있고, 어떤 시점에서는 서로 다른 window size를 가질 수도 있음에도 공정하다고 할 수 있다. 이는 figure 4로 주어진 그래프가 잘 설명해주고 있는데, 이를 이해하기 위해서 다음과 같은 상황을 가정하자:		TCP는 각각의 연결들이 서로 다른 시점에 시작될 수 있고, 어떤 시점에서는 서로 다른 window size를 가질 수도 있음에도 공정하다고 할 수 있다. 이는 figure 4로 주어진 그래프가 잘 설명해주고 있는데, 이를 이해하기 위해서 다음과 같은 상황을 가정하자:
	1) Link capacity가 R인 하나의 링크를 두개의 TCP 연결이 공유하며, 다른 TCP 연결이나 UDP 패킷은 간섭하지 않는다.<br>		1) Link capacity가 R인 하나의 링크를 두개의 TCP 연결이 공유하며, 다른 TCP 연결이나 UDP 패킷은 간섭하지 않는다.<br>

Pinkgo: /* Fairness */

2025-04-07T03:51:24Z

Fairness

← 이전 판		2025년 4월 7일 (월) 03:51 판
58번째 줄:		58번째 줄:
	3) AIMD에서 Slow-start 단계는 무시하고, 항상 congesiton avoidance 단계에서 작동하며, TCP Reno를 따른다.		3) AIMD에서 Slow-start 단계는 무시하고, 항상 congesiton avoidance 단계에서 작동하며, TCP Reno를 따른다.
	4) 두 연결 모두 전송할 데이터가 충분하다.<br>		4) 두 연결 모두 전송할 데이터가 충분하다.<br>
	이런 상황에서 TCP가 link capacity를 두 연결에 공정하게 나눈다면, throughput은 원점에서 45도 각도로 뻗는 직선 상에 위치해야 한다. 또한 두 연결의 throughput의 합이 R이 되어야 이상적이다. 즉, 이상적인 목표는 equal bandwidth share선과 full bandwidth utilization선이 교차하는 지점 근처에 연결의 throughput이 수렴하는 것이다.		이런 상황에서 TCP가 link capacity를 두 연결에 공정하게 나눈다면, throughput은 원점에서 45도 각도로 뻗는 직선 상에 위치해야 한다. 또한 두 연결의 throughput의 합이 R이 되어야 이상적이다. 즉, 이상적인 목표는 equal bandwidth share선과 full bandwidth utilization선이 교차하는 지점 근처에 연결의 throughput이 수렴하는 것이다.<br>
			이제, 위에서 한 가정과 그래프를 바탕으로 두 TCP 연결이 어떻게 진행되는지 살펴보자. 처음에 두 TCP 연결의 throughput은 그래프의 점 A와 같다. 이 경우, TCP의 congestion avoidance 알고리즘에 따라 매 RTT마다 cwnd를 1MSS 씩 증가시키고, 이에 따라 두 연결의 throughput은 점 A를 시점으로하는 45도 선을 따라 증가한다. 결국은 어느 시점에서 패킷 손실이 일어나게 되는데, 그 시점의 throughput이 점 B라고 하자. 이때 TCP는 이 손실에 반응해 각 연결의 cwnd를 반으로 줄인다. 그 결과 throughput은 점 C에 해당하는 값이 된다. 이러한 과정을 반복하여, 두 연결의 throughput은 결국 equal bandwidth share선 근처에서 진동하게 된다. 또한 처음 위치가 어디든지 그 결과는 이러하다. 이는 TCP 연결이 위의 가정을 만족할 경우 일정한 성능을 보장하며 각 연결들에게 균등한 link capacity를 제공한다는 것을 알려준다.<ref>만약 RTT가 더 짧은 연결이 존재한 다면, 해당 연결은 cwnd가 더욱 빠르게 증가하므로 상대적으로 더 높은 throughput을 누릴 수 있다.</ref>

	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]

Pinkgo: /* Fairness */

2025-04-07T03:43:49Z

Fairness

← 이전 판		2025년 4월 7일 (월) 03:43 판
53번째 줄:		53번째 줄:
	각각의 연결들은 큰 파일을 전송 중이며, 병목 링크를 통과하는 UDP 트래픽은 없다고 하자. 이때, 혼잡 제어 메커니즘이 '''공정하다(fair)''' 고 말하려면, 각 연결의 '''평균 transmission rate가 R/K에 근접'''해야 한다. 즉, 각각의 연결이 link capacity를 동일하게 나누어 가져야 한다.		각각의 연결들은 큰 파일을 전송 중이며, 병목 링크를 통과하는 UDP 트래픽은 없다고 하자. 이때, 혼잡 제어 메커니즘이 '''공정하다(fair)''' 고 말하려면, 각 연결의 '''평균 transmission rate가 R/K에 근접'''해야 한다. 즉, 각각의 연결이 link capacity를 동일하게 나누어 가져야 한다.

	TCP는 각각의 연결들이 서로 다른 시점에 시작될 수 있고, 어떤 시점에서는 서로 다른 window size를 가질 수도 있음에도 공정하다고 할 수 있다. ~~왜 그런지~~		TCP는 각각의 연결들이 서로 다른 시점에 시작될 수 있고, 어떤 시점에서는 서로 다른 window size를 가질 수도 있음에도 공정하다고 할 수 있다. 이는 figure 4로 주어진 그래프가 잘 설명해주고 있는데, 이를 이해하기 위해서 다음과 같은 상황을 가정하자:
			1) Link capacity가 R인 하나의 링크를 두개의 TCP 연결이 공유하며, 다른 TCP 연결이나 UDP 패킷은 간섭하지 않는다.<br>
			2) 두 연결은 같은 MSS와 RTT를 가진다. 즉, cwnd가 같다면 처리량도 같다.<br>
			3) AIMD에서 Slow-start 단계는 무시하고, 항상 congesiton avoidance 단계에서 작동하며, TCP Reno를 따른다.
			4) 두 연결 모두 전송할 데이터가 충분하다.<br>
			이런 상황에서 TCP가 link capacity를 두 연결에 공정하게 나눈다면, throughput은 원점에서 45도 각도로 뻗는 직선 상에 위치해야 한다. 또한 두 연결의 throughput의 합이 R이 되어야 이상적이다. 즉, 이상적인 목표는 equal bandwidth share선과 full bandwidth utilization선이 교차하는 지점 근처에 연결의 throughput이 수렴하는 것이다.

	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]

← 이전 판		2025년 4월 18일 (금) 19:52 판
6번째 줄:		6번째 줄:
	==TCP congestion의 기본 배경==		==TCP congestion의 기본 배경==
	===Send Rate and Congestion Window===		===Send Rate and Congestion Window===
	TCP이 congestion에 취하는 기본적인 접근 방식은 송신자가 감지한 네트워크 congestion의 정도에 따라 자신이 해당 연결에 대해 보내는 트래픽의 전송 속도를 ~~조절하는~~ 것이다. 즉, 송신자가 자신과 목적지 사이의 경로에 congestion이 거의 없다고 판단되면 send rate를 증가시키고, 반대로 congestion이 있다고 판단되면 send rate를 줄인다. 이때, TCP는 송신자의 send rate를 조절하기 위해 '''cwnd(congestion window)'''라는 추가적인 변수를 활용한다. 이때 cwnd는 TCP 송신자가 네트워크로 트래픽을 보낼 수 있는 속도를 제한하는 제약 조건을 제공한다. 이 제약 조건은 송신자의 바이트 스트림(byte stream)에서 미확인된(unackowledged) 바이트의 양은 cwnd와 rwnd(receive window) 중 작은 값보다 클 수 없다는 것이다. 즉 다음과 같은 공식을 만족한다.		TCP이 congestion에 취하는 기본적인 접근 방식은 '''송신자가 감지한 네트워크 congestion의 정도에 따라 자신이 해당 연결에 대해 보내는 트래픽의 전송 속도를 조절'''하는 것이다. 즉, 송신자가 자신과 목적지 사이의 경로에 congestion이 거의 없다고 판단되면 send rate를 증가시키고, 반대로 congestion이 있다고 판단되면 send rate를 줄인다. 이때, TCP는 송신자의 send rate를 조절하기 위해 '''cwnd(congestion window)'''라는 추가적인 변수를 활용한다. 이때 cwnd는 TCP 송신자가 네트워크로 트래픽을 보낼 수 있는 속도를 제한하는 제약 조건을 제공한다. 이 제약 조건은 송신자의 바이트 스트림(byte stream)에서 미확인된(unackowledged) 바이트의 양은 cwnd와 rwnd(receive window) 중 작은 값보다 클 수 없다는 것이다. 즉 다음과 같은 공식을 만족한다.
	LastByteSent − LastByteAcked ≤ min{cwnd, rwnd}		LastByteSent − LastByteAcked ≤ min{cwnd, rwnd}
	이때 rwnd의 값이 충분히 크다면, 송신자의 미확인 바이트의 양은 오직 cwnd에 의해서 제한되며, 이를 통해 send rate를 간접적으로 제한할 수 있다. 이를 이해 하기 위해 패킷 손실과 transmission delay가 무시할 수 있을 정도로 작다고 가정한 연결을 생각해 보자. 이 경우, 매 RTT의 시작에서 송신자는 cwnd 바이트의 데이터를 연결로 보낼 수 있고, RTT가 끝날 때쯤 송신자는 해당 데이터에 대한 확인 응답을 받는다. 따라서 send rate는 약 <code>cwnd/RTT bytes/sec</code>이다. 즉 송신자는 swnd 값을 조절하여 send rate를 조절할 수 있다.		이때 rwnd의 값이 충분히 크다면, 송신자의 미확인 바이트의 양은 오직 cwnd에 의해서 제한되며, 이를 통해 send rate를 간접적으로 제한할 수 있다. 이를 이해 하기 위해 패킷 손실과 transmission delay가 무시할 수 있을 정도로 작다고 가정한 연결을 생각해 보자. 이 경우, 매 RTT의 시작에서 송신자는 cwnd 바이트의 데이터를 연결로 보낼 수 있고, RTT가 끝날 때쯤 송신자는 해당 데이터에 대한 확인 응답을 받는다. 따라서 send rate는 약 <code>cwnd/RTT bytes/sec</code>이다. 즉 송신자는 swnd 값을 조절하여 send rate를 조절할 수 있다.
31번째 줄:		31번째 줄:
	호스트가 패킷 손실을 감지하는 방법으로는 timeout과 3개의 중복 ACK를 수신하는 것이 있는데, 이 두 방법은 미묘한 차이점을 가지고 있다. Timeout은 네트워크가 메우 혼잡한 상태라고 간주되기 때문에 cwnd의 급격한 감소가 필요하다. 하지만 3개의 중복 ACK가 수신된 경우는 패킷의 손실이 있더라도, 그 외의 패킷들은 모두 정상적으로 도착하고 있기 때문에 timeout보다는 네트워크의 상태가 양호함을 시사한다. 따라서 3개의 중복 ACK를 수신했을 때는 '''fast recovery''' state로 전환하여 더욱 효율적인 송신을 한다.		호스트가 패킷 손실을 감지하는 방법으로는 timeout과 3개의 중복 ACK를 수신하는 것이 있는데, 이 두 방법은 미묘한 차이점을 가지고 있다. Timeout은 네트워크가 메우 혼잡한 상태라고 간주되기 때문에 cwnd의 급격한 감소가 필요하다. 하지만 3개의 중복 ACK가 수신된 경우는 패킷의 손실이 있더라도, 그 외의 패킷들은 모두 정상적으로 도착하고 있기 때문에 timeout보다는 네트워크의 상태가 양호함을 시사한다. 따라서 3개의 중복 ACK를 수신했을 때는 '''fast recovery''' state로 전환하여 더욱 효율적인 송신을 한다.

	Fast recovery가 어떻게 동작하는지 알아보기 위해 다음과 같은 상황을 살펴보자. 만약 송신자가 1~10번 세그먼트를 전송하였으나, 4번 세그먼트가 손실되었고, 수신측은 세그먼트 5, 6, 7을 받았다고 하자. 이 경우, 수신자는 ACK(4)를 3개 보낸다. 이 경우, 송신자는 ACK(4)를 3개 수신한다. 이는 패킷의 손실로 간주되며 <code>ssthresh = ~~cwd~~/2</code>, <code>cwnd = ssthresh + 3xMSS</code><ref>중복 ACK 3개를 고려해 MSS를 3개 만큼 늘린다.</ref>로 설정된다. 이후 중복 ACK를 추가로 수신할 때마다 cwnd의 값을 MSS만큼 더한다. 해당 과정을 진행하는 중, 누락된 세그먼트에 대한 ACK을 수신하면<ref>ACK(8)</ref>, cwnd를 ssthresh로 갱신하고, congesiton avoidance로 전환한다.		Fast recovery가 어떻게 동작하는지 알아보기 위해 다음과 같은 상황을 살펴보자. 만약 송신자가 1~10번 세그먼트를 전송하였으나, 4번 세그먼트가 손실되었고, 수신측은 세그먼트 5, 6, 7을 받았다고 하자. 이 경우, 수신자는 ACK(4)를 3개 보낸다. 이 경우, 송신자는 ACK(4)를 3개 수신한다. 이는 패킷의 손실로 간주되며 <code>ssthresh = cwnd/2</code>, <code>cwnd = ssthresh + 3xMSS</code><ref>중복 ACK 3개를 고려해 MSS를 3개 만큼 늘린다.</ref>로 설정된다. 이후 중복 ACK를 추가로 수신할 때마다 cwnd의 값을 MSS만큼 더한다. 해당 과정을 진행하는 중, 누락된 세그먼트에 대한 ACK을 수신하면<ref>ACK(8)</ref>, cwnd를 ssthresh로 갱신하고, congesiton avoidance로 전환한다.

	'''TCP Reno'''는 fast recovery를 이용하는 TCP 버전이며, '''TCP Tahoe'''는 fast recovery를 사용하지 않는다. timeout이던 3번의 중복 ACK던 무조건 cwnd를 1MSS로 줄이고 slow start 상태로 전환한다. 오른쪽의 그래프는 TCP Reno와 TCP Tahoe의 차이점을 잘 보여준다.		'''TCP Reno'''는 fast recovery를 이용하는 TCP 버전이며, '''TCP Tahoe'''는 fast recovery를 사용하지 않는다. timeout이던 3번의 중복 ACK던 무조건 cwnd를 1MSS로 줄이고 slow start 상태로 전환한다. 오른쪽의 그래프는 TCP Reno와 TCP Tahoe의 차이점을 잘 보여준다.
51번째 줄:		51번째 줄:
	[[파일:Two TCP connections sharing a single bottleneck link.png\|대체글=Figure 3. Two TCP connections sharing a single bottleneck link\|섬네일\|Figure 3. Two TCP connections sharing a single bottleneck link]]		[[파일:Two TCP connections sharing a single bottleneck link.png\|대체글=Figure 3. Two TCP connections sharing a single bottleneck link\|섬네일\|Figure 3. Two TCP connections sharing a single bottleneck link]]
	K개의 TCP 연결이 각각 end-to-end 경로를 가지고 있지만, 모두 전송 속도가 R bps인 병목 링크(bottleneck link)를 통과한다고 가정하자.<ref>여기서 병목 링크란, 각 연결 경로에 있는 다른 링크들은 혼잡하지 않고, 병목 링크보다 충분한 전송 용량을 가진다는 의미다.</ref>		K개의 TCP 연결이 각각 end-to-end 경로를 가지고 있지만, 모두 전송 속도가 R bps인 병목 링크(bottleneck link)를 통과한다고 가정하자.<ref>여기서 병목 링크란, 각 연결 경로에 있는 다른 링크들은 혼잡하지 않고, 병목 링크보다 충분한 전송 용량을 가진다는 의미다.</ref>
	각각의 연결들은 큰 파일을 전송 중이며, 병목 링크를 통과하는 UDP 트래픽은 없다고 하자. 이때, 혼잡 제어 메커니즘이 '''공정하다(fair)''' 고 말하려면, 각 연결의 '''평균 transmission rate가 R/K에 근접'''해야 한다. 즉, 각각의 연결이 link capacity를 동일하게 나누어 가져야 한다.		각각의 연결들은 큰 파일을 전송 중이며, 병목 링크를 통과하는 UDP 트래픽은 없다고 하자. 이때, 혼잡 제어 메커니즘이 '''공정하다(fair)''' 고 말하려면, 각 연결의 '''평균 transmission rate가 R/K에 근접'''해야 한다. 즉, 각각의 연결이 '''link capacity를 동일하게 나누어 가져야 한다.'''
	[[파일:Throughput realized by TCP connections 1 and 2.png\|대체글=Figure 4. Throughput realized by TCP conn. 1 and 2\|섬네일\|Figure 4. Throughput realized by TCP conn. 1 and 2]]		[[파일:Throughput realized by TCP connections 1 and 2.png\|대체글=Figure 4. Throughput realized by TCP conn. 1 and 2\|섬네일\|Figure 4. Throughput realized by TCP conn. 1 and 2]]
	TCP는 각각의 연결들이 서로 다른 시점에 시작될 수 있고, 어떤 시점에서는 서로 다른 window size를 가질 수도 있음에도 공정하다고 할 수 있다. 이는 figure 4로 주어진 그래프가 잘 설명해주고 있는데, 이를 이해하기 위해서 다음과 같은 상황을 가정하자:<br>		TCP는 각각의 연결들이 서로 다른 시점에 시작될 수 있고, 어떤 시점에서는 서로 다른 window size를 가질 수도 있음에도 공정하다고 할 수 있다. 이는 figure 4로 주어진 그래프가 잘 설명해주고 있는데, 이를 이해하기 위해서 다음과 같은 상황을 가정하자:<br>
	1) Link capacity가 R인 하나의 링크를 두개의 TCP 연결이 공유하며, 다른 TCP 연결이나 UDP 패킷은 간섭하지 않는다.<br>		1) Link capacity가 R인 하나의 링크를 두개의 TCP 연결이 공유하며, 다른 TCP 연결이나 UDP 패킷은 간섭하지 않는다.<br>
	2) 두 연결은 같은 MSS와 RTT를 가진다. 즉, cwnd가 같다면 처리량도 같다.<br>		2) 두 연결은 '''같은 MSS와 RTT를 가진다. 즉, cwnd가 같다면 처리량도 같다.'''<br>
	3) AIMD에서 Slow-start 단계는 무시하고, 항상 congesiton avoidance 단계에서 작동하며, TCP Reno를 따른다.		3) AIMD에서 Slow-start 단계는 무시하고, 항상 congesiton avoidance 단계에서 작동하며, TCP Reno를 따른다.
	4) 두 연결 모두 전송할 데이터가 충분하다.<br>		4) 두 연결 모두 전송할 데이터가 충분하다.<br>
	이런 상황에서 TCP가 link capacity를 두 연결에 공정하게 나눈다면, throughput은 원점에서 45도 각도로 뻗는 직선 상에 위치해야 한다. 또한 두 연결의 throughput의 합이 R이 되어야 이상적이다. 즉, 이상적인 목표는 equal bandwidth share선과 full bandwidth utilization선이 교차하는 지점 근처에 연결의 throughput이 수렴하는 것이다.<br>		이런 상황에서 TCP가 link capacity를 두 연결에 공정하게 나눈다면, throughput은 원점에서 45도 각도로 뻗는 직선 상에 위치해야 한다. 또한 두 연결의 throughput의 합이 R이 되어야 이상적이다. 즉, 이상적인 목표는 equal bandwidth share선과 full bandwidth utilization선이 교차하는 지점 근처에 연결의 throughput이 수렴하는 것이다.<br>
	이제, 위에서 한 가정과 그래프를 바탕으로 두 TCP 연결이 어떻게 진행되는지 살펴보자. 처음에 두 TCP 연결의 throughput은 그래프의 점 A와 같다. 이 경우, TCP의 congestion avoidance 알고리즘에 따라 매 RTT마다 cwnd를 1MSS 씩 증가시키고, 이에 따라 두 연결의 throughput은 점 A를 시점으로하는 45도 선을 따라 증가한다. 결국은 어느 시점에서 패킷 손실이 일어나게 되는데, 그 시점의 throughput이 점 B라고 하자. 이때 TCP는 이 손실에 반응해 각 연결의 cwnd를 반으로 줄인다. 그 결과 throughput은 점 C에 해당하는 값이 된다. 이러한 과정을 반복하여, 두 연결의 throughput은 결국 equal bandwidth share선 근처에서 진동하게 된다. 또한 처음 위치가 어디든지 그 결과는 이러하다. 이는 TCP 연결이 위의 가정을 만족할 경우 일정한 성능을 보장하며 각 연결들에게 균등한 link capacity를 제공한다는 것을 알려준다.<ref>만약 RTT가 더 짧은 연결이 존재한 다면, 해당 연결은 cwnd가 더욱 빠르게 증가하므로 상대적으로 더 높은 throughput을 누릴 수 있다.</ref>		이제, 위에서 한 가정과 그래프를 바탕으로 두 TCP 연결이 어떻게 진행되는지 살펴보자. 처음에 두 TCP 연결의 throughput은 그래프의 점 A와 같다. 이 경우, TCP의 congestion avoidance 알고리즘에 따라 매 RTT마다 cwnd를 1MSS 씩 증가시키고, 이에 따라 두 연결의 throughput은 점 A를 시점으로하는 45도 선을 따라 증가한다. 결국은 어느 시점에서 패킷 손실이 일어나게 되는데, 그 시점의 throughput이 점 B라고 하자. 이때 TCP는 이 손실에 반응해 각 연결의 cwnd를 반으로 줄인다. 그 결과 throughput은 점 C에 해당하는 값이 된다. 이러한 과정을 반복하여, '''두 연결의 throughput은 결국 equal bandwidth share선 근처에서 진동하게 된다.''' 또한 처음 위치가 어디든지 그 결과는 이러하다. 이는 TCP 연결이 위의 가정을 만족할 경우 일정한 성능을 보장하며 각 연결들에게 균등한 link capacity를 제공한다는 것을 알려준다.<ref>만약 RTT가 더 짧은 연결이 존재한 다면, 해당 연결은 cwnd가 더욱 빠르게 증가하므로 상대적으로 더 높은 throughput을 누릴 수 있다.</ref>

	===Fairness and UDP===		===Fairness and UDP===
67번째 줄:		67번째 줄:

	===Parallel TCP Connections===		===Parallel TCP Connections===
	만약 각각의 UDP 연결이 link capacity가 균등하게 link capacity를 배분받도록 강제할 수 있다 해도, 공정성 문제는 완전히 해결되지 않는다. 왜냐하면, TCP 기반 애플리케이션은 종종 병렬 연결(pararell connection)을 사용하기 때문이다. 예를 들어, 웹 브라우저는 하나의 웹 페이지에 있는 여러 object를 전송하기 위해 다수의 병렬 TCP 연결을 사용하며, 이를 통해 congestion link에서도 더 많은 link capacity를 확보할 수 있다. 예를 들어, transmission rate가 R인 링크에서 9개의 클라이언트-서버 애플리케이션이 각자 하나의 TCP 연결을 사용한다고 하자. 이때 새로운 애플리케이션이 1개의 TCP 연결만 추가하면, 각 애플리케이션은 대략 R/10씩 나누어 갖는다. 하지만 이 새 애플리케이션이 11개의 병렬 TCP 연결을 사용하면,		만약 각각의 UDP 연결이 link capacity가 균등하게 link capacity를 배분받도록 강제할 수 있다 해도, 공정성 문제는 완전히 해결되지 않는다. 왜냐하면, '''TCP 기반 애플리케이션은 종종 병렬 연결'''(pararell connection)을 사용하기 때문이다. 예를 들어, 웹 브라우저는 하나의 웹 페이지에 있는 여러 object를 전송하기 위해 다수의 병렬 TCP 연결을 사용하며, 이를 통해 congestion link에서도 더 많은 link capacity를 확보할 수 있다. 예를 들어, transmission rate가 R인 링크에서 9개의 클라이언트-서버 애플리케이션이 각자 하나의 TCP 연결을 사용한다고 하자. 이때 새로운 애플리케이션이 1개의 TCP 연결만 추가하면, 각 애플리케이션은 대략 R/10씩 나누어 갖는다. 하지만 이 새 애플리케이션이 11개의 병렬 TCP 연결을 사용하면,
	이 애플리케이션은 전체 bandwidth의 절반 이상을 차지한다. 즉, 병렬 연결을 사용하면 공정성이 깨지는 현상이 발생한다.		이 애플리케이션은 전체 bandwidth의 절반 이상을 차지한다. 즉, 병렬 연결을 사용하면 공정성이 깨지는 현상이 발생한다.

	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]