Blog

Filter by:

Blog Subscription Form

Some deep thinking about applications, clouds, and networking

Igor Tarasenko
By Igor Tarasenko | 12.14.18 | No Comments

For technical readers of our blog who might be interested in rigorous thinking related to Bayware innovations, here are papers that show active areas of industry discussion that are relevant to Bayware’s architecture.

In terms of key issues…

We see two parallel activities in application and network domains on intelligent traffic routing. Below are two examples from 2018. They look like non-overlapping solutions. The networking domain paper talks about layer 2.5-3 routing. The application domain paper presents routing at layers 4-7. A relevant question for us is how these work together.

As an introduction: draft-dm-net2cloud-problem-statement-03 – this fairly rough-draft RFC shared with us by our technical advisors reveals uncertainty in cloud networking. It relates to one of Bayware’s foundational concepts that networking is not ready for multi-cloud or–better said–struggles to stretch across a new variety of administrative, technological, or security boundaries introduced by the cloud age.

Network Domain: https://tools.ietf.org/html/draft-guichard-sfc-nsh-sr-00 - an example on the network side shows how to dynamically create network services or SFC for specific flows. A key concept at Bayware is that cross-node connectivity will continue to be important, and that flat mesh networks will struggle here. The rhetorical question is whether these new but still configuration-centric–network services will make networks more responsive to cloud-native applications.

Application Domain: https://istio.io/blog/2018/v1alpha3-routing/ -  a new traffic routing feature in Istio/Envoy mesh. It is not the same routing level as we see in the RFC drafts above. It’s layer 4-7 vs layer 2.5-3. Clearly, the key concept of service mesh is, after a target is selected, everything from there is encrypted above layer 4. It seems only IP-based filtering is applicable in the network after that. But IP-based policy makes little sense in today’s networking. Thus, here also we see not even a hint on application and network domains interoperability.

In terms of key solutions…

New types of networking: This paper on Content Centric and Named Data Networks - https://conferences.sigcomm.org/acm-icn/2017/proceedings/icn17-2-slides.pdf - discusses a network protocol design that departs from traditional IP-based routing. The authors present a very interesting approach to path discovery and steering in Information-Centric Network. You will find some important similarities between that and our Application-Centric Network, and some key differences.

New use cases: In this Hotnets paper -  https://mcanini.github.io/papers/daiet.hotnets17.pdf - the authors advocate the ability to compute in line for a variety of use cases that are especially relevant to big data and AI applications. They mention Active Networks as a concept to embed code in packets, a concept that we agree was once ahead of the time. They build use cases using the P4 language and the Tofino chip.  Our point of view is that there are other options. Moreover, we think about in-line computation departing from network configuration altogether, and rather sending data with code, and treating network nodes as Turing-complete computation environments that produce an action set without a match-action pipeline.

From Bayware’s point of view, computing in the network is a perfect candidate to bridge the gap between network and application domains today. Computing in the Network opens new horizons for AI, IoT, and XR as well.

As this is a technical blog, future posts will begin exploring in detail some of these concepts and how we implement them with network microservices. Stay tuned.