네트워크 시뮬레이션 공방

Riverbed(OPNET) Modeler WLAN 모델에서 사용되는 MCS(Modulation & Conding Scheme)는 데이터 전송 속도에 따라서 달라진다. 즉, 사용자가 설정해준 데이터 전송 속도에 의해 MCS 레벨이 선택되며, 시뮬레이션 도중에 동적으로 변화하지는 않는다.
16.1 버전에서 사용되는 데이터 전송 속도별 MCS 레벨을 살펴보면 다음과 같다(17.5 PL5 버전까지는 동일하다). 변조(Modulation) 방식만 구분되며, 코딩률(Coding Rate)은 구분되지 않기 떄문에 MCS로 표현하기에는 조금 부족한 면이 있다.

데이터 전송 속도가 11Mbps일 때 변조방식은 CCK11임을 표에서 확인할 수 있다. "WiFi 모델에서의 통신 가능 거리"에서 분석할 당시까지의 OPNET 버전에서는 WiFi 모델의 "Data Rate (bps)"의 기본값이 11Mbps였으며, CCK11 변조방식에 대한 BER 커브를 분석에 사용한 것은 이 때문이었다.

Riverbed(OPNET) Modeler의 라이센스는 floating 형태로 설치하더라도 동일한 서브넷 상에 속한 단말에서만 사용할 수 있다.
단일 연구실이나 부서에서 사용할 경우에는 이러한 특성이 별 문제가 되지 않지만, 서브넷 주소가 다른 여러 부서에서 공동으로 사용하거나 여러 사업장을 가진 회사에서 사용할 경우에는 문제가 된다. 이러한 경우VPN 사용이 좋은 대책이 될 수 있다. VPN을 사용하면 서로 다른 서브넷에 속한 Riverbed(OPNET) Modeler 사용자들을 라이센스 서버와 동일 서브넷으로 만들어 줄 수 있기 때문이다.

Riverbed Modeler 18.7.0 버전이 지난 1월22일자로 발표되었습니다(이번 버전에 관한 내용은 "Riverbed Modeler18.6.1 발표" 참조). 공지가 없어서 배포된 줄도 몰랐네요. Riverbed사의 다른 제품군에 대한 업데이트 안내는 Modeler 사용자에게도 꼬박꼬박해주더니 정작 Modeler에 대한 업데이트 안내는 안해주네요. 상당히 당황스럽습니다.
Release notes를 통해 변경 사항을 살펴보았습니다. 모델 업데이트는 2가지입니다.

- Wireless LAN Model Enhancement
- Software-Defined Networking (SDN) Model Enhancement

WLAN 모델 개선 사항은 802.11ac Very High Throughput(VHT)에 대한 지원입니다. 세부적으로는 80MHz 대역폭 전송, 정적/동적 대역폭 선택 방법, 최대 8개의 spatial 스트림, 256-QAM 모듈레이션, VHT MPDU/PPDU 포맷, A-MSDU와 A-MPDU에 대한 보다 큰 최대 크기 적용, 11n과 11a 기술에 대한 하위호완성 등입니다.
SDN 모델 개선 사항은 Barrier Request/Response 메시지와 Role Request/Response 메시지 추가입니다.

이외에 버그 및 마이너한 개선사항 4건도 포함되었습니다만, 현재 관심이 가는 내용이 아니라서 생략합니다.

"다중경로 라우팅(4) - 동일 목적지 예제"와 "다중경로 라우팅(5) - 다수 목적지 예제"에서 살펴본 것처럼, 트래픽 로드 밸런싱 효과는 Packet-Based 방식이 더 좋다. 하지만, 실제 통신망에서 Packet-Based 방식은 거의 사용되는지 않는데, 그 주된 이유는 Packet Reordering으로 인한 부작용 때문이다.
다음 그림은 Packet-Based 방식의 로드 밸런싱에서 발생하는 Packet Reordering 현상을 확인하기 위하여, "다중경로 라우팅(1) - ECMP"에서 사용한 시나리오를 수정하여 작성한 시험망의 구조를 나타낸 것이다. R1 <-> R2 링크의 delay는 50ms, R1 <-> R3 링크의 delay는 40ms로 설정하였으며, TCP 트래픽을 발생시키기
위하여 FTP를 사용하여 20MBytes 크기의 파일이 Client 노드에서 Server 노드로 전송되도록 설정해주었다.

다음 그림은 Destination-Based와 Packet-Based 방식을 적용하였을 때, Server 노드에 수신된 IP 패킷의 종단간 지연을 비교한 것이다. Destination-Based 방식에서는 약 51ms로 일정한 종단간 지연을 가지지만, Packet-Based 방식에서는 약 46ms ~ 47ms로 유동적인 지연을 가진다. 이러한 차이가 발생하는 이유는 Destination-Based 방식에서는 하나의 링크(R1 -> R3)로 모든 트래픽이 전달되지만, Packet-Based 방식에서는 지연이 다른 두 개의 링크(R1 -> R2, R1 -> R3)로 트래픽이 전달되기 때문이다.

Packet-Based 방식을 사용했을 때 상대적으로 작은 종단간 지연을 가지므로 성능면에서 더 유리할 것으로 생각할 수도 있지만, 다중 경로로 인해 종단간 지연이 유동적이라는 것은 실제로는 심각한 문제를 야기한다. 다중 경로로 인해 종단간 지연이 유동적이게 되면, 송신된 패킷의 순서가 뒤바껴서 수신(Packet Reordering)되는 현상이 발생한다. 이는 TCP 재전송을 유발시키며, 전체적인 TCP 전송 성능을 크게 떨어뜨리게 된다. 다음 그림은 Destination-Based와 Packet-Based 방식을 적용하였을 때, TCP 계층에서의 트래픽 전달 성능을 비교한 것이다. Destination-Based 방식에서의 전송 속도는 약 5.1Mbps(= 630 Kbytes/sec)인데 비해, Packet-Based 방식에서의 전송속도는 약 1Mbps(=125Kbytes/sec)로 Destination-Based 방식에서의 20% 수준밖에 되지 않는다.

Packet-Based 방식에서의 이렇게 낮은 전송 속도는 TCP 재전송에 의한 것임은 다음 그림처럼 송신측(이 예제에서는 Client 노드)의 TCP 재전송 횟수를 통해 확인할 수 있다. Destination-Based 방식에서는 재전송이 발생하지 않으므로 해당 결과가 관찰되지 않는다.

다음 그림은 FTP 계층에서 파일 전달을 수행하는데 걸린 시간을 비교한 것이다. Destination-Based 방식에서는 약 52초가 걸린데 비해, Packet-Based 방식에서는 약 181초로 훨씬 많은 시간이 소요되었음을 알 수 있다.

Riverbed(OPNET) Modeler TCP 모델에서는 TCP 가속  기능을 제공하는데, 여기에는 TAO(TCP Accelerated Open)와 Piggyback FIN이 포함된다(WAN 가속에서도 TCP 가속이라는 표현을 사용하지만, 이것과는 완전히 다른 개념이다). 다음 그림은 Riverbed(OPNET) Modeler TCP 가속 속성 설정창을 보인 것이다.

각 속성항목의 용도는 다음과 같다.
- Accelerated Open : TAO 사용 여부를 지정. 기본값은 Disabled.
- Send FIN with Data : Piggyback FIN 사용 여부를 지정. 기본값은 Disabled.

Adaptive 모드 지터 버퍼는 고정 크기의 지터 버퍼를 사용하지 않고, 현재의 VoIP 패킷 간격에 맞추어 지터 버퍼의 크기를 계속 변경해가면서 사용하는 방식이다. Fixed 모드 지터 버퍼와의 비교를 위해서 동일한 시험망("VoIP 지터 버퍼(3) - Fixed 모드" 참조)에서 지터 버퍼 설정만 변경하여 Adaptive 모드 지터 버퍼의 효과를 확인해보았다.
음성 코덱은 G.711을 사용하였으며, 네트워크에서의 패킷 지연은 균등(uniform) 분포 함수를 사용하여 None(시나리오 1), 20ms(시나리오 2), 40ms(시나리오 3), 60ms(시나리오 4) 범위로 설정하였다.
Adaptive 모드 지터 버퍼의 파라미터는 "Minimum Value: Default", "Maximum Value: 80", "Sliding Mean Coefficient: 0.5", "Buffer Sizing Interval: 100"으로 설정하였다.

다음 그림은 각 시나리오별로 지터 버퍼 크기를 관찰한 결과이다. x축은 시간이며, y축은 측정된 지터 버퍼 크기이다. 지터 버퍼의 크기가 시간에 따라 계속 변하고 있으며, 네트워크에서의 패킷 지연 변화폭이 증가할수록(즉, 지터가 커질수록) 평균적인 지터 버퍼 크기 역시 증가하고 있는 것을 알 수 있다.

다음 그림은 각 시나리오별 MOS 값 결과를 나타낸 것이다. x축은 시간이며, y축은 측정된 MOS 값이다. 모든 시나리오에 대해서 동일한 지터 버퍼를 사용하고 있음에도 불구하고 Adaptive 모드 지터 버퍼 사용시에는 최악의 경우(시나리오 3, 4)에도 일정 수준의 MOS 값이 유지되는 것을 알 수 있다.

그런데, Fixed 모드 지터 버퍼의 결과("VoIP 지터 버퍼(3) - Fixed 모드" 참조)와 비교해보면, Adaptive 모드 지터 버퍼의 MOS 결과 값은 매우 낮다. 그 원인에 대해서는 이후에 별도의 글에서 다루도록 하겠다.

"OSPF 메시지(3) - Encapsulation"에서 살펴본 것처럼, OSPF Hello 메시지는 멀티캐스트 주소를 사용하여 전달된다. 하지만, 이 멀티캐스트 패킷들은 단일 홉내에서만 사용되며, 다음 홉으로는 전달되지 않는다.
시뮬레이션을 통해 이를 확인해보기로 하자. 다음 그림은 "OSPF 라우팅 예제"에서 사용한 시나리오를 수정한 시험망 구조인데, R1 노드에서 R2 노드로 보내는 Hello Interval을 1초로 수정한 것이다.

다음 그림은 수정된 시험망 시나리오에서의 R1 --> R2 링크 트래픽 유통량을 기존의 시험망 시나리오와 비교한 것이다. 약 10배 정도로 트래픽이 증가하였으며, 이는 Hello 메시지 발생량이 10배로 증가(Hello Interval이 10초에서 1초로 축소됨)한 것을 고려하면 타당한 결과인다.

이제 R2 --> R4 링크의 트래픽 유통량을 두 시나리오간에 비교해보면 다음 그림과 같다. 전반적인 트래픽 유통량은 두  시나리오간에 동일함을 알 수 있으며, 이는 R1 노드에서 R2 노드 로의 Hello 메시지 발생량 증가가 R2 노드에서 R4 노드로의 Hello 메시지 발생량에 영향을 미치지 않았음을 의미한다.

즉, Hello 메시지는 다중 홉 너머로 Flooding되지 않는다.

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

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

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

쿼드런트(Quadrant)는 GRP("GRP 개요" 참조)에서 가장 핵심적인 개념이며, 대상 노드의 위치 정보에 대한 측정 단위라고 볼 수 있다. 즉, 같은 쿼드런트에 속한 노드인지의 여부에 따라 저장하는 위치 정보의 의미가 달라진다.

1) 동일한 쿼드런트에 속한 노드 : 대상 노드의 좌표값을 위치 정보로 사용
2) 동일한 쿼드런트에 속하지 않은 노드 : 대상 노드가 속한 쿼드런트의 좌표값을 위치 정보로 사용

다음 그림은 이러한 개념을 그림으로 표현한 것이다. 1번 노드를 기준으로 살펴보았을 때, 2번 노드는 1번 노드와 동일한 쿼드런트 A에 속한 노드이므로 2번 노드의 직접 좌표값이 저장된다. 3번 노드와 4번 노드는 1번 노드와 달리 쿼드런트 B에 속한 노드이므로 3번 노드와 4번 노드의 직접 좌표값 대신 쿼드런트 B의 좌표값이 저장된다.

다만, 실제로는 쿼드런트가 계층적으로 존재하므로 좀 더 복잡한 양상을 보이게 된다. 쿼드런트의 계층적 개념에 대해서는 별도의 글에서 다시 살펴보도록 하겠다.

AODV에서는 이웃을 찾아내고 이웃과의 관계를 유지하기 위해서 Route Request(RREQ), Route Reply(RREP), Route Error(RERR), Route Reply Acknowledgment(RREP-ACK), Hello 메시지를 사용한다. 다음 그림은 Riverbed(OPNET) Modeler AODV 모델에서 사용하는 패킷 포맷과 Options 필드에 실리는 정보를 나타낸 것이다.

그림에서 알수 있듯이, 각 메시지 별로 다른 패킷을 사용하지 않고 하나의 공통 AODV 패킷 포맷을 사용한다. 대신 각 메시시별로 Options 필드에 실리는 구조체의 내용을 달리하여 서로 다른 메시지 정보를 수용한다.
AODV 패킷 포맷임에도 UDP 헤더 필드가 포함되어 있는 것은 "AODV 프로토콜 계층 구조"에서 설명하였듯이 AODV 메시지가 UDP를 사용함[1]에도 불구하고, AODV 프로세스 모델이 UDP 모듈 상위가 아닌 IP 모듈에 직접 구현되어 있기 때문이다.

[1] RFC 3561, "Ad hoc On-Demand Distance Vector (AODV) Routing", IETF, July 2003.