# RMT

### Main Idea 

* **Trade-offs between programmability and speed**
  * can match-action hardware permit (just) enough reconfiguration in the field so that new types of packet processing can be supported at run-time (can this be done at reasonable cost without sacrificing speed) 
* **Reconfigurable Match-action Table (RMT) model**: Minimal instruction set like RISC, designed to run really fast in heavily pipelined hardware 
  * First formal description of a switch architecture providing programmability without giving up performance 
  * Flexibility at no cost 
    * Allow new fields to be added by modifying the parser
    * Allow new fields to be matched by modifying match memories 
    * Allow new actions by modifying stage instructions
    * Allow new queueing by modifying the queue discipline for each queue 
  * Flexible 
    * Packet parsing: can add new header fields and have the switch match on them
    * Match on new header fields and new combinations of headers
    * Actions (packet editing): modify packet headers in somewhat more arbitrary ways 
    * Table sizing: only need to respect overall constraint on SRAM (exact match) and TCAM (tenary match) memory sizes 
* Contributions 
  * An architecture for RMT 
    * allow definition of arbitrary headers and header sequences, arbitrary matching of fields by an arbitrary number of tables, arbitrary writing of packet header fields, and state update per packet 
    * Main abstraction: parse graph (that defines headers), and a table flow graph (that expresses the match table topology) 
  * Use cases: implement forwarding using Ethernet and IP headers, and support RCP 
  * Chip design and cost: implementation of a 640 Gbps switch chip; detail in logic and circuit design, floorplanning and layout, etc. 
* RMT model: a way to think about programming the network, and direct expression in HW using a configurable pipeline of match tables and action processors 

<figure><img src="https://2097630930-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MVORxAomcgtzVVUqmws%2Fuploads%2Fk1eirSrlmnObw3ZorEvs%2Fimage.png?alt=media&#x26;token=ab8f34ec-c5af-4c97-a667-6ea6dc6a9d6e" alt=""><figcaption></figcaption></figure>

* Some interesting [notes](https://cs.nyu.edu/~anirudh/CSCI-GA.2620-001/lectures/lec8_rmt_p4.txt)&#x20;
  * OpenFlow, but more flexible version?&#x20;
  * How to make data plane programmable as well? (i.e. SDN then was all about control plane programmability, still quite limited by what was provided by the switches)&#x20;
  * Some restrictions&#x20;
    * Can't run everything as you can on a CPU&#x20;
    * isn't Turing complete (?)
    * Can't do packet scheduling, payload manipulation, programmatic state manipulation; can't do packet encryption or regular expression processing on the packet body&#x20;
  * What's the benefit&#x20;
    * Researchers trying out new ideas&#x20;
    * Network operators who want to customize the network to their needs (e.g. traffic engineerings, load balancing)&#x20;
    * Switch vendors: easier to fix bugs in the software without making new hardware chips&#x20;
  * Paper notes
    * High- to low-level description, top down approach&#x20;
    * Combine ideas cross fields (networking, hardware design, compilers, circuit design, algorithms)&#x20;