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