네트워크 시뮬레이션 공방

OPNET을 사용하다보면 버전간의 호환성 문제로 고생하는 경우가 종종 발생한다. 모델을 수정/개발해서 사용하는 경우라면, 기존 버전에서는 문제가 없는 모델이 다른 버전에서는 컴파일 또는 실행 에러가 발생하여 시뮬레이션이 중단되는 문제가 있을 수 있다. OPNET 표준 모델을 사용하는 경우에도, 동일한 시나리오를 구성하였음에도 불구하고 시뮬레이션 결과가 크게 다른 현상이 발생할 수도 있다.
 이러한 문제의 원인은 대부분 OPNET의 버그때문이 아니라, OPNET에서 제공하는 프로토콜 모델이 계속 업데이트 되고 있기 때문이다(물론, 버그때문인 경우도 있기는 하다). 즉, OPNET 버전 업에 따라 프로토콜 기능수정, 사용하는 구조체/패킷 형식 변경, 프로세스/노드 모델 파라미터 변경등이 계속 이루어지고 있으며(이런 변경은 아무런 공지사항없이 이루어지는 경우도 많다), 변경사항을 정확히 확인하지 않고 다른 버전을 적용하면 전혀 예상치 못했던 문제가 발생할 수 있다. 특히, 네트워크 시뮬레이션의 특성("NLS와 SLS" 참조)상 여러 계층의 프로토콜이 함께 사용되기때문에, 관심 대상이 아닌 다른 프로토콜의 변화도 시뮬레이션 수행 과정에서 발생하는 오류나 결과에 큰 영향을 미칠 수 있다.
다음은 16.1 버전에서 잘 동작하던 시나리오를 15.0 버전에서 그대로 적용하였을 때 시뮬레이션 결과가 크게 달라져서 사용자를 당황시킨 한가지 예이다(모델을 수정/개발하는 경우와는 달리, 표준 모델을 사용하는 경우에는 상위 버전에서 사용하던 시나리오를 하위 버전에서 적용해보는 상황이 가끔씩 있다). 16.1 버전에서는 트래픽이 꾸준히 잘 전달되는 반면, 15.0 버전에서는 트래픽이 전달되지 않는 구간이 더 많은 것을 볼 수 있다.

이러한 문제가 발생하는 원인은 WLAN 프로토콜 Data rate의 Default 설정값이 15.0 버전에서는 802.11b 11Mbps인 반면, 16.1 버전에서는 802.11g 24Mbps로 변경되었기 때문이었다. 필자는 16.1 버전에서 WLAN 모델에 상당한 변화(새로운 기능의 추가, "OPNET Modeler 16.1 PL1 발표" 참조)가 있다는 것을 알고 있는 상황이었음에도 불구하고, WLAN이 이 시뮬레이션에서의 주된 관찰 대상이 아니었기 때문에 15.0 버전에서도 별다른 차이가 없을 것이라고 가볍게 생각하였다가 고생을 했던 것이다(이런 속도 변경은 트래픽 손실과는 별 관련이 없어 보이지만, 다른 프로토콜의 동작과 결부되면 이 예처럼 예상치 못한 결과를 초래하기도 한다).

"OPNET 기초다지기" 3.2절의 간섭이 있는 무선랜 예제를 수행할 때, 16.1 버전을 사용할 경우 다음 그림과 같이 에러가 발생하는 문제가 있다.

이 에러는 16.1 버전에서만 발생하며, 16.0 버전이나 17.1 버전에서는 발생하지 않는다. 이는 WLAN 모델 업데이트 과정(16.1 버전에서 802.11n 기능이 추가되었다.)에서의 버그라고 보여지며, 다음에 설명하는 방법으로 해결할 수 있다. wlan_mac 프로세스 모델을 열고 FB에서 wlan_physical_layer_data_arrival() 함수를 찾는다(16.1.A PL1 버전에서는
3758 라인에서 시작한다). 함수 시작 부준에 있는 수신된 프레임에서 PHY 정보를 읽어내는 코드(원래는 3804 ~ 3806 라인에 위치)를 찾아서, Jammer가 발생시킨 패킷이 아닌 경우에만 동작하도록 바로 위의 if 조건문 다음의 실행문 위치로 이동시킨다. 다시 wlan_mac 프로세스 모델을 컴파일하고, 시뮬레이션을 실행시키면 에러가 발생하지 않을 것이다.

조만간 출판 예정인 개정판에는 이 오류가 수정되어 있다.

"OPNET 기초다지기" 3.5절의 TCP 예제를 수행해보면 Slow start 구간에서 결과 그래프가 지수적으로 증가하지 않고 다음 그림처럼 선형적으로 증가하는 것을 볼 수 있다.

이렇게 논리적으로 예측된 결과와 OPNET 시뮬레이션 결과값 사이의 차이를 이해하는 것은 네트워크 시뮬레이션에 대한 감각을 익히는데 대단히 중요하다(비단 OPNET에만 한정되는 사항은 아니다). 논리적으로 예측한 결과값을 얻을 수 있도록 시뮬레이션 조건을 설정해주고, 다시 OPNET 시뮬레이션 결과값을 논리적 해석과 연결시키는 이러한 부분이야 말로 OPNET 사용에 있어서 가장 핵심적인 부분이라고 필자는 생각한다.

3.5절의 TCP 예제에서 CWND(Congestion Window)의 크기가 선형적인 증가폭을 보여주는 원인은 3가지인데, 1) 네트워크 환경 조건과, 2) TCP 파라메터 설정, 3) 결과 그래프 표시방법의 차이이다. 즉, 교재의 TCP 예제에서도 CWND 크기는 지수함수적인 방법으로 증가하고 있지만, 이 3가지 조건이 잘 맞지않은 관계로 예쁜 지수 함수로 보이지 못하고, 마치 직선인 것처럼 (찌그러져서) 보인 것이다.
다음 그림은 3.5절의 예제에서 몇 가지 설정사항만을 변경하여 다시 시뮬레이션한 결과이다. (빨간색 점과 녹색선은 이해를 돕기위하여 필자가 그려 넣어준 것이다) 동일한 소스 코드를 통한 시뮬레이션 결과이지만, 적합한 네트워크 환경 조건 및 TCP 파라메터 설정을 통해 CWND가 지수함수적 패턴으로 증가하는 현상을 잘 보여주고 있다.

여기에서 한 가지 주목해야할 사실은, 적절한 시뮬레이션 조건을 설정해준다 할지라도 시뮬레이션 결과 그래프는 논리적인 분석 그래프 모습과는 좀 다를 수 있다는 것이다. 위의 그림에서 녹색선은 (네트워크 서적에서 흔히 보여주는) 이론적인 예측 그래프이며, 빨간색 점은 (마지막 점을 제외하고) 이 녹색 그래프를 그리는데 사용된 CWND 값이다. 즉, 우리가 논리적인 예측을 할 때에는 모든 CWND 값을 사용한 것이 아니라, 일정 주기 간격으로 CWND 값을 샘플링하여 사용한 것이다. 더욱이, 엄밀하게 말해서 그 샘플링 간격이 일정하지도 않다. (위의 그림에서 빨간색 점의 x축(시간) 간격은 일정하지 않다. 뒤로 갈수록 길어진다.) 따라서, 기계적으로 CWND 값을 수집하는 경우(이는 실장비의 값을 측정하는 경우에도 마찬가지이다)에는 논리적인 분석처럼 예쁜 지수함수 그래프를 얻을 수 없다.

"OPNET 기초다지기" 3.5절의 TCP 예제를 수행할 때, 15.0 이상의 버전을 사용할 경우 New Reno에 관한 결과가 시뮬레이션 결과가 교재와 달리 다음 그림처럼 Fast Recovery가 동작하지 않는 것처럼 보여지는 문제가 있다. (15.0 이후부터 현재의 최신 버전인 17.1까지 15.0, 16.0, 16.1, 17.1 버전 모두 동일한 현상을 보이고 있으며, 이는 15.0 버전에서의 TCP 모델 업데이트 때문인 것으로 생각된다.)

이 문제를 피해가기 위해서는 TCP 모델을 약간 수정해야만 한다. tcp_conn_v3 프로세스 모델의 FB를 열고, tcp_ack_check() 함수 선언을 찾는다. tcp_ack_check() 함수에서 New Reno 방식일 경우 호출되는 tcp_cwnd_stat_update() 함수(17.1 PL1 버전에서는 704 라인에 위치한다)를 주석처리하고, 그 아래쪽에서 New Reno 방식에 대한 Congestion window 업데이트가 수행되었음을 의미하는 플래그 설정(17.1 PL1 버전에서는 708 라인에 위치한다)을 역시 주석 처리한다. 프로세스 모델을 다시 컴파일하여 변경된 내용이 시뮬레이션에 적용되도록 해준다. 수정 후에 시뮬레이션 결과를 다시 살펴보면, 다음 그림처럼 New Reno에서도 Fast Recovery가 잘 동작하는 것을 확인할 수 있다.

조만간 출판 예정인 개정판에는 이 오류가 수정되어 있다.