Waleed Reda

wfhsr (at) kth.se

Isafjordsgatan 26, 16440 Kista Stockholm, Sweden

I received my PhD in 2022 from KTH Royal Institute of Technology and UCLouvain. On a high-level, my interests are mainly in distributed systems and networks. My research has led to the development of ultra low-latency distributed filesystems that use state-of-the-art storage and networking hardware (Assise, LineFS). My recent work explores how to turn commodity NICs into general-purpose processors to exploit their computational power.

I was previously supported by the EMJD-DC fellowship.

News

Feb 24, 2022	RezSort breaks the JouleSort 2021 world record!
Oct 26, 2021	LineFS awarded best paper at SOSP’21!
Jun 11, 2021	Can RDMA support arbitrarily-complex offloads? The answer is yes! RedN accepted at NSDI’22.
Aug 4, 2020	Assise accepted at OSDI’20.

Select publications

NSDI

RDMA is Turing complete, we just did not know it yet!

Reda, Waleed, Canini, Marco, Kostić, Dejan, and Peter, Simon

In 19th USENIX Symposium on Networked Systems Design and Implementation (NSDI) 2022

Abs PDF Code

It is becoming increasingly popular for distributed systems to exploit offload to reduce load on the CPU. Remote Direct Memory Access (RDMA) offload, in particular, has become popular. However, RDMA still requires CPU intervention for complex offloads that go beyond simple remote memory access. As such, the offload potential is limited and RDMA-based systems usually have to work around such limitations. We present RedN, a principled, practical approach to implementing complex RDMA offloads, without requiring any hardware modifications. Using self-modifying RDMA chains, we lift the existing RDMA verbs interface to a Turing complete set of programming abstractions. We explore what is possible in terms of offload complexity and performance with a commodity RDMA NIC. We show how to integrate these RDMA chains into applications, such as the Memcached key-value store, allowing us to offload complex tasks such as key lookups. RedN can reduce the latency of key-value get operations by up to 2.6× compared to state-of-the-art KV designs that use one-sided RDMA primitives (e.g., FaRM-KV), as well as traditional RPC-over-RDMA approaches. Moreover, compared to these baselines, RedN provides performance isolation and, in the presence of contention, can reduce latency by up to 35× while providing applications with failure resiliency to OS and process crashes.
SOSP

LineFS: Efficient SmartNIC Offload of a Distributed File System with Pipeline Parallelism

Kim, Jongyul, Jang, Insu, Reda, Waleed, Im, Jaeseong, Canini, Marco, Kostić, Dejan, Kwon, Youngjin, Peter, Simon, and Witchel, Emmett

In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles (SOSP) 2021

Abs PDF Code Best Paper

In multi-tenant systems, the CPU overhead of distributed file systems (DFSes) is increasingly a burden to application performance. CPU and memory interference cause degraded and unstable application and storage performance, in particular for operation latency. Recent client-local DFSes for persistent memory (PM) accelerate this trend. DFS offload to SmartNICs is a promising solution to these problems, but it is challenging to fit the complex demands of a DFS onto simple SmartNIC processors located across PCIe. We present LineFS, a SmartNIC-offloaded, high-performance DFS with support for client-local PM. To fully leverage the SmartNIC architecture, we decompose DFS operations into execution stages that can be offloaded to a parallel datapath execution pipeline on the SmartNIC. LineFS offloads CPU-intensive DFS tasks, like replication, compression, data publication, index and consistency management to a Smart-NIC. We implement LineFS on the Mellanox BlueField Smart-NIC and compare it to Assise, a state-of-the-art PM DFS. LineFS improves latency in LevelDB up to 80% and throughput in Filebench up to 79%, while providing extended DFS availability during host system failures.
OSDI

Assise: Performance and Availability via Client-local NVM in a Distributed File System

Anderson, Thomas E, Canini, Marco, Kim, Jongyul, Kostić, Dejan, Kwon, Youngjin, Peter, Simon, Reda, Waleed*, Schuh, Henry N, and Witchel, Emmett

In 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI) 2020

* Lead student author

Abs PDF Code

The adoption of low latency persistent memory modules (PMMs) upends the long-established model of remote storage for distributed file systems. Instead, by colocating computation with PMM storage, we can provide applications with much higher IO performance, sub-second application failover, and strong consistency. To demonstrate this, we built the Assise distributed file system, based on a persistent, replicated coherence protocol that manages client-local PMM as a linearizable and crash-recoverable cache between applications and slower (and possibly remote) storage. Assise maximizes locality for all file IO by carrying out IO on process-local, socket-local, and client-local PMM whenever possible. Assise minimizes coherence overhead by maintaining consistency at IO operation granularity, rather than at fixed block sizes. We compare Assise to Ceph/BlueStore, NFS, and Octopus on a cluster with Intel Optane DC PMMs and SSDs for common cloud applications and benchmarks, such as LevelDB, Postfix, and FileBench. We find that Assise improves write latency up to 22x, throughput up to 56x, fail-over time up to 103x, and scales up to 6x better than its counterparts, while providing stronger consistency semantics.
SIGCOMM

Path Persistence in the Cloud: A Study of the Effects of Inter-Region Traffic Engineering in a Large Cloud Provider’s Network

Reda, Waleed, Bogdanov, Kirill, Milolidakis, Alexandros, Ghasemirahni, Hamid, Chiesa, Marco, Maguire Jr, Gerald Q, and Kostić, Dejan

ACM SIGCOMM Computer Communication Review 2020

Abs PDF

A commonly held belief is that traffic engineering and routing changes are infrequent. However, based on our measurements over a number of years of traffic between data centers in one of the largest cloud provider’s networks, we found that it is common for flows to change paths at ten-second intervals or even faster. These frequent path and, consequently, latency variations can negatively impact the performance of cloud applications, specifically, latency-sensitive and geo-distributed applications. Our recent measurements and analysis focused on observing path changes and latency variations between different Amazon aws regions. To this end, we devised a path change detector that we validated using both ad hoc experiments and feedback from cloud networking experts. The results provide three main insights: (1) Traffic Engineering (TE) frequently moves (TCP and UDP) flows among network paths of different latency, (2) Flows experience unfair performance, where a subset of flows between two machines can suffer large latency penalties (up to 32% at the 95th percentile) or excessive number of latency changes, and (3) Tenants may have incentives to selfishly move traffic to low latency classes (to boost the performance of their applications). We showcase this third insight with an example using rsync synchronization. To the best of our knowledge, this is the first paper to reveal the high frequency of TE activity within a large cloud provider’s network. Based on these observations, we expect our paper to spur discussions and future research on how cloud providers and their tenants can ultimately reconcile their independent and possibly conflicting objectives. Our data is publicly available for reproducibility and further analysis at http://goo.gl/25BKte.