네트워크 시뮬레이션 공방

시스템 성능에 비하여 과도한 트래픽이 사용된 것이 아님에도 불구하고, 시스템 NIC에 수신된 패킷이 Riverbed(OPNET) SITL 게이트웨이로 넘겨지는 과정에서 일부가 누락되는 경우가 있다. VLC 프로그램을 사용하여 비디오 스트리밍 트래픽을 발생시키는 경우에 이러한 현상이 확인되었으며, 그 원인은 패킷 간격때문인 것으로 생각된다.

1) 다음 그림은 Gigabit 이더넷 인터페이스를 통해 Iperf로 30Mbps 트래픽을 발생시켰을 때 수신된 패킷 간격을 측정한 것이다. 패킷 간격이 수백us인 것을 확인할 수 있으며, Riverbed(OPNET) SITL GW에서 패킷 누락없이 처리된다.

2) 다음 그림은 VLC를 사용하여 평균이 수Mbps인 트래픽을 발생시켰을 때 수신된 패킷 간격을 측정한 것이다. 패킷들이 집중된 구간에서는 때때로 수us 간격으로 패킷이 수신되는 것을 확인할 수 있으며, Riverbed(OPNET) SITL GW
에서 패킷 누락이 발생한다.

"RIP 라우팅 예제"에서 사용한 예제망의 라우팅 프로토콜을 OSPF로 변경하여 OSPF의 동작을 확인해보기로 하자. 첫번째 예제의 네트워크 토폴로지와 실제로 할당된 IP주소 내역은 다음과 같다.

시뮬레이션을 수행한 후, R1 노드에서 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다. ("라우팅 경로 확인하기" 참조).

R2 - R4, R3 - R4, R4 - Server 네트워크에 대한 라우팅 정보가 OSPF에 의해 생성되었으며, R2 - R4, R3 - R4 네트워크에 대한 Metric은 4, R4 - Server 네트워크에 대한 Metric은 5임을 확인할 수 있다. (R4 - Server 네트워크에 대해서 2개의 경로 정보가 구성된 것은 ECMP 때문이다. ECMP의 영향에 대해서는 이후의 글에서 살펴볼 것이다.) "OSPF에서의 링크 비용"에서 설명하였듯이 OSPF는 대역폭 정보로부터 계산된 인터페이스의 비용을 기본 Metric으로 사용하며, 기본값 사용시 DS3(44.746Mbps) 링크의 비용은 2, Fast Ethernet(100Mbps) 링크의 비용은 1로 계산된다. 따라서, R1 -> R2 -> (R4) 경로와 R1 -> R3 -> (R4) 경로의 Metric은 2 + 2 = 4가 되며, R1-> R2-> R4 -> (Server) 경로의 Metric은 2 + 2 + 1= 5가 된다.

Client 노드로부터 Server 노드로의 트래픽 전달 경로는 다음과 같이 2홉 경로(R1 -> R3 -> R4 경로)으로 확인되며, 이는 라우팅 테이블과 일치한다. (이후의 1홉 예제의 결과와 비교할 것이므로 R1 -> R3 -> R4 경로, 또는 R1 -> R2 -> R4 경로 어느 쪽이던 별 상관은 없다)

이제 R1 노드와 R4 노드사이에 1홉 링크를 추가하여 OSPF의 특성을 보다 자세히 살펴보자. 다음 그림은 첫번째 예제를 변형한 두번째 예제의 구조이다. R1 노드와 R4 노드 사이에 다른 링크(DS3)보다 작은 대역폭의 링크(DS1)를 추가하였다.

시뮬레이션을 수행한 후, 두 번재 시나리오에서 R1 노드에 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다.

R1 노드와 R4 노드를 연결하는 링크가 추가되었음에도 불구하고 R4 - Server 네트워크에 대한 경로는 변경이 없으며, Metric도 동일하게 5임을 확인 할 수 있다.
이제 Client 노드로부터 Server 노드로의 트래픽 전달 경로를 살펴보면 라우팅 테이블의 구성과 같이 2홉 경로(R1 -> R3 -> R4)인 것을 알 수 있다.

즉, 기본적으로 OSPF는 링크의 대역폭 정보로부터 계산된 인터페이스의 비용을 기반으로 라우팅 경로를 선정한다. 만약, 링크(인터페이스) 비용이 더 작은 경로가 존재하는 경우라면, 홉 수에 상관없이 해당 경로를 라우팅 경로로 선정한다.

512bytes 크기의 데이터가 30ms 간격으로 발생하며 TCP Ack를 응답받는데 걸리는 시간이 충분히 큰 경우, TCP Nagle 알고리즘을 사용하지 않은 경우와 사용한 경우의 동작을 예측해보면 다음과 같다.

이제 시뮬레이션을 통해 이 예측이 맞음을 확인해보도록 하자. 다음 그림은 TCP Nagle 알고리즘의 동작을 시험하기 위해서 "TCP Window Scaling(1) - LFN에서의 동작"에서 사용한 시나리오를 수정한 시험망 토폴로지를 나타낸 것이다. Server 노드와 STA 노드 사이의 RTT는 100ms가 되도록 설정한다.

Nagle 알고리즘을 사용하지 않은 경우와 사용한 경우의 비교를 위하여, Server 노드와 STA 노드의 "Nagle Algorithm" 속성값을 다음 그림과 같이 Disabled로 설정한 시나리오와 Enabled로 설정한 시나리오를 작성한다.

시뮬레이션을 수행한 후, Nagle 알고리즘이 실제로 수행되었음은 다음 그림처럼 TCP 송신측(이 시나리오에서는 Server 노드)에서 측정된 "Send Delay (Nagle's) (sec)" 결과항목값을 관찰하여 확인할 수 있다. ("Nagle Algorithm" 속성값을 Disabled로 설정한 시나리오에서는 값이 기록되지 않는다)

"Send Delay (Nagle's) (sec)" 결과항목값은 Nagle 알고리즘의 수행여부를 확인하는데는 유용하지만, Nagle 알고리즘의 효과를 확인하기에는 충분하지 않다.
Nagle 알고리즘으로 인한 효과를 확인하기 위해서, Server 노드에서 전송한 IP 패킷의 수를 비교해보면 Nagle 알고리즘을 사용한 경우에 네트워크로 내보낸 패킷의 수가 다음 그림처럼 크게(이 시나리오에서는 약 1/3 수준으로) 감소하였음을 확인할 수 있다.

패킷의 수는 이처럼 크게 감소하지만 전송된 데이터의 양에는 차이가 없다. 다음 그림은 전송된 데이터 양이 동일함을 확인하기 위하여, STA 노드의 TCP 단에서 수신한 트래픽 양을 비교한 것이다.

동일한 양의 데이터를 훨씬 작은 수의 패킷으로 전달 할 수 있다면, Nagle 알고리즘을 사용하는 것이 항상 유리한 것일까? 그렇지는 않다. Nagle 알고리즘은 네트워크로 내보내는 패킷의 수를 줄이기 위해 작은 크기의 패킷 전송을 제한하므로, 지연(Delay) 측면에서는 불리하다. 다음 그림은 이를 확인하기 위해서 STA 노드에서 측정한 TCP 데이터의 지연을 나타낸 것이다. Nagle 알고리즘을 사용한 경우가 사용하지 않은 경우보다 큰(이 시나리오에서는 2배 이상) 지연을 가지는 것을 확인할 수 있다.

어제(2015년 12월 1일) Riverbed Modeler 18.5.0 버전이 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.0.3 발표" 참조). Release note에는 11월 5일로 표기되어 있습니다만, 실제로 배포된 것은 12월 1일이 맞습니다.
Release note에 따르면, LTE 모델에 대한 기능 개선과 버그 수정(총 6건)이 변경된 사항입니다.

LTE 모델 개선 사항은 다음과 같습니다.
- Semi-Persistent Scheduling

Semi-Persistent Scheduling(SPS)는 음성과 같이 작은 크기의 패킷이 일정한 간격으로 발생하는 경우에 유용한 Scheduling 방법으로, SPS 기능의 추가와 함께 해당 기능의 설정을 위해 LTE Config 노드와 eNodeB 노드에 관련 파라미터들이 추가되었다고 합니다.

이외에도, 제품 구조상의 변화(Flow Analysis 등 몇 개의 기능이 제외되고 ODK가 표준 기능으로 포함됨)와 ZigBee 모델 기능 개선에 대한 설명도 있습니다만, 제품 구조의 이러한 변화는 18.0 버전에서 적용된 사항("Riverbed Modeler 18.0 발표" 참조)이고 ZigBee 모델 기능 개선은 18.0.3 버전에서 적용된 사항("Riverbed Modeler 18.0.3 발표" 참조)이므로, 18.5 버전에서 새롭게 변경된 사항들은 아닙니다.(Riverbed Modeler로 변경된 이후로는 Release note가 좀 보기 혼란스럽게 작성된다는 느낌이 드네요).

Riverbed(OPNET) Modeler WiMAX 모델에서 Multi-path fading이 계산되는 구조는 다음 그림과 같다.

SNR이 계산되면 Modulation/Coding 기법과 multi-path 종류에 따라 fading이 포함됨 Effective SNR로 변환하는 EESM(Exponential Effective SNR Mapping) 과정을 통해 multi-path fading을 반영한다. EESM의 계산 공식은 다음과 같다.

r_eff는 effective SNR이며, r_i는 i_th 서브캐리어의 순시 SNR이다. N은 서브캐리어의 수이며, beta는 MCS에 따라 변하는 계수값이다.
Riverbed(OPNET) Modeler에서는 시뮬레이션 수행시 이 공식을 직접 적용하는 대신 사전에 이 공식에 따라 계산해둔 테이블(EESM Coefficient array)을 이용하는 방식을 사용한다. EESM Coefficient 행렬 선택에는 현재의 페이딩 스테이트가 필요하다. 페이딩 스테이트는 FSMC(Finite State Markove Chain)에 의해서 결정되며, 시테이트의 수는 16개이다. 이러한 스테이트 변환은 1ms마다 일어나며, 스테이트간의 천이는 Multi-path channel 모델에 따라서 선택된 TPM(Transition Probability Matrix)에 의해서 결정된다. TPM도 사전에 계산해둔 행렬값을 사용한다.

OPNET Modeler 17.5("OPNET Modeler 17.5 PL6 발표" 참조)은 공식적으로는 MS Visual Studio 2010 버전까지만을 지원한다.
하지만, 실제로는 OPNET Modeler 17.5에서 MS Visual Studio 2013을 사용하여도 컴파일시 에러는 발생하지 않는다. (그렇더라도, MSVS 2013이 OPNET Modeler 17.5에서도 항상 문제없이 동작한다고 필자가 보장할 수는 없다.)

Nagle 알고리즘은 작은 크기의 패킷 전송을 제한하여 네트워크의 효율성을 높이기 위한 것으로, Riverbed(OPNET) Modeler TCP 모델 역시 Nagle 알고리즘을 지원한다. 다음 그림은 사용자가 Nagle 알고리즘 적용 여부를 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

이 속성에서 선택 가능한 값은 Disabled, Enabled, Per-Send 이다. Per-Send는 전송 절차가 호출된 시점에 응답(ACK)을 받지 못한 세그먼트가 존재하는 경우에만, MSS보다 작은 크기의 세크먼트 전송을 제한하는 방식이다. 기본값은 17.1 버전까지는 "Disabled", 17.5 버전에서는 "Enabled"이다.

Riverbed(OPNET) Modeler TCP 모델은 설정 가능한 최대 동시 연결 수를 사용자가 지정할 수 있도록 다음 그림처럼 Active Connection Threshold 속성을 제공한다.

TCP 연결 요청이 도착하였을 떄, 기존에 설정되어 있는 활성(active) TCP 연결의 수가 Active Connection Threshold 이상아면 해당 연결 설정 요청은 거절된다. 기본값은 Unlimited 이다.

시뮬레이션상의 노드와 실세계 장비간에 직접 통신이 일어나는 Real-Sim 형태의 SITL 시뮬레이션을 수행할 경우 실장비에서 생성한 패킷을 Riverbed(OPNET) Modeler에서 해석할 수 있어야 하다, 반대로 Riverbed(OPNET) Modeler에서 생성한 패킷도 실장비에서 사용할 수 있어야 한다.

하지만, "SITL에서 지원하는 프로토콜의 종류"에서 살펴본 것처럼 SITL에서는 UDP/TCP 계층보다 상위 계층 프로토콜에 대해서는 변환을 지원하지 않는다. 따라서, Real-Sim 형태의 SITL 시뮬레이션시에는 사용되는 트래픽의 UDP/TCP 상위계층 프로토콜에 대해서 PDU를 직접 생성하고 해석하는 기능을 사용자가 구현해 주어야만 한다.

"OPNET 중급입문"과 "G.711 모델링"에서 설명하였듯이, Riverbed Modeler(OPNET)에서는 음성 코덱을 간편하게 모델링하여 시뮬레이션에서 사용하는 기능을 제공할 뿐만 아니라 널리 사용되는 음성 코덱들을 이미 모델링하여 제공하므로 쉽게 사용할 수 있다.
G.729 계열의 경우, G.729A는 기본적으로 모델링되어 있어서 손쉽게 사용할 수 있다. 그러면, G.729 계열의 다른 코덱들은 어떻게 모델링 할 수 있을까? G.711과는 달리 G.729는 G.729A와 G.729B를 포괄하는 표현이 아니다. G.729A는 G.729와 호환되면서 보다 낮은 연산량이 사용되는 새로운 코덱이며, G.729B는 G.729나 G.729A에서 묵음 압축을 적용하는 방안이다[1, 2].
G.729는 G.729A와 Frame Size, Coding Rate가 동일하며 음성 품질도 미세한 차이가 있을 뿐이므로, Riverbed Modeler(OPNET)에서 기본적으로 제공하는 G.729A 음성 코덱 정보를 동일하게 사용하면 된다. G.729B 또는 G.729AB는 묵음 압푹이 적용된 것 뿐이므로, Riverbed Modeler(OPNET)에서 기본적으로 제공하는 G.729A (silence) 음성 코덱 정보를 사용하면 된다. 단, Riverbed Modeler(OPNET)에서는 묵음 구간에서 패킷이 전혀 발생되지 않으며, Comfort Noise 발생을 위한 Silence Insertion Descriptor(SID) 프레임 역시 사용되지 않는다. 따라서, SID 프레임과 관련된 사항은 시뮬레이션 할 수 없다(해당 기능을 구현하는 작업은 그리 어렵지 않을 것으로 생각된다).

[1] ITU-T G.729, "Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP)," 2012.
[2] http://en.wikipedia.org/wiki/G.729