Abstract: This disclosure describes techniques and mechanisms for using a domain-specific language (DSL) to express and compile serverless network functions, and optimizing the deployment location for the serverless network functions on network devices. In some examples, the serverless network functions may be expressed entirely in the DSL (e.g., via a text-based editor, a graphics-based editor, etc.), where the DSL is a computer language specialized to a particular domain, such as a network function domain. In additional examples, the serverless network functions may be expressed and compiled using a DSL in combination with a general-purpose language (GSL). Once the serverless network function have been expressed and/or compiled, the techniques of this disclosure further include determining an optimized network component on which the serverless network function is to execute, and deploying the serverless function to the optimized network component.

Abstract: Techniques for using computer networking protocol extensions to route control-plane traffic and data-plane traffic associated with a common application are described herein. For instance, a traffic flow associated with an application may be established such that control-plane traffic is sent to a control-plane node associated with the application and data-plane traffic is sent to a data-plane node associated with the application. When a client device sends an authentication request to connect to the application, the control-plane node may send an indication of a hostname to be used by the client device to send data-plane traffic to the data-node. As such, when a packet including the hostname corresponding with the data-plane node is received, the packet may be forwarded to the data-plane node.

Abstract: Techniques for multi-tenant overlays with per-tenant distributed routing are described herein. The techniques may include provisioning an overlay network such that tenants hosted by a forwarding plane of the overlay network are each configured to forward routing protocol packets to a routing control plane of the overlay network and the routing control plane of the overlay network is configured to determine routing paths between each tenant and respective destinations. A routing protocol packet may be sent to the routing control plane by a first tenant. The routing protocol packet may include an indication of a destination that is served by the first tenant. Based on receiving the routing protocol packet, the routing control plane may determine one or more routing paths between the tenants and the destination. Additionally, an indication of the routing path may be sent to the tenants.

Abstract: In one embodiment, a monitoring engine obtains mesh flow data for traffic flows between nodes in a service mesh. The monitoring engine associates the mesh flow data with network traffic between an endpoint device and an edge of the service mesh. The monitoring engine identifies, based on the mesh flow data, a particular container workload associated with the traffic flows. The monitoring engine provides an indication that the particular container workload is associated with the network traffic between the endpoint device and the edge of the service mesh.

Abstract: Techniques are described for using observability to allocate and deploy workloads for execution by computing resources in a cloud network. The workloads may be allocated and deployed to the computing resources based on metrics. The workloads may be deployed to the computing resources, based on the computing resources providing a number of types of observability that matches the number of metrics. The workloads may be deployed to the computing resources, further based on each of the computing resources matching a corresponding one of the metrics. Deployment of the workloads may be further based on availability of the computing resources. The workloads may be redeployed to other computing resources that provide different types of observability associated with the metrics, in comparison to the initial computing resources. The workloads may be allocated and deployed based on intent based descriptions indicating characteristics utilized to determine types of metrics for providing observability.

Abstract: Techniques for a computing resource network to send a packet through a processing flow (e.g., a service chain) according to an order of processing workloads (e.g., services) included in the processing flow, configured as an optimized service chain. In some examples, the computing resource network may include a policy evaluation engine configured to determine the best probabilistic outcome of an order of routing between the services that results in the lowest computational costs based on the probability that a given packet will be terminated/modified at one of the earlier processing workloads in the service chain, a prediction engine configured to determine the order of the processing workloads included in the processing flow based on a policy and/or telemetry data associated with the processing workloads, and/or an intelligent routing engine configured to route a packet between the one or more processing workloads included in a processing flow according to the order.

Abstract: Techniques for operationalizing workloads at edge network nodes, while maintaining centralized intent and policy controls. The techniques may include storing, in a cloud-computing network, a workload image that includes a function capability. The techniques may also include receiving, at the cloud-computing network, a networking policy associated with an enterprise network. Based at least in part on the networking policy, a determination may be made at the cloud-computing network that the function capability is to be operationalized on an edge device of the enterprise network. The techniques may also include sending the workload image to the edge device to be installed on the edge device to operationalize the function capability. In some examples, the function capability may be a security function capability (e.g., proxy, firewall, etc.), a routing function capability (e.g., network address translation, load balancing, etc.), or any other function capability.

Abstract: Techniques for load balancing encrypted traffic based on security parameter index (SPI) values of packet headers and sets of 5-tuple values of the packet headers are described herein. Additionally, techniques for including quality of service (QoS)-type information in SPI value fields of packet headers are also described herein. The QoS-type information may indicate a particular traffic class according to which the packet is to be handled. Further, techniques for pre-configuring a backend host such that encrypted traffic may be migrated to the backend host from another backend host without causing temporary service disruptions are also described herein.

Abstract: This disclosure describes techniques for performing application-based tagging. An example method is performed by a virtual socket of a device. The method includes receiving non-packetized data from an application, generating a label based on the application, and providing the non-packetized data and the label to a kernel of the device.

Abstract: In one embodiment, a videoconference service determines a selection of a virtual background for a videoconference from a particular participant of a plurality of participants in the videoconference. The videoconference service determines an audio context filter that is associated with a visual context of the virtual background. The videoconference service modifies an audio stream of the videoconference into a modified audio stream according to the audio context filter. The videoconference service presents, to the plurality of participants during the videoconference, the particular participant using the virtual background and the modified audio stream. In an embodiment, the videoconference service ascertains the visual context of the virtual background based on applying a machine learning model to the virtual background.

Abstract: Systems, methods, and computer-readable media are provided for reusing execution environments and code of serverless functions while ensuring isolation in serverless computing environments. In some examples, a method can include, in response to a first request to run a serverless function, executing, at an execution environment on a network, computer-readable code configured to perform the serverless function; after the computer-readable code has executed, modifying a pointer to an area of memory used to store a first state of the serverless function to reference a different area of memory; in response to a second request to run the serverless function, reusing, at the execution environment, the computer-readable code to perform the serverless function; and based on the pointer referencing the different area of memory, using the different area of memory to store a second state of the serverless function.

Abstract: Techniques for routing service mesh traffic based on whether the traffic is encrypted or unencrypted are described herein. The techniques may include receiving, from a first node of a cloud-based network, traffic that is to be sent to a second node of the cloud-based network and determining whether the traffic is encrypted or unencrypted. If it is determined that the traffic is encrypted, the traffic may be sent to the second node via a service mesh of the cloud-based platform. Alternatively, or additionally, if it is determined that the traffic is unencrypted, the traffic may be sent to the second node via an encrypted tunnel. In some examples, the techniques may be performed at least partially by a program running on the first node of the cloud-based network, such as an extended Berkeley Packet Filter (eBPF) program, and the like.

Abstract: Techniques for policy-based connection provisioning using Domain Name System (DNS) requests are described herein. The techniques may include receiving policy data associated with one or more headend nodes that manage connections to computing resources. Additionally, the techniques may include receiving a DNS request from a client device to establish a connection between the client device and a first headend node of the one or more headend nodes. The DNS request may include an attribute associated with the client device. A provisioning service may determine that the connection should be established between the client device and the first headend node based at least in part on evaluating the attribute with respect to the policy data. Additionally, the techniques may include sending an internet protocol (IP) address, which is associated with the first headend node, to the client device to facilitate establishment of the connection.

Abstract: This disclosure describes techniques and mechanisms for using a domain-specific language (DSL) to express and compile serverless network functions, and optimizing the deployment location for the serverless network functions on network devices. In some examples, the serverless network functions may be expressed entirely in the DSL (e.g., via a text-based editor, a graphics-based editor, etc.), where the DSL is a computer language specialized to a particular domain, such as a network function domain. In additional examples, the serverless network functions may be expressed and compiled using a DSL in combination with a general-purpose language (GSL). Once the serverless network function have been expressed and/or compiled, the techniques of this disclosure further include determining an optimized network component on which the serverless network function is to execute, and deploying the serverless function to the optimized network component.

Abstract: Techniques for orchestrating workloads based on policy to operate in optimal host and/or network proximity in cloud-native environments are described herein. The techniques may include receiving flow data associated with network paths between workloads hosted by a cloud-based network. Based at least in part on the flow data, the techniques may include determining that a utilization of a network path between a first workload and a second workload is greater than a relative utilization of other network paths between the first workload and other workloads. The techniques may also include determining that reducing the network path would optimize communications between the first workload and the second workload without adversely affecting communications between the first workload and the other workloads. The techniques may also include causing at least one of a redeployment or a network path re-routing to reduce the networking proximity between the first workload and the second workload.

Abstract: A system and computer-implemented method for routing an encrypted packet through a cloud enforcement network based on a metadata tag. The cloud enforcement network applies policy and routing attributions or tags outside of the encrypted packet payload in such a way as to not require an inner packet to first be decrypted. Traffic prioritization, data protection, and per application policies are achieved by using such metadata tags for internode routing without the need for DPI or decryption. Furthermore, the metadata itself can also be signed or encrypted depending on the provenance of the data. As such, applying meta-tagging external to an encrypted packet, the payload would not be needed to be decrypted during transit of the packet to express end-to-end policy and routing decisions.

Abstract: In one embodiment, a monitoring engine obtains mesh flow data for traffic flows between nodes in a service mesh. The monitoring engine associates the mesh flow data with network traffic between an endpoint device and an edge of the service mesh. The monitoring engine identifies, based on the mesh flow data, a particular container workload associated with the traffic flows. The monitoring engine provides an indication that the particular container workload is associated with the network traffic between the endpoint device and the edge of the service mesh.

Abstract: In one embodiment, a device receives results of a plurality of load tests for a web application, the results comprising information about one or more domains accessed when loading the web application during the plurality of load tests. The device determines a baseline of expected domains that are accessed during loading of the web application based on normalizing the results of the plurality of load tests. The device identifies, based on the baseline of expected domains, an anomalous domain that is loaded during a loading of the web application. The device performs one or more mitigation actions in response to identifying the anomalous domain.

Abstract: Techniques for tunneling Layer 2 ethernet frames over a connection tunnel using the MASQUE protocol are described herein. The MASQUE protocol may be extended to include a new entity, configured to proxy ethernet frames using a MASQUE proxy connection, and an associated CONNECT method, CONNECT-ETH. Using the extended MASQUE protocol, an Ethernet over MASQUE (EoMASQUE) tunnel may then be established between various networks that are remote from one another and connected to the internet. An EoMASQUE tunnel, established between separate remote client premises, and/or between a remote client premise and an enterprise premise, may tunnel ethernet packets between the endpoints. Additionally, a first EoMASQUE tunnel, established between a first client router provisioned in a first remote client premise and an EoMASQUE proxy node, and a second EoMASQUE tunnel, established between a second client premise and the EoMASQUE proxy node, may tunnel ethernet packets between the first and second client premise.

Abstract: Techniques for leveraging the MASQUE protocol to provide remote clients with full application access to private enterprise resources are described herein. One or more network nodes may be configured to execute a MASQUE proxy service to provide a remote client device with full access to an enterprise/private application resource executing on an application node and hosted in an enterprise/application network, behind the MASQUE proxy service. In some examples, the MASQUE proxy service may execute on a single proxy node hosted at an edge of a cloud network or at an edge of an enterprise network. Additionally, or alternatively, a first instance of the MASQUE proxy service may execute on a first proxy node hosted at an edge of a cloud network (e.g., an ingress proxy node) and a second instance of the MASQUE proxy service may execute on a second proxy node hosted at an edge of the enterprise network.