Rights statement: ©2021 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.
Accepted author manuscript, 3.4 MB, PDF document
Available under license: CC BY-NC: Creative Commons Attribution-NonCommercial 4.0 International License
Final published version
Research output: Contribution to Journal/Magazine › Journal article › peer-review
Research output: Contribution to Journal/Magazine › Journal article › peer-review
}
TY - JOUR
T1 - A Congestion Control Framework Based on In-Network Resource Pooling
AU - Rene, S.
AU - Ascigil, O.
AU - Psaras, I.
AU - Pavlou, G.
N1 - ©2021 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.
PY - 2022/4/30
Y1 - 2022/4/30
N2 - Congestion control has traditionally relied on monitoring packet-level performance (e.g. latency, loss) through feedback signals propagating end-to-end together with various queue management practices (e.g. 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 In-Network Resource Pooling Protocol (INRPP) 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 (possibly bloated) 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 alternative sub-paths 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.
AB - Congestion control has traditionally relied on monitoring packet-level performance (e.g. latency, loss) through feedback signals propagating end-to-end together with various queue management practices (e.g. 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 In-Network Resource Pooling Protocol (INRPP) 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 (possibly bloated) 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 alternative sub-paths 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.
KW - Bandwidth
KW - Monitoring
KW - multipath.
KW - Network topology
KW - Protocols
KW - resource pooling
KW - Routing protocols
KW - Servers
KW - Topology
KW - Transport protocol
KW - Digital storage
KW - Traffic congestion
KW - Transmission control protocol
KW - End to end
KW - In networks
KW - Multipath
KW - Multipath.
KW - Network resource
KW - Resource pooling
KW - Router buffer
KW - Routing-protocol
KW - Transport protocols
U2 - 10.1109/TNET.2021.3128384
DO - 10.1109/TNET.2021.3128384
M3 - Journal article
VL - 30
SP - 683
EP - 697
JO - IEEE/ACM Transactions on Networking
JF - IEEE/ACM Transactions on Networking
SN - 1063-6692
IS - 2
ER -