네트워크 시뮬레이션 공방

이더넷 (더미) 허브는 연결된 포트로 들어오는 트래픽을 다른 포트들로 모두 복사/전달하는 기능을 수행하는 장비이다. 따라서, 실제 목적지가 아닌 포트들로도 트래픽이 같이 전달되므로, 측정되는 유통 트래픽 량이 실제로 전달되어야하는 트래픽 양보다 크다. Riverbed(OPNET) Modeler에서 제공하는 이더넷 허브 노드 모델 역시 이와 같은 특성을 그대로 보여주므로, 허브 노드가 포함된 시험망의 트래픽을 설정하고 결과를 해석할 때에는 조금 더 세심한 주의가 필요하다.
다음은 "허브 노드를 지나는 디맨드 트래픽의 경로"에서 사용한 예제망을 재활용한 것이다.

Client 노드에서 Server 노드로 향하는 플로우와 Client 노드에서 Server_2 노드로 향하는 플로우의 Traffic Mix 속성을 All Explicit로 변경하고 Client

노드로부터 R1, Hub, Server 노드로 전달되는 트래픽량을 비교해보면 다음 그림과 같다. Client 노드에서 R1 노드, Hub 노드에서 Server 노드, 허브 노드에서 Server_2 노드로 전달되는 트래픽 양이 모두 동일한데, 이는 Client 노드에서 발생하여 Server 노드와 Server_2 노드로 향하던 트래픽이 Hub 노드에서 분기되지 않고 양 링크로 모두 전달되었기 때문이다. 

트래픽 발생을 위해 Application Model을 사용하여도 허브 노드가 연결된 모드 링크로 트래픽을 복사/전송하는 특성은 동일하게 나타난다. 다음 그림은 허브 노드를 지나는 Application Model 트래픽 효과를 관찰하기 위하여 구성한 예제망이다. 디맨드 플로우를 삭제하고, 동등한 수준의 Application Model 트래픽(Custom)을 추가해주었다.

시뮬레이션을 수행한 후 Client 노드로부터 R1, Hub, Server 노드로 전달되는 트래픽량을 비교해보면 다음 그림과 같다. Application Model 트래픽을 사용하여도, Hub 노드에서 트래픽이 분기되지 않고 양 링크로 모두 전달되므로 Client 노드에서 R1 노드, Hub 노드에서 Server 노드, 허브 노드에서 Server_2 노드로 전달되는 트래픽 양이 모두 동일한 것을 확인할 수 있다.

디맨드 모델에 의한 백그라운드 트래픽 부하가 허브와 연결된 링크에서는 정상적으로 관찰되지 않는 제약점이 있다는 것은 "Background Traffic의 영향(9) Demand Model과 허브"에서 살펴보았다. 하지만, 이 경우에는 중간 경유 링크 구간에서만 트래픽이 관찰되지 않는 것이었으므로 상대적으로 오해가 소지가 적었다. 이번에는 허브에 단말들이 연결되어 있는 경우에 결과 해석상에 어떠한 주의점이 필요한지 살펴보기로 하자.
다음은 허브 노드를 지나는 트래픽 효과를 관찰하기 위하여 구성한 예제망이다. "Background Traffic의 영향(9) Demand Model과 허브"에서 사용한 예제망을 변경한 것으로, R4 노드를 삭제하고 Server 노드와 동일한 단말 노드를 추가하고 Hub 노드에 연결해주었다.

시뮬레이션을 수행한 후 Client 노드에서 Server 노드로 향하는 디맨드 트래픽의 라우팅 경로를 확인해보면 다음 그림과 같다. ("라우팅 경로 확인하기" 참조) 그런데, 라우팅 경로가 표시되기는 하지만, 일부 오류가 있는 것으로 표현되는 것을 알 수 있다. 또 표시된 라우팅 경로도 우리가 원한 Server 노드로뿐만 아니라 Server_2 노드로의 경로도 포함되어 있다.

이 시험망에서 라우팅 경로에 오류가 있는 것처럼 보이는 것은 연결된 모드 링크로 트래픽을 복사/전송하는 허브 노드의 특성때문이며, 트래픽이 백그라운드 모드이기 때문은 아니다. 즉, 디맨드 트래픽 모델을 이더넷 허브 노드가 포함된 시험망에 사용했을 때에는 디맨드 트래픽에 대한 정확한 라우팅 경로 확인이 어렵다.(실제 장비의 특성때문이므로, Riverbed Modeler(OPNET)의 버그라고 볼 수는 없을 것 같다.)

특정 소스와 목적지간에 백그라운드 트래픽을 ip_traffic_flow 디맨드 모델을 이용하여 간단히 모의하는 방법을 "Background Traffic의 영향(4) - Demand Model"에서 살펴보았으며, 이 때 "Traffic Mix" 속성을 All Background로 설정하면 시뮬레이션 수행시간을 크게 줄일 수 있음은 "Background Traffic의 영향(5) - Traffic Mix"에서 살펴보았다.
그런데, 네트워크 토폴로지 상에 허브가 포함되는 경우에는 드맨드 모델에 의한 트래픽 부하가 정상적으로 관찰되지 않으므로 주의하여야만 한다. 다음은 드맨드 모델에 의한 백그라운드 트래픽이 허브 모델을 지나갈때 관찰되는 트래픽을 확인하기 위하여 구성한 시험망을 나타낸 것이다. "RIP 라우팅 예제"에서 사용한 시험망을 변경한 것으로 R1 노드와 R4 노드 사이에 이더넷 허브 노드를 배치하고 이더넷 링크로 연결해 주었다.

시뮬레이션을 수행한 후 Traffic Mix 모드가 All Background 인 경우와 All Explcit인 경우에 대해서 Client 노드로부터 R1, Hub, R4, Server 노드로 전달되는 트래픽량을 비교해보면 다음 그림과 같다.

Traffic Mix 모드가 All Background인 경우에는 R1 노드에서 Hub 노드, Hub 노드에서 R4 노드 구간에서는 디맨드 플로우에 의한 트래픽이 전혀 관찰되지 않는다. 하지만, Client 노드로부터 R1 노드로 전달된 것과 동등한 양의 트래픽이 R4 노드에서 Server 노드로 전달되는 것이 확인되므로, 실제로는 트래픽이 R1 노드에서 사라진 것이 아니라 R1 -> Hub, Hub -> R4 링크에서 관찰되지만 않은 것임을 알 수 있다. (링크뿐만 아니라 Hub 노드에서도 관찰되지 않는다)
반면, Traffic Mix 모드가 All Explicit인 경우에는 모든 구간에서 디맨드 플로우에 의한 트래픽이 정상적으로 관찰된다.
따라서, 허브 노드가 포함된 시험망에서 디맨드 트래픽 모델을 사용할 때에는 트래픽 유통량 분석 과정에서 Traffix Mix 모드가 어떻게 설정되어 있는지에 대한 세심한 주의가 필요하다.

"분포함수(1) - 정규분포"에서 살펴보았듯이, OPNET에서 제공하는 분포함수는 이론적 정의와 일치하는 결과를 제공한다. 그런데, ip32_cloud 노드 모델의 Pakcet Latency 속성을 이용하여 네트워크 지터를 발생("네트워크 Jitter(1) - VoIP 실험을 위한 네트워크 Jitter 설정" 참조)시키고 측정해보면 상당한 차이가 나는 경우가 있다. 다음 그림은 normal(0.01, 0.005) 분포를 적용하였을 때 분포함수에서 발생한 결과값과 ip32_cloud 노드 모델을 통해 측정된 Packet Latency 결과값을 비교하여 나타낸 것인데, 두 결과값이 상당한 차이를 보여준다.

이러한 차이가 발생하는 원인은 선행 패킷의 전송지연시간이 후속 패킷의 Latency에 영향을 미치는 패킷 통신망의 특성때문이다. 이를 확인해보기 위해서 선행 패킷의 전송지연이 후속 패킷의 Latency에 영향을 미치지 않도록 코드를 수정하고 실험해본 결과는 다음 그림과 같다.
분포함수에서 발생한 결과값과 Packet Latency 결과값이 잘 일치하는 것을 확인할 수 있다.

특정 소스와 목적지간에 백그라운드 트래픽을 ip_traffic_flow 디맨드 모델을 이용하여 간단히 모의하는 방법은 "Background Traffic의 영향(4) - Demand Model"에서 살펴보았다. 특정 소스와 목적지간에 백그라운드 트래픽을 모의하는 또 다른 방법은 Application Model을 사용하는 것이다.
Application Model은 일반적으로 Explicit Traffic을 발생시키기 위해 사용된다. 그런데, voice와 video conferencing 모델은 Traffic Mix 속성을 제공하고 있으며, 이 속성값을 조정하면 Background Traffic을 발생시키는데 사용할 수 있다(Traffic Mix 속성의 사용법은 "Background Traffic의 영향(5) - Traffic Mix"에서 설명한 것과 동일하다). 다음 그림은 Video Conferencing Application Model의  Traffic Mix 속성을 보인 것이다.

다음 그림은 "Background Traffic의 영향(4) - Demand Model"에서 사용한 네트워크 토폴로지에 Video Conferencing Application Model을 적용하고, Explicit Traffic을 사용하였을 때와 Background Traffic을 사용하였을 때 링크에서 측정된 트래픽 발생량을 나타낸 것이다. Background Traffic을 사용하였을 때도 Explicit Traffic과 동일한 크기의 트래픽이 발생한 것을 확인할 수 있다.

그런데, Application Model의 Traffic Mix 속성을 사용하여 백그라운드 트래픽을 발생시킬 때 한가지 주의해야 할 점은 Background 방식으로 발생된 트래픽의 경우 노드에서는 관측되지 않는 다는 것이다.

앞에서 살펴본 것처럼 링크에서는 Application Model의 Traffic Mix 속성을 사용하여 Background Traffic으로 발생된 트래픽도 잘 정상적으로 관측되지만, 노드에서는 Background Traffic 분량만큼을 제외한 트래픽(즉 Explicit Traffic 분량)만이 관측된다. 다음 그림은 Application Model의 Traffic Mix 속성값이 All Explicit, 50%, All Background 일 때, 노드의 MAC단에서 측정된 트래픽 부하를 나타낸 것이다.

"Background Traffic의 영향(5) - Traffic Mix"에서 설명하였듯이, Explicit Traffic 방식을 사용하면 시뮬레이션 수행시간이 오래걸리지만 좀 더 정밀한 결과를 얻을 수 있고, Background Traffic 방식을 사용하면 시뮬레이션 수행시간을 크게 줄일 수 있지만, 정밀도는 조금 낮아진다.
그러면, 실제로 두 가지 방식을 적용하였을 때, 시뮬레이션 수행시간이 어느 정도 차이가 발생하는지 확인해 보자. "Background Traffic의 영향(5) - Traffix Mix"에서 사용한 두 시나리오를 동일한 PC(CPU: Intel Core2 Duo E8400 3.0GHz, RAM: 2GB, OS: Windows XP 32비트)에서 실행하였을 때, All Background 방식의 시나리오 에서는 18초가 소요되었으며 All Explicit 방식의 시나리오에서는 거의 10배인 2분 48초가 소요되었다. 이 시나리오들의 네트워크 토폴로지는 매우 작은 크기를 가지며 실험대상 시간(Duration)인 600초(10분)중 백그라운드 트래픽이 적용되는 구간은 100초에 불과 하다는 점을 고려하면, 이 차이는 대단히 큰 것이라고 볼 수 있다.
이제 시뮬레이션 결과에서는 어느 정도 차이가 발생하는지 확인해 보자. Calling_party 노드에서 측정된 MOS 값을 살펴보면 다음과 같다.

Explicit Traffic 방식의 시나리오에서는 평균값이 약 4.33600이며, 약 0.00002의 변동폭을 가진다. Background Traffic 방식의 시나리오에서는 평균값이 약 4.336035이며 약 0.000005의 변동폭을 가진다. 약간의 차이가 발생하기는 하지만, 매우 유사한 결과를 얻을 수 있다는 것을 확인할 수 있다.

물론, 이 차이가 측정하고자 하는 결과에 영향을 주지않는 수준의 작은 차이인가 아닌가는 시험 케이스에 따라서 실험자가 판단해야하는 문제이며, 항상 무시할 수 있는 수준이라고 장담할 수는 없다. 이 예제의 경우 Explicit Traffic을 사용했을 때와 Background Traffic을 사용했을 때의 결과값만을 비교하면 어느 정도 차이가 난다고 볼 수도 있지만, MOS 절대값의 범위가 1~5라는 점을 고려하면 소수점 5째자리에서의 차이는 무시할 수준이라고 볼 수 있다. (그런 점에서 이 예제는 Background Traffic 사용에 의한 정밀도 차이를 보여주기에 그리 좋은 예제는 아니다)

특정 소스와 목적지간에 백그라운드 트래픽을 ip_traffic_flow 디맨드 모델을 이용하여 간단히 모의하는 방법을 "Background Traffic의 영향(4) - Demand Model"에서 살펴본 바 있다. 이 때 "Traffic Mix" 속성을 All Background로 설정하였었는데, "Traffix Mix" 속성이 시뮬레이션 결과에 어떤 영향을 미치는지 살펴보겠다.
여기에서 백그라운드 트래픽이라는 표현에 대해서 약간의 혼란이 발생할 수 있으므로, 먼저 백그라운드 트래픽에 대한 정의를 짚어보고자 한다. OPNET 시뮬레이션에서 백그라운드 트래픽은 두가지 의미로 사용될 수 있는데, 하나는 주된 관찰 대상인가의 여부에 관한 것이고, 다른 하나는 트래픽을 만들어내는 방법에 관한 것이다.

1) 관찰 대상이 아니라는 의미의 백그라운드 트래픽: 특정 어플리케이션 트래픽의 품질이나 네트워크 장비의 동작 특성을 분석할때, 네트워크에 부가되어 있는 트래픽의 크기에 따라 결과가 달라질 수 있다. 이때, 관찰 대상이 되는 트래픽은 아니지만, 네트워크를 의도한 상태로 만들어주기 위해서 부가하는 트래픽을 의미한다. 이러한 의미로 사용되는 경우가 더 많으며, OPNET에 한정되는 표현은 아니다.

2) 트래픽 생성 방법으로서의 백그라운드 트래픽: OPNET에서만 사용되는 개념이다. OPNET에서 트래픽은 생성 방법에 따라 Explicit(or Discrete) Traffic과 Background Traffic으로 구분된다. Explicit Traffic은 개별 패킷을 직접 발생시켜 트래픽을 구성하는 것이고, Background Traffic은 개별 패킷 생성없이 링크 부하등의 계산에만 트래픽 특성을 반영시키는 것이다. Explicit Traffic 방식을 사용하면 좀 더 정밀한 결과를 얻을 수 있지만, 시뮬레이션 수행시간이 오래
걸린다. Background Traffic 방식을 사용하면 정밀도는 조금 낮아지지만, 시뮬레이션 수행시간을 크게 줄일 수 있다.

본 글은 관찰 대상이 아닌 트래픽(1번 의미)을 생성하는 구체적인 방법(2번 의미)에 관한 것이다. 따라서, 이글에서 지금부터 사용되는 백그라운드 트래픽(Background Traffic)은 2번의 의미로서 사용된 것이다.
"Traffic Mix" 속성은 사용자가 설정해준 트래픽 크기에서 실제로 개별 패킷 발생에 의한  Explicit Traffic의 비율이 얼마인가를 설정하는 것이다. 따라서, 0 (또는 All Background)이면 개별 패킷 생성이 전혀 없이 트래픽이 구성되고, 100 (또는 All Explicit)이면 전적으로 개별 패킷 생성에 의해서 트래픽이 구성된다. 사용자가 임의의 비율을 설정해주는 것도 가능하다.
이 때 유의하여야할 점 한가지는 Background Traffic을 발생시켰을 때와 Explicit Traffic을 발생시켰을 때, 네트워크에 부가되는 트래픽의 크기가 실제로는 조금 다르다는 것이다.
다음 그림은 "Background Traffic의 영향(4) - Demand Model"의 시나리오를 사용하여 Explicit Traffic을 발생시킨후, 그 결과를 Background Traffic인 경우와 비교한 결과이다.

Background Traffic을 사용한 경우보다 Explicit Traffic을 사용한 경우에 더 많은 트래픽이 발생한 것을 알 수 있다. 이러한 현상은 시뮬레이션 엔진이 각각의 트래픽을 취급하는 방법이 다르기 때문에 발행한 것이며, 원하는 트래픽을 정확한 크기로 발생시키기 위해서는 여러번의 시험을 통해 실제로 발생되는 트래픽 크기를 확인하는 것이 필요하다.

특정 링크에 걸리는 백그라운드 트래픽을 링크 모델의 "Traffic Load(bps)" 속성을 이용하여 손쉽게 모의하는 방법은 "Background Traffic의 영향"에서 살펴보았다. 이번에는 특정 소스와 목적지간에 백그라운드 트래픽을 ip_traffic_flow 디맨드 모델을 이용하여  간단히 모의하는 방법을 살펴보기로 하겠다.
사용할 예제망의 토폴로지는 다음과 같다. "Background Traffic의 영향"에서 사용한 것과 동일한 토폴로지에서 Called_party 노드와 Calling_1 노드간을 ip_traffic_flow 디맨드 모델로 연결한 것이다.

이 예제망에서 백그라운드 트래픽은 모든 링크에 흐르게 될 것이다. 설정할 트래픽 양은 GW_1 노드와 ISP_backbone 노드 사이의 링크(DS3) 용량 대비 30%, 50%, 70%이다. ip_traffic_flow의 "Traffic (bits/second)" 속성을 Edit 모드로 선택하여 300sec에서 400sec 사이에 트래픽이 발생하도록 설정해 주었다. 이때 트래픽의 크기는 %가 아닌 bps로 설정되어야 한다. 이 예제에서는 DS3급(44.736Mbps) 링크를 사용하였으므로, 30%, 50%, 70%에 맞추어 13,420,800bps, 22,368,000bps, 31,315,200bps를 설정해 주었다. 다음 그림은 이 과정을 보인 것이다. 이 때 "Traffic Mix" 속성이 All Background로 설정되어 있음을 확인하여야 한다. ("Traffix Mix" 속성의 사용법과 그 영향은 별도의 글에서 다룰 것이다.)

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

"네트워크 Jitter(1) - VoIP 실험을 위한 네트워크 Jitter 설정"에서 설명한 것처럼 ip32_cloud 노드 모델의 Packet Latency (secs) 속성을 이용하여 망 전체에서 발생하는 Jitter를 넣어주는 방법을 사용할 때, 고려할 수 있는 유용한 Jitter 분포 모델 중 한가지는 laplace 분포이다.
다음 그림은 평균 = 45ms, scale = 3.9ms의 laplace 분포로 발생된 latency의 PDF를 나타낸 것이다.

VoIP 시뮬레이션을 할 때 Jitter는 VoIP 서비스의 품질(ex: MOS)에 큰 영향을 미치는 중요한 요소이다. 대상 통신망 구조와 트래픽을 모두 모델링하여 시뮬레이션에 반영하고 시뮬레이션 과정에서 Jitter가 자연스럽게 발생하도록 하는 방법도 생각해볼 수 있겠지만, 이는 망 구조나 트래픽 정보 수집에 대한 어려움을 차치하고서라도 시뮬레이션 수행시간이 너무나도 오래 걸릴 수 있기 때문에 실제로 사용하기는 매우 곤란하다.
따라서, 많은 경우에 있어 (ip32_cloud 노드 모델의 Performance Metrics-->Packet Latency (secs) 속성같은) 강제적인 방법으로 망 전체에서 발생하는 Jitter를 넣어주는 방법을 사용하기도 한다.