네트워크 시뮬레이션 공방

Timeout이 발생하지 않았을 때의 Retransmission Timeout(RTO) 값 계산에 대한 OPNET에서의 구현 방식은 초기 표준[1]을 기본으로 하고, Roud Trip Time(RTT) 값 계산 과정은 Jacobson이 제시한 방식[2, 3]을 따른 것이다. (따라서, 최신 표준[6]에서 설명된 절차와는 약간 차이가 있다.)
즉, OPNET에서 사용하고 있는 RTO 및 Smoothed RTT(SRTT) 계산 절차는 다음과 같다(RTO 계산을 위한 상수값들을 변경하지 않고 "TCP 재전송(1) - RTO 파라미터 설정"에서 설명한 기본값을 사용하였을 때).

여기에서 LBOUND는 "TCP 재전송(1) - RTO 파라미터 설정"에서 살펴본 Minimum RTO 속성값이며, UBOUND는 Maximum RTO 속성값이다.
일반적인 통신망에서 RTT는 수백ms 이내이며, RTTVAR은 RTT보다 훨씬 작은 값을 가진다. 따라서, 대부분의 경우 RTO는 LBOUND에 의해서 결정된다.

[1] RFC 793, "Transmission Control Protocol," IETF, Sep. 1981.
[2] Jacobson V., "Congestion Avoidance and Control," In Proceeding of SIGCOMM '88, ACM, Aug. 1988.
[3] Jacobson V. and M. Karels, "Congestion avoidance and control," LBNL, Nov. 1988.
[4] RFC 1122, "Requirements for Internet Hosts - Communication Layers," IETF, Oct. 1989.
[5] RFC 2988, "Computing TCP's Retransmission Timer," IETF, Nov. 2000.
[6] RFC 6298, "Computing TCP's Retransmission Timer," IETF, Jun. 2011.
[7] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols," In Proceeding of SIGCOMM '87, ACM, Aug. 1987.

Timeout에 의한 TCP 재전송에는 RTO 값이 사용된다. 다음 그림은 OPNET에서 제공하는 RTO 값 계산관련 속성 설정창을 보인 것이다.

각 속성 항목의 용도는 다음과 같다.

- Initial RTO (sec) : RTO 초기값, 기본값은 3초.
- Minimum RTO (sec) : RTO 최소값, 기본값은 1초.
- Maximum RTO (sec) : RTO 최대값, 기본값은 64초.
- RTT Gain : Smoothed RTT(SRTT) 계산을 위한 gain, 기본값은 0.125 이다.
- Deviation Gain : RTT 분산(RTTVAR) 계산을 위한 gain, 기본값은 0.25 이다.
- RTT Deviation Coefficient : RTO 계산시 RTT 분산(RTTVAR) 반영을 위한 계수, 기본값은 4 이다.
- Timer Granularity (sec) : RTT 측정시의 시간 정밀도, 기본값은 0.5초.
- Karn's Algorithm : Karn 알고리즘 적용 여부, 기본값은 Enabled.

TCP Window Scale option을 사용하면 TCP의 전송률을 크게 증가시킬 수 있음은 "TCP Window Scaling(1) - LFN에서의 동작"에서 살펴보았으며, LFN이 아닌 경우에는 Window Sccaling option을 사용하더라도 TCP 전송률의 개선은 기대할 수 없음을 "TCP Window Scaling(2) - LFN이 아닌 경우의 동작"에서 살펴보았다. 이번에는 Window Scale option을 사용하였을 때 이론적으로 예상되는 성능과 시뮬레이션 결과가 잘 일치하는지를 살펴보기로 한다.
1.544Mbps 대역폭과 513ms의 RTT를 가지는 전송 링크에서 Window Scaling 기능이 적용되지 않는 TCP를 사용할 경우 이론적인 최대 전송율은 1.02Mbps이며, 1.5Mbps의 전송율을 내기 위해서는 100,860바이트의 Window가 필요하다[1, 2].
시뮬레이션을 통해 이 예측을 확인해 보자. "TCP Window Scaling(1) - LFN에서의 동작"에서 사용한 시나리오들에서 대역폭은 DS1(1.544Mbps)로, RTT는 513ms가 되도록 변경한다.
다음은 [1]의 예제에 맞추어 수정된 시나리오에서 Window Scaling 속성을 사용하였을 때와 사용하지 않았을  때의 전송률(throughput)을 비교한 것이다.

Window Scaling을 사용하지 않았을 때는 최대 전송률이 약 1Mbps이고 Window Scaling을 사용하면 1.5Mbps임을 확인할 수 있으며, 이는 이론적인 예측과 일치하는 것이다.

[1] http://en.wikipedia.org/wiki/Window_scaling
[2] http://nenunena.tistory.com/149

"TCP Window Scaling(1) - LFN에서의 동작"에서 살펴본 것처럼 TCP Window Scale option을 사용하면 TCP의 전송율을 크게 증가시킬 수 있다. 하지만, 이러한 성능 개선은 LFN[1]인 경우에 나타나며, LFN이 아닌 곳에서는 TCP Window Scaling option을 사용하더라도 TCP 전송률은 개선되지 않는다.
LFN이 아닌 곳에서 TCP Window Scale option이 미치는 영향을 살펴보기 위해서, "TCP Window Scaling(1) - LFN에서의 동작"에서 사용한 시나리오들의 RTT가 0ms가 되도록 변경한다.
다음은 수정된 시나리오(즉, LFN이 아닌 망)에서 Window Scaling 속성을 사용하였을 때와 사용하지 않았을 때의 전송률(throughput)을 비교한 것이다.

Server 노드에서 STA 노드로 전달되는 트래픽 전송률에 아무런 차이가 없으며, 두 경우 모두 링크의 최대 전송 속도(45Mbps)를 모두 사용하고 있는 것을 알 수 있다. 이는 Window Scaling 기능에 문제가 있어서가 아니라, RTT(Round Trip Time)가 너무 작아서 16비트로 표현되는 윈도우 크기로도 링크의 최대 전송 속도(45Mbps)에 해당하는 성능을 TCP가 낼 수 있었기 때문이다.
실제로 이 경우에도 Window Scaling 기능이 잘 동작하고 있음은 다음 그림과 같이 CWND(Congestion Window) 크기를 통해 확인할 수 있다. "TCP Window Scaling(1) - LFN에서의 동작"에서와 마찬가지로 Window Scaling을 사용하지 않았을 경우 CWND는 작은 값을 가지는 반면, Window Scaling을 사용하는 경우 CWND는 매우 큰 값을 가지는 것을 볼 수 있다.

따라서, LFN이 아닌 경우에는 Window Scaling option을 사용하더라도 TCP 전송율의 개선은 기대할 수 없다.

[1] RFC 1323, "TCP Extensions for High Performance," IETF, 1992.

OPNET TCP 모델에서는 Window Scale Option[1] 기능을 "Window Scaling"이라는 이름의 속성으로 제공한다. 다음 그림은 OPNET의 Window Scaling 속성 설정창을 보인 것이다.

그러면, Window Scaling이 적용되었을 때 실제로 성능 향상이 있는지 시뮬레이션을 통해 확인해보기로 하자. 다음 그림은 TCP Window Scaling 성능을 확인하기 위한 시험망 토폴로지이다.

ppp_wkstn 노드 모델(STA 노드)과 ppp_server 노드 모델(Server 노드), 그리고 Packet Discarder 노드 모델(Discarder_1, 2 노드)을 배치하고, 노드간을 단방향 ppp_adv 링크 모델을 사용하여 연결하였다. 링크의 전송 속도(data rate)는 DS3로 설정한다. (Discarder_1과 Discarder_2 노드는 이 시뮬레이션에서 실제로 사용되지는 않는다. 하지만, 이후의 TCP 파라미터 관련 시뮬레이션 결과들과의 비교를 쉽게 하기 위해서 이 시뮬레이션에서도 동일한 토폴로지로 구성하였다.) 링크 지연은 Server 노드와 STA 노드 사이의 RTT가 50ms가 되도록 설정한다. (이는 시험망을 LFN[1], 즉 "Long, Fat pipe Network"로 만들기 위해서이다.)

트래픽은 FTP를 사용하여 Server 노드에서 STA 노드로 50,000,000bytes 크기의 파일이 전달되도록 하였다. Window Scaling의 효과를 확인하기 위해서 STA 노드와 Server 노드의 TCP Window Scaling이 Disabled된 시나리오와 Enabled된 시나리오를 각각 저장하고, 시뮬레이션을 수행한다. (17.1 버전("OPNET Modeler 17.1 PL2 발표" 참조)까지는 Window Scaling 속성의 기본값이 Disabled였는데, 17.5 버전(OPNET Modeler 17.5 PL3 발표" 참조)부터 Enabled로 변경되었음에 유의하여야 한다.)

다음은 Window Scaling을 사용하면 TCP의 성능을 어떻게 개선시키는지 살펴보기 위해 Window Scaling 속성 사용 여부에 따른 전송율(throughput) 차이를 비교한 것이다.

Window Scaling을 사용하지 않았을 때는 최대 전송율이 불과 10Mbps 정도인 반면, Window Scaling을 사용하면 최대 전송율이 45Mbps로 크게 증가함을 확인할 수 있다. 또한, 전송율이 증가하므로 FTP 파일 전송에 걸리는 시간도 훨씬 짧아진다.
최대 전송율이 이렇게 증가한 것은 Window Scaling 사용에 따라 송/수신시에 사용하는 버퍼의 크기가 증가하였고, 이에 따라 Ack 없이 전송할 수 있는 데이터의 양이 증가하였기 때문이다. 이는 다음 그림과 같이 해당 TCP 연결의 Flight Size 결과를 통해 확인할 수 있다.

Window Scaling을 사용하지 않았을 때와 사용하였을 때의 CWND(Congestion Window) 크기를 비교해 보면 다음 그림과 같다. Window Scaling을 사용하지 않았을 경우 ssthresh 초기값으로 작은 수가 사용되므로 CWND 역시 작은 값을 가지는 반면, Window Scaling을 사용하는 경우 ssthresh 초기값으로 매우 큰 수가 사용되므로 CWND 역시 매우 큰 값을 가지는 것을 볼 수 있다.

[1] RFC 1323, "TCP Extensions for High Performance," IETF, 1992.