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