Enabling Fast, Dynamic Network Processing with ClickOS, Joao Martins, NEC (by TheLinuxFoundation)
The Picture You Paint Of The Browser Is That It Has Become Very Complicated With Many Ways To Send And Consume Data (Ajax, DataChannel, WebRTC, WebSocket, SSE). Has The Browser Jumped The Shark Complexity-Wise?
Actually, I would argue that it’s pretty simple once you know the underlying mechanics and use cases for each of the API’s. Take AJAX, SSE, and WebSocket: AJAX is optimized for HTTP request-response, SSE is for server-side streaming over HTTP, and WebSocket is for bi-directional streaming. On the other hand, WebRTC and DataChannel are for P2P communication. Once you know your use case, you can quickly narrow down the list to one or at most two API’s. From there, you need to take a look under the hood of each protocol to understand how it works, and how you should optimize your application code to get the best performance from it. That’s what HPBN is all about.„
Well-designed architecture has complexity (and state) concentrated at the network edge. The core devices keep minimum state (example: IP subnets), while the edge devices keep session state. In a virtual network case, the hypervisors should know the VM endpoints (MAC addresses, IP addresses, virtual segments) and the physical devices just the hypervisor IP address, not the other way round.
Furthermore, as much state as possible should be stored in low-speed devices using software-based forwarding. It’s pretty simple to store a million flows in software-based Open vSwitch (updating them is a different story) and mission-impossible to store 10.000 5-tuple flows in Trident 2 chipset used by most ToR switches.„