A Congestion Control Framework Based on In-Network Resource Pooling

Abstract

Congestion control has traditionally relied on monitoring packet-level performance ( <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">e.g.</i> , latency, loss) through feedback signals propagating end-to-end together with various queue management practices ( <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">e.g.</i> , carefully setting various parameters, such as router buffer thresholds) in order to regulate traffic flow. Due to its end-to-end nature, this approach is known to transfer data according to the path’s slowest link, requiring several RTTs to transmit even a few tens of KB during slow start. In this paper, we take a radically different approach to control congestion, which obviates end-to-end performance monitoring and careful setting of network parameters. The resulting <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">In-Network Resource Pooling Protocol (INRPP)</i> extends the resource pooling principle to exploit in-network resources such as router storage and unused bandwidth along alternative sub-paths. In INRPP, content caches or large ( <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">possibly bloated</i> ) router buffers are used as a place of temporary custody for incoming data packets in a store and forward manner. Data senders push data in the network and when it hits the bottleneck link, in-network caches at every hop store data in excess of the link capacity; nodes progressively move/send data (from one cache to the next) towards the destination. At the same time <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">alternative sub-paths</i> are exploited to move data faster towards the destination. We demonstrate through extensive simulations that INRPP is TCP friendly, and improves flow completion time and fairness by as much as 50% compared to RCP, MPTCP and TCP, under realistic network conditions.