6.7. SBC Dimensioning and Performance Tuning

This section provides background information on typical traffic patterns, its performance implications, and performance tuning possibilites. This information can help to make a more educated estimate than provided in Section Capacity planning. However, certainity can only be achieved by measurement of the target ABC SBC configuration against actual traffic on the used hardware.

The reference hardware we used is Sun SunFire X4170 with the following configuration:

  • 2 x Intel Xeon X5570 @ 2.93GHz CPUs, each 4 cores with hyper-threading enabled
  • 2 x on-board Intel Gigabit ethernet adapter
  • 8 GB RAM

As an alternative, we measured on a Dell R410 with the following configuration:

  • 2 x 4-core Intel X5550 CPU 2.6GHz
  • 2 x Broadcom NetXtreme II BCM5716, 8 irqs/queues
  • 12 GB RAM

The alternative results are shown in parenthessis.

On the reference hardware, the maximum performance limits of the ABC SBC have been measured as follows:

  • 5000 parallel G.711 calls with media anchoring (3600)
  • down by factor of five when transcoding is used,
  • call rate of 480 calls per second, without media anchoring
  • registration rate of 9900 registrations per second.

Actual use-cases may have significantly different traffic characteristics and therefore the resulting performance may be driven by different limits. In this section we look at the most typical cases: a trunking case with and without transcoding and a residential deployment scenario. All the use-cases assume a single-pass SBC traversal for both SIP and RTP. In the next section, we also summarise the critical configuration aspects that need to be checked when tuning the system for the highest performance.

6.7.1. Trunking Use Case

This case is characterised by handling many calls, both signalling and media, from rather few sources. SIP traffic is not NATed and does not include REGISTER transactions. In this case, the most demanded functionality is media forwarding and the most significant bottleneck is the packet rate of the Ethernet card. Small packets as common with VoIP saturate Ethernet card nominal capacity much earlier than large HTTP packets would. A reasonable Ethernet card shall deliver at least 400 thousand packets per second in each TX and RX direction.

With such a packet rate, the following number of parallel calls can be achieved for the respective number of calls:

codec/packetisation number of calls
G.711/20ms 5,000 (3,600)
G.729 6,000 (4,680)

6.7.2. Trunking with Transcoding

Transcoding is typically deployed as an additional feature in the trunking case. However, as transcoding is computationally expensive the bottleneck shifts to CPU. The following numbers are achievable on the reference platform:

transcoding number of calls
G.711-to-G.729 1,000 (750)

6.7.3. Traffic Estimates for Residential VoIP

With residential VoIP, the deployment sees many challenges: the clients are connecting from unmanaged networks over NATs and variety of SIP client types causes interoperability issues. Addressing NAT traversal by enforcing media anchoring (see Section Media Anchoring (RTP Relay)) and frequent re-registration (Section Registration Handling Configuration Options) causes substantial increase in overhead. The ABC SBC keeps the heavy SIP traffic off the infrastructure behind it, however the bandwidth impact on the incoming side must be considered.

Without frequent re-registrations NAT address bindings would expire and SIP devices behind NATs would loose incoming traffic. While other more light-weight methods (STUN, CRLF) exist, re-registrations are safe in that they work with every SIP client and create traffic keeping any NAT bindings alive. The penalty is quite high resource consumption. The “background SIP traffic” is even higher in public SIP services than one could infer from baseline calculation based on re-registration period. Alone use of digest authentication doubles number of REGISTER transactions, many clients send additional traffic to check voicemail status (SUBSCRIBE), announce their online status (PUBLISH), and get over NATs on their own (OPTIONS). As a result, the number of SIP request roughly quadruples against base-line.

The following table summarized empirical impact of driving re-registration traffic to 180 seconds period for population of 1000 subscribers:

  Rate per second (incoming interface)
REGISTER requests (w and w/o digest) 20 pps
all requests 40 pps
all requests and answers 80 pps
bandwidth (TX and RX about 1:1) 380 kbps

This load is noticable both in terms of bandwidth and CPU impact.

The following table present impact of media-relay on bandwidth for 1000 subscribers in peak periods. The underlying asssumption is that in peak periods, there is one call for every ten active subscribers.

number of subscribers 1000
parallel calls (10:1) 100
G.711 bandwidth (RX and TX) 197*2*100= 39,400 kbps
SIP bandwidth (RX and TX) 380 kbps
Total bandwidth ~40 Mbps

6.7.4. Performance Tuning

The performance of the system can be increased by proper configuration of the hardware, operating system and the SBC. The following paragraphs list configuration suggestions that are known to bring the greatest performance benefits.

Hardware has expectedly profound impact on system performance. With networking applications, is network cards that shall receive particular attention. Our experience has been that Intel Ethernet cards are at least on part with cards of other vendors and often overperform them. Note that it is necessary that the kernel is using specific card drivers: performance of generic ethernet drivers is noticeably lower. Hints to hardware specific configuration option are provided in Sec. Hardware Specific Configurations.

Key card driver parameters that don’t come preconfigured with the ABC SBC are those specific to Ethernet interfaces. If available, tune the following parameters:

  • enable Receive Packet Steering
  • increase coalesce and ring buffer size
  • bond statically NIC RX queues to CPU cores

Furthermore, you shall also make sure that your ABC SBC configuration is not causing unnecessary load.  Configuration options that can considerably increase overhead are especially media relay and registration processing. Media relay shall be avoided if not needed. If an SBC connects networks that are  mutually routable, anchoring media may be entirely unnecessary. Also in many cases,  when signalling passes the SBC twice on the way in and out, you may need to pay attention to configure the media to pass the SBC only once. Registration processing is primarily driven by the NAT keep-alive interval. We recommend a period of 180 seconds. Shorter intervals will not dramatically improve NAT traversal and will cost performance degradation. Longer intervals could result in expired NAT bindings for NATs that expire too rapidly.