네트워크 시뮬레이션 공방

다중경로 라우팅시에 로드 밸런싱을 위해 Destination-Based 방식과 Packet-Based 방식중에서 하나를 선택할 수 있음을 "다중경로 라우팅(3) - 로드 밸런싱"에서 살펴보았다. 이 두 가지 방식이 실제로 어떤 차이점을 보여주는지 예제망을 통해 살펴보기로 하자. 먼저, 트래픽 플로우들의 목적지가 동일한 경우이다.
다음은 10개의 트래픽 플로우가 하나의 목적지 노드로 향하는 경우의 예제망 구조이다("다중경로 라우팅(1) - ECMP"의 예제망에서 확장). Client 노드에서 Server 노드로 향하는 트래픽 플로우는 10개가 겹쳐진 것이며,
100초마다 하나씩 트래픽을 발생시키도록 설정하였다(이는 트래픽 증가에 따른 로드 밸런싱 효과를 관찰하기 위해서이다).

로드 밸런싱이 Destination-Based 방식인 경우와 Packet-Based 방식인 경우에 Client 노드로부터 Server 노드로의 트래픽 전달 경로를 비교해보면 다음 그림과 같다. Destination-Based 방식인 경우 각 트래픽 플로우는 하나의 라우팅 경로를 통해서만 전달되며, 목적지가 같으므로 동일한 경로(이 예제에서는 R1 -> R2 -> R4)가 사용되는 것을 알 수 있다. Packet-Based 방식인 경우 각 트래픽 플로우는 다중 경로를 통해 분산되어 전달(R1 -> R3 -> R4와 R1 -> R2 -> R4)되는 것을 알 수 있다.

R1 -> R2 링크와 R1 -> R3 링크의 트래픽유통량을 비교해보면 다음 그림과 같다.

Destination-Based 방식인 경우 모든 트래픽이 같은 경로(이 예제에서는 R1 -> R3 링크)를 통해 전달된 반면, Packet-Based 방식인 경우 다중 경로(R1 -> R2, R1 -> R3 링크)로 트래픽이 균등하게 분산되었음을 확인할 수 있다. 즉, 동일 목적지에 대해서는 Destination-Based 방식은 로드 밸런싱 효과가 전혀 없으며, Packet-Based 방식만이 효과가 있다("다중경로 라우팅(3) - 로드 밸런싱" 참조).

Riverbed(OPNET) Modeler TCP 모델은 TCP 헤더에 사용되는 Sequence Number의 초기값을 지정할 수
있는 기능을 제공한다. 다음 그림은 사용자가 Sequence Number 초기값을 설정할 수 있도록 Riverbed
(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

이 속성에서 입력 가능한 값은 양의 정수 또는 "Auto Compute"이다. "Auto Compute"로 설정되면, 임의의 값이 선택되어 사용된다.

"OSPF 이웃 상태정보 확인"에서 살펴본 것처럼, OSPF는 이웃(Neighbor) 노드와 Adjacency 관계를 맺는다. 하지만, Broadcast 네트워크일 경우에는 이웃끼리도 모두 Adjacent가 되지는 않으며, DR 및 BDR과만 Adjacent가 된다. (즉, DR/BDR <--> DR other 및 DR <--> BDR 간에만 Adjacent가 관계(Full 상태)가 된다.)
"OSPF DR(1) - 라우터 상태"에서 사용한 예제를 통해 Riverbed(OPNET) Modeler OSPF Model에서도 동일한 관계가 형성됨을 확인해보도록 하자. 다음은 "OSPF DR(1) - 라우터 상태"에서 사용한 예제망의 구조이며, R1, R2, R3, R4 노드간은 Broadcast 방식인 Ethernet으로 연결되어 있다.

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

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

DR인 R4 노드 및 BDR인 R3 노드("OSPF DR(1) - 라우터 상태" 참조)와만 Adjacent 관계이며(Full 상태), DR other인 R2 노드와는 단지 이웃(Neighor) 관계에만 있음을 확인할 수 있다.
R1, R2, R3, R4 노드간의 관계 상태를 종합하면 다음 그림과 같다.

다중경로 라우팅을 통한 로드 밸런싱(부하 분산)을 Riverbed(OPNET) Modeler로도 시뮬레이션할 수 있음은 "다중경로 라우팅(1) - ECMP"에서 살펴보았다. 로드 밸런싱 방법은 Load Balancing Options 속성값을 설정하여 변경할 수 있으며, 선택 가능한 값은 다음과 같다.

- Destination-Based: Load Balancing Options의 기본값이며, 목적지 주소별로 경로를 배분하는 방법이다. Packet reordering 등 다중 경로 사용으로 인한 부작용이 없는 장점이 있지만, 로드 밸런싱 효과가 확실히 보장되지 않는 단점이 있다.

- Packet-Based: 패킷별로 경로를 배분하는 방법이다. 로드 밸런싱 효과가 확실하다는 장점이 있지만("다중경로 라우팅(1) - ECMP"에서 사용한 예제가 로드 밸런싱 효과를 쉽게 관찰하기 위하여 Packet-Based로 시험한 것이다), packet redordering 등의 부작용이 발생하는 단점이 있다.

지터 버퍼의 사용이 음성 품질 향상에 어느 정도 기여하는지를 시뮬레이션을 통해 확인해보도록 하자. 다음 그림은 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 값을 얻을 수 있는 것으로 예측되는 지터 버퍼 크기가 선택되어 사용된다.