I am a Computer Science graduate student in the PhD program at UC Berkeley. My advisor is Sylvia Ratnasamy, and my research interests are primarily in computer networks. My dissertation focuses on new opportunities and challenges arising from moving middlebox services to clouds and ISPs.
I'm interested in big networking questions surrounding middleboxes, networked systems, measurement, Internet architecture, and cloud computing. Some of my past and current projects are below; more details are on my publications page and in my CV.
In a study of 57 enterprise networks, we found that middleboxes like firewalls and caches are expensive, failure-prone, and difficult to manage. To resolve these challenges, we built APLOMB, a service which allows enterprises to ditch their middleboxes entirely. With APLOMB, cloud providers offer middleboxes as a "service" to enterprise clients who tunnel their traffic to a nearby datacenter to receive security and performance processing services.
Network middleboxes must offer high availability, with automatic failover when a device fails. Unlike routers, when middleboxes fail they most recover lost state about active network connections to perform properly; without this lost state clients face connection resets, downtime, or insecure behaviors. No existing middlebox design provides failover that is correct, fast to recover, and imposes little increased latency on failure-free operations. Our system, FTMB, adds only 30us of latency to median per packet latencies -- a 100-1000x improvement over existing fault-tolerance mechanisms. Our system introduces moderate throughput overheads (5-30%) and can reconstruct lost state in 40-275ms for practical system configurations.
The rapid rise in adoption of encrypted protocols like HTTPS means that middleboxes are in trouble. Unable to access the data they need to inspect or modify, they either fail to do their job entirely, or adopt supsicious "man in the middle" approaches to decrypt the user's traffic and circumvent user privacy goals. We propose and implement BlindBox, a middlebox which uses new cryptographic algorithms to process user connections while leaving the user's traffic encrypted. BlindBox is the first system which can both meet users demands for privacy and permit network providers to inspect and process traffic, e.g., for intrusion detection.
In cloud environments, many tenants share access to the network where their traffic may be queued, dropped, or throttled by the presence of other tenants' traffic. We designed and built Silo, a network architecture for public cloud architectures that can guarantee message completion times for all users; for large tranfers and even for short and latency-sensitive applications. Silo builds upon network calculus to determine how tenants with competing requirements can coexist, using a novel packet pacing mechanism to ensure the requirements are met. With Silo, clients can have the same kinds of guarantees from their public cloud as they would from a tightly engineered private network.
At startup, congestion control algorithms must carefully balance the desire to send aggressively -- making best use of available resources -- and to send cautiously -- in order to avoid congestion, heavy packet loss, and unfairness. TCP slow start takes the cautious route, sending only 4-10 packets in the first round trip time, and only slowly ramping up the sending rate from there. We propose RC3, which allows senders to send aggressively without the threat of heavy congestion or unfairness. RC3 `keeps the pipe full' from the very first RTT, sending additional traffic (beyond what TCP might send) at strictly lower priorities than normal traffic. We find that RC3 improves flow completion times in the wide area by 40-80%.
Services like firewalling, protocol acceleration, and caching are widely available today through the deployment of middleboxes. However, these capabilities are not exposed to end host applications through the `interface' the network exposes to them. We designed netcalls to allow end hosts to invoke and configure the advanced capabilities offered in any network their traffic traverses; for example, we built a web server which invokes inter-domain DDoS defense when it detects it is under attack.
IP timestamps are a little-known feature of every packet that traverses the Internet, allowing a client to request a simple timestamp from any router which handles the packet. We showed that IP timestamps are supported by a substantial fraction of routers on the Internet -- about 30% -- and that IP timestamps can be used for a number of useful measurements: measuring parts of the reverse path a packet takes from server to client, identifying when two IP addresses belong to the same router, and measuring course-grained link latencies.