네트워크 시뮬레이션 공방

Riverbed(OPNET) Modeler TCP 모델은 시뮬레이션에서 사용된 TCP 연결들을 사용자가 확인할 수 있도록 화면상에 정보를 출력하는 기능을 제공한다. 이러한 기능은 실제 TCP 구현물에서는 제공되지 않는 것으로, 시뮬레이터이기에 가능한 부분이다. (굳이 비교 대상을 찾자면 Windows나 Linux에서 제공하는 netstat 명령어와 유사한 면이 있다.) 다음 그림은 사용자가 TCP 연결 정보 출력 여부를 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

"TCP Windows Scaling(1) - LFN에서의 동작"에서 사용한 시나리오를 사용하여 시뮬레이션을 수행한 후, 화면에 출력되는 TCP 연결 정보를 살펴보면 다음과 같다.

FTP 연결(포트 20번 사용)이 100.0초에 설정되어 시뮬레이션이 끝날때까지 사용된 것을 쉽게 확인할 수 있다.

TCP 영속(persistence) 타이머는 probe 세그먼트[1, 2]을 보내는 시간 간격을 조정하기 위하여 사용되며, Riverbed(OPNET) Modeler TCP 모델은 persistence 타이머 값을 지정할 수 있는 기능을 제공한다. 다음 그림은 사용자가 persistence 타이머 값을 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

이 속성에는 실수값을 입력할 수 있으며 기본값은 1.0, 즉 1초이다.

[1] RFC 793, "TRANSMISSION CONTROL PROTOCOL", IETF, Sep. 1981.
[2] RFC 1122, "Requirements for Internet Hots -- Communication Layers", IETF, Oct. 1989.

Riverbed(OPNET) Modeler TCP 모델은 재전송 수행시의 횟수를 제한하는 기준을 설정할 수 있는 기능을 제공한다. 다음 그림은 사용자가 TCP 재전송 횟수를 제한하는 방식과 기준값을 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

Retransmission Thresholds 속성 항목은 하위 속성 항목들의 조합이며, 선택 가능한 값은 Attempts Based, Time Based, Windows 2000, HP-UX 10.x/11.x이다. 이외에도 하위 속성 항목들을 직접 설정하는 것도 가능하다. 기본값은 17.1 버전까지는 "Attempts Based"이고, 17.5 버전부터는 직접 설정된 값(Attempts Based가 일부 수정됨)이다.
각 하위 속성항목의 용도는 다음과 같다.

- Mode : 재전송 횟수를 제한하는 기준 방법을 정의. 선택 가능한 값은 Attempts Based와 Time Based이다. Attempts Based는 재전송이 수행되는 횟수를 제한하는 방법이며, Time Based는 재전송이 수행되는 시간을 제한하는 방법이다. Windows NT는 Attempts Based 방법을 사용하고, Solaris는 Time Based 방법을 사용한다.
- Maximum Connect Attempts (attempts) : 연결 요청(SYN) 메시지 최대 전송 횟수.
- Maximum Data Attempts (attempts) : 데이터 세그먼트 최대 전송 횟수.
- Maximum Connect Interval (seconds) : 연결 요청(SYN) 메시지 전송 절차 최대 진행 시간.
- Maximum Data Interval (seconds) : 데이터 세그먼트 전송 절차 최대 진행 시간.

"TCP 재전송(5) - 연속된 Timeout"에서 살펴본 것처럼, 최대 재전송 횟수를 넘어서면 TCP 재전송은 더이상 수행되지 않는다.

[1] http://www.microsoft.com/korea/technet/network/tcpip2k.mspx
[2] http://www.speedguide.net/articles/windows-7-vista-2008-tweaks-2574

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

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

다음 그림은 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 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.

Nagle 알고리즘으로 인한 효과는 "TCP Nagle 알고리즘(2) - 예제"에서 살펴보았다. 그런데, "TCP Nagle 알고리즘(1) - 파라미터 설정"에서 설명하였듯이, OPNET TCP 모델에서 제공하는 "Nagle Algorithm" 속성값은 "Disabled"나 "Enabled" 외에 "Per-Send"로도 선택 가능하다. Per-Send 방식은 Optimized 버전이라고도 하며, Per-Segment 방식인 표준 Nagle 알고리즘을 개선한 것이다.
5,120bytes 크기의 데이터를 전송하는 경우, Per-Segment 방식과 Per-Send 방식의 동작을 예측해보면 다음과 같다.

이제 시뮬레이션을 통해 이 예측이 맞음을 확인해보도록 하자.
Per-Send 방식의 Nagle 알고리즘을 사용하였을 경우의 효과를 확인하기 위하여, "TCP Nagle 알고리즘(2) - 예제"에서 사용한 시나리오를 이용하여 5,120바이트 크기의 패킷을 1개 생성하도록 Task를 수정하고, 이 Task가 15초 간격으로 수행되도록 Profiles를 수정한다.
시뮬레이션을 수행한 후, Per-Segment 방식을 사용한 경우와 Per-Send 방식을 사용한 경우의 결과를 비교해보면, Server 노드에서 전송한 IP 패킷의 수는 동일한 것을 확인할 수 있다.

또한, 전송된 데이터의 양에는 차이가 없다. 다음 그림은 전송된 데이터 양이 동일함을 확인하기 위하여, Server 노드와 Discarder_2 노드간 링크에서 측정된 트래픽 양을 비교한 것이다.

전송한 패킷 수도 같고 데이터의 양도 같은데, Per-Send 방식에서는 무엇이 개선된 것일까? 그것은 TCP 레벨에서의 전달 지연(Delay)이다. Per-Send 방식에서는 전달해야할 하나의 데이터가 여러 세그먼트로 분할된 후 마지막 세그먼트가 MSS보다 작은 경우, Per-Segment 방식과는 달리 이전 세그먼트의 응답을 기다리지 않고 바로 전송하므로 전달 지연이 평균적으로 작다.
다음 그림은 이를 확인하기 위해서 Glaobal Statistics에서 측정한 TCP 데이터의 지연을 나타낸 것이다. Per-Send 방식(Optimized 버전)을 사용한 경우가 Per-Segment 방식(RFC 버전)을 사용한 경우보다 훨씬 낮은 평균 지연을 가지는 것을 확인할 수 있다.

512bytes 크기의 데이터가 30ms 간격으로 발생하며 TCP Ack를 응답받는데 걸리는 시간이 충분히 큰 경우, TCP Nagle 알고리즘을 사용하지 않은 경우와 사용한 경우의 동작을 예측해보면 다음과 같다.

이제 시뮬레이션을 통해 이 예측이 맞음을 확인해보도록 하자. 다음 그림은 TCP Nagle 알고리즘의 동작을 시험하기 위해서 "TCP Window Scaling(1) - LFN에서의 동작"에서 사용한 시나리오를 수정한 시험망 토폴로지를 나타낸 것이다. Server 노드와 STA 노드 사이의 RTT는 100ms가 되도록 설정한다.

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

시뮬레이션을 수행한 후, Nagle 알고리즘이 실제로 수행되었음은 다음 그림처럼 TCP 송신측(이 시나리오에서는 Server 노드)에서 측정된 "Send Delay (Nagle's) (sec)" 결과항목값을 관찰하여 확인할 수 있다. ("Nagle Algorithm" 속성값을 Disabled로 설정한 시나리오에서는 값이 기록되지 않는다)

"Send Delay (Nagle's) (sec)" 결과항목값은 Nagle 알고리즘의 수행여부를 확인하는데는 유용하지만, Nagle 알고리즘의 효과를 확인하기에는 충분하지 않다.
Nagle 알고리즘으로 인한 효과를 확인하기 위해서, Server 노드에서 전송한 IP 패킷의 수를 비교해보면 Nagle 알고리즘을 사용한 경우에 네트워크로 내보낸 패킷의 수가 다음 그림처럼 크게(이 시나리오에서는 약 1/3 수준으로) 감소하였음을 확인할 수 있다.

패킷의 수는 이처럼 크게 감소하지만 전송된 데이터의 양에는 차이가 없다. 다음 그림은 전송된 데이터 양이 동일함을 확인하기 위하여, STA 노드의 TCP 단에서 수신한 트래픽 양을 비교한 것이다.

동일한 양의 데이터를 훨씬 작은 수의 패킷으로 전달 할 수 있다면, Nagle 알고리즘을 사용하는 것이 항상 유리한 것일까? 그렇지는 않다. Nagle 알고리즘은 네트워크로 내보내는 패킷의 수를 줄이기 위해 작은 크기의 패킷 전송을 제한하므로, 지연(Delay) 측면에서는 불리하다. 다음 그림은 이를 확인하기 위해서 STA 노드에서 측정한 TCP 데이터의 지연을 나타낸 것이다. Nagle 알고리즘을 사용한 경우가 사용하지 않은 경우보다 큰(이 시나리오에서는 2배 이상) 지연을 가지는 것을 확인할 수 있다.

Nagle 알고리즘은 작은 크기의 패킷 전송을 제한하여 네트워크의 효율성을 높이기 위한 것으로, Riverbed(OPNET) Modeler TCP 모델 역시 Nagle 알고리즘을 지원한다. 다음 그림은 사용자가 Nagle 알고리즘 적용 여부를 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

이 속성에서 선택 가능한 값은 Disabled, Enabled, Per-Send 이다. Per-Send는 전송 절차가 호출된 시점에 응답(ACK)을 받지 못한 세그먼트가 존재하는 경우에만, MSS보다 작은 크기의 세크먼트 전송을 제한하는 방식이다. 기본값은 17.1 버전까지는 "Disabled", 17.5 버전에서는 "Enabled"이다.

Riverbed(OPNET) Modeler TCP 모델은 설정 가능한 최대 동시 연결 수를 사용자가 지정할 수 있도록 다음 그림처럼 Active Connection Threshold 속성을 제공한다.

TCP 연결 요청이 도착하였을 떄, 기존에 설정되어 있는 활성(active) TCP 연결의 수가 Active Connection Threshold 이상아면 해당 연결 설정 요청은 거절된다. 기본값은 Unlimited 이다.