What would happen if TCP flow control is turned off hypothetically? [closed]

Question

I understand that TCP flow control provides a way for the receiver to backpressure the sender. But what if we eliminated this from the protocol. Of course, the receiver would still ACK everything that is received and successfully saved in a buffer or transferred to application layer, but would simply drop everything else. The sender would re-transmit and this would ensure reliable delivery.

Why doesn't this work? I could see that this would cause a part of network capacity to be wasted on dropped packets. But it saves on the complexity of implementing sliding window.

Thanks

Answer 1

But what if we eliminated this from the protocol.

Then it would not be TCP.

The point of flow control is that the receiving host has a buffer to receive data, and it is a fixed size. The receiver tells the sender what the available buffer space is left in the acknowledgements. As the receiving TCP receives data and fills the buffer, the window shrinks, and as the TCP gives data to the application and frees buffer space, then the window grows. If the receiver can keep up with giving data to the application, then the window can keep up with the sender.

Flow control is what TCP is built around. The flow control is based on the window sent back in every acknowledgement. If you do not want flow control, then you use a different protocol. Usually, you would use UDP and create an application-layer protocol that implements the other TCP features that you want. This is often done by programmers.

---

Edit:

RFC 793, Transmission Control Protocol explains that flow control is a required part of reliable communication (I have highlighted the relevant text):

To provide this service on top of a less reliable internet communication system requires facilities in the following areas:

Basic Data Transfer
Reliability
Flow Control
Multiplexing
Connections
Precedence and Security

Remember that IP (both IPv4 and IPv6) is an unreliable protocol on top of which TCP rides

Answer 2

• Assume a sender / server connected to its local network at 10Gbps.
• Assume 10Gbit/s networking from the sender to the WAN Edge router of it's datacenter.
• Assume a WAN Edge Router with 10Gbps on the datacenter side and multiple WAN circuits of 100Mbps each.
• Assume a WAN Router at one of the spoke sites, with 100Mbps WAN and 1Gbps LAN connectivity.
• Assume the receiver being connected to that spoke site LAN with 1Gbit/s.

Being initiator and receiver, a client system at a spoke site requests to download a file from a server at the datacenter.

The server, being responder and sender, will quickly start to blast away at 10Gbps. The WAN Edge router will instantly fill up its egress queue/buffer to the WAN circuit, and tail-dropping will start.

If the sender won't throttle it's sending rate, the WAN router will continue to be tail dropping at an insane rate, effectivley DoS'ing the WAN circuit, for ALL users at the other end of the given 100Mbps circuit.

What's more - if the network path from sender to receiver is likely to be dropping >90% of all packets, the sender will have to keep a LOT more of the data to be sent (and possibly re-sent) in a buffer, further increasing the system ressources demands on the server/sender side (... large scale buffering for potentially 100s of client/receivers).

That's why there is flow control/congestion avoidance in TCP, so the sender has a metric to estimate the allowable sending rate individually per receiver, and it can throttle down to a level where the rate of missing ACKs and retransmissions becomes marginal or zero.

This also ensures some degree of fairness for other data flows competing for bandwidth across a narrow link.

Answer 3

Actually this is not only a theoretical question. There were (are?) problems with BBR alghorithm which was too aggressive and was taking over streams with "classic" congestion mitigation mechanisms (like Cubic), apparently something like described here. AFAIR this was the reason for BBRv2 adjustments.

In such situation (abusive pacing) one stream takes over the entire bandwidth with some unfair ratio (depending on "aggaressiveness"), so other services run degraded, except for the abusive stream itself.

So if you ask for no flow+congestion avoidance at all: this will break every transmission (including own) on every link that gets overflown - after (during) jamming other streams it will inevitably make itself overflow too.

As noted by Ron Maupin in the comment below, this answer is about congestion, not flow control; however, since flow control handles entire end-to-end communication, while congestion considers the network capacity, it's obvious that flow control is irrelevant if the network (well, just include endpoints as parts of it) is not capable of delivering packets.

Thus the answer would be more complicated:

1. if you only want to disable (make it ineffective in practice, anyhow) flow control, you could observe higher network utilization and packet drops, but no other effects - since the congestion avoidance might (like BBR) use the dropped packet metric to slow down sending, or much different issues depending on congestion control used by the sender; in particular, if sender doesn't use drop-resilient CC the stream would be unstable or even stall,
2. if you meant disabling every stream speed control knobs (i.e. both, flow and congestion control) - the effects would be like described above, similar to UDP flood.

In short: disabled flow control (window big enough to be practically infinite) will cause excessive traffic and packet drops [but the transmission itself could be (depending on congestion control metrics used) intact; after all, every drop should be retransmitted, or expose direct effects of packet drops itself.]

As for the 2nd comment - yes, that distinction is crucial. Flow control being proactive (and declarative: "how much can(not) I take"), while congestion control retroactive (and using "hidden variables" like drop rate or RTT). In order to completely break the TCP one has to inactivate both of them, i.e. make the abusive change at least on sending side (aggressive/non congestion and ignoring flow control parameters by setting and keeping huge window); receiving party cannot exploit flow control to request unfair share of the bandwidth.

In a very simplified form one could say that while congestion control is about fairness, the flow control is about dropless. And to be honest ...both of them were failing on their job. Flow control cannot prevent random drops generated in dynamic environments (like wireless), while all the classic and even the modern CC algorithms didn't cope well in general sense "fairness". One might even say that TCP is obsoleted and such statement is also truish. These (and many others) shortcomings were addressed in QUIC protocol which were implemented in web browsers to overcome long release cycles of dominating operating systems. Fixing the TCP to catch up with modern world involved BBR - it is drop resilient and has fast convergence (dynamic, adaptiveness). And since v2 is not overwhelming against other streams and has it's own TCP pacing, so doesn't require FqCoDeL qdisc on L2 interface. This is how different elements of calculating stream desired speed are intertwining now.

As for the "extra complexity" of sliding window - in any asynchronous variable-length packet transmission protocol you need some kind of buffer management anyway. Building it in a way that can expose the available window space is some extra effort, but it's not like you could ditch this thing entirely.

Also, remember that TCP was designed decades ago and what you consider "some little overhead" currently was a really huge and unacceptable loss in times, where available bandwidths were orders of magnitude slower than today. Back then, without advanced congestion control, drop ratios beyond some threshold would lead to sudden stall of the stream, so not only the tiny bandwidth would be wasted on retransmissions, but also it couldn't be effectively used. Just think about 9600 baud fixed line with about 70% maximum utilization, when 3% drop rate nukes the transmission; if such line were noisy, the TCP would simply not work over it.