We all think that networking is changing, and most probably agree that 1) the cloud is the primary driver, and 2) SDN is the term we use to describe the new “connection architecture”. I think that the point-three here is that NFV is the cloud-platform architecture that will describe how the hosted network elements are deployed and managed. The big question is just how this is going to impact the end-game, what “networking” does really mean in the future.
Scott Shenker, who I’ve quoted before in blogs for his thought leadership in SDN, postulates that the network of the future may push all the traditional networking functions into software and out to the edge, leaving “the core” as a mechanism for pure transport. He also talks about the “middle-box” problem, meaning the issues created in the network by the multiplicity of devices that don’t switch or route but rather provide some other network service—things like load-balancers and firewalls. He cites statistics that say that middle-box devices are as common as routers in today’s networks. That’s at least not inconsistent with my survey results, which cite them as an operational issue as large as that of routers. So you could argue that Schenker’s vision of “SDN futures” is a combination of an NFV-like function-hosting of network capabilities relating to service and focused near the edge, and a highly commoditized but-pushing process that makes up the core.
The only problem I have with this is that the model is really not a model of networking but of the Internet, which is almost a virtual network in itself. The real networks we build today, as I’ve noted in prior blogs, are really metro enclaves in which the great majority of service needs are satisfied, linked by “core” networks to connect the small number of services that can’t live exclusively in a metro. And yes, you can argue that the metro in my model might have its own “core” and “edge”, and that Scott’s model would apply, there’s a difference in that metro distances mean that the economics of networking there don’t match those of the Internet, which spans the world. In particular, metro presents relatively low unit cost of transport and a low cost gradient over metro distances. That means that you can put stuff in more places—“close to the edge” is achieved by hosting something anywhere in the metro zone. NFV, then, could theoretically host virtual functions in a pretty wide range of places and achieve at least a pragmatic level of conformance to Scott’s model.
To figure out what the real economics are for this modified model of the future, though, you have to ask the question “What’s the functional flow among these smart service elements at Scott’s edge?” Service chaining, which both SDN and NFV guys talk about, is typically represented by a serial data path relationship across multiple functions, so you end up with something like NAT and DNS and DHCP and firewall and load-balancing strung out like beads. Clearly it would be less consumptive of network bandwidth if you had all these functions close to the edge because the connection string between them would span less network resources. However, if we wanted to minimize network resource consumption it would be even better to host them all in one place, in VMs on the same servers. And if we do that, why not make them all part of a common software load so the communications links between the functions aren’t ever moving out of the programming level?
If virtual functions are transliterated from current network software, they expect to have Ethernet or IP connectivity with each other and you see the “edge functions” as a software hosted VLAN-connected virtual community that probably looks to the user like a default gateway or carrier edge router. And you also see that if this is all done to connect the user to the VPN that provides enterprise services, for example, it really doesn’t change the connection economics if you put the services close to the user, or close to the VPN on-ramp. That’s particularly true in the metro where as I’ve noted bandwidth-cost-distance gradients are modest. The whole metro is the edge of Scott’s model.
For content services, it’s obviously true that having caching near the user is the best approach, but the determinant factor in content caching strategies isn’t the connection cost inside the metro, it’s the cost of storing the content. Because metro networks are more often aggregation networks than connection networks, there is at any point in the aggregation hierarchy a specific number of users downstream. Those users have a specific profile of what they’re likely to watch and there’s a specific chance of having many users served from a single content element cached there, because some elements are popular in that group. Go closer to the user to cache and you get closer to giving every user private content storage, which clearly isn’t going to work. So you have to adapt to the reality of the metro–again.
My point here is that the evolution of the network under the pressure of NFV and SDN isn’t something that we can deduce from structural analysis of the Internet model of networking. It’s a consequence of the cost/benefit of business and consumer services in the real world of the metro-enclave model of service fulfillment. We still have a lot of thinking to do on where SDN and NFV will take us, because we still haven’t addressed this basic reality of network evolution.