If their size exceeds the Maximum Transmission Unit (MTU) of a link, larger IP payloads may be fragmented (sliced and diced into smaller packets) as they traverse network infrastructure. While each device might apply its own fragmentation algorithm, the process is quite straightforward: The payload of a large packet is divided into multiple smaller packets, each with duplicate IP header information, but containing a unique subset (portion) of the original data. OK – so there is a little more to it than that. There are fragmentation offsets in the IP header that tell the receiver what part of the packet it is getting and a ‘more fragmentation’ flag that is set from 0 to 1 when more packets should be expected to completely recompile the original payload.

Now, SIP traffic is far from immune from fragmentation. While many might consider them small packets, all it takes is for a user agent client (UAC) distribution to offer a reasonable bunch of voice and video codecs and the increased SDP size can easily push an IP payload over the edge.

Although it is an algorithmic process, the act of packet fragmentation is not particularly a processor-intensive function. Once segmented, the packet fragments flow independently through any remaining network links. Indeed, with intermediate devices blissfully unaware of their inherent relationship, many will take completely different paths with their own bandwidth, latency and hop characteristics. With each hop being a switch/router of some description, these fragments will also be placed in diverse queues which are serviced at differing intervals. This inherent disorder results in a major problem, when it comes to reassembly, which is… well… disorder.

You see, the receiver has the tricky job of taking these seemingly miscellaneous packet fragments, deciphering them from other packets or packet fragments arriving simultaneously and piecing them back together – somewhat akin to a jigsaw puzzle – but without the aid of the picture on the lid of the box. Naturally, this process takes memory resources to store packet fragments, while waiting for their counterparts to arrive, then processing cycles to compile them. Obviously, the service ultimately consuming these packets benefits greatly from this procedure being completed as quickly as possible and without taking processing cycles away from the core application. If fragmented packets are not successfully reassembled in a timely manner, then a retransmission will be requested or initiated, thereby further compounding the reassembly issue.

While some session border controllers perform this function in the (or their equivalent of the) userland or user space, packet reassembly is really a low-level function and should be pushed as close to the underlying bare metal as possible - to the operating system kernel or kernel space.

When performed at the kernel-level, reassembly of fragmented IP packets can be achieved much faster more efficiently than higher-up the platform stack. System calls to and from a specialized kernel module are much faster than from the user space. Plus they can get direct access to memory and I/O resources – both critical in the reassembly process.