On the Sub-Packetization Size and the Repair Bandwidth of Reed-Solomon Codes

TL;DR

This paper explores the tradeoff between sub-packetization size and repair bandwidth in Reed-Solomon codes, proposing new schemes that balance these factors and extend to multiple failures.

Contribution

It introduces flexible code constructions and repair schemes that interpolate between existing bounds, optimizing the tradeoff for various evaluation point sizes and failure scenarios.

Findings

Proposed schemes achieve a balance between sub-packetization size and repair bandwidth.

Extended schemes to handle multiple node failures.

Generalized methods for different evaluation point sizes.

Abstract

Reed-Solomon (RS) codes are widely used in distributed storage systems. In this paper, we study the repair bandwidth and sub-packetization size of RS codes. The repair bandwidth is defined as the amount of transmitted information from surviving nodes to a failed node. The RS code can be viewed as a polynomial over a finite field $GF(q^\ell)$ evaluated at a set of points, where $\ell$ is called the sub-packetization size. Smaller bandwidth reduces the network traffic in distributed storage, and smaller $\ell$ facilitates the implementation of RS codes with lower complexity. Recently, Guruswami and Wootters proposed a repair method for RS codes when the evaluation points are the entire finite field. While the sub-packization size can be arbitrarily small, the repair bandwidth is higher than the minimum storage regenerating (MSR) bound. Tamo, Ye and Barg achieved the MSR bound but the sub-packetization size grows faster than the exponential function of the number of the evaluation points. In this work, we present code constructions and repair schemes that extend these results to accommodate different sizes of the evaluation points. In other words, we design schemes that provide points in between. These schemes provide a flexible tradeoff between the sub-packetization size and the repair bandwidth. In addition, we generalize our schemes to manage multiple failures.