mirror of
https://github.com/rd-stuffs/msm-4.14.git
synced 2025-02-20 11:45:48 +08:00
d39d810ccf
BBR v2 is an enhacement to the BBR v1 algorithm. It's designed to aim for lower
queues, lower loss, and better Reno/CUBIC coexistence than BBR v1.
BBR v2 maintains the core of BBR v1: an explicit model of the network path that
is two-dimensional, adapting to estimate the (a) maximum available bandwidth
and (b) maximum safe volume of data a flow can keep in-flight in the
network. It mains the estimated BDP as a core guide for estimating an
appropriate level of in-flight data.
BBR v2 makes several key enhancements:
o Its bandwidth-probing time scale is adapted, within bounds, to allow improved
coexistence with Reno and CUBIC. The bandwidth-probing time scale is (a)
extended dynamically based on estimated BDP to improve coexistence with
Reno/CUBIC; (b) bounded by an interactive wall-clock time-scale to be more
scalable and responsive than Reno and CUBIC.
o Rather than being largely agnostic to loss and ECN marks, it explicitly uses
loss and (DCTCP-style) ECN signals to maintain its model.
o It aims for lower losses than v1 by adjusting its model to attempt to stay
within loss rate and ECN mark rate bounds (loss_thresh and ecn_thresh,
respectively).
o It adapts to loss/ECN signals even when the application is running out of
data ("application-limited"), in case the "application-limited" flow is also
"network-limited" (the bw and/or inflight available to this flow is lower than
previously estimated when the flow ran out of data).
o It has a three-part model: the model explicit three tracks operating points,
where an operating point is a tuple: (bandwidth, inflight). The three operating
points are:
o latest: the latest measurement from the current round trip
o upper bound: robust, optimistic, long-term upper bound
o lower bound: robust, conservative, short-term lower bound
These are stored in the following state variables:
o latest: bw_latest, inflight_latest
o lo: bw_lo, inflight_lo
o hi: bw_hi[2], inflight_hi
To gain intuition about the meaning of the three operating points, it
may help to consider the analogs in CUBIC, which has a somewhat
analogous three-part model used by its probing state machine:
BBR param CUBIC param
----------- -------------
latest ~ cwnd
lo ~ ssthresh
hi ~ last_max_cwnd
The analogy is only a loose one, though, since the BBR operating
points are calculated differently, and are 2-dimensional (bw,inflight)
rather than CUBIC's one-dimensional notion of operating point
(inflight).
o It uses the three-part model to adapt the magnitude of its bandwidth
to match the estimated space available in the buffer, rather than (as
in BBR v1) assuming that it was always acceptable to place 0.25*BDP in
the bottleneck buffer when probing (commodity datacenter switches
commonly do not have that much buffer for WAN flows). When BBR v2
estimates it hit a buffer limit during probing, its bandwidth probing
then starts gently in case little space is still available in the
buffer, and the accelerates, slowly at first and then rapidly if it
can grow inflight without seeing congestion signals. In such cases,
probing is bounded by inflight_hi + inflight_probe, where
inflight_probe grows as: [0, 1, 2, 4, 8, 16,...]. This allows BBR to
keep losses low and bounded if a bottleneck remains congested, while
rapidly/scalably utilizing free bandwidth when it becomes available.
o It has a slightly revised state machine, to achieve the goals above.
BBR_BW_PROBE_UP: pushes up inflight to probe for bw/vol
BBR_BW_PROBE_DOWN: drain excess inflight from the queue
BBR_BW_PROBE_CRUISE: use pipe, w/ headroom in queue/pipe
BBR_BW_PROBE_REFILL: try refill the pipe again to 100%, leaving queue empty
o The estimated BDP: BBR v2 continues to maintain an estimate of the
path's two-way propagation delay, by tracking a windowed min_rtt, and
coordinating (on an as-ndeeded basis) to try to expose the two-way
propagation delay by draining the bottleneck queue.
BBR v2 continues to use its min_rtt and (currently-applicable) bandwidth
estimate to estimate the current bandwidth-delay product. The estimated BDP
still provides one important guideline for bounding inflight data. However,
because any min-filtered RTT and max-filtered bw inherently tend to both
overestimate, the estimated BDP is often too high; in this case loss or ECN
marks can ensue, in which case BBR v2 adjusts inflight_hi and inflight_lo to
adapt its sending rate and inflight down to match the available capacity of the
path.
o Space: Note that ICSK_CA_PRIV_SIZE increased. This is because BBR v2
adds 17 more u32 to struct bbr. However, there are 11 u32 fields from
BBR v1 that we can remove after switching to BBR v2:
struct minmax bw; /* Max recent delivery rate in pkts/uS << 24 */
u32 rtt_cnt; /* count of packet-timed rounds elapsed */
...
packet_conservation:1, /* use packet conservation? */
...
lt_is_sampling:1, /* taking long-term ("LT") samples now? */
lt_rtt_cnt:7, /* round trips in long-term interval */
lt_use_bw:1; /* use lt_bw as our bw estimate? */
u32 lt_bw; /* LT est delivery rate in pkts/uS << 24 */
u32 lt_last_delivered; /* LT intvl start: tp->delivered */
u32 lt_last_stamp; /* LT intvl start: tp->delivered_mstamp */
u32 lt_last_lost; /* LT intvl start: tp->lost */
So ultimately BBR v2 uses 17-11 = 6 more u32 fields than v1.
o Code: BBR v2 reuses many pieces from BBR v1. But it omits the following
significant pieces:
o "packet conservation" (bbr_set_cwnd_to_recover_or_restore(),
bbr_can_grow_inflight())
o long-term bandwidth estimator ("policer mode")
The code layout tries to keep BBR v2 code near the bottom of the
file, so that v1-applicable code in the top does not accidentally
refer to v2 code.
o Docs:
See the following docs for more details and diagrams decsribing the BBR v2
algorithm:
https://datatracker.ietf.org/meeting/104/materials/slides-104-iccrg-an-update-on-bbr-00
https://datatracker.ietf.org/meeting/102/materials/slides-102-iccrg-an-update-on-bbr-work-at-google-00
o Internal notes:
For this upstream rebase, Neal started from:
git show 6f6734c1c3c4:net/ipv4/tcp_bbr.c > net/ipv4/tcp_bbr.c
then removed dev instrumentation (dynamic get/set for parameters)
and code that was only used by BBRv1
Effort: net-tcp_bbr
Origin-9xx-SHA1: 2c84098e60bed6d67dde23cd7538c51dee273102
Change-Id: I125cf26ba2a7a686f2fa5e87f4c2afceb65f7a05
(cherry-picked from 90e22aa359)
[kdrag0n: Backported to k4.14 by removing reord_seen from bbr_debug's
output as it's not mandatory and 4.14 doesn't have it]
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: azrim <mirzaspc@gmail.com>
68 lines
2.7 KiB
Makefile
68 lines
2.7 KiB
Makefile
# SPDX-License-Identifier: GPL-2.0
|
|
#
|
|
# Makefile for the Linux TCP/IP (INET) layer.
|
|
#
|
|
|
|
obj-y := route.o inetpeer.o protocol.o \
|
|
ip_input.o ip_fragment.o ip_forward.o ip_options.o \
|
|
ip_output.o ip_sockglue.o inet_hashtables.o \
|
|
inet_timewait_sock.o inet_connection_sock.o \
|
|
tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o \
|
|
tcp_minisocks.o tcp_cong.o tcp_metrics.o tcp_fastopen.o \
|
|
tcp_rate.o tcp_recovery.o tcp_ulp.o \
|
|
tcp_offload.o datagram.o raw.o udp.o udplite.o \
|
|
udp_offload.o arp.o icmp.o devinet.o af_inet.o igmp.o \
|
|
fib_frontend.o fib_semantics.o fib_trie.o fib_notifier.o \
|
|
inet_fragment.o ping.o ip_tunnel_core.o gre_offload.o
|
|
|
|
obj-$(CONFIG_NET_IP_TUNNEL) += ip_tunnel.o
|
|
obj-$(CONFIG_SYSCTL) += sysctl_net_ipv4.o
|
|
obj-$(CONFIG_PROC_FS) += proc.o
|
|
obj-$(CONFIG_IP_MULTIPLE_TABLES) += fib_rules.o
|
|
obj-$(CONFIG_IP_MROUTE) += ipmr.o
|
|
obj-$(CONFIG_NET_IPIP) += ipip.o
|
|
gre-y := gre_demux.o
|
|
obj-$(CONFIG_NET_FOU) += fou.o
|
|
obj-$(CONFIG_NET_IPGRE_DEMUX) += gre.o
|
|
obj-$(CONFIG_NET_IPGRE) += ip_gre.o
|
|
obj-$(CONFIG_NET_UDP_TUNNEL) += udp_tunnel.o
|
|
obj-$(CONFIG_NET_IPVTI) += ip_vti.o
|
|
obj-$(CONFIG_SYN_COOKIES) += syncookies.o
|
|
obj-$(CONFIG_INET_AH) += ah4.o
|
|
obj-$(CONFIG_INET_ESP) += esp4.o
|
|
obj-$(CONFIG_INET_ESP_OFFLOAD) += esp4_offload.o
|
|
obj-$(CONFIG_INET_IPCOMP) += ipcomp.o
|
|
obj-$(CONFIG_INET_XFRM_TUNNEL) += xfrm4_tunnel.o
|
|
obj-$(CONFIG_INET_XFRM_MODE_BEET) += xfrm4_mode_beet.o
|
|
obj-$(CONFIG_INET_TUNNEL) += tunnel4.o
|
|
obj-$(CONFIG_INET_XFRM_MODE_TRANSPORT) += xfrm4_mode_transport.o
|
|
obj-$(CONFIG_INET_XFRM_MODE_TUNNEL) += xfrm4_mode_tunnel.o
|
|
obj-$(CONFIG_IP_PNP) += ipconfig.o
|
|
obj-$(CONFIG_NETFILTER) += netfilter.o netfilter/
|
|
obj-$(CONFIG_INET_DIAG) += inet_diag.o
|
|
obj-$(CONFIG_INET_TCP_DIAG) += tcp_diag.o
|
|
obj-$(CONFIG_INET_UDP_DIAG) += udp_diag.o
|
|
obj-$(CONFIG_INET_RAW_DIAG) += raw_diag.o
|
|
obj-$(CONFIG_NET_TCPPROBE) += tcp_probe.o
|
|
obj-$(CONFIG_TCP_CONG_BBR) += tcp_bbr.o
|
|
obj-$(CONFIG_TCP_CONG_BBR2) += tcp_bbr2.o
|
|
obj-$(CONFIG_TCP_CONG_BIC) += tcp_bic.o
|
|
obj-$(CONFIG_TCP_CONG_CDG) += tcp_cdg.o
|
|
obj-$(CONFIG_TCP_CONG_CUBIC) += tcp_cubic.o
|
|
obj-$(CONFIG_TCP_CONG_DCTCP) += tcp_dctcp.o
|
|
obj-$(CONFIG_TCP_CONG_WESTWOOD) += tcp_westwood.o
|
|
obj-$(CONFIG_TCP_CONG_HSTCP) += tcp_highspeed.o
|
|
obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybla.o
|
|
obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o
|
|
obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o
|
|
obj-$(CONFIG_TCP_CONG_NV) += tcp_nv.o
|
|
obj-$(CONFIG_TCP_CONG_VENO) += tcp_veno.o
|
|
obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
|
|
obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o
|
|
obj-$(CONFIG_TCP_CONG_YEAH) += tcp_yeah.o
|
|
obj-$(CONFIG_TCP_CONG_ILLINOIS) += tcp_illinois.o
|
|
obj-$(CONFIG_NETLABEL) += cipso_ipv4.o
|
|
|
|
obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
|
|
xfrm4_output.o xfrm4_protocol.o
|