Netronome Systems Incorporated

Oracle International Corporation

Stuart Wray

Gavin J Stark

Felix Schmidt

Craig Schelp

Nipun Agarwal

Andrew Brownsword

Pravin Shinde

Manel Fernandez Gomez

Rod Reddekopp

Akhilesh Singhania

Onur Kocberber

Matteo Casserini

Tayler Hetherington

Yasha Pushak

Guang-Tong Zhou

Renata Khasanova

Juan Fernandez Peinador

Hossein Hajimirsadeghi

Pavan Chandrashekar

Techniques are described that extend supervised machine-learning algorithms for use with semi-supervised training. Random labels are assigned to unlabeled training data, and the data is split into k partitions. During a label-training iteration, each of these k partitions is combined with the labeled training data, and the combination is used train a single instance of the machine-learning model. Each of these trained models are then used to predict labels for data points in the k−1 partitions of previously-unlabeled training data that were not used to train of the model. Thus, every data point in the previously-unlabeled training data obtains k−1 predicted labels. For each data point, these labels are aggregated to obtain a composite label prediction for the data point. After the labels are determined via one or more label-training iterations, a machine-learning model is trained on data with the resulting composite label predictions and on the labeled data set.

Generalized expectation maximization for semi-supervised learning

Techniques are described herein for using machine learning to learn vector representations of DNS requests such that the resulting embeddings represent the semantics of the DNS requests as a whole. Techniques described herein perform pre-processing of tokenized DNS request strings in which hashes, which are long and relatively random strings of characters, are detected in DNS request strings and each detected hash token is replaced with a placeholder token. A vectorizing ML model is trained using the pre-processed training dataset in which hash tokens have been replaced. Embeddings for the DNS tokens are derived from an intermediate layer of the vectorizing ML model. The encoding application creates final vector representations for each DNS request string by generating a weighted summation of the embeddings of all of the tokens in the DNS request string. Because of hash replacement, the resulting DNS request embeddings reflect semantics of the hashes as a group.

Machine learning-based DNS request string representation with hash replacement

Techniques are provided herein for contextual embedding of features of operational logs or network traffic for anomaly detection based on sequence prediction. In an embodiment, a computer has a predictive recurrent neural network (RNN) that detects an anomalous network flow. In an embodiment, an RNN contextually transcodes sparse feature vectors that represent log messages into dense feature vectors that may be predictive or used to generate predictive vectors. In an embodiment, graph embedding improves feature embedding of log traces. In an embodiment, a computer detects and feature-encodes independent traces from related log messages. These techniques may detect malicious activity by anomaly analysis of context-aware feature embeddings of network packet flows, log messages, and/or log traces.

Malicious activity detection by cross-trace analysis and deep learning

Embodiments monitor statistics from groups of devices and generate an alarm upon detecting a utilization imbalance that is beyond a threshold. Particular balance statistics are periodically sampled, over a timeframe, for a group of devices configured to have balanced utilization. The devices are ranked at every data collection timestamp based on the gathered device statistics. The numbers of times each device appears within each rank over the timeframe are tallied. The device/rank summations are collectively used as a probability distribution representing the probability of each device being ranked at each of the rankings in the future. Based on this probability distribution, an entropy value that represents a summary of the imbalance of the group of devices over the timeframe is derived. An imbalance alert is generated when one or more entropy values for a group of devices shows an imbalanced utilization of the devices going beyond an identified imbalance threshold.

Detecting device utilization imbalances

Embodiments use Bayesian techniques to efficiently estimate the bit error rates (BERs) of cables in a computer network at a customizable level of confidence. Specifically, a plurality of probability records are maintained for a given cable in a computer system, where each probability record is associated with a hypothetical BER for the cable, and reflects a probability that the cable has the associated hypothetical BER. At configurable time intervals, the probability records are updated using statistics gathered from a switch port connected to the cable. In order to estimate the BER of the cable at a given confidence level, embodiments determine which probability record is associated with a probability mass that indicates the confidence level. The estimate for the cable BER is the hypothetical BER that is associated with the indicated probability mass. Embodiments store the estimate in memory and utilize the estimate to aid in maintaining the computer system.

Estimate bit error rates of network cables

Herein are techniques for analysis of data streams. In an embodiment, a computer associates each software actor with data streams. Each software actor has its own backlog queue of data to analyze. In response to receiving some stream content and based on the received stream content, data is distributed to some software actors. In response to determining that the data satisfies completeness criteria of a particular software actor, an indication of the data is appended onto the backlog queue of the particular software actor. The particular software actor is reset to an initial state by loading an execution snapshot of a previous initial execution of an embedded virtual machine. Based on the particular software actor, execution of the execution snapshot of the previous initial execution is resumed to dequeue and process the indication of the data from the backlog queue of the particular software actor to generate a result.

Engine for reactive execution of massively concurrent heterogeneous accelerated scripted streaming analyses

An integrated circuit includes a processor and an exact-match flow table structure. A first packet is received onto the integrated circuit. The packet is determined to be of a first type. As a result of this determination, execution by the processor of a first sequence of instructions is initiated. This execution causes bits of the first packet to be concatenated and modified in a first way, thereby generating a first Flow Id. The first Flow Id is an exact-match for the Flow Id of a first stored flow entry. A second packet is received. It is of a first type. As a result, a second sequence of instructions is executed. This causes bits of the second packet to be concatenated and modified in a second way, thereby generating a second Flow Id. The second Flow Id is an exact-match for the Flow Id of a second stored flow entry.

Executing a selected sequence of instructions depending on packet type in an exact-match flow switch

A Software-Defined Networking (SDN) switch includes external network ports for receiving external network traffic onto the SDN switch, external network ports for transmitting external network traffic out of the SDN switch, a first Network Flow Switch (NFX) integrated circuit that has multiple network ports and that maintains a first flow table, another Network Flow Switch (NFX) integrated circuit that has multiple network ports and that maintains a second flow table, a Network Flow Processor (NFP) circuit that maintains a third flow table, and a controller processor circuit that maintains a fourth flow table. The controller processor circuit is coupled by a serial bus to the NFP circuit but is not directly coupled by any network port to either the NFP circuit nor the first NFX integrated circuit nor the second NFX integrated circuit.

Modular and partitioned SDN switch

A method involves a Software-Defined Networking (SDN) switch that includes multiple Network Flow Switch (NFX) integrated circuits, a Network Flow Processor (NFP) circuit, and a controller processor. The controller processor is coupled to the NFP circuit by a serial bus. A flow table is maintained on each of the NFX integrated circuits. A SDN flow table is maintained on the NFP circuit. A copy of each of the flow tables is maintained on the NFP circuit. Another SDN flow table is maintained on the controller processor. A SDN protocol stack is executed on the controller processor. A SDN protocol message is received onto the SDN switch via one of the NFX integrated circuits. The SDN protocol message is communicated across a network link to the NFP circuit, and across the serial bus from the NFP circuit to the controller processor such that the SDN protocol message is received and processed by the SDN protocol stack executing on the controller processor.

Method of handling SDN protocol messages in a modular and partitioned SDN switch

An exact-match flow table structure of an integrated circuit stores flow entries. Each flow entry includes a Flow Id and an action value. Each Flow Id is a multi-bit digital value that uniquely identifies a flow. A Flow Id does not include any wildcard indictor. The flow table structure cannot and does not store an indicator that any particular part of a packet should be matched against any part of a Flow Id. In one example, a packet is received onto the integrated circuit. A Flow Id is generated from the packet. If the flow table structure determines that the Flow Id is a bit-by-bit exact-match of any Flow Id of any stored flow entry, then the packet is handled according to the action value of the flow entry. If, on the other hand, there is not exact-match, then a miss indication is output from the integrated circuit.

Flow switch IC that uses flow IDs and an exact-match flow table

An exact-match flow table structure stores flow entries. Each flow entry includes a Flow Id. A flow entry is generated from an incoming packet. The flow table structure determines whether there is a stored flow entry, the Flow Id of which is an exact-match for the generated Flow Id. In one novel aspect, a programmable reduce table circuit is used to generate a Flow Id. A selected subset of bits of an incoming packet is supplied as an address to an SRAM, so that the SRAM outputs a data value. The data value is supplied to a programmable lookup circuit such that the lookup circuit performs a selected type of lookup operation, and outputs a result value of a reduced number of bits. A multiplexer circuit is used to form a Flow Id such that the result value is a part of the Flow Id.

Making a flow ID for an exact-match flow table using a programmable reduce table circuit

An integrated circuit includes an exact-match flow table structure, a crossbar switch, and an egress packet modifier. Each flow entry includes an egress action value, an egress flow number, and an egress port number. A Flow Id is generated from an incoming packet. The Flow Id is used to obtain a matching flow entry. A portion of the packet is communicated across the crossbar switch to the egress packet modifier, along with the egress action value and flow number. The egress action value is used to obtain non-flow specific header information stored in a first egress memory. The egress flow number is used to obtain flow specific header information stored in a second egress memory. The egress packet modifier adds the header information onto the portion of the packet, thereby generating a complete packet. The complete packet is then output from an egress port indicated by the egress port number.

Crossbar and an egress packet modifier in an exact-match flow switch

An exact-match flow table structure stores flow entries. Each flow entry includes a Flow Id and an action value. A flow entry is generated from an incoming packet. The flow table structure determines whether there is a stored flow entry, the Flow Id of which is an exact-match for generated Flow Id. In one novel aspect, a multiplexer circuit is used to generate Flow Ids. The multiplexer circuit includes a plurality of byte-wide multiplexer. Each respective one of the byte-wide multiplexers outputs a byte that is a corresponding respective byte of the Flow Id. The various inputs of the byte-wide multiplexers are coupled to receive various bytes of the incoming packet, various bytes of modified or compressed packet data, as well as bytes of metadata. By controlling select values supplied onto the select inputs of the multiplexer circuit, Flow Ids of different forms can be generated.

Making a flow ID for an exact-match flow table using a byte-wide multiplexer circuit

A method of Software-Defined Networking (SDN) switching. A packet of a flow is received onto a SDN switch via a NFX circuit. The NFX circuit determines that the packet matches a flow entry stored in any flow table in the NFX circuit, counts the number of packets of the flow received, and determines that the number of packets of the flow received is above a threshold value. The NFX circuit then forwards the packet to a NFP circuit in the SDN switch. The NFP circuit determines that the packet matches a flow entry stored in the flow table in the NFX and generates a new flow entry that applies to a relatively narrow subflow of packets that is forwarded to and stored the flow table in the NFX circuit. A subsequent packet of the flow is switched by the SDN switch without forwarding the packet to the NFP.

Growing community of inventors

Cambridge, United Kingdom

Stuart Wray