네트워크 시뮬레이션 공방

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.

다음의 그림은 OPNET WiMAX 모델에서 제공하는 PHY 파이프라인 스테이지 모델의 구조를 기능별 블럭으로 개념적으로 구분하여 나타낸 것으로, 파이프라인 스테이지 코드를 분석하기전에 살펴보면 많은 도움이 된다.

WiMAX 모델의 PHY 기능은 크게 Pathloss, Co-channel interference, Multipath fading의 3가지 블럭으로 나누어진다. Pathloss는 송신자와 수신자 사이에서 발생하는 신호 감쇄로서 IEEE Erceg 모델과 ITU Vehicular/Pedestrian 모델, 그리고 Free Space 모델을 지원한다. 또한 pathloss에는 shadow fading도 포함된다.
Co-channel interference는 동일한 주파수(Sub-carrier)를 사용하는 burst간의 충돌에 의한 신호감쇄로서, 시간/주파수가 얼마나 중첩되는냐에 따라 계산된다.
Multipath fading은 신호가 여러 경로로 수신되는 과정에서 그 합성 신호의 강도가 시공간적으로 변하는 현상이며, 주기적으로 multipath 채널 모델에 따라 그 영향이 새로 계산된다.

OPNET에서는 PPP(Point-to-point protocol)를 위한 별도의 프로세스 모델을 제공하지 않지만, IP 관련 프로세스 모델에서 PPP 기능을 함께 제공한다. 따라서 PPP 링크의 경우 ip 프로세서 모듈에 직접 연결된 point-to-point 송/수신 포트에 접속된다. (point-to-point tx/rx 포트와 point-to-point 링크 모델은 PPP만을 위한 것만이 아님에 유의할 필요가 있다)
또한, PPP를 위한 별도의 패킷 포맷 역시 사용되지 않으며, 단지 PPP 프레임 오버헤드에 해당하는 크기만큼이 IP 패킷 크기에 추가로 적용될 뿐이다. 적용되는 PPP 프레임 오버헤드 크기는 7Bytes이다. 즉, PPP 링크로 전송되는 IP 패킷의 경우 7Bytes(56bits)만큼 패킷의 크기가 증가되어져 사용된다. 다음 그림은 표준[1, 2]에 정의된 PPP 프레임 구조를 나타낸 것이며, 7Bytes는 PPP 프레임 오버헤드의 최소 크기이다. (인터넷상에는 PPP 프레임의 오버헤드가 8Bytes 고정으로 표현된 자료가 많은데, 이는 정확하지 않은 것이다)

다음 그림은 20ms마다 200Bytes 크기의 패킷이 IP 계층에서 발생하였을 때, PPP 링크 모델을 통해 전달되는 트래픽의 크기를 측정한 것이다(비교를 위하여 IP 계층에서 발생된 트래픽의 크기를 함께 나타내었다). 측정된 트래픽의 크기가 82.8Kbps이므로, 개별 패킷의 크기는 82,800 bits/sec * 20 ms / 8 bits/Byte = 207Bytes이다. 즉, PPP 링크를 위한 오버헤드 크기만큼 증가되어져 있는 것이다.

[1] RFC 1661, "The Point-to-Point Protocol (PPP)," IETF, 1994.
[2] RFC 1662, "PPP in HDLC-like Framing," IETF, 1994.

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

SITL 시뮬레이션을 위한 sitl_virtual_gateway_to_real_world 노드 모델은 사용자가 설정할 수 있는 몇가지 속성들을 제공하는데, 그 중 한 가지가 "Incoming Packet Filter String" Attribute이다.

Incoming Packet Filter String 속성은 해당 시뮬레이션에 필요하지 않은 패킷들을 차단하고 필요한 패킷들만을 시뮬레이션에 사용하기 위한 것이며, 필터 기술 방식은 BPF(Berkely Packet Filter) 문법을 따른다.
BPF 문법은 TcpDump[1], WinPCap[2], Wireshark[3] 등에서도 사용되고 있으므로, 해당 도구의 매뉴얼을 참고하여도 된다. 다음은 TcpDump, WinPCap, Wireshark의 필터링 문법에 대한 설명 페이지 이다.

- http://www.tcpdump.org/tcpdump_man.html
- http://www.winpcap.org/docs/docs_412/html/group__language.html
- http://wiki.wireshark.org/CaptureFilters

한가지 주의해야할 사항은 Wireshark의 경우 2 종류의 필터(Capture Filter와 Display Filter)가 사용되고 있으며, 이중 Capture FIlter만이 BPF 문법을 사용한다. 즉, Display Filter에 사용되는 표현은 SITL 패킷 필터에 사용할 수 없다.

[1] http://www.tcpdump.org/
[2] http://www.winpcap.org/
[3] http://www.wireshark.org/

OPNET WiMAX 모델에서는 ASN-GW를 위한 별도의 노드 모델을 제공하지 않으며, 일반적인 라우터 모델을 ASN-GW로 사용한다. 하지만, 단순히 라우터를 BS에 연결한다고 해서 ASN-GW로 동작하는 것은 아니며 BS와 ASN-GW로 사용할 라우터 사이에 터널링을 설정해 주어야 한다. BS에 반드시 ASN-GW가 연결될 필요는 없다.

다음 그림은 표준[1]에서 정의하고 있는 MS-initiated HO 절차(Figure J.3 참조)이며, "WiMAX 모델(97) - Handover"에서 설명한 OPNET WiMAX 모델에 구현된 절차는 MS-initiated HO와 일치한다. BS-initiated HO(Figure J.4참조)는 OPNET WiMAX 모델에서 지원하지 않는다.

[1] IEEE 802.16-2009, "Air Interface for Broadband Wireless Access Systems", 2009

"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 시뮬레이션 공방"에서 다루는 OPNET은 정확히는 OPNET Modeler를 의미합니다. OPNET사의 제품군에는 Modeler외에도 IT Guru, SP Guru나 APM이 있었습니다만, 회사 설립 초기에 Modeler를 주력으로 성장했기때문에 OPNET Modeler는 OPNET으로 통칭되었습니다. 이 블로그 이름을 "OPNET Modeler 시뮬레이션 공방"이 아니라 "OPNET 시뮬레이션 공방"으로 지은 이유도 이 때문이었습니다.
OPNET사는 2년전에 Riverbed사에 매각되었습니다만("OPNET, 리버베드에 인수됨" 참조), 그 이후로도 OPNET이라는 이름에는 변동이 없었고, OPNET Modeler에 대한 업데이트는 계속 이루어져왔습니다("OPNET Modeler/Release notes" 참조),
그런데, 최근 OPNET 이라는 명칭이 변경될 것 같다는 느낌이 듭니다. 다음은 Riverbed사 홈페이지의 제품 소개 화면을 오늘 캡춰한 것인데, Riverbed Modeler로만 소개되어 있을뿐 OPNET이라는 단어는 어디에도 없습니다.

OPNET이라는 단어가 사라진 Modeler 소개, 굉장히 낯서네요. 다음번 버전이 나와봐야 확실해질 것 같습니다만, 어쩌면 블로그 이름도 변경해야 할지도 모르겠네요. (하지만, "Riverbed Modeler"는 임팩트가 너무 약하군요)

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.