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_XFRM_TUNNEL
406	tristate
407	select INET_TUNNEL
408	default n
409
410config INET_TUNNEL
411	tristate
412	default n
413
414config INET_DIAG
415	tristate "INET: socket monitoring interface"
416	default y
417	help
418	  Support for INET (TCP, DCCP, etc) socket monitoring interface used by
419	  native Linux tools such as ss. ss is included in iproute2, currently
420	  downloadable at:
421
422	    http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2
423
424	  If unsure, say Y.
425
426config INET_TCP_DIAG
427	depends on INET_DIAG
428	def_tristate INET_DIAG
429
430config INET_UDP_DIAG
431	tristate "UDP: socket monitoring interface"
432	depends on INET_DIAG && (IPV6 || IPV6=n)
433	default n
434	help
435	  Support for UDP socket monitoring interface used by the ss tool.
436	  If unsure, say Y.
437
438config INET_RAW_DIAG
439	tristate "RAW: socket monitoring interface"
440	depends on INET_DIAG && (IPV6 || IPV6=n)
441	default n
442	help
443	  Support for RAW socket monitoring interface used by the ss tool.
444	  If unsure, say Y.
445
446config INET_DIAG_DESTROY
447	bool "INET: allow privileged process to administratively close sockets"
448	depends on INET_DIAG
449	default n
450	help
451	  Provides a SOCK_DESTROY operation that allows privileged processes
452	  (e.g., a connection manager or a network administration tool such as
453	  ss) to close sockets opened by other processes. Closing a socket in
454	  this way interrupts any blocking read/write/connect operations on
455	  the socket and causes future socket calls to behave as if the socket
456	  had been disconnected.
457	  If unsure, say N.
458
459menuconfig TCP_CONG_ADVANCED
460	bool "TCP: advanced congestion control"
461	help
462	  Support for selection of various TCP congestion control
463	  modules.
464
465	  Nearly all users can safely say no here, and a safe default
466	  selection will be made (CUBIC with new Reno as a fallback).
467
468	  If unsure, say N.
469
470if TCP_CONG_ADVANCED
471
472config TCP_CONG_BIC
473	tristate "Binary Increase Congestion (BIC) control"
474	default m
475	help
476	  BIC-TCP is a sender-side only change that ensures a linear RTT
477	  fairness under large windows while offering both scalability and
478	  bounded TCP-friendliness. The protocol combines two schemes
479	  called additive increase and binary search increase. When the
480	  congestion window is large, additive increase with a large
481	  increment ensures linear RTT fairness as well as good
482	  scalability. Under small congestion windows, binary search
483	  increase provides TCP friendliness.
484	  See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/
485
486config TCP_CONG_CUBIC
487	tristate "CUBIC TCP"
488	default y
489	help
490	  This is version 2.0 of BIC-TCP which uses a cubic growth function
491	  among other techniques.
492	  See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/cubic-paper.pdf
493
494config TCP_CONG_WESTWOOD
495	tristate "TCP Westwood+"
496	default m
497	help
498	  TCP Westwood+ is a sender-side only modification of the TCP Reno
499	  protocol stack that optimizes the performance of TCP congestion
500	  control. It is based on end-to-end bandwidth estimation to set
501	  congestion window and slow start threshold after a congestion
502	  episode. Using this estimation, TCP Westwood+ adaptively sets a
503	  slow start threshold and a congestion window which takes into
504	  account the bandwidth used  at the time congestion is experienced.
505	  TCP Westwood+ significantly increases fairness wrt TCP Reno in
506	  wired networks and throughput over wireless links.
507
508config TCP_CONG_HTCP
509	tristate "H-TCP"
510	default m
511	help
512	  H-TCP is a send-side only modifications of the TCP Reno
513	  protocol stack that optimizes the performance of TCP
514	  congestion control for high speed network links. It uses a
515	  modeswitch to change the alpha and beta parameters of TCP Reno
516	  based on network conditions and in a way so as to be fair with
517	  other Reno and H-TCP flows.
518
519config TCP_CONG_HSTCP
520	tristate "High Speed TCP"
521	default n
522	help
523	  Sally Floyd's High Speed TCP (RFC 3649) congestion control.
524	  A modification to TCP's congestion control mechanism for use
525	  with large congestion windows. A table indicates how much to
526	  increase the congestion window by when an ACK is received.
527	  For more detail see https://www.icir.org/floyd/hstcp.html
528
529config TCP_CONG_HYBLA
530	tristate "TCP-Hybla congestion control algorithm"
531	default n
532	help
533	  TCP-Hybla is a sender-side only change that eliminates penalization of
534	  long-RTT, large-bandwidth connections, like when satellite legs are
535	  involved, especially when sharing a common bottleneck with normal
536	  terrestrial connections.
537
538config TCP_CONG_VEGAS
539	tristate "TCP Vegas"
540	default n
541	help
542	  TCP Vegas is a sender-side only change to TCP that anticipates
543	  the onset of congestion by estimating the bandwidth. TCP Vegas
544	  adjusts the sending rate by modifying the congestion
545	  window. TCP Vegas should provide less packet loss, but it is
546	  not as aggressive as TCP Reno.
547
548config TCP_CONG_NV
549	tristate "TCP NV"
550	default n
551	help
552	  TCP NV is a follow up to TCP Vegas. It has been modified to deal with
553	  10G networks, measurement noise introduced by LRO, GRO and interrupt
554	  coalescence. In addition, it will decrease its cwnd multiplicatively
555	  instead of linearly.
556
557	  Note that in general congestion avoidance (cwnd decreased when # packets
558	  queued grows) cannot coexist with congestion control (cwnd decreased only
559	  when there is packet loss) due to fairness issues. One scenario when they
560	  can coexist safely is when the CA flows have RTTs << CC flows RTTs.
561
562	  For further details see http://www.brakmo.org/networking/tcp-nv/
563
564config TCP_CONG_SCALABLE
565	tristate "Scalable TCP"
566	default n
567	help
568	  Scalable TCP is a sender-side only change to TCP which uses a
569	  MIMD congestion control algorithm which has some nice scaling
570	  properties, though is known to have fairness issues.
571	  See http://www.deneholme.net/tom/scalable/
572
573config TCP_CONG_LP
574	tristate "TCP Low Priority"
575	default n
576	help
577	  TCP Low Priority (TCP-LP), a distributed algorithm whose goal is
578	  to utilize only the excess network bandwidth as compared to the
579	  ``fair share`` of bandwidth as targeted by TCP.
580	  See http://www-ece.rice.edu/networks/TCP-LP/
581
582config TCP_CONG_VENO
583	tristate "TCP Veno"
584	default n
585	help
586	  TCP Veno is a sender-side only enhancement of TCP to obtain better
587	  throughput over wireless networks. TCP Veno makes use of state
588	  distinguishing to circumvent the difficult judgment of the packet loss
589	  type. TCP Veno cuts down less congestion window in response to random
590	  loss packets.
591	  See <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1177186>
592
593config TCP_CONG_YEAH
594	tristate "YeAH TCP"
595	select TCP_CONG_VEGAS
596	default n
597	help
598	  YeAH-TCP is a sender-side high-speed enabled TCP congestion control
599	  algorithm, which uses a mixed loss/delay approach to compute the
600	  congestion window. It's design goals target high efficiency,
601	  internal, RTT and Reno fairness, resilience to link loss while
602	  keeping network elements load as low as possible.
603
604	  For further details look here:
605	    http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf
606
607config TCP_CONG_ILLINOIS
608	tristate "TCP Illinois"
609	default n
610	help
611	  TCP-Illinois is a sender-side modification of TCP Reno for
612	  high speed long delay links. It uses round-trip-time to
613	  adjust the alpha and beta parameters to achieve a higher average
614	  throughput and maintain fairness.
615
616	  For further details see:
617	    http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
618
619config TCP_CONG_DCTCP
620	tristate "DataCenter TCP (DCTCP)"
621	default n
622	help
623	  DCTCP leverages Explicit Congestion Notification (ECN) in the network to
624	  provide multi-bit feedback to the end hosts. It is designed to provide:
625
626	  - High burst tolerance (incast due to partition/aggregate),
627	  - Low latency (short flows, queries),
628	  - High throughput (continuous data updates, large file transfers) with
629	    commodity, shallow-buffered switches.
630
631	  All switches in the data center network running DCTCP must support
632	  ECN marking and be configured for marking when reaching defined switch
633	  buffer thresholds. The default ECN marking threshold heuristic for
634	  DCTCP on switches is 20 packets (30KB) at 1Gbps, and 65 packets
635	  (~100KB) at 10Gbps, but might need further careful tweaking.
636
637	  For further details see:
638	    http://simula.stanford.edu/~alizade/Site/DCTCP_files/dctcp-final.pdf
639
640config TCP_CONG_CDG
641	tristate "CAIA Delay-Gradient (CDG)"
642	default n
643	help
644	  CAIA Delay-Gradient (CDG) is a TCP congestion control that modifies
645	  the TCP sender in order to:
646
647	  o Use the delay gradient as a congestion signal.
648	  o Back off with an average probability that is independent of the RTT.
649	  o Coexist with flows that use loss-based congestion control.
650	  o Tolerate packet loss unrelated to congestion.
651
652	  For further details see:
653	    D.A. Hayes and G. Armitage. "Revisiting TCP congestion control using
654	    delay gradients." In Networking 2011. Preprint: http://goo.gl/No3vdg
655
656config TCP_CONG_BBR
657	tristate "BBR TCP"
658	default n
659	help
660
661	  BBR (Bottleneck Bandwidth and RTT) TCP congestion control aims to
662	  maximize network utilization and minimize queues. It builds an explicit
663	  model of the bottleneck delivery rate and path round-trip propagation
664	  delay. It tolerates packet loss and delay unrelated to congestion. It
665	  can operate over LAN, WAN, cellular, wifi, or cable modem links. It can
666	  coexist with flows that use loss-based congestion control, and can
667	  operate with shallow buffers, deep buffers, bufferbloat, policers, or
668	  AQM schemes that do not provide a delay signal. It requires the fq
669	  ("Fair Queue") pacing packet scheduler.
670
671choice
672	prompt "Default TCP congestion control"
673	default DEFAULT_CUBIC
674	help
675	  Select the TCP congestion control that will be used by default
676	  for all connections.
677
678	config DEFAULT_BIC
679		bool "Bic" if TCP_CONG_BIC=y
680
681	config DEFAULT_CUBIC
682		bool "Cubic" if TCP_CONG_CUBIC=y
683
684	config DEFAULT_HTCP
685		bool "Htcp" if TCP_CONG_HTCP=y
686
687	config DEFAULT_HYBLA
688		bool "Hybla" if TCP_CONG_HYBLA=y
689
690	config DEFAULT_VEGAS
691		bool "Vegas" if TCP_CONG_VEGAS=y
692
693	config DEFAULT_VENO
694		bool "Veno" if TCP_CONG_VENO=y
695
696	config DEFAULT_WESTWOOD
697		bool "Westwood" if TCP_CONG_WESTWOOD=y
698
699	config DEFAULT_DCTCP
700		bool "DCTCP" if TCP_CONG_DCTCP=y
701
702	config DEFAULT_CDG
703		bool "CDG" if TCP_CONG_CDG=y
704
705	config DEFAULT_BBR
706		bool "BBR" if TCP_CONG_BBR=y
707
708	config DEFAULT_RENO
709		bool "Reno"
710endchoice
711
712endif
713
714config TCP_CONG_CUBIC
715	tristate
716	depends on !TCP_CONG_ADVANCED
717	default y
718
719config DEFAULT_TCP_CONG
720	string
721	default "bic" if DEFAULT_BIC
722	default "cubic" if DEFAULT_CUBIC
723	default "htcp" if DEFAULT_HTCP
724	default "hybla" if DEFAULT_HYBLA
725	default "vegas" if DEFAULT_VEGAS
726	default "westwood" if DEFAULT_WESTWOOD
727	default "veno" if DEFAULT_VENO
728	default "reno" if DEFAULT_RENO
729	default "dctcp" if DEFAULT_DCTCP
730	default "cdg" if DEFAULT_CDG
731	default "bbr" if DEFAULT_BBR
732	default "cubic"
733
734config TCP_MD5SIG
735	bool "TCP: MD5 Signature Option support (RFC2385)"
736	select CRYPTO
737	select CRYPTO_MD5
738	help
739	  RFC2385 specifies a method of giving MD5 protection to TCP sessions.
740	  Its main (only?) use is to protect BGP sessions between core routers
741	  on the Internet.
742
743	  If unsure, say N.
744