Transport Protocols

TCP CUBIC: the “modern default” TCP

The TCP you are familiar with is called TCP RENO, which updates its congestion window cwnd with an AIMD algorithm.

Recall

• AI: additive increase
• MD: multiplicative decrease

Slow Start

• cwnd grows exponentially
  • At timeout, set ssthresh to half of the last bandwidth and restart.
  • Once ssthresh is reached, switch to congestion avoidance.

Congestion Avoidance (AIMD)

• cwnd grows linearly (additive increase).
• $3$ duplicate ACKs are considered mild congestion.
  • cwnd is halved (multiplicative decrease).
• A timeout is considered strong congestion.
  • set sstresh to half of last bandwidth and switch to slow start.

A gentle additive increase and aggressive multiplicative decrease ensures fairness and efficiency.

Nowadays, TCP CUBIC is the default. CUBIC is not fundamentally different from RENO.

Why CUBIC?

In real networks, things often do not go as planned. Let’s recall some of the design goals of TCP.

• Deliver data reliably over a best-effort Internet
  • This one is usually fine
• Share resources fairly
  • every flow gets the same share of bandwidth
  • cwnd as a function of time
• Use the available bandwidth efficiently while not congesting the network
  • cubic increase

CUBIC is fairer if competing flows have different RTTs:

but it isn’t perfect either!

TCP RENO vs CUBIC

In TCP RENO, cwnd grows proportionally to the path RTT.

• Between congestion events, short-RTT flows ramp up quicker.
• long-RTT flows ramp up more slowly.
• on a shared bottleneck, long-RTT flows starve.

In TCP CUBIC, cwnd grows proportionally to time.

• Between congestion events, cwnd grows with time.
• short- and long-RTT flows grow equally.
• short-RTTs still have some advantage (shorter reaction time).
• CUBIC grows the cwnd always at least as fast as RENO, as RENO can be very aggressive if RTTs are low.

Why a cubic function instead of linear increase?

Let’s consider two scenarios where linear increase is not efficient.

The combination of concave, convex, and flat steady state is key. A cubic function is an easy way to achieve it, but not the only one.

BIC is the predecessor of CUBIC. CUBIC achieves the same, but is simpler to implement and analyze.

Multi-path TCP

Nowadays, most clients have more than one connection available. Couldn’t we leverage this for more performance?

• We often have more than one connection to the Internet.
• As a huge use-case, consider WiFi/Cellular on mobile phones:
  • Mobile phones make up over 55% of traffic and 92% of users

While WiFi is theoretically more restricted, we mostly tend to surf when it is available. More than 7 times the traffic over WiFi then Cellular.

Multipath TCP uses multiple paths for the same connection.

• → Increase in throughput
• → Increase in reliability

While it should theoretically be easy to extend TCP, the real internet is not dumb. It contains many middle-boxes, which are devices that inspect or modify traffic for many purposes.

While TCP should keep the network simple, dumb, and application-unaware to allow improving transport on the same network, middle-boxes break this separation. We need to be careful when extending TCP.

Constraints

To understand why Multipath works the way it does, we need to consider two important constraints.

1. Network Address Translation (NAT)
   • Different paths are translated differently.
   • We cannot tell which connections came from the same host.
   • How can we know that two connections go together?
2. Deep Packet Inspection of TCP headers
   • Packets that do not belong to an existing connection may be dropped.
   • Packets that seem out of order may be dropped.
   • How do we ensure that data is transmitted?

Workaround

To work around these constrains, Multipath TCP uses subflows. Each subflow is sent over a single path and looks like regular TCP.

Multipath TCP starts like a regular TCP flow. During the handshake, client and server set an option called MP_CAPABLE in the TCP options header field. They agree on a token unique to their connection.

Additional paths are set up like regular TCP flows as well. This means they need to do a separate handshake! During this handshake, they use the TCP option MP_ADD, including the token, such that the new flow can be matched with the existing one.

Each path has independent sequence numbers so that middle-boxes won’t drop traffic. The “real” sequence numbers are sent in a TCP option called data sequence signal (DSS).