Wednesday, September 11, 2013

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.

Monday, September 09, 2013

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.


Costs in Training LLMs

 I went through the Llama-2 white paper that was released with the model by meta. I was hoping to learn some special technique they may be ...