Commit a87c83d5 authored Oct 16, 2018 by Neal Cardwell Committed by David S. Miller Oct 17, 2018

tcp_bbr: adjust TCP BBR for departure time pacing



Adjust TCP BBR for the new departure time pacing model in the recent
commit ab408b6d ("tcp: switch tcp and sch_fq to new earliest
departure time model").

With TSQ and pacing at lower layers, there are often several skbs
queued in the pacing layer, and thus there is less data "in the
network" than "in flight".

With departure time pacing at lower layers (e.g. fq or potential
future NICs), the data in the pacing layer now has a pre-scheduled
("baked-in") departure time that cannot be changed, even if the
congestion control algorithm decides to use a new pacing rate.

This means that there can be a non-trivial lag between when BBR makes
a pacing rate change and when the inter-skb pacing delays
change. After a pacing rate change, the number of packets in the
network can gradually evolve to be higher or lower, depending on
whether the sending rate is higher or lower than the delivery
rate. Thus ignoring this lag can cause significant overshoot, with the
flow ending up with too many or too few packets in the network.

This commit changes BBR to adapt its pacing rate based on the amount
of data in the network that it estimates has already been "baked in"
by previous departure time decisions. We estimate the number of our
packets that will be in the network at the earliest departure time
(EDT) for the next skb scheduled as:

   in_network_at_edt = inflight_at_edt - (EDT - now) * bw

If we're increasing the amount of data in the network ("in_network"),
then we want to know if the transmit of the EDT skb will push
in_network above the target, so our answer includes
bbr_tso_segs_goal() from the skb departing at EDT. If we're decreasing
in_network, then we want to know if in_network will sink too low just
before the EDT transmit, so our answer does not include the segments
from the skb departing at EDT.

Why do we treat pacing_gain > 1.0 case and pacing_gain < 1.0 case
differently? The in_network curve is a step function: in_network goes
up on transmits, and down on ACKs. To accurately predict when
in_network will go beyond our target value, this will happen on
different events, depending on whether we're concerned about
in_network potentially going too high or too low:

 o if pushing in_network up (pacing_gain > 1.0),
   then in_network goes above target upon a transmit event

 o if pushing in_network down (pacing_gain < 1.0),
   then in_network goes below target upon an ACK event

This commit changes the BBR state machine to use this estimated
"packets in network" value to make its decisions.

Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

parent cb10c7c0

net/ipv4/tcp_bbr.c

+35 −2

Original line number	Diff line number	Diff line
		@@ -369,6 +369,39 @@ static u32 bbr_target_cwnd(struct sock *sk, u32 bw, int gain)
		return cwnd;
		}

		/* With pacing at lower layers, there's often less data "in the network" than
		* "in flight". With TSQ and departure time pacing at lower layers (e.g. fq),
		* we often have several skbs queued in the pacing layer with a pre-scheduled
		* earliest departure time (EDT). BBR adapts its pacing rate based on the
		* inflight level that it estimates has already been "baked in" by previous
		* departure time decisions. We calculate a rough estimate of the number of our
		* packets that might be in the network at the earliest departure time for the
		* next skb scheduled:
		* in_network_at_edt = inflight_at_edt - (EDT - now) * bw
		* If we're increasing inflight, then we want to know if the transmit of the
		* EDT skb will push inflight above the target, so inflight_at_edt includes
		* bbr_tso_segs_goal() from the skb departing at EDT. If decreasing inflight,
		* then estimate if inflight will sink too low just before the EDT transmit.
		*/
		static u32 bbr_packets_in_net_at_edt(struct sock *sk, u32 inflight_now)
		{
		struct tcp_sock *tp = tcp_sk(sk);
		struct bbr *bbr = inet_csk_ca(sk);
		u64 now_ns, edt_ns, interval_us;
		u32 interval_delivered, inflight_at_edt;

		now_ns = tp->tcp_clock_cache;
		edt_ns = max(tp->tcp_wstamp_ns, now_ns);
		interval_us = div_u64(edt_ns - now_ns, NSEC_PER_USEC);
		interval_delivered = (u64)bbr_bw(sk) * interval_us >> BW_SCALE;
		inflight_at_edt = inflight_now;
		if (bbr->pacing_gain > BBR_UNIT) /* increasing inflight */
		inflight_at_edt += bbr_tso_segs_goal(sk); /* include EDT skb */
		if (interval_delivered >= inflight_at_edt)
		return 0;
		return inflight_at_edt - interval_delivered;
		}

		/* An optimization in BBR to reduce losses: On the first round of recovery, we
		* follow the packet conservation principle: send P packets per P packets acked.
		* After that, we slow-start and send at most 2*P packets per P packets acked.
		@@ -460,7 +493,7 @@ static bool bbr_is_next_cycle_phase(struct sock *sk,
		if (bbr->pacing_gain == BBR_UNIT)
		return is_full_length; /* just use wall clock time */

		inflight = rs->prior_in_flight; /* what was in-flight before ACK? */
		inflight = bbr_packets_in_net_at_edt(sk, rs->prior_in_flight);
		bw = bbr_max_bw(sk);

		/* A pacing_gain > 1.0 probes for bw by trying to raise inflight to at
		@@ -741,7 +774,7 @@ static void bbr_check_drain(struct sock sk, const struct rate_sample rs)
		bbr_target_cwnd(sk, bbr_max_bw(sk), BBR_UNIT);
		} /* fall through to check if in-flight is already small: */
		if (bbr->mode == BBR_DRAIN &&
		tcp_packets_in_flight(tcp_sk(sk)) <=
		bbr_packets_in_net_at_edt(sk, tcp_packets_in_flight(tcp_sk(sk))) <=
		bbr_target_cwnd(sk, bbr_max_bw(sk), BBR_UNIT))
		bbr_reset_probe_bw_mode(sk); /* we estimate queue is drained */
		}

Admin message