L3 to Server

There is a trend towards moving switching (L2) out of the hypervisor and onto a NIC. After multiple false starts, it looks like it might actually happen.

Overlay networks essentially empower a virtual management tool or orchestrator to perform the control functions of a L2 network. The tool knows the full lifecycle of a VM and does not really need to learn any mac addresses. Coupled with a intelligent NIC and some standard based overlay (MacInIP), this tool can remove the need for a L2 switch in Hypervisor and facilitate bring L3 network directly to a server. If this happens, it will shift the network edge inside a server and shift the market power away from pure networkers to server vendors.

NfV Packet Processing

One of the key pillars on which the vision of NfV rests is optimized (meaning fast) cpu based packet processing. Sometime referred to as datapath processing in the cpu-mem complex without the need for any asic acceleration. No requiring any asic in the data path makes the cpu fungible (changed at will) and dramatically brings down the cost of network functions.

As we look at optimizations, we may also want to looks at why we have the ethernet I and II packet types and why the MTU min/max/jumbo packet sizes were arrived at. Do we really need the ethernet packet when the conversation is between two virtual machines on the same node?  Even across the host boundaries, but within the same data center, it is possible to have a conversation without having to create ethernet frames.

Hopefully we won't take existing VNFs and simply make OVFs out of them and run on a favorite hypervisor. Real NfV would involve refactoring the VNFs to use packet gateways for certain function and use standard RPC/IPC mechanisms for others.

Hypervisor based Overlays or Web Server based Overlays?

There  is a characterization of overlays as an abstraction as defined in computer science. An abstraction can be compiled down to the physical sometimes using an intermediate format. (like objects to byte code). Overlays are not abstraction, they are mark-ups and create a new layer for processing.  Mark-up are hints to higher layer software on how to process the content. There are services that these overlays need from the underlay and the exchange points are implemented in gateways.

Lot of complexity is being built into overlay networking because the design center of overlay networking is the hypervisor. By making hypervisor as a key node in the federated controller architecture, we are leaving out alternate mechanisms that enforce tenant/workload isolation like lpars/containers etc.  which don't need or require hypervisors.

Packets, Flows and Messages

I came across this post while doing the daily reading on SDN  https://devcentral.f5.com/articles/the-bifurcation-of-the-network-flows-versus-messages#.UjDVZ7Hn_mE. This resulted in a flashback as I recall sometime in 2004/5 time frame I was trying to explain to folks that message based switches are the way to go for then emerging service oriented network.

I would articulate the messages vs. tuple (flows) vs. header (packet) a little differently. In a service oriented network (and it is not SDN), the brain or intelligence bubbles up into a overlay network of proxies. Those proxies communicate among each other using messages. The brawn sinks down into a dumb data plane. The mapping between the two is done by "binding" to a transport. In those days HTTP was the transport but it was very apparent that it could not serve the purpose due to lack of asynchronous MEP (exchange). Today we are closer to realizing that vision.

Alas.. but we got hit on the head with murphy's law. In came SDN trying to disrupt the data plane by creating a centralized control plane. Except the control plane is not as intelligent as a the control plane of the original SON concept. It still works on packets. Fortunately, the byproduct of SDN hype is the real fruit of all this labor. That by product is programmability of the network device (not the network just the device). Today a message processor can read a route sent over the overlay of proxies and program the control plane on the switch to change the flow direction. This was not available in 2004/5. This was the original network virtualization concept. Virtualization because in the message processor you can have multiple tenants (although in those days we called it applications) and each one sees a different topology for its packets.

Big learning from that experience ... it hurts more to be early more than to be late.

Using Options Exchange to Price Cloud Computing

Traditional business decision tools like ROI, NPV do not sufficiently capture the risk in an investment decision on cloud computing. The demand for cloud services is not a sales forecast (linear) but more like a stock price (stochastic). Today this demand is met with a service that prices itself using an ancient cost accounting method, resulting in pricing models like pay-as-you-go or all-you-can-eat. The price does not take any market input. Imagine buying the stock of a company for a constant price regardless of the volume.

An option is an instrument that give you the right to buy the underlying security but does not obligate a purchase. Trading this instrument with underlying compute capacity as the security will help researchers and businesses study the demand for the cloud computing. Knowing the real demand and the market price for this emerging commodity will help guide investments for service providers and businesses. In the absence of this, we are going down the monopolistic pricing path that we are seeing right now. Except in the case of cloud computing, there is no government backstop for this monopoly.

SDN: Technology and Business Model

If SDN is an architecture, then what is the technology? Clearly it is not virtualization, in fact, most SDN architecture are not yet virtualized. It is not a protocol. The whole point of giving software the control is not to be constrained by a protocol. It is the API. API is what makes SDN possible. APIs like a network stack is not monolithic. There is the free API i.e .REST and there is the premium API which may or may not be proprietary - but will always be Open. APIs come with their own infrastructure and scaling that infrastructure is the challenge of SDN.

Moving on to business model of SDN. It is not in selling controllers. There are too many of them. It is not in scripting, integrating and scaling them in a cloud infrastructure like say OpenStack. Those are what is normally called out as NRE in the ROI spreadsheet. The business model of SDN is in hosting the cloud. SDN lowers the barrier to entry to enter the business of hosting.

So if you want to make money off SDN, get into hosting. If you want to work on SDN, get into APIs.

Internet of Things

There isn't just one web. There are many webs, the one we call web is the information web that can be browsed. There is a web being built that is invisible to a browser, it is the web of machines - referred to sometimes as IoT. As usual it is being met with cynicism, because we are not able to see the potential of machine to machine communication. Machines don't have to be physical devices, they can software logic elements. The communication transport does not need to be heavy weight, it does not even need to run entirely over existing TCI/IP transport. Some of the possibilities of IoT are obvious i.e. call home feature, automated trading floors, intelligent surveillance etc. But some are not so obvious. Take for example, your TV prompting you to watch a program because it read a note on your blog or read your profile and "understood" that some program running now is important to you. (apple tv take hint please). Or it knows using face recognition using kinect who is watching the Tv and adjusts the shows according to preference.

I would like the kitchen not just the refrigerator to tell me that the dish on today's cooking list does need an ingredient that I don't have or will run out of soon.

How about my shingles on my roof detecting the leak and sending their location so I don't have to spend hours on the roof with a bucket of water to find it.

Or how about my favorite.. ,(being the only guy I know who had to lost two cars to engine blow out because the engine did not enough oil and broke down)  where my car simply decides that maintenance can no longer be postponed and using  the yet to be developed or perfected driverless technology drives itself to a oil changer get its maintenance after dropping me at work.

Increasingly the innovation is in removing the human element from processes which ultimately makes the human more productive.

Cloud Requires a Market Maker

The business model of cloud computing is boiling down to keeping marginal cost of providing capacity to a marginal demand from mostly corporate user. Even though the cloud enthusiasts continue to believe all corporate computing will move to the cloud, it is not happening and unlikely to happen. The marginal demand though is moving to the cloud and many corporations are designing an overflow capacity in the cloud (kind of like line of computing account). Serving this marginal demand with capacity at a marginal cost that covers the service provider margin requirements is becoming the biz model of the cloud. We have seen the ramification of this on data center site selection and facility design. Now the ramifcations are becoming apparent in the infrastructure that gets deployed in these data centers. Few standouts are ...

Fungible is perhpas the most important requirement for any infrastructure that will be deployed in a cloud. No bells and whistles is another requirement. Basic bare bones is winning over hardened and over engineered systems. The datacenter managers use software to fill the gap between the skeleton and skin. Another standout is virtualization is not a  key requirement. In fact, as more applications onboard it is becoming apparent that cloud based service has to be hybrid of virtual and physical. All of these put together still not enable datacenters to serve the marginal demand at the lowest cost in almost real time. I don't think this can be solved technically, it  is really not a technical initiative, it is a market initiate. Makes sense as demand and supply are really market forces.  Customers engaged in price discovery need a market to query and a market maker to take the order. You can look at airline industry or the securities industry to get a feel for how this might evolve. Consolidators buy blocks of tickets at steep discount in anticipation of demand. Market makers take position in stock with similar intentions. In both of these industries the market maker is a critical element without whom the industry would not function.

This is what we need in cloud industry as well. Something or entity that plays the role of a Goldman or Priceline. I am waiting for the day when AWS starts a program which uses the rack of computer in my garage as capacity to sell to their customers. Kind of like the smart grid or SETI program. We may after all realize the vision of grid computing. The missing link is the market maker.  

Industrial Internet

May be they should rename industrial internet as software defined manufacturing or at least smart manufacturing. There is lot of software in manufacturing already mainly driven by precision requirements. The name, Industrial Internet, conjures up notions of a network hardened against hackers and natural calamities. Moving to software defined everything SD-* is essentially accepting that most basic intelligence today can be codified and stored in data bases that can be queried at high speeds. But that does not mean there is no room for software learning.

Software learning is where software does not just query for data but also reasons with the results of a query and draws inferences and acts on them. This type of software should form the base platform of industrial internet or just plain old IoT. When the devices on you connect to one another not just at the bluetooth layer but at a application layer. For example, when a device playing music is in the vicinity of a speaker, it switches to the speaker (after asking of course) or when you suddenly brake your car to avoid an accident, the video and music playing devices inside the car stop to let the passengers focus on the road, or the same behavior when listening or watching movies in an airplane.

Solution is a state not a path

Networking is going through a identity crisis. Is it a special device or just a program on a commodity machine? The crux of the problem lies in a shift in the problem space where networkers spent all their time. The solution to a networking problem today is not the best path but the best state. In the early years this branch was taken by networkers because in those finding the best path in a graph was the solution to getting the applications (in those days printing, later email) to work. But today, a simple struts application has more action elements (routes) than a BGP table on internet. In other words, there are more paths a browser can take after it has landed on the web server than it had to take getting to the web server.

When state mangement and control is the problem, the solution is software. The paths are discovered and known what matters now is the learning on which ones for which application. This is what is causing the identity crisis for networkers which then manifests itself as SDN, Programmable Networks etc. Also the reason why the largest networking company flips flops between we are going to focus on networking to we want to be an IT company. Hope it does not do what freeport did - a copper company acquiring a O&G company.

State Description Language

After almost a decade after WSDL - the service interface description language - was introduced, I think it is time for industry to create a state description language. Just like WSDL enabled communication of interface between the two points engaged in a conversation (or any other MEP), we need two infrastructure components inside a data center to communicate their state among one another. The end goal is autonomic data center where a component "learns" about the fellow components and reflects and adjusts its own state.

Application integration is easy today. Everybody has an API on which default information (useless) can be communicated. But to use this new found connection we need to develop languages that enable communication about data, state, intention etc. The whole movement to cloud has commoditized compute, storage to a point where $5/month can buy me more IT infrastructure than my university had when I was studying engineering...

Biggest Bottleneck in Bigdata is the human

Today's WSJ carries an article on Bigdata being the brain behind hiring in companies. There are lots of Bigdata articles all around and each one points to a new bottleneck for the industry to overcome. There is one bottleneck that no one discusses. It is the ultimate consumer of Bigdata - the human. If we have trouble getting computers to deal with Bigdata, imagine presenting the analysis to a human. We are simply not wired to consume all this analysis. That is where visualization steps in.

So what is visualization of Bigdata? It is the rendering of insight in a data analysis using images, animations, selective disclosures, progressive disclosures or charts/figures/clouds/bubbles etc. The challenge here is not in rendering these visual elements, but in mapping these elements to the data that is sourced across the internet, parsed by multiple parsers, collated/curated and correlated with multiple streams and displayed on a canvas that is hosted in yet another place. Then there is the debate of HTML5 vs native too.

Visualization of Bigdata is a field actively targeted by research community and there is a strong business case for it as well: it solves the biggest bottleneck in the bigdata ecosystem i.e. the human.

IM is the Best Overlay Network

Under the moniker of Software Defined Network or SDN a flurry of new technical proposals are vying to become the next standards. The business case for them is very sound i.e service providers after failing in their first attempt in late 90s and early 2000s are now confident that there is a way to monetize services which run inside datacenters. The problem is of course the scale at which they need to operate requires that services run across traditional boundaries set up by networking. To cross these boundaries they are devicing clever ways of getting bits across a policy boundary using overlays (envelopes inside other envelopes). The debate is lately on which layer's envelope shall I use. Layer-2 or Layer-3.  Ok, so at the end of day what is needed is a mechanism that abstracts the underlying network and presents it to the applications over sockets in a programmer friendly fashion .

What the networking guys need to do is to look at how this problem was solved in application world over a decade ago. Hint: Use HTTP for control plane, XML for management plane and whatever you want for data plane. The best overlay network in the world continues to be IM (instant messaging)

SDN vs SdN

May be they should have define software Driven network  as application driven network so as not to confuse it with software defined network (openflow and the rest...).  The former is all about network applications using the open APIs on the network to provision, reserve and optimize the path that the application data takes. The open API could be network as a service. The ultimate goal of this initiative is programmable network.

The latter is a rearchitecture of the switch with focus on virtualization of the hardware forwarding plane. A multi device network operating system and bunch of controllers that use use the NOS to configure the devices. The ultimate goal of this initiative is operational excellence.

Innovation is its own Business Case

"What is the business case for this innovation?" Heard that?

Innovation or lack of it is the reason for 2.x% GDP growth in the developed world and we still hear this call for justification. Fed funds rate is 0-0.25% and yet we have to justify NPV of a project. Everybody from company president to the country president is asking (no begging) for innovation, but we need to prove ROI for a project. The chinese did not need a business case to build so called "Ghost cities". They consume 40% of copper production in the world without business case. They are the equivalent of Apple in the world today with surplus cash to buy out several greek deficits. They even placed their machine on the Top 500.

Innovation is its own business case. You cannot calculate the ROI of innovation because you cannot measure the return. So think of the "I" in ROI as your ability to finance (means) and risk tolerance.

SDN

When J Hamilton said network gets in the way, I believe he was asking for a economical solution kind of like the way x86 based servers replace risc processors. The x86 world did not bring complexity, unknown paradigm with unknown cost and difficult to estimate performance. Software Defined Networking a.k.a SDN is apparently doing just that. What started as simple protocol to read/write/replace entries into a switch's forwarding table now has attracted a code bloat and frameworks which promise a network which does substantially what is already done with VMWare's vswitch.

The original call to simplify the network listed a few use cases as drivers which can be categorized as 1) Workload placement (includes all shapes/forms of vm mobility, code mobility etc.) and 2) big data processing. The first challenge attracted solution such as overlays and tunnels which can extend a vm's notion of its layer-2 domain within and across datacenters. What we need now is a standardized way of doing this not a new framework which disassembles a network devices data, control and management plane and places one or more of those on general purpose CPU. We had already done some of this in the olden day with Infiniband's subnet manager and come to the conclusion that it does not scale for dynamic workloads. The second challenge is still in the process of becoming a challenge. With all the hype behind bigadata, an average cluster running bigdata analysis is under 40 nodes. Even Hadoop does not scale beyond 4K nodes.

What the datacenter really wants is a cheap network switch that cost no more than $10/GByte of traffic in motion. $10/GB is the same metric used to guage the efficacy of storage service. It should not cost more than $10 for a gigabyte of data in store or in motion (on the wire) and in the future in memory on the compute side.

Hadoop - Still full of potential

Japan's K-Computer has 705K cores stayed on top of the Top 500 supercomputer list. Now that is scale! I am reacquainting myself to Hadoop to which I was introduced in 2006 and find it is still using stateful nodes maxes out around 3-4K and does not use network storage. Security is an after thought and it is not yet suitable for its killer application interactive behavioral processing or the future killer application real-time stock data processing. If I were to add cloud related requirement of multi-tenancy, virtualization, billing etc etc. you see how underdeveloped this system is and how big its potential is.

BigData = HPC 2.0 and Network 2.0 and reduces healthcare costs

Mckinsey report on big data . http://www.mckinsey.com/mgi/publications/big_data/pdfs/MGI_big_data_full_report.pdf Excerpt from this.. For instance, if US health care could use big data creatively and effectively to drive efficiency and quality, we estimate that the potential value from data in the sector could be more than $300 billion in value every year, two-thirds of which would be in the form of reducing national health care expenditures by about 8 percent May be the republican candidates should study big data ; they are far easier to remember than three agencies...

Cloud Storage

I ran into the letter to stockholders for AMZN. http://phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9OTA4ODB8Q2hpbGRJRD0tMXxUeXBlPTM=&t=1

It does not read like a letter that a retailer sends out to its stockholder. It reads more like a conversation between two technologists. AMZN realizes that if it only gets to store/manage 2% of the 500 Billion Gigabytes of data that exists in the world, it could earn at the rate of $1.2M/Petabyte/year enough to more than double ths stock price from its current (often considered lofty) levels.

NIST Cloud Standards

NIST released its cloud computing standards July 5th. Besides the standard definition around delivery models and characteristics "What" of the cloud, what stands out to me as the most important element of cloud computing is the definition and standardization of the roles in cloud computing. More specifically, the definition of the role "Cloud Auditor". With increasing deployment of clouds, this role becomes about as important if not more as the "Cloud Broker" role.