SDN for Ad Tech

SDN for Ad Tech

Software-Defined Network (SDN) dates back to the mid-1990s, around the time AT&T labs created a Java Virtual Machine (JVM)-based middleware platform that managed networks and network connected services. This was the genesis of soft-switching networks; software that reconfigured physical switches and dynamically loaded new services and made them available for consumption on the network.

Today’s SDN can be described in terms of communication agents that provide dynamic configuration to data paths, traffic routes, traffic processing and termination. The modern SDN architecture can be decomposed into three planes; applications, control and data.



Software-Defined Networking is an emerging architecture that is dynamic, manageable, cost-effective and adaptable; making it ideal for the high-bandwidth dynamic nature of today's applications. (ONF, n.d.)

The application plane is comprised of software that programmatically configures traffic requirements to the control plane. The control plane provides centralized abstraction to the data plane where data paths are configured. Data paths are logical network devices providing OSI layer 4 through 7 switching functionality. This allows systems to dynamically control the flow of traffic by transmitting control messages via a well-defined protocol or API.

So what does this have to do with advertising technology?

The programmatic revolution caused the ad tech industry to grow at a rate where network bandwidth and compute resources became a cost limiting factor in terms of scalability. The sheer volume of transactions available in the marketplace along with a somewhat standard protocol makes it easy for digital media companies to participate in the ecosystem. 

It has always been difficult for demand side platforms (DSPs) to compete for relevant traffic without making significant investments in hardware and data center build-outs. Media buying platforms try to solve the problem by having intelligent bidding systems that use algorithms to determine which traffic can be monetized. However, DSPs still have to invest in infrastructure to listen to as much traffic as possible in order to bid according to demand.

nToggle provides a solution for ad tech supply and demand platforms that maximizes the use of resources and infrastructure by providing full and transparent control over the bid requests that get routed to their infrastructure. At nToggle, we have modeled our platform using elements of SDN and high frequency trading systems architecture.

nRoute's control plane allows applications to configure the flow of traffic in terms of quality and volume. For each request, a router extracts elements out of each bid request, (OpenRTB-JSON or Google Protocol Buffers over HTTP) and populates a feature vector (FV). The FV is evaluated by the core routing engine using our proprietary algorithm and if any route is matched, the raw request is forwarded to the route with the highest weight, assuming that the rate limit is not exceeded. 

Applications that consume the control plane API configure their routers in real-time. If desired, the control plane can be dynamically configured based on the behavior of the application plane. In this mode, nRoute™ will look at response metadata, without inspecting the data payload, and will dynamically change the shape of the traffic that it routes. If nodes in the application plane are misbehaving, dynamic back pressure is applied. Routers are clustered, however they are never put behind a load balancer, as we use TCP ANYCAST and BGP directly from our core switching.

The nRoute platform possesses most of the architectural components found in a modern SDN. It is dynamic, adaptable and manageable. Taking a page out of high-frequency trading, the nRoute network infrastructure provides performance, scale as well economic benefits to ad tech enterprises. 

Look for future posts where we will dive into our network architecture as well as the technology stack.