네트워크 시뮬레이션 공방

Riverbed(OPNET) Modeler TCP 모델은 패킷 손실에 의한 재전송 수행시 Slow Start 기준값(ssthreshold)을 계산하는 방법을 선택할 수 있도록 "Segment Send Threshold" 속성을 제공한다.

이 속성에서 선택 가능한 값은 Byte Boundary와 MSS Boundary이다. 패킷 손실에 의한 재전송 수행시 ssthreshold 크기는 현재 네트워크를 통해 전송중인 데이터 크기(FlightSize)의 절반으로 줄어든다("OPNET 기초다지기" 참조). 이 때, Segment Send Threshold 속성이 Byte Boundary로 설정되어 있으면 ssthresh 크기는 단순히 전송중인 데이터 크기의 절반으로 줄어들고, MSS Boundary로 설정되어 있으면 가장 근접한 MSS("TCP MSS" 참조) 배수값에 맞춘다. 기본값은 MSS Boundary이다.

다음은 ECN 기능 적용시의 효과를 확인하기 위하여 "TCP 재전송(8) - Duplicate ACK"에서 사용한 시나리오를 수정한 시험망 토폴로지를 나타낸 것이다. 네트워크에서 혼잡상황 발생시 IP 패킷에 표시(마킹)를 해주기 위하여 Discarder_2 노드를 라우터 노드 모델로 대체하였다. 또, 이 라우터에 혼잡 상황을 발생시키기 위하여 디맨드 모델("Background Traffic의 영향(4) - Demand Model" 참조)을 이용하여 100초동안 2.5Mbps의 트래픽이 Server 노드에서 STA 노드로 전달되도록 하였다.

혼잡상황 발생시 라우터 버퍼에서의 패킷 손실을 구현하는 것이 목적이므로 디맨드 모델의 Taffic Mix는 "All Explicit"로 설정("Background Taffic의 영향(5) - Traffic Mix" 참조)하였다. 요즘 사용되는 대부분의 TCP 구현물들은 Fast Recovery를 사용하고 있으므로, Server 노드의 Fast Recovery 속성도 New Reno로 설정하였다.
ECN 기능을 사용하였을 경우와의 비교를 위하여, 먼저 ECN 기능을 사용하지 않았을 경우의 송신측(Server 노드) CWND 결과값과 Retransmission Count 결과값을 살펴보면 다음 그림과 같다. 라우터(R1 노드)에서 혼잡상황이 발생한 212초부터 재전송이 발생하고 CWND 값이 매우 작은 크기(주로 2,920 바이트)로 감소하는 겂을 볼 수 있다.

이제 ECN 기능을 사용하였을 경우의 송신측(Server 노드) CWND 결과값을 살펴보면 다음 그림과 같다. 혼잡 상황이 발생한 212초부터 CWND 값이 감소하기는 하였으나, 재전송은 발생하지 않았다(재전송이 발생하지 않으므로 Retransmission Count 결과 항목에 대한 그래프는 그려지지 않는다). 또 CWND 값도 ECN 기능을 사용하지 않아 재전송이 발생한 경우와 비교하면 매우 큰 수준(8,115 ~ 8,994바이트)이다.

Riverbed Modeler(OPNET) TCP 모델은 다음 그림처럼 사용자가 ECN(Explicit Congestion Notification)[1] 적용 여부를 설정할 수 있는 ECN Capability 속성을 제공한다.

이 속성에서 선택 가능한 값은 Enabled, Disabled, Passive이다. Passive로 설정되면 상대방(client)에서 ECN 사용을 먼저 요청하는 경우에만 ECN을 사용한다. 즉, Passive는 Server 노드에서만 의미가 있으며, Client 노드가 Passive로 설정되면 Disbled로 설정된 것과 동일하다. 기본값은 "Disabled"이다.

[1] RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP", IETF, Sep. 2001.

TCP SACK의 동작을 시험하기 위해서 "TCP 재전송(8) - Duplicate ACK"에서 사용한 시나리오를 수정하여 Discarder_2 노드에서 폐기되는 패킷수를 2로 변경하고, STA 노드와 Server 노드의 "Selective ACK (SACK)" 속성값을 다음 그림과 같이 Enabled로 변경한다.

시뮬레이션을 수행한 후, Server 노드에서 측정된 "Selectively ACKed Data (bytes)" 결과 항목을 살펴보면 다음 그림처럼 200초 무렵에 패킷 손실이 발생하였을 때 SACK에 의한 응답이 사용되었음을 확인할 수 있다.

"Selective ACK (SACK)" 속성값이 Disabled로 설정된 경우에는 SACK에 의한 응답이 사용되지 않으므로, 이 "Selectively ACKed Data (bytes)" 결고 항목에 아무런 값도 기록되지 않는다.

Riverbed Modeler(OPNET) TCP 모델은 다음 그림처럼 사용자가 Selective Acknowlegment(SACK) 적용 여부를 설정할 수 있는 속성을 제공한다.

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

Riverbed Modeler(OPNET) TCP 모델은 다음 그림처럼 사용자가 Slow Start에서 사용될 Congestion Window의 초기값을 설정할 수 있는 기능을 제공한다.

이 속성값은 MSS("TCP MSS" 참조)의 배수를 의미하며, 선택 가능한 값은 1, 2, 4, As defined in RFC-2414 이다. "As defined in RFC-2414"가 선택되면 RFC 2414[1]에 정의되어 있는 다음 수식에 따라 Congestion Window의 초기값을 계산한다.

initial window = min (4*MSS, max (2*MSS, 4380 bytes))  (1)

RFC 2414[1]는 RFC 3390[2]으로 대체되었지만, initial window 계산 공식에는 변화가 없다.

[1] RFC 2414, "Increasing TCP's Initial Window", IETF, Sep. 1998.
[2] RFC 3390, "Increasing TCP's Initial Window", IETF, Oct. 2002.

TCP의 Delayed ACK Mechanism이 Segment/Clock Based 방식이고 데이터가 계속 수신되고 있는 상태라면 ACK 메시지는 대부분 Segment 기반으로 (즉, Maximum ACK Segments에 도달하여) 발생되지만, Clock 기반으로 (즉, Maximum ACK Delay에 도달하여) 발생되는 경우도 있다.
실제로 "TCP Delayed ACK(2) - 예제"에서의 결과에서도 200.4초에 송신된 ACK는 Clock 기반으로 발생된 (즉, Maximum ACK Delay에 도달하여 수신 세그먼트 1개에 대한 응답만으로 구성된) 것이다. 단순하게 생각하면 Maximum ACK Delay 시간(200ms)보다 훨씬 짧은 간격(약 100ms)으로 데이터가 계속 수신되고 있으므로, 모든 ACK는 Maximum ACK Segments에 의해 발생되어야 할 것 같은데 왜 이런 현상이 발생한 것일까?
그 이유는 Delayed ACK을 위한 타임아웃 설정은 데이터 패킷 수신 시점을 기준으로 이루어지는 것이 아니라, Maximum ACK Delay 시간 단위(tick)로 이루어지기 때문이다. 따라서, 데이터 패킷을 계속 수신중이라 할지라도 마지막 ACK 송신후 수신된 데이터 패킷의 수가 Maximum ACK Segments에 도달하지 않은 상태(즉, ACK를 보내지 않은 데이터 패킷이 있는 상태)에서 Maximum ACK Delay에 의한 타임아웃 시각에 도달하는 경우가 발생할 수도 있는 것이다.

"TCP 재전송(8) - Duplicate ACK"의 시나리오에서 STA 노드에서 송신한 TCP Segment Ack Number와 수신된 TCP Segment Sequence Number를 관찰하면 수신 Segment 2개마다 1개의 Ack가 송신된 것을 볼 수 있는데, 이는 STA 노드의 Maximum ACK Segments 속성의 값이 2로 설정되어 있기 때문이다("TCP Delayed ACK(1) - 파라미터 설정" 참조). 이 시나리오에서는 Server 노드에서 STA 노드로 데이터가 계속 보내지고 있는 상태이기 때문에 Maximum ACK Delay (sec) 속성값에 의한 영향은 거의 관찰되지 않는다.

또한, 이 결과에서 확인할 수 있듯이 패킷 손실로 인하여 중복된 Ack Number를 송신할 때에는 Delayed ACK가 적용되지 않는다(200.07초에 표시된 Sent Segment Ack Number는 실제로는 동일한 값을 가지는 5개의 점이 중복하여 찍혀진 것이다).

Riverbed Modeler(OPNET) TCP 모델은 다음 그림처럼 사용자가 Delayed ACK를 설정할 수 있는 속성들을 제공한다.

- Delayed ACK Mechanism : Delayed ACK 발생 방식을 지정. Clock Based 방식과 Segment/Clock Based 방식이 선택 가능하다. 선택된 방식에 해당하는 기준을 넘어서면, 해당 방향으로 전송할 데이터가 없더라도 ACK 패킷을 전송한다. (해당 방향으로 전송할 데이터가 있으면 ACK는 piggyback 방식으로 전달된다) 즉, 데이터없이 전달되는 ACK이므로 dataless ACK라고도 한다.

- Maximum ACK Delay (sec) : ACK를 보내기 전에 기다리는 최대 지연 시간.

- Maximum ACK Segments : ACK를 보내기전에 기다리는 최대 수신 segment 수.

"TCP Window Advertisement(1) - 파라미터 설정"에서 살펴본 것처럼 "Receive Buffer Usage Threshold (of RCV BUFF)" 속성의 기본값은 0.0 이며, 항상 수신 버퍼 크기 전체가 수신 가능 윈도우 크기로 사용된다. "TCP Window Scaling(3) - 예제"의 시나리오에서 TCP Conneciton-->Remote Receive Window Size (bytes) 결과를 Server 노드에서 관찰하면 Receive Window가 항상 일정한 것은 이 때문이다.

이는 Window XP나 Window 7과 같은 현재의 일반적인 운영체계에서는 맞지 않다. 다음은 Wireshark를 이용하여 64,512바이트의 수신 버퍼를 사용하는 Windows XP 시스템에서 내보내는 Advertisement Window 값을 관찰한 것이다. 수신 버퍼 전체 크기가 항상 Advertisement Window 값으로 사용되지는 않는다는 것을 확인할 수 있다.

Advertisement Window 크기에 변화를 주기위해서 다음과 같이 STA 노드의 "Receive Buffer Usage Threshold (of RCV BUFF)" 속성값을 변경한다. (여기에서 0.1은 예를 들기 위해 임의의 값을 선택한 것이며, 대상 시스템에 따라 값이 달라질 수 있다.)

시뮬레이션을 수행한 후, Receive Buffer Usage Threshold가 0.0인 경우와 0.1인 경우에 대해 Server 노드에서 수신된 수신 가능 윈도우 크기를 살펴보면 다음과 같다. 수신 가능 윈도우 크기가 59,095 ~ 65,535바이트로 시간에 따라 변화하였음을 확인할 수 있다.