| blob | 91a2557942fa8533564943f1f8e8d9df4d7df141 |
1 #
2 # IP configuration
3 #
4 config IP_MULTICAST
5 bool "IP: multicasting"
6 help
7 This is code for addressing several networked computers at once,
8 enlarging your kernel by about 2 KB. You need multicasting if you
9 intend to participate in the MBONE, a high bandwidth network on top
10 of the Internet which carries audio and video broadcasts. More
11 information about the MBONE is on the WWW at
12 <http://www.savetz.com/mbone/>. For most people, it's safe to say N.
14 config IP_ADVANCED_ROUTER
15 bool "IP: advanced router"
16 ---help---
17 If you intend to run your Linux box mostly as a router, i.e. as a
18 computer that forwards and redistributes network packets, say Y; you
19 will then be presented with several options that allow more precise
20 control about the routing process.
22 The answer to this question won't directly affect the kernel:
23 answering N will just cause the configurator to skip all the
24 questions about advanced routing.
26 Note that your box can only act as a router if you enable IP
27 forwarding in your kernel; you can do that by saying Y to "/proc
28 file system support" and "Sysctl support" below and executing the
29 line
31 echo "1" > /proc/sys/net/ipv4/ip_forward
33 at boot time after the /proc file system has been mounted.
35 If you turn on IP forwarding, you should consider the rp_filter, which
36 automatically rejects incoming packets if the routing table entry
37 for their source address doesn't match the network interface they're
38 arriving on. This has security advantages because it prevents the
39 so-called IP spoofing, however it can pose problems if you use
40 asymmetric routing (packets from you to a host take a different path
41 than packets from that host to you) or if you operate a non-routing
42 host which has several IP addresses on different interfaces. To turn
43 rp_filter on use:
45 echo 1 > /proc/sys/net/ipv4/conf/<device>/rp_filter
46 or
47 echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
49 Note that some distributions enable it in startup scripts.
50 For details about rp_filter strict and loose mode read
51 <file:Documentation/networking/ip-sysctl.txt>.
53 If unsure, say N here.
55 config IP_FIB_TRIE_STATS
56 bool "FIB TRIE statistics"
57 depends on IP_ADVANCED_ROUTER
58 ---help---
59 Keep track of statistics on structure of FIB TRIE table.
60 Useful for testing and measuring TRIE performance.
62 config IP_MULTIPLE_TABLES
63 bool "IP: policy routing"
64 depends on IP_ADVANCED_ROUTER
65 select FIB_RULES
66 ---help---
67 Normally, a router decides what to do with a received packet based
68 solely on the packet's final destination address. If you say Y here,
69 the Linux router will also be able to take the packet's source
70 address into account. Furthermore, the TOS (Type-Of-Service) field
71 of the packet can be used for routing decisions as well.
73 If you are interested in this, please see the preliminary
74 documentation at <http://www.compendium.com.ar/policy-routing.txt>
75 and <ftp://post.tepkom.ru/pub/vol2/Linux/docs/advanced-routing.tex>.
76 You will need supporting software from
77 <ftp://ftp.tux.org/pub/net/ip-routing/>.
79 If unsure, say N.
81 config IP_ROUTE_MULTIPATH
82 bool "IP: equal cost multipath"
83 depends on IP_ADVANCED_ROUTER
84 help
85 Normally, the routing tables specify a single action to be taken in
86 a deterministic manner for a given packet. If you say Y here
87 however, it becomes possible to attach several actions to a packet
88 pattern, in effect specifying several alternative paths to travel
89 for those packets. The router considers all these paths to be of
90 equal "cost" and chooses one of them in a non-deterministic fashion
91 if a matching packet arrives.
93 config IP_ROUTE_VERBOSE
94 bool "IP: verbose route monitoring"
95 depends on IP_ADVANCED_ROUTER
96 help
97 If you say Y here, which is recommended, then the kernel will print
98 verbose messages regarding the routing, for example warnings about
99 received packets which look strange and could be evidence of an
100 attack or a misconfigured system somewhere. The information is
101 handled by the klogd daemon which is responsible for kernel messages
102 ("man klogd").
104 config IP_ROUTE_CLASSID
105 bool
107 config IP_PNP
108 bool "IP: kernel level autoconfiguration"
109 help
110 This enables automatic configuration of IP addresses of devices and
111 of the routing table during kernel boot, based on either information
112 supplied on the kernel command line or by BOOTP or RARP protocols.
113 You need to say Y only for diskless machines requiring network
114 access to boot (in which case you want to say Y to "Root file system
115 on NFS" as well), because all other machines configure the network
116 in their startup scripts.
118 config IP_PNP_DHCP
119 bool "IP: DHCP support"
120 depends on IP_PNP
121 ---help---
122 If you want your Linux box to mount its whole root file system (the
123 one containing the directory /) from some other computer over the
124 net via NFS and you want the IP address of your computer to be
125 discovered automatically at boot time using the DHCP protocol (a
126 special protocol designed for doing this job), say Y here. In case
127 the boot ROM of your network card was designed for booting Linux and
128 does DHCP itself, providing all necessary information on the kernel
129 command line, you can say N here.
131 If unsure, say Y. Note that if you want to use DHCP, a DHCP server
132 must be operating on your network. Read
133 <file:Documentation/filesystems/nfs/nfsroot.txt> for details.
135 config IP_PNP_BOOTP
136 bool "IP: BOOTP support"
137 depends on IP_PNP
138 ---help---
139 If you want your Linux box to mount its whole root file system (the
140 one containing the directory /) from some other computer over the
141 net via NFS and you want the IP address of your computer to be
142 discovered automatically at boot time using the BOOTP protocol (a
143 special protocol designed for doing this job), say Y here. In case
144 the boot ROM of your network card was designed for booting Linux and
145 does BOOTP itself, providing all necessary information on the kernel
146 command line, you can say N here. If unsure, say Y. Note that if you
147 want to use BOOTP, a BOOTP server must be operating on your network.
148 Read <file:Documentation/filesystems/nfs/nfsroot.txt> for details.
150 config IP_PNP_RARP
151 bool "IP: RARP support"
152 depends on IP_PNP
153 help
154 If you want your Linux box to mount its whole root file system (the
155 one containing the directory /) from some other computer over the
156 net via NFS and you want the IP address of your computer to be
157 discovered automatically at boot time using the RARP protocol (an
158 older protocol which is being obsoleted by BOOTP and DHCP), say Y
159 here. Note that if you want to use RARP, a RARP server must be
160 operating on your network. Read
161 <file:Documentation/filesystems/nfs/nfsroot.txt> for details.
163 config NET_IPIP
164 tristate "IP: tunneling"
165 select INET_TUNNEL
166 select NET_IP_TUNNEL
167 ---help---
168 Tunneling means encapsulating data of one protocol type within
169 another protocol and sending it over a channel that understands the
170 encapsulating protocol. This particular tunneling driver implements
171 encapsulation of IP within IP, which sounds kind of pointless, but
172 can be useful if you want to make your (or some other) machine
173 appear on a different network than it physically is, or to use
174 mobile-IP facilities (allowing laptops to seamlessly move between
175 networks without changing their IP addresses).
177 Saying Y to this option will produce two modules ( = code which can
178 be inserted in and removed from the running kernel whenever you
179 want). Most people won't need this and can say N.
181 config NET_IPGRE_DEMUX
182 tristate "IP: GRE demultiplexer"
183 help
184 This is helper module to demultiplex GRE packets on GRE version field criteria.
185 Required by ip_gre and pptp modules.
187 config NET_IP_TUNNEL
188 tristate
189 select DST_CACHE
190 select GRO_CELLS
191 default n
193 config NET_IPGRE
194 tristate "IP: GRE tunnels over IP"
195 depends on (IPV6 || IPV6=n) && NET_IPGRE_DEMUX
196 select NET_IP_TUNNEL
197 help
198 Tunneling means encapsulating data of one protocol type within
199 another protocol and sending it over a channel that understands the
200 encapsulating protocol. This particular tunneling driver implements
201 GRE (Generic Routing Encapsulation) and at this time allows
202 encapsulating of IPv4 or IPv6 over existing IPv4 infrastructure.
203 This driver is useful if the other endpoint is a Cisco router: Cisco
204 likes GRE much better than the other Linux tunneling driver ("IP
205 tunneling" above). In addition, GRE allows multicast redistribution
206 through the tunnel.
208 config NET_IPGRE_BROADCAST
209 bool "IP: broadcast GRE over IP"
210 depends on IP_MULTICAST && NET_IPGRE
211 help
212 One application of GRE/IP is to construct a broadcast WAN (Wide Area
213 Network), which looks like a normal Ethernet LAN (Local Area
214 Network), but can be distributed all over the Internet. If you want
215 to do that, say Y here and to "IP multicast routing" below.
217 config IP_MROUTE
218 bool "IP: multicast routing"
219 depends on IP_MULTICAST
220 help
221 This is used if you want your machine to act as a router for IP
222 packets that have several destination addresses. It is needed on the
223 MBONE, a high bandwidth network on top of the Internet which carries
224 audio and video broadcasts. In order to do that, you would most
225 likely run the program mrouted. If you haven't heard about it, you
226 don't need it.
228 config IP_MROUTE_MULTIPLE_TABLES
229 bool "IP: multicast policy routing"
230 depends on IP_MROUTE && IP_ADVANCED_ROUTER
231 select FIB_RULES
232 help
233 Normally, a multicast router runs a userspace daemon and decides
234 what to do with a multicast packet based on the source and
235 destination addresses. If you say Y here, the multicast router
236 will also be able to take interfaces and packet marks into
237 account and run multiple instances of userspace daemons
238 simultaneously, each one handling a single table.
240 If unsure, say N.
242 config IP_PIMSM_V1
243 bool "IP: PIM-SM version 1 support"
244 depends on IP_MROUTE
245 help
246 Kernel side support for Sparse Mode PIM (Protocol Independent
247 Multicast) version 1. This multicast routing protocol is used widely
248 because Cisco supports it. You need special software to use it
249 (pimd-v1). Please see <http://netweb.usc.edu/pim/> for more
250 information about PIM.
252 Say Y if you want to use PIM-SM v1. Note that you can say N here if
253 you just want to use Dense Mode PIM.
255 config IP_PIMSM_V2
256 bool "IP: PIM-SM version 2 support"
257 depends on IP_MROUTE
258 help
259 Kernel side support for Sparse Mode PIM version 2. In order to use
260 this, you need an experimental routing daemon supporting it (pimd or
261 gated-5). This routing protocol is not used widely, so say N unless
262 you want to play with it.
264 config SYN_COOKIES
265 bool "IP: TCP syncookie support"
266 ---help---
267 Normal TCP/IP networking is open to an attack known as "SYN
268 flooding". This denial-of-service attack prevents legitimate remote
269 users from being able to connect to your computer during an ongoing
270 attack and requires very little work from the attacker, who can
271 operate from anywhere on the Internet.
273 SYN cookies provide protection against this type of attack. If you
274 say Y here, the TCP/IP stack will use a cryptographic challenge
275 protocol known as "SYN cookies" to enable legitimate users to
276 continue to connect, even when your machine is under attack. There
277 is no need for the legitimate users to change their TCP/IP software;
278 SYN cookies work transparently to them. For technical information
279 about SYN cookies, check out <http://cr.yp.to/syncookies.html>.
281 If you are SYN flooded, the source address reported by the kernel is
282 likely to have been forged by the attacker; it is only reported as
283 an aid in tracing the packets to their actual source and should not
284 be taken as absolute truth.
286 SYN cookies may prevent correct error reporting on clients when the
287 server is really overloaded. If this happens frequently better turn
288 them off.
290 If you say Y here, you can disable SYN cookies at run time by
291 saying Y to "/proc file system support" and
292 "Sysctl support" below and executing the command
294 echo 0 > /proc/sys/net/ipv4/tcp_syncookies
296 after the /proc file system has been mounted.
298 If unsure, say N.
300 config NET_IPVTI
301 tristate "Virtual (secure) IP: tunneling"
302 select INET_TUNNEL
303 select NET_IP_TUNNEL
304 depends on INET_XFRM_MODE_TUNNEL
305 ---help---
306 Tunneling means encapsulating data of one protocol type within
307 another protocol and sending it over a channel that understands the
308 encapsulating protocol. This can be used with xfrm mode tunnel to give
309 the notion of a secure tunnel for IPSEC and then use routing protocol
310 on top.
312 config NET_UDP_TUNNEL
313 tristate
314 select NET_IP_TUNNEL
315 default n
317 config NET_FOU
318 tristate "IP: Foo (IP protocols) over UDP"
319 select XFRM
320 select NET_UDP_TUNNEL
321 ---help---
322 Foo over UDP allows any IP protocol to be directly encapsulated
323 over UDP include tunnels (IPIP, GRE, SIT). By encapsulating in UDP
324 network mechanisms and optimizations for UDP (such as ECMP
325 and RSS) can be leveraged to provide better service.
327 config NET_FOU_IP_TUNNELS
328 bool "IP: FOU encapsulation of IP tunnels"
329 depends on NET_IPIP || NET_IPGRE || IPV6_SIT
330 select NET_FOU
331 ---help---
332 Allow configuration of FOU or GUE encapsulation for IP tunnels.
333 When this option is enabled IP tunnels can be configured to use
334 FOU or GUE encapsulation.
336 config INET_AH
337 tristate "IP: AH transformation"
338 select XFRM_ALGO
339 select CRYPTO
340 select CRYPTO_HMAC
341 select CRYPTO_MD5
342 select CRYPTO_SHA1
343 ---help---
344 Support for IPsec AH.
346 If unsure, say Y.
348 config INET_ESP
349 tristate "IP: ESP transformation"
350 select XFRM_ALGO
351 select CRYPTO
352 select CRYPTO_AUTHENC
353 select CRYPTO_HMAC
354 select CRYPTO_MD5
355 select CRYPTO_CBC
356 select CRYPTO_SHA1
357 select CRYPTO_DES
358 select CRYPTO_ECHAINIV
359 ---help---
360 Support for IPsec ESP.
362 If unsure, say Y.
364 config INET_ESP_OFFLOAD
365 tristate "IP: ESP transformation offload"
366 depends on INET_ESP
367 select XFRM_OFFLOAD
368 default n
369 ---help---
370 Support for ESP transformation offload. This makes sense
371 only if this system really does IPsec and want to do it
372 with high throughput. A typical desktop system does not
373 need it, even if it does IPsec.
375 If unsure, say N.
377 config INET_IPCOMP
378 tristate "IP: IPComp transformation"
379 select INET_XFRM_TUNNEL
380 select XFRM_IPCOMP
381 ---help---
382 Support for IP Payload Compression Protocol (IPComp) (RFC3173),
383 typically needed for IPsec.
385 If unsure, say Y.
387 config INET_XFRM_TUNNEL
388 tristate
389 select INET_TUNNEL
390 default n
392 config INET_TUNNEL
393 tristate
394 default n
396 config INET_XFRM_MODE_TRANSPORT
397 tristate "IP: IPsec transport mode"
398 default y
399 select XFRM
400 ---help---
401 Support for IPsec transport mode.
403 If unsure, say Y.
405 config INET_XFRM_MODE_TUNNEL
406 tristate "IP: IPsec tunnel mode"
407 default y
408 select XFRM
409 ---help---
410 Support for IPsec tunnel mode.
412 If unsure, say Y.
414 config INET_XFRM_MODE_BEET
415 tristate "IP: IPsec BEET mode"
416 default y
417 select XFRM
418 ---help---
419 Support for IPsec BEET mode.
421 If unsure, say Y.
423 config INET_DIAG
424 tristate "INET: socket monitoring interface"
425 default y
426 ---help---
427 Support for INET (TCP, DCCP, etc) socket monitoring interface used by
428 native Linux tools such as ss. ss is included in iproute2, currently
429 downloadable at:
431 http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2
433 If unsure, say Y.
435 config INET_TCP_DIAG
436 depends on INET_DIAG
437 def_tristate INET_DIAG
439 config INET_UDP_DIAG
440 tristate "UDP: socket monitoring interface"
441 depends on INET_DIAG && (IPV6 || IPV6=n)
442 default n
443 ---help---
444 Support for UDP socket monitoring interface used by the ss tool.
445 If unsure, say Y.
447 config INET_RAW_DIAG
448 tristate "RAW: socket monitoring interface"
449 depends on INET_DIAG && (IPV6 || IPV6=n)
450 default n
451 ---help---
452 Support for RAW socket monitoring interface used by the ss tool.
453 If unsure, say Y.
455 config INET_DIAG_DESTROY
456 bool "INET: allow privileged process to administratively close sockets"
457 depends on INET_DIAG
458 default n
459 ---help---
460 Provides a SOCK_DESTROY operation that allows privileged processes
461 (e.g., a connection manager or a network administration tool such as
462 ss) to close sockets opened by other processes. Closing a socket in
463 this way interrupts any blocking read/write/connect operations on
464 the socket and causes future socket calls to behave as if the socket
465 had been disconnected.
466 If unsure, say N.
468 menuconfig TCP_CONG_ADVANCED
469 bool "TCP: advanced congestion control"
470 ---help---
471 Support for selection of various TCP congestion control
472 modules.
474 Nearly all users can safely say no here, and a safe default
475 selection will be made (CUBIC with new Reno as a fallback).
477 If unsure, say N.
479 if TCP_CONG_ADVANCED
481 config TCP_CONG_BIC
482 tristate "Binary Increase Congestion (BIC) control"
483 default m
484 ---help---
485 BIC-TCP is a sender-side only change that ensures a linear RTT
486 fairness under large windows while offering both scalability and
487 bounded TCP-friendliness. The protocol combines two schemes
488 called additive increase and binary search increase. When the
489 congestion window is large, additive increase with a large
490 increment ensures linear RTT fairness as well as good
491 scalability. Under small congestion windows, binary search
492 increase provides TCP friendliness.
493 See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/
495 config TCP_CONG_CUBIC
496 tristate "CUBIC TCP"
497 default y
498 ---help---
499 This is version 2.0 of BIC-TCP which uses a cubic growth function
500 among other techniques.
501 See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/cubic-paper.pdf
503 config TCP_CONG_WESTWOOD
504 tristate "TCP Westwood+"
505 default m
506 ---help---
507 TCP Westwood+ is a sender-side only modification of the TCP Reno
508 protocol stack that optimizes the performance of TCP congestion
509 control. It is based on end-to-end bandwidth estimation to set
510 congestion window and slow start threshold after a congestion
511 episode. Using this estimation, TCP Westwood+ adaptively sets a
512 slow start threshold and a congestion window which takes into
513 account the bandwidth used at the time congestion is experienced.
514 TCP Westwood+ significantly increases fairness wrt TCP Reno in
515 wired networks and throughput over wireless links.
517 config TCP_CONG_HTCP
518 tristate "H-TCP"
519 default m
520 ---help---
521 H-TCP is a send-side only modifications of the TCP Reno
522 protocol stack that optimizes the performance of TCP
523 congestion control for high speed network links. It uses a
524 modeswitch to change the alpha and beta parameters of TCP Reno
525 based on network conditions and in a way so as to be fair with
526 other Reno and H-TCP flows.
528 config TCP_CONG_HSTCP
529 tristate "High Speed TCP"
530 default n
531 ---help---
532 Sally Floyd's High Speed TCP (RFC 3649) congestion control.
533 A modification to TCP's congestion control mechanism for use
534 with large congestion windows. A table indicates how much to
535 increase the congestion window by when an ACK is received.
536 For more detail see http://www.icir.org/floyd/hstcp.html
538 config TCP_CONG_HYBLA
539 tristate "TCP-Hybla congestion control algorithm"
540 default n
541 ---help---
542 TCP-Hybla is a sender-side only change that eliminates penalization of
543 long-RTT, large-bandwidth connections, like when satellite legs are
544 involved, especially when sharing a common bottleneck with normal
545 terrestrial connections.
547 config TCP_CONG_VEGAS
548 tristate "TCP Vegas"
549 default n
550 ---help---
551 TCP Vegas is a sender-side only change to TCP that anticipates
552 the onset of congestion by estimating the bandwidth. TCP Vegas
553 adjusts the sending rate by modifying the congestion
554 window. TCP Vegas should provide less packet loss, but it is
555 not as aggressive as TCP Reno.
557 config TCP_CONG_NV
558 tristate "TCP NV"
559 default n
560 ---help---
561 TCP NV is a follow up to TCP Vegas. It has been modified to deal with
562 10G networks, measurement noise introduced by LRO, GRO and interrupt
563 coalescence. In addition, it will decrease its cwnd multiplicatively
564 instead of linearly.
566 Note that in general congestion avoidance (cwnd decreased when # packets
567 queued grows) cannot coexist with congestion control (cwnd decreased only
568 when there is packet loss) due to fairness issues. One scenario when they
569 can coexist safely is when the CA flows have RTTs << CC flows RTTs.
571 For further details see http://www.brakmo.org/networking/tcp-nv/
573 config TCP_CONG_SCALABLE
574 tristate "Scalable TCP"
575 default n
576 ---help---
577 Scalable TCP is a sender-side only change to TCP which uses a
578 MIMD congestion control algorithm which has some nice scaling
579 properties, though is known to have fairness issues.
580 See http://www.deneholme.net/tom/scalable/
582 config TCP_CONG_LP
583 tristate "TCP Low Priority"
584 default n
585 ---help---
586 TCP Low Priority (TCP-LP), a distributed algorithm whose goal is
587 to utilize only the excess network bandwidth as compared to the
588 ``fair share`` of bandwidth as targeted by TCP.
589 See http://www-ece.rice.edu/networks/TCP-LP/
591 config TCP_CONG_VENO
592 tristate "TCP Veno"
593 default n
594 ---help---
595 TCP Veno is a sender-side only enhancement of TCP to obtain better
596 throughput over wireless networks. TCP Veno makes use of state
597 distinguishing to circumvent the difficult judgment of the packet loss
598 type. TCP Veno cuts down less congestion window in response to random
599 loss packets.
600 See <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1177186>
602 config TCP_CONG_YEAH
603 tristate "YeAH TCP"
604 select TCP_CONG_VEGAS
605 default n
606 ---help---
607 YeAH-TCP is a sender-side high-speed enabled TCP congestion control
608 algorithm, which uses a mixed loss/delay approach to compute the
609 congestion window. It's design goals target high efficiency,
610 internal, RTT and Reno fairness, resilience to link loss while
611 keeping network elements load as low as possible.
613 For further details look here:
614 http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf
616 config TCP_CONG_ILLINOIS
617 tristate "TCP Illinois"
618 default n
619 ---help---
620 TCP-Illinois is a sender-side modification of TCP Reno for
621 high speed long delay links. It uses round-trip-time to
622 adjust the alpha and beta parameters to achieve a higher average
623 throughput and maintain fairness.
625 For further details see:
626 http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
628 config TCP_CONG_DCTCP
629 tristate "DataCenter TCP (DCTCP)"
630 default n
631 ---help---
632 DCTCP leverages Explicit Congestion Notification (ECN) in the network to
633 provide multi-bit feedback to the end hosts. It is designed to provide:
635 - High burst tolerance (incast due to partition/aggregate),
636 - Low latency (short flows, queries),
637 - High throughput (continuous data updates, large file transfers) with
638 commodity, shallow-buffered switches.
640 All switches in the data center network running DCTCP must support
641 ECN marking and be configured for marking when reaching defined switch
642 buffer thresholds. The default ECN marking threshold heuristic for
643 DCTCP on switches is 20 packets (30KB) at 1Gbps, and 65 packets
644 (~100KB) at 10Gbps, but might need further careful tweaking.
646 For further details see:
647 http://simula.stanford.edu/~alizade/Site/DCTCP_files/dctcp-final.pdf
649 config TCP_CONG_CDG
650 tristate "CAIA Delay-Gradient (CDG)"
651 default n
652 ---help---
653 CAIA Delay-Gradient (CDG) is a TCP congestion control that modifies
654 the TCP sender in order to:
656 o Use the delay gradient as a congestion signal.
657 o Back off with an average probability that is independent of the RTT.
658 o Coexist with flows that use loss-based congestion control.
659 o Tolerate packet loss unrelated to congestion.
661 For further details see:
662 D.A. Hayes and G. Armitage. "Revisiting TCP congestion control using
663 delay gradients." In Networking 2011. Preprint: http://goo.gl/No3vdg
665 config TCP_CONG_BBR
666 tristate "BBR TCP"
667 default n
668 ---help---
670 BBR (Bottleneck Bandwidth and RTT) TCP congestion control aims to
671 maximize network utilization and minimize queues. It builds an explicit
672 model of the the bottleneck delivery rate and path round-trip
673 propagation delay. It tolerates packet loss and delay unrelated to
674 congestion. It can operate over LAN, WAN, cellular, wifi, or cable
675 modem links. It can coexist with flows that use loss-based congestion
676 control, and can operate with shallow buffers, deep buffers,
677 bufferbloat, policers, or AQM schemes that do not provide a delay
678 signal. It requires the fq ("Fair Queue") pacing packet scheduler.
680 choice
681 prompt "Default TCP congestion control"
682 default DEFAULT_CUBIC
683 help
684 Select the TCP congestion control that will be used by default
685 for all connections.
687 config DEFAULT_BIC
688 bool "Bic" if TCP_CONG_BIC=y
690 config DEFAULT_CUBIC
691 bool "Cubic" if TCP_CONG_CUBIC=y
693 config DEFAULT_HTCP
694 bool "Htcp" if TCP_CONG_HTCP=y
696 config DEFAULT_HYBLA
697 bool "Hybla" if TCP_CONG_HYBLA=y
699 config DEFAULT_VEGAS
700 bool "Vegas" if TCP_CONG_VEGAS=y
702 config DEFAULT_VENO
703 bool "Veno" if TCP_CONG_VENO=y
705 config DEFAULT_WESTWOOD
706 bool "Westwood" if TCP_CONG_WESTWOOD=y
708 config DEFAULT_DCTCP
709 bool "DCTCP" if TCP_CONG_DCTCP=y
711 config DEFAULT_CDG
712 bool "CDG" if TCP_CONG_CDG=y
714 config DEFAULT_BBR
715 bool "BBR" if TCP_CONG_BBR=y
717 config DEFAULT_RENO
718 bool "Reno"
719 endchoice
721 endif
723 config TCP_CONG_CUBIC
724 tristate
725 depends on !TCP_CONG_ADVANCED
726 default y
728 config DEFAULT_TCP_CONG
729 string
730 default "bic" if DEFAULT_BIC
731 default "cubic" if DEFAULT_CUBIC
732 default "htcp" if DEFAULT_HTCP
733 default "hybla" if DEFAULT_HYBLA
734 default "vegas" if DEFAULT_VEGAS
735 default "westwood" if DEFAULT_WESTWOOD
736 default "veno" if DEFAULT_VENO
737 default "reno" if DEFAULT_RENO
738 default "dctcp" if DEFAULT_DCTCP
739 default "cdg" if DEFAULT_CDG
740 default "bbr" if DEFAULT_BBR
741 default "cubic"
743 config TCP_MD5SIG
744 bool "TCP: MD5 Signature Option support (RFC2385)"
745 select CRYPTO
746 select CRYPTO_MD5
747 ---help---
748 RFC2385 specifies a method of giving MD5 protection to TCP sessions.
749 Its main (only?) use is to protect BGP sessions between core routers
750 on the Internet.
752 If unsure, say N.