Session 3 Paper 1: Language-Directed Hardware Design for Network Performance Monitoring (Srinivas, Anirudh, Vikram, Prateesh, Venkat, Mohammad, Vimalkumar, Changhoon)

Presenter: Srinivas Narayana

Authors: Srinivas Narayana, Anirudh Sivaraman, Vikram Nathan, Prateesh Goyal, Venkat Arun, Mohammad Alizadeh, Vimalkumar Jeyakumar, Changhoon Kim






Performance monitoring is important to quickly localize many network problems. While endpoints-based approach can be used for network monitoring, it lacks visibility to localize problems at links deep. Switch-based approach, however, can provide more direct visibility. But traditional mechanisms can't collect enough information or provide relevant performance data, and are thus restrictive.

To achieve more flexible performance monitoring, Srinivas Narayana presented a language-directed hardware design. They designed the language Marple to express monitoring use cases and switch hardware primitives for this language. The operator writes query in Marple language, which will be compiled into a switch program. The program will run on the programmable switches. The operator can get results from the collection servers which receive streams from switches.

Narayana et al. evaluated Marple in terms of hardware compute resources, memory and bandwidth overheads. Srinivas also presented two use cases of Marple: debugging microbursts and flowlet size distributions. It is shown that Marple is effective for fine-grained and programmable network monitoring. And it only requires modest amount of hardware resources. 

This paper received Best Paper Awards this year. You can check out this paper here. 

Q&A:

Q: When you finish processing the query, do you explicitely deallocate things from the backing store.
A: That could be part of the system, like allocating or deallocating memory for each query. If you have a continues query system, then potentially you need to have some way to archive that. If you know you just want to run it for a specific period of time, you could deallocate them once you write them off.

Q: Have you thought about security problems of programming inside network? Because having stuff out there that can be programmed without control over who writes what programs can lead to all sorts of nasty problems.
A: In this case, the operators who run the network are the ones running the programs. This is very different from a user, or a public customer writing programs on switches. But in general if you have a more flexible system in the network, there is a chance that you are exposed to attacks.