Site menu Master Dissertation

Master Dissertation

SCTP performance test - Multihomed server

Scenario: BIKER as server, COP as client. There is a straight 10mbps network between BIKER and COP, as well as another 11Mbps wireless network with ARP intermediate router.

In multihomed tests, primary link (10Mbps) traffic is allowed for 10 seconds, then blocked for another 10 seconds, and so on. Routing and firewall rules were used to enforce blocking and avoid asymetric routing.

Measured network latency was aprox. 0.18ms at 10Mbps network, and 1.87ms at 11Mbps wireless network.


Protocol10Mbps network11Mbps networkMultihomed

Throughput iin kbps (1kbps = 1000bps)


Protocol10Mbps network11Mbps networkMultihomed

Latency em µs


This is a functionality test instead of a performance test, because TCP has no multihoming support. So there is no point in comparisions. In multihomed tests, TCP simply uses the intermitent primary link, and its performance will be obviously bad. The results of "multihomed" TCP are marked with asterisks in table.

Two additional "advantages" were given to SCTP in this test.

The first advantage is the test start syncronized with activation of primary link. This was done because LK-SCTP API does not implement sctp_connectx() function yet, so the association must start via server primary IP; the alternative IPs are exchanged after association establishment.

The second advantage was tuning of path_max_retrans sysctl parameter, from 5 to 1. This reduces the SCTP react time to link state changes. The original value is appropriate for real networks, but the 10-second intermitence imposed in this test demanded more quickness.

In latency test, multihomed SCTP had almost the same result as TCPM. It happened because SCTP continued to use the secondary link for more 2 or 3 seconds after primary link restore, and secondary link network latency is a lot higher.