> On 6 Dec, 2022, at 10:57 am, Michael Welzl <[email protected]> wrote: > > I have a question. You keep saying that you use a TCP connection for every > link. That seems odd, because, if that’s all it is, then congestion control > doesn’t really do much… for CC to do something meaningful, it needs MUXing to > happen at intermediate systems, in between the sender and receiver. Else, all > one gets from TCP is reliability (is this a benefit here?) and flow control - > and then, when too many packets arrive at a node at the same time, the > app-layer - TCP buffer will become very large. This means that one would need > congestion control again - now operating over TCP input buffers instead of > network layer buffers. Hence, recursive ;-)
Flow control is enough for TCP to usefully handle a bottleneck in the control plane. Delays in delivery to the control plane result in a slower opening of the right edge of the receive window, and hence backpressure at the sender to make it reduce its send rate. That's pretty much what we want to see, rather than just blasting packets blindly at line rate. Additionally, it's not at all true that TCP congestion control has "nothing to do" in the absence of multiplexing. If a data-plane or link-layer bottleneck arises, TCP congestion control can be used to prevent excessive packet losses. I contend that retransmissions are slower than correctly pacing the traffic in the first place. - Jonathan Morton
