06 - Congestion control

Overview

Data center

data centers are a place with racks
- each rack has a number of certain server
  - each of them has a NIC
- each rack has a switch

congestion control
- two senders want to send packets using one switch
- the switch will have lots of dropped packets
- therefore, while we use congestion control to adjust the sending rate accordingly to our bandwidth
  - the sender or the switch needs to check what’s the latency

When switch detects congestion, many approaches are available:

RED: switch sets a threshold, then when a packet arrives and it is within the threshold, the switch randomly drops it
ECN: what if we use RED notifying the sender? So here we don’t randomly drop packages, rather than we mark them. When the receiver will get the marked packets, it will ask to slow down, preventing the congestion. The problem is that you are going to always reduce as long as you receive marked packages. IT’S SLOW!
DCTCP: DCTCP uses Explicit Congestion Notification (ECN) to detect congestion in the network. It responds to congestion by reducing the TCP window size more aggressively than traditional TCP, ensuring a more rapid response to network congestion.
- This works for TCP, but what about RDMA?
PFC: PFC allows Ethernet switches to pause entire Ethernet flows when congestion is detected, preventing packet loss. This could leads to deadlock.
DCQCN: QCN + DCTCP. DCQCN quantizes the congestion notification to allow finer control over the congestion response. It’s especially useful in high-speed networks
HPCC: Adjust flow rates per ACK

When a sender detects congestion, only two approaches are available:

Swift: Swift uses a decentralized architecture where nodes collaborate to store and retrieve data, providing high availability and fault tolerance
RL-CC: RL-CC employs reinforcement learning models to dynamically adjust network parameters based on real-time network conditions, maximizing throughput and minimizing latency.
- Requires substantial training and tuning