This Article IsCreated at 2024-01-19Last Modified at 2024-01-19Referenced as ia.www.f16

On Congestion Control

Assuming you are using blocking socket API, the backpressue is felt by blocking.

Assuming you are using io_uring, the backpressure is felt when ring buffer full.

BBR paces the send rate with observation of past delivery rate 1, but how does it know that a stream is app-limited?

I found the anwser in Linux kernel source code.

	/* Clear app limited if bubble is acked and gone. */
	if (tp->app_limited && after(tp->delivered, tp->app_limited))
		tp->app_limited = 0;
/* If a gap is detected between sends, mark the socket application-limited. */
void tcp_rate_check_app_limited(struct sock *sk)
{
	struct tcp_sock *tp = tcp_sk(sk);

	if (/* We have less than one packet to send. */
	    tp->write_seq - tp->snd_nxt < tp->mss_cache &&
	    /* Nothing in sending host's qdisc queues or NIC tx queue. */
	    sk_wmem_alloc_get(sk) < SKB_TRUESIZE(1) &&
	    /* We are not limited by CWND. */
	    tcp_packets_in_flight(tp) < tcp_snd_cwnd(tp) &&
	    /* All lost packets have been retransmitted. */
	    tp->lost_out <= tp->retrans_out)
		tp->app_limited =
			(tp->delivered + tcp_packets_in_flight(tp)) ? : 1;
}

well,,,basically,,,when nothing is in flight it’s considered app_limited,,,and if any new packet is delivered it’s no longer considered app_limited.

Isn’t it kind of weird how TCP can be paced where IP packets are not?