Page tree
Skip to end of metadata
Go to start of metadata

SURFnet8 contains many 100G-10G transitions, which potentially may lead to congestion problems. Congestion control algorithms often only run in the end hosts and work by using either packet loss (e.g., TCP Reno) or increase in RTT (e.g., TCP Vegas) as an indicator for congestion. There are two disadvantages to these approaches. Firstly, the buffers on a network device can be over-dimensioned, causing a delay between congestion occurrence and congestion detection. Thus, loss-based algorithms may not detect congestion on time and delay-based algorithms may have problems establishing the base RTT value in highly utilized networks. Secondly, many of these congestion control algorithms only kick in after congestion has occurred and need at least one RTT to react to the perceived congestion. It would be preferable to detect congestion before the network has to drop packets or cause significant delay to them. Explicit Congestion Notification (ECN) facilitates end-to-end notification of network congestion without dropping packets, but support for it is hardware dependent.

SDN offers an alternative. The main idea is to detect congestion in the switches themselves and then to reroute the affected traffic to a less congested path. Existing congestion detection and avoidance algorithms in SDN usually detect congestion by increased link utilization. While there might be some correlation between link utilization and congestion, the proposed algorithms might perform (in case of a highly utilized network) too many path recalculations. Our objective is to use network telemetry in P4 to find better metrics (delay per node, queue length, queuing delay, ...) to detect congestion directly in the dataplane (without any assistance from the controller). By using P4 we circumvent the inflexibility of ECN.

 We would like to start by a literature survey on different transport protocols (TCP, BBR, QUIC, etc.) and to experiment with a representative set of those protocols within SURFnet's testbed, by creating various levels of network load. Our experiments and observations will guide to development of our own P4-based congestion control solution.

Deliverable: A report on congestion control experiments, due Dec. 31, 2018

  • No labels