Outline of Conference Write up

User Story

Give the measurement engineer the ability to read packets of interest from pcap file and analyze the packets.

---

Use of P4 Language

The advantages of using P4 language for a measurement software are to be discussed. The way the following concepts of P4 language get mapped to the packet parsing software also need to be discussed.

1. Header format specification (utilized on the server-side)
2. Parse graph (generated on client side)
3. Match table (null at present)
4. Action methods (store to DB at present)
5. Control (none at present)

The missing part is the semantic constraints on the header formats. P4 language need to be extended in this direction. There are already good ideas in the selected packet parsing language papers on this topic.

---

Architecture

The architecture section must explain the analyzer, session controller and MVC part of the web application. The top-level sub-sections would be,

1. Analyzer Cell
2. Session Controller
3. MVC Server
4. REST API with JSON Objects
5. MVC on Client-side

Analyzer Cell

The sub-section on the analyzer cell must talk about the following points.

1. Kinds of analysis performed -- generic and custom
2. Configuration specifications for generic analyzer and custom plug-ins
3. Event bus configuration
4. Queues
5. pipeline using threads

Each analyzer cell, specifically, the generic and custom analyzers of the analyzer cell, shall have two data paths. They are fast path and slow path. The fast path quickly analyzes the packet header and passes the payload to the next analyzer. The slow path persists the analysis of the fast path to the DB.

---

Session Controller

The sub-section on the session controller must talk about the steps involved in the P4 parse graph to pipeline generation. Some of these steps are:

1. Implicit capture filters (WHAT DOES THIS MEAN?)
2. Configuration of the cells
3. Queuing and linking

The P4 parse graph generated by the front-end is used in two ways. One is the selection of custom analyzers and the second is the linking of these selected custom analyzers into a neat pipeline architecture.

The best way to explain the parse graph to pipeline mapping is to talk of the mapping as a community detection problem. Each node shall be identified with one layer in the layered reference model. We can think of each layer as having one color. All the vertices of one color (community) get mapped to one pipeline stage. This mapping is fixed and does not change from one experiment to another. The software comes with a pre-configured parse graph that acts as a base graph from which experimenter selects a sub-graph. The user through parse graph configuration file only specifies the sub-graph of the big union graph available on the analyzer software.

MVC on Server-Side

Not much to discuss here as this is a standard architecture. Only have to mention about the persistent data model and the linking with the MVC on client-side using REST API.

Data Model

The ER model of the RDBMS (Postgres) and the map structure of the NoSQL should be talked about here. Both the databases shall be denormalized to reduce the response time to the RESTful requests from the clients. The denormalization can be done based on visualization requirements. The denormalization and table preparation can take place after the packet processing is over.

REST API

A sample structure of the REST API calls along with the JSON object formats.

MVC on Client

A general architecture of the Backbone JS library along with the sitemap. A table providing a short description of each of the pages. The techniques used to generate P4 parse graph from graph library needs to be discussed.

A few sample visualization techniques would be better here.

---

Performance Results

The following graphs are to be made for packet size increments of 100 bytes.

1. Overall throughput
2. Queue grow sizes at all stages
3. Screenshots of the UI