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