네트워크 시뮬레이션 공방

지터 버퍼의 사용이 음성 품질 향상에 어느 정도 기여하는지를 시뮬레이션을 통해 확인해보도록 하자. 다음 그림은 Fixed 모드 지터 버퍼의 효과를 확인하기 위한 시험망 토폴로지이다.

음성 코덱은 G.711을 사용하였으며, 균등(uniform) 분포 함수를 사용하여 None(시나리오 1), 20m(시나리오 2), 40ms(시나리오 3), 60ms(시나리오 4) 범위로 네트워크 지연이 발생("네트워크 Jitter(1) - VoIP 실험을 위한 네트워크 Jitter 설정" 참조)하도록 하였다. (지터 발생을 위한 네트워크 패킷 지연 모델로 uniform 분포가 현실적인가의 문제는 여기에서 논하지 않겠다. 보다 현실적인 모델로는 Laplace 분포 등이 고려될 수 있겠지만("네트워크 Jitter(3) - Laplace 모델" 참조), 해석의 편의를 위해서 여기에서는 uniform 분포를 사용하였다.)
다음 그림은 시뮬레이션 결과를 나타낸 것이다. x축은 지터 버퍼의 크기이며, y축은 측정된 MOS 값이다.

지터가 없는 경우(시나리오 1)에는 지터 버퍼의 크기가 작을수록 높은 MOS 값을 보여준다. 하지만, 지터가 발생하는 경우(시나리오 2, 3, 4)에 지터 버퍼의 크기가 작으면 MOS는 급격히 저하되지만, 충분한 크기의 지터 버퍼가 있으면(시나리오 2: 40ms 이상, 시나리오 3: 50ms 이상, 시나리오 4: 70ms 이상) MOS가 크게 개선됨을 알 수 있다.
Fixe 모드 지터 버퍼의 단점은 지터 범위를 정확히 예측할 수 없거나 가변적인 경우, 적합한 지터 버퍼 크기를 결정하기 어렵다는 것이다. 지터 버퍼의 크기를 너무 크게 설정해주면 평균 지연 시간의 증가로 인해서 MOS를 저하시키며, 반대로 지터 버퍼의 크기를 너무 작게 설정해주면 지터를 완전히 제거하지 못함으로 인해서 MOS를 저하시킨다. 그런데, 위의 결과에서 볼 수 있듯이 해당 네트워크의 특성(지터 크기)에 따라 최적의 지터 버퍼 크기는 서로 다르다. 따라서, 해당 네트워크의 지터 특성을 정확히 모르거나 가변적인 경우, Fixed 모드 지터 버퍼 크기의 최적값을 경정하는데 어려움이 따른다.

"서브넷 경계를 넘어서는 WLAN 노드간의 통신(1) - BSS ID"에서 살펴본 것처럼, 서로 다른 서브넷에 배치되어 있는 WLAN 노드들간에도 서브넷 경계를 넘어서 통신이 가능하다. 단, 이 때 Simulation Attributes의 WLAN Transmission Candidacy 항목이 다음 그림처럼 "Objects Across Entire Network"로 설정되어 있어야만 한다.
만약 이 항목이 "Objects in Same Subnet"으로 설정되어 있으면, BSS ID를 수동으로 맞추어 주더라도 서로 다른 서브넷에 배치되어 있는 WLAN 노드들간에는 통신이 이루어지지 않는다. 기본값은 "Object Across Entire Network"이므로, 사용자가 별도로 변경한 경우가 아니라면 특별히 신경쓸 필요는 없다.

다음 그림은 TCP 타임스탬프 기능 동작을 시험하기 위해서 "TCP ECN Capability(2) - 예제"에서 사용한 시나리오를 수정한 시험망 토폴로지를 나타낸 것이다. Router_1 노드에서 STA 노드로의 최대 전송률은 128Kbps로 설정한다.

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

시뮬레이션을 수행한 후, 타임스탬프에 의한 RTT 측정이 이루어졌을 떄의 효과는 다음 그림처럼 TCP 송신측(이 시나레오에서는 Server 노드)에서 측정된 "Segment Round Trip Time (sec)" 결과항목 값을 비교하여 확인할 수 있다.

타임스탬프를 사용하지 않으면 RTT 측정은 RTT에 해당하는 시간간격마다 한번씩만 이루어지므로 RTT가 큰 경우에는 SRTT가 실제 RTT 값에 수렴하기까지는 상당한 시간이 걸리며(측정된 RTT로부터 SRTT가 계산 되는 과정은 "TCP 재전송(2) - Timeout이 발생하지 않았을 때의 RTO 계산" 참조), 측정 결과값도 정확하지 않다. 이는 또한 실제 네트워크 상황에 맞는 RTO 값에 수렴하기까지에도 상당한 시간이 걸린다는 것을 의미한다.
반면, 타임스탬프를 사용하면 RTT 측정은 TCP ACK 패킷을 수신할 때마다 한번씩 이루어지므로 RTT가 큰 경우에도 SRTT가 실제 RTT 값에 수렴하는데에 오랜 시간이 걸리지 않는다.

Riverbed(OPNET) Modeler OSPF 모델은 다음 그림처럼 인터페이스별로 Router Priority를 설정할 수 있는 기능을 제공한다.

이 Router Priority 값은 DR/BDR 선출시 사용되며, 가장 큰 Router Priority 값을 가지는 노드가 DR로 선출된다[1]. "OSPF DR(1) - 라우터 상태"의 예제에서 R4 노드가 DR로 선출된 것은 (사용자의 설정이 없어서) 모든 노드의 Router Priority가 모두 동일하였기 때문에, 그 다음 비교값인 Router ID(즉, IP 주소)가 가장 큰 노드로 선정되었기 때문이다.

이제, Router Priority 값을 변경하여 특정 노드가 DR로 선출되도록 해보자. "OSPF DR(1) - 라우터 상태"의 예제를 활용하여 Hub 노드와 연결된 R1 노드 인터페이스의 Router Priority 값을 2로 수정한다. R2, R3, R4 노드는 여전히 기본값인 1의 Router Priority를 가질 것이므로, 더 높은 Router Priority를 가진 노드 1이 DR로 선출될 것이다.
다음 그림은 수정된 예제에서 R1, R2, R3, R4 노드에 구성된 OSPF 인터페이스 정보를 ODB를 통해 살펴본 것이다.

예상한 것처럼 192.0.1.x 네트워크에 대하여 R1 노드가 DR로 동작하고 있음을 확인할 수 있다.

[1] RFC 2328, "OSPF Version 2", IETF, April 1998.

ECMP가 사용되면 다중 경로를 통해 트래픽이 분산됨은 "다중경로 라우팅(1) - ECMP"에서 트래픽 유통량을 통해 살펴보았다. 여기에서는 이러한 경우에 라우팅 테이블이 어떻게 구성되는지를 확인해 보도록 하자. 사용된 예제의 네트워크 토폴로지와 실제로 할당된 IP주소 내역은 다음과 같다.

ECMP가 사용되지 않은 경우에, R1 노드에 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다("라우팅 경로 확인하기" 참조). Server 노드가 속한 서브네트워크로 향하는 경로가 하나 뿐인 것을 알 수 있다.

ECMP가 사용되는 경우에, R1 노드에 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다. Server 노드가 속한 서브네트워크로 향하는 경로가 두 개인 것을 알 수 있다.

지터 버퍼에서의 지연은 다음 수식처럼 지터 버퍼의 크기(패킷 수)와 패킷들의 간격(시간)의 곱으로 계산된다.

지터 버퍼 지연 = 지터 버퍼 크기(패킷 수) * 패킷 간격(평균 시간)    (1)

Fixed 모드일 경우, 지터 버퍼 지연 계산 결과값은 지터 버퍼 속성의 Nominal Value 값과 동일하다. Adaptive 모드일 경우, 예상 지터 버퍼 지연과 예상 지터에 의한 패킷 손실을 모두 고려하였을 때 최상의 MOS 값을 얻을 수 있는 것으로 예측되는 지터 버퍼 크기가 선택되어 사용된다.

Riverbed(OPNET) Modeler WLAN 모델은 같은 서브넷 내에 있는 노드간에만 통신이 가능하다고 안내되어 있다. 하지만, 이는 정확하지 않은 것이며, 실제로는 WLAN 노드들간에 서브넷 경계를 넘어서(Ex: 서브넷 안에 위치한 AP 노드와 서브넷 밖에 위치한 STA 노드간) 통신이 가능하다. 단, 동일한 서브넷 내에 배치되어 있지 않은 WLAN 노드들간에는 BSS ID에 대한 Auto Assign 기능을 이용할 수 없으므로 사용자가 직접 BSS ID를 설정해 주어야만 한다(약간의 편법을 사용하면 이 경우에도 Auto Assign 기능을 적용할 수 있기는 하나 권장할만한 수준은 아니다).

다음은 통신을 원하는 WLAN 노드들이 서브넷 경계를 넘어서 배치되는 2가지 경우에 대한 예이다.

1) AP 노드는 서브넷 내부에, STA 노드는 서브넷 외부에 배치

AP 노드는 Subnet1 서브넷 내부에 배치되어 있으며, STA 노드에서 발생시킨 트래픽의 목적지가 되는 Server
노드와 AP 노드는 Ethernet 링크로 연결되어 있다. STA 노드는 서브넷 외부에 배치되어 있으며 Server 노드를 향해 트래픽(1024bytes 패킷을 0.1sec 간격으로 UDP를 통해 전송)을 발생시킨다. 시뮬레이션 결과를 살펴보면 다음 그림처럼 STA 노드에서 발생된 트래픽이 Subnet1의 AP 노드로 잘 전달되고 있음을 확인할 수 있다.

2) AP 노드와 STA 노드가 각각 서로 다른 서브넷에 위치

AP 노드는 Subnet1 서브넷에 배치되어 있으며, STA 노드에서 발생시킨 트래픽의 목적지가 되는 Server 노드와 AP 노드는 Ethernet 링크로 연결되어 있다. STA 노드는 Subnet2 서브넷에 배치되어 있으며 Server 노드를 향해 트래픽을 발생시킨다. 시뮬레이션 결과를 살펴보면 다음 그림처럼 Subnet2의 STA 노드에서 발생된 트래픽이 Subnet1의 AP 노드로 잘 전달되어 있음을 확인할 수 있다.

Riverbed(OPNET) Modeler TCP 모델에서는 Timestamps Option[1] 기능을 제공한다. 다음 그림은 Riverbed
(OPNET) Modeler의 Timestamp 속성 설정창을 보인 것이다.

각 속성항목의 용도는 다음과 같다.

- Status : 타임스탬프 기능 사용 여부를 설정. 선택 가능한 값은 Enabled, Disabled, Passive이다. Passive로 설정되면 상대방(client)에서 타임스탬프 사용을 먼저 요청하는 경우에만 타임스탬프를 사용한다. 즉 Passive는 Server 노드에서만 의미가 있으며, Client 노드가 Passive로 설정되면 Disabled로 설정된 것과 동일하다. 기본값은 17.1 버전까지는 "Disabled", 17.5 버전에서는 "Passive"이다.

- Clock Tick (millisec) : 타임스탬프 값의 증가 단위. 기본값은 500ms.

[1] RFC 1323, "TCP Extensions for High Performance," IETF, 1992.

지난 주(2016년 4월 28일)에 Riverbed Modeler 18.5.1 버전이 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.5.0 발표" 참조). Release note에는 4월 18일로 표기되어 있습니다만, 실제로 배포된 것은 4월 28일입니다.
Release note에 따르면 기능상에 주요 변화는 없으며, 문제점 수정 3건이 전부입니다. (Riverbed Modeler로 바뀌더니, 업데이트가 부실해진 건 사실인 것 같습니다.) 다만, 이 수정 사항 중 한건은 사용자 편의에 매우 큰 영향을 주는 부분인데, Attributes 편집창이 열릴 때 기본적으로는 "Advanced" 모드로 열리지 않도록 변경되었다고 합니다. 이 "Avdanced" 모드로 열리는 부분 때문에 그동안 상당히 불편했었는데, 이제서야 수정을 해주는군요. (사실은 원복입니다.)

Broadcast 네트워크나 NBMA 네트워크에서 OSPF는 DR(Designated Router)를 사용한다[1]. 다음은 Riverbed(OPNET) Modeler OSPF Model에서 DR이 사용되고 있음을 확인하기 위한 시험망의 구조이다. "OSPF 라우팅 예제"에서 사용한 시나리오를 수정한 것으로, R1, R2, R3, R4 노드간을 Broadcast 방식인 Ethernet으로 연결하였다.

시뮬레이션 수행시 실제로 할당된 IP주소 내역은 다음과 같다.

이 때, R1, R2, R3, R4 노드에 구성된 OSPF 인터페이스 정보를 ODB를 통해 살펴보면 다음과 같다.

192.0.1.x 네트워크에 대하여 R4 노드가 DR로, R3 노드가 BDR(Backup DR)로 동작하고 있음을 확인할 수 있다. 이 정보는 [2]에서 제시한 양식을 따른 것이다.

[1] RFC 2328, "OSPF Version 2", IETF, April 1998.
[2] RFC 1247, "OSPF Version 2", IETF, July 1991.