네트워크 시뮬레이션 공방

하나의 시나리오에서 네트워크 파라미터의 변경이 전혀없이 생성된 결과 그래프들인데도 불구하고, 실행할 때마다 그 값이 달라지는 경우가 종종 있다. (물론 시뮬레이션 seed값이 다른 경우라면 이는 당연할 것이며, 여기에서는 동일한 seed 값이 사용된 경우를 얘기한다) 이 경우, OPNET에 익숙하지 않은 사용자들은 당황하거나, 심지어는 OPNET 시뮬레이션 결과를 불신하는 상황이 벌어지기도 한다.
하지만, 이는 OPNET에서 결과값을 기록하는 방식을 정확히 이해하지 못하는 데서 발생하는 오해(?)로서, 시뮬레이션이 잘못된 것이 전혀 아니다. 즉, 시뮬레이션의 실제 결과값은 동일하지만, 이 결과값들을 가공하여 사용자에게 보여주는 과정에서 마치 다른 결과값들인 것처럼 보여지는 경우가 있는 것이다. 어떤 관점에서 보면, 결과값을 사용자에게 보여주는 방법에 있어서 너무 다양한 수단을 제공하기 때문에 발생하는 문제라고 할 수 있다.
그 예로서, 아래의 두 결과 그래프를 비교해보도록 하자. 첫번째 그래프는 VoIP_example 시나리오  (조만간 출판될 "OPNET 중급입문" 교재에 소개되어 있다)에서 Calling_1 노드의 Voice Application -->Traffic Received (bytes/sec) 항목을 그린 것이며(10분동안 수행된다), 두번째 그래프는 동일한 시나리오를 5분동안만 수행하고 동일한 항목의 결과를 그린 것이다.

두 개의 결과값이 다르게 보이는 것을 확인할 수 있을 것이다. 동일한 시뮬레이션인데도 불구하고 왜 결과값이 달라보이는 것일까? 그 이유는 역설적이지만 두 시뮬레이션에서 동일한 "Values per statistic" 속성값이 사용되었기 때문이다. Values per statistic 속성은 하나의 결과항목(statistic)을 위해서 몇 개의 값(value point)을 기록할 것인가를 지정하는 것으로, 시뮬레이션 수행시 Configuration/Run DES 창에서 설정할 수 있으며 기본값은 100이다.

두 시뮬레이션에서 동일하게 100개의 값만을 최종적으로 기록하므로, 10분(600sec)동안 시뮬레이션을 한 경우에는 600sec/100 = 6sec 간격으로 데이터를 기록하고 5분(300sec)동안 시뮬레이션을 한 경우에는 300sec/100 = 3sec 간격으로 데이터를 기록하게 된다. 기록되는 데이터는 시간에 대한 평균값이므로, 설령 동일한 시각의 기록이라 할지라도 기록 간격이 다르면 서로 다른 값으로 보여지게 된다.
다음의 결과는 이러한 매커니즘을 확인하기 위한 것이다. 첫번째 그래프는 Values per statistic 값을 100으로 두고 5분동안 수행한 것이며, 두번째 그래프는 Values per statistic 값을 200으로 변경하고 10분동안 수행한 것이다. 따라서, 두 시뮬레이션에서 데이터를 기록하는 간격은 동일하게 3sec이다. 5분까지의 결과만을 살펴보았을 때, 두 시뮬레이션의 결과가 완벽하게 일치하는 것을 확인할 수 있다.

이렇게 시뮬레이션 수행시간에 따라 결과 그래프가 달라지는 현상을 피하고 싶다면, 해당 결과항목(statistic probe)의 capture mode를 수정하여 데이터 기록 주기를 일정하게 고정시켜주면 된다. 단, 이 상태에서 긴 수행시간에 대해서 시뮬레이션을 수행할 경우, 기록되는 데이터 양의 증가로 인해 결과 프래프를 표현하는데 불편함이 발생할 수 있으니 주의하기 바란다.
다음의 결과 그래프는 동일한 시뮬레이션 결과에 대해서 데이터 기록 간격을 서로 달리하여 결과를 수집하여 그 차이를 비교해본 것이다. 즉, 세 시뮬레이션에서 실제로 발생한 raw data는 모두 같지만, 결과 데이터를 기록하는 간격이 6sec(600sec/100), 3sec(600sec/200), 1sec(매 1초마다 기록하도록 고정)로 다를 뿐이다.

단말의 수가 많은 세그먼트에서 실제 네트워크 구성시, 이더넷 허브를 데이지 체인(daisy chain) 형태로 연결하여 사용하는 경우가 있다. 즉, 허브에 허브를 연결하여 연결 가능한 포트수를 늘리는 것으로, 허브의 포트수가 부족한 경우에 많은 포트수를 가지는 새로운 장비를 구입할 필요없이 기존의 허브를 활용하여 문제를 해결할 수 있으므로, 상당히 유용한 방법이며 종종 사용된다.
이러한 구성이 OPNET에서도 가능할까? 아쉽게도 이렇게 허브를 연속적으로 연결하는 구성은 OPNET에서 지원되지 않는다. 즉, OPNET의 이더넷 허브 모델은 자신이 다른 허브와 직접 연결되지 않는다고 가정하고 만들어졌기 때문에, 허브에 허브를 연결하고 시뮬레이션을 수행하면 다음과 같은 에러 메시지를 보여주고 시뮬레이션이 중단된다.

이러한 에러메시지가 출력되는 직접적인 이유는 이덧넷 허브 노드 모델에 사용되는 etherent_hub_v2 프로세스 모델의 init 스테이트에서 연결된 주변 노드들을 검사하고 만약 허브와 연결되어 있으면 시뮬레이션을 중단시키기 때문이다.
init 스테이트의 Exit 블럭을 살펴보면 168라인에 다음과 같은 코드가 있다. 이웃 노드에 등록된 프로세스들을 살펴보고 "protocol" 속성값으로 "eth_hub"를 가진 프로세스가 있으면, 에러 메시지를 출력하고 시뮬레이션을 종료(ethernet_hub_concat_log_wirte() 함수)시키는 것이다.

물론, 단순히 이 부분의 코드를 삭제한다고 해서 데이지 체인으로 연결된 허브가 성공적으로 시뮬레이션 되지는 않는다. 이 부분에서 시뮬레이션을 종료시키는 이유는 데이지 체인 형태의 연결에 의한 문제인 경우, 이후의 코드에서 다른 원인에 의해서 발생하는 에러메시지와 구분되지 않아서 혼란을 주는 것을 예방하기 위해서이기 때문이다.
이러한 문제를 해결하는 방안은 충분한 포트수를 가지는 이더넷 허브 모델을 사용(256 포트를 가지는 모델을 기본으로 제공한다)하거나, 허브와 허브 사이에 브릿지나 스위치를 연결해주는 것이다.
시뮬레이션 관점에서 본다면, 한개의 허브에 수백개의 단말을 개별적으로 연결해야하는 경우는 극히 드물다. 왜냐하면 많은 수의 단말에 의한 전체적인 영향을 살펴보기 위해서라면, 한개의 LANs 노드 모델로 충분히 모델링이 가능하며 훨씬 간편하기 때문이다.

인터넷망에서 사용자가 경험하는 서비스 품질은 백그라운드 트래픽(해당 사용자에 의해서 발생되는 패킷이외의 패킷들)에 의해서 많은 영향을 받는다. 즉, 동일한 망에서 서비스를 받는 경우에도 해당 경로상에 존재하는 백그라운드 트래픽의 양에 따라 사용자가 경험하는 서비스 품질이 달라지는 것이다. OPNET에서는 이러한 백그라운 트래픽을 간단하게 설정할 수 있는 몇 가지 방법을 제공하고 있는데, 그 중 한가지가 링크의 "Traffic Load" 속성을 이용하는 것이다. 이 속성을 이용하면 백그라운드 트래픽을 매우 쉽게 설정할 수 있을 뿐만 아니라, 시뮬레이션 수행시간에는 거의 영향을 미치지 않으면서 큰 백그라운드 트래픽에 의한 영향을 살펴볼 수 있다.
백그라운드 트래픽이 시뮬레이션 결과에 어떤 영향을 미치는지 예제를 통해 살펴보도록 하자. 사용할 예제망의 토폴로지는 다음과 같으며, Calling_1 노드와 Called_party 노드간에는 "Voice over IP Call (PCM Quality)" 어플리케이션을 설정해 주었다.

예제망에서 백그라운드 트래픽이 설정될 구간은 GW_1 노드와 ISP_backbone 노드 사이의 링크이며, 설정할 트래픽 양은 링크 용량 대비 30%, 50%, 70%이다. 링크의 "Traffic Information" 속성에 한개의 열(Row)을 추가하고, "Traffic Load (bps)" 속성을 Edit 모드로 선택하여 300sec에서 400sec 사이에 트래픽이 발생하도록 설정해 주었다. 이때 트래픽의 크기는 %가 아닌 bps로 설정되어야 한다. 이 예제에서는 DS3급(44.736Mbps) 링크를 사용하였으므로, 30%, 50%, 70%에 맞추어 13,420,800bps, 22,368,000bps, 31,315,200bps를 설정해 주었다. 다음 그림은 이 과정을 보인 것이다.

이제 각 설정별 시나리오에 대한 시뮬레이션을 수행하고 결과를 비교해보도록 하자. 먼저 백그라운드 트래픽이 잘 걸렸는지 확인하기 위해서, GW_1 노드와 ISP_backbone 노드 사이 링크의 throughput을 살펴보도록 한다. 다음 그림은 우리가 설정해준 크기대로 백그라운드 트래픽이 잘 걸렸음을 보여준다.

이제 Calling_1 노드에 수신된 패킷의 End-to-End Delay를 살펴보면, 백그라운드 트래픽이 높아질수록 delay 값이 증가하는 것을 다음과 같이 확인할 수 있다.

Delay가 증가하면 MOS는 떨어지게 되는데, 이 역시 다음과 같이 확인할 수 있다.

이상과 같이 백그라운드 트래픽을 링크에 간단하게 설정하는 방법과, 이러한 설정이 실제로 시뮬레이션 결과에 영향을 미친다는 것을 살펴보았다. 하지만, 여기에서 한가지 의문을 가질 수 있는데, 그것은 백그라운드 트래픽이 시뮬레이션 결과에 영향을 미치기는 하지만, 그 차이가 예상보다(?) 터무니없이 작다는 점이다. (이 예제에서 백그라운드 트래픽을 70%까지 증가시켰을 경우에도 백그라운드 트래픽이 전혀 없을 때와는 차이는 겨우 170usec 정도에 불과하다) 이 문제에 대해서는 다음 포스팅에서 다루어 보도록 하겠다.