Standards approach or Open Source?

Extracted from SDN / NFV in wireless networks.

[...] Over the last few years, wireless networks have started to adopt enterprise technologies and trends. One of these trends is the open source collaborative model, where, instead of creating a set of documents to standardize a technology and leave vendors to implement their interpretation, a collective of vendors, operators and independent developers create source code that can be augmented by all participants.

Originally started with the Linux operating system, the open source development model allows anyone to contribute, use, and modify source code that has been released by the community for free.

The idea is that a meritocratic model emerges, where feature development and overall technology direction are the result of the community’s interest. Developer and companies gain influence by contributing, in the form of source code, blueprints, documentation, code review and bug fixes.

This model has proven beneficial in many case for the creation of large software environments ranging from operating system (Linux), HTTP servers (Apache) or big data (Hadoop) that have been adapted by many vendors and operators for their benefit.

The model provides the capacity for the creation and adoption of new technologies without having necessarily a large in-house developer group in a cost effective manner.

On the other hand, many companies find that the best-effort collaborative environment is not necessarily the most efficient model when the group of contributors come from very different background and business verticals.

While generic server operating system, database technology or HTTP servers have progressed rapidly and efficiently from the open source model, it is mostly due to the fact that these are building block elements designed to do only a fairly limited set of things.

SDN and NFV are fairly early in their development for mobile networks but one can already see that the level of complexity and specificity of the mobile environment does not lend itself easily to the adoption of generic IT technology without heavy customization.

In 2016, open source has become a very trendy buzzword in wireless but the reality shows that the ecosystem is still trying to understand and harness the model for its purposes. Wireless network operators have been used to collaborating in fairly rigid and orthodox environments such as ETSI and 3GPP. These standardization bodies have been derided lately as slow and creating sets of documentations that were ineffective but they have been responsible for the roll out of 4 generations of wireless networks and the interoperability of billions of devices, in hundreds of networks with thousands of vendors.

Open source is seen by many as a means to accelerate technology invention with its rapid iteration process and its low documentation footprint. Additionally, it produces actual code, that is pre tested and integrated, leaving little space for ambiguity as to its intent or performance. It creates a very handy level playing field to start building new products and services.

The problem, though is that many operators and vendors still treat open source in wireless as they did the standards, expecting a handful of contributing companies to do the heavy lifting of the strategy, design and coding and placing change requests and reviews after the fact. This strategy is unlikely to succeed, though. The companies and developers involved in open source coding are in for their benefit. Of course they are glad to contribute to a greater ecosystem by creating a common denominator layer of functional capabilities, but they are busy in parallel augmenting the mainline code with their customization and enhancements to market their products and services.

One of the additional issues with open source in wireless for SDN and NFV is that there is actually very little that is designed specifically for wireless. SDN, OpenStack, VMWare, OpenFlow… are mostly defined for general IT and you are more likely to find an insurance a bank or a media company at OpenStack forums than a wireless operator. The consequence is that while network operators can benefit from implementation of SDN or OpenStack in their wireless networks, the technology has not been designed for telco grade applicability and the chance of it evolving this way are slim without a critical mass of wireless oriented contributors. Huawei, ALU, Ericsson are all very present in these forums and are indeed contributing greatly but I would not rely on them too heavily to introduce the features necessary to ensure vendor agnosticism...

The point here is that being only a customer of open source code is not going to result in the creation of any added value without actual development. Mobile network operators and vendors that are on the fence regarding open source movements need to understand that this is not a spectator sport and active involvement is necessary if they want to derive differentiation over time.

SDN / NFV part V: flexibility or performance?

Early on in my investigations of how SDN and NFV are being implemented in mobile networks, I have found that performance remains one of the largest stumbling blocks the industry has to overcome if we want to transition to next generations networks.

Specifically, many vendors recognize behind closed doors that a virtualized environment today has many performance challenges. It explains probably why so many of the PoCs feature chipset vendors as a participant. A silicon vendor as a main proponent of virtualization is logical, as the industry seeks to transition from purpose-built proprietary hardware to open COTS platforms. It does not fully explain though the heavy involvement of the chipset vendors in these PoCs. Surely, if the technology is interoperable and open, chipset vendor integration would not be necessary?

Linux limitations

Linux as an operating system has been developed originally for single core systems. As multi-core and multithreaded architectures made their appearance, the operating system has shown great limitations in managing particularly demanding data planes applications. When one looks at virtualized network function, one has to contend with the host OS and the guest OS. 
In both cases, a major loss of performance is observed at enter and exits of a VM and the OS. These software interrupt are necessary to pull the packets from the data plane to the application layer so that they can be processed. The cost of software interrupt for kernel Linux access ends up being prohibitive and create bottlenecks and race conditions as the traffic increases and more thread are involved. Specifically, every time the application needs to access the Linux kernel, it must pause the VM, save its context and stall the application to access the kernel. For instance, a base station can have over 100k software interrupt per second.

Intel DPDK and SR-IOV

Intel Data Plane Development Kit (DPDK) developed by 6Wind is used for I/O and packet forwarding functions. A “fast path” is created between the VM and the virtual network interface card (NIC) that improves the data path processing performance. This implementation allows to effectively bypass the guest hypervisor and to provide fast processing of packets between the VM and the host.

At the host level, Single Root I/O Virtualization (SR-IOV) is also used in conjunction with DPDK to provide NIC-to-VM connectivity, bypassing the Linux host and improving packet forwarding performance. The trade off there is that each VM on SR-IOV requires to be tied to a physical network card.

Performance or Flexibility?

The implementation of DPDK and SR-IOV has a cost. While performance for VNFs implementing both techniques show results close to physical appliance, the trade off is flexibility. In implementing these mechanisms, the VMs are effectively bound to the physical hardware resource they depend on. A perfect configuration and complete identical replication of every element, at the software and physical level is necessary for migration and scaling out. While Intel is working on a virtual DPDK integrated in the hypervisor, implementation of SDN / NFV in wireless networks for data plane hungry network functions will force vendors and networks in the short to medium term to choose between performance or flexibility.

More content available here.