forked from ~ljy/RK356X_SDK_RELEASE
blame | history | patch | commit | commitdiff
hc
2024-05-10 cde9070d9970eef1f7ec2360586c802a16230ad8 
 kernel/net/ipv4/Kconfig
....@@ -1,3 +1,4 @@
1
+# SPDX-License-Identifier: GPL-2.0-only
12 #
23 # IP configuration
34 #
....@@ -9,11 +10,11 @@
910 	  intend to participate in the MBONE, a high bandwidth network on top
1011 	  of the Internet which carries audio and video broadcasts. More
1112 	  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
+	  <https://www.savetz.com/mbone/>. For most people, it's safe to say N.
1314 
1415 config IP_ADVANCED_ROUTER
1516 	bool "IP: advanced router"
16
-	---help---
17
+	help
1718 	  If you intend to run your Linux box mostly as a router, i.e. as a
1819 	  computer that forwards and redistributes network packets, say Y; you
1920 	  will then be presented with several options that allow more precise
....@@ -48,14 +49,14 @@
4849 
4950 	  Note that some distributions enable it in startup scripts.
5051 	  For details about rp_filter strict and loose mode read
51
-	  <file:Documentation/networking/ip-sysctl.txt>.
52
+	  <file:Documentation/networking/ip-sysctl.rst>.
5253 
5354 	  If unsure, say N here.
5455 
5556 config IP_FIB_TRIE_STATS
5657 	bool "FIB TRIE statistics"
5758 	depends on IP_ADVANCED_ROUTER
58
-	---help---
59
+	help
5960 	  Keep track of statistics on structure of FIB TRIE table.
6061 	  Useful for testing and measuring TRIE performance.
6162 
....@@ -63,7 +64,7 @@
6364 	bool "IP: policy routing"
6465 	depends on IP_ADVANCED_ROUTER
6566 	select FIB_RULES
66
-	---help---
67
+	help
6768 	  Normally, a router decides what to do with a received packet based
6869 	  solely on the packet's final destination address. If you say Y here,
6970 	  the Linux router will also be able to take the packet's source
....@@ -72,7 +73,7 @@
7273 
7374 	  If you need more information, see the Linux Advanced
7475 	  Routing and Traffic Control documentation at
75
-	  <http://lartc.org/howto/lartc.rpdb.html>
76
+	  <https://lartc.org/howto/lartc.rpdb.html>
7677 
7778 	  If unsure, say N.
7879 
....@@ -116,7 +117,7 @@
116117 config IP_PNP_DHCP
117118 	bool "IP: DHCP support"
118119 	depends on IP_PNP
119
-	---help---
120
+	help
120121 	  If you want your Linux box to mount its whole root file system (the
121122 	  one containing the directory /) from some other computer over the
122123 	  net via NFS and you want the IP address of your computer to be
....@@ -128,12 +129,12 @@
128129 
129130 	  If unsure, say Y. Note that if you want to use DHCP, a DHCP server
130131 	  must be operating on your network.  Read
131
-	  <file:Documentation/filesystems/nfs/nfsroot.txt> for details.
132
+	  <file:Documentation/admin-guide/nfs/nfsroot.rst> for details.
132133 
133134 config IP_PNP_BOOTP
134135 	bool "IP: BOOTP support"
135136 	depends on IP_PNP
136
-	---help---
137
+	help
137138 	  If you want your Linux box to mount its whole root file system (the
138139 	  one containing the directory /) from some other computer over the
139140 	  net via NFS and you want the IP address of your computer to be
....@@ -143,7 +144,7 @@
143144 	  does BOOTP itself, providing all necessary information on the kernel
144145 	  command line, you can say N here. If unsure, say Y. Note that if you
145146 	  want to use BOOTP, a BOOTP server must be operating on your network.
146
-	  Read <file:Documentation/filesystems/nfs/nfsroot.txt> for details.
147
+	  Read <file:Documentation/admin-guide/nfs/nfsroot.rst> for details.
147148 
148149 config IP_PNP_RARP
149150 	bool "IP: RARP support"
....@@ -156,13 +157,13 @@
156157 	  older protocol which is being obsoleted by BOOTP and DHCP), say Y
157158 	  here. Note that if you want to use RARP, a RARP server must be
158159 	  operating on your network. Read
159
-	  <file:Documentation/filesystems/nfs/nfsroot.txt> for details.
160
+	  <file:Documentation/admin-guide/nfs/nfsroot.rst> for details.
160161 
161162 config NET_IPIP
162163 	tristate "IP: tunneling"
163164 	select INET_TUNNEL
164165 	select NET_IP_TUNNEL
165
-	---help---
166
+	help
166167 	  Tunneling means encapsulating data of one protocol type within
167168 	  another protocol and sending it over a channel that understands the
168169 	  encapsulating protocol. This particular tunneling driver implements
....@@ -179,8 +180,8 @@
179180 config NET_IPGRE_DEMUX
180181 	tristate "IP: GRE demultiplexer"
181182 	help
182
-	 This is helper module to demultiplex GRE packets on GRE version field criteria.
183
-	 Required by ip_gre and pptp modules.
183
+	  This is helper module to demultiplex GRE packets on GRE version field criteria.
184
+	  Required by ip_gre and pptp modules.
184185 
185186 config NET_IP_TUNNEL
186187 	tristate
....@@ -266,7 +267,7 @@
266267 
267268 config SYN_COOKIES
268269 	bool "IP: TCP syncookie support"
269
-	---help---
270
+	help
270271 	  Normal TCP/IP networking is open to an attack known as "SYN
271272 	  flooding". This denial-of-service attack prevents legitimate remote
272273 	  users from being able to connect to your computer during an ongoing
....@@ -279,7 +280,7 @@
279280 	  continue to connect, even when your machine is under attack. There
280281 	  is no need for the legitimate users to change their TCP/IP software;
281282 	  SYN cookies work transparently to them. For technical information
282
-	  about SYN cookies, check out <http://cr.yp.to/syncookies.html>.
283
+	  about SYN cookies, check out <https://cr.yp.to/syncookies.html>.
283284 
284285 	  If you are SYN flooded, the source address reported by the kernel is
285286 	  likely to have been forged by the attacker; it is only reported as
....@@ -305,8 +306,8 @@
305306 	depends on IPV6 || IPV6=n
306307 	select INET_TUNNEL
307308 	select NET_IP_TUNNEL
308
-	depends on INET_XFRM_MODE_TUNNEL
309
-	---help---
309
+	select XFRM
310
+	help
310311 	  Tunneling means encapsulating data of one protocol type within
311312 	  another protocol and sending it over a channel that understands the
312313 	  encapsulating protocol. This can be used with xfrm mode tunnel to give
....@@ -322,7 +323,7 @@
322323 	tristate "IP: Foo (IP protocols) over UDP"
323324 	select XFRM
324325 	select NET_UDP_TUNNEL
325
-	---help---
326
+	help
326327 	  Foo over UDP allows any IP protocol to be directly encapsulated
327328 	  over UDP include tunnels (IPIP, GRE, SIT). By encapsulating in UDP
328329 	  network mechanisms and optimizations for UDP (such as ECMP
....@@ -332,36 +333,38 @@
332333 	bool "IP: FOU encapsulation of IP tunnels"
333334 	depends on NET_IPIP || NET_IPGRE || IPV6_SIT
334335 	select NET_FOU
335
-	---help---
336
+	help
336337 	  Allow configuration of FOU or GUE encapsulation for IP tunnels.
337338 	  When this option is enabled IP tunnels can be configured to use
338339 	  FOU or GUE encapsulation.
339340 
340341 config INET_AH
341342 	tristate "IP: AH transformation"
342
-	select XFRM_ALGO
343
-	select CRYPTO
344
-	select CRYPTO_HMAC
345
-	select CRYPTO_MD5
346
-	select CRYPTO_SHA1
347
-	---help---
348
-	  Support for IPsec AH.
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.
349353 
350354 	  If unsure, say Y.
351355 
352356 config INET_ESP
353357 	tristate "IP: ESP transformation"
354
-	select XFRM_ALGO
355
-	select CRYPTO
356
-	select CRYPTO_AUTHENC
357
-	select CRYPTO_HMAC
358
-	select CRYPTO_MD5
359
-	select CRYPTO_CBC
360
-	select CRYPTO_SHA1
361
-	select CRYPTO_DES
362
-	select CRYPTO_ECHAINIV
363
-	---help---
364
-	  Support for IPsec ESP.
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.
365368 
366369 	  If unsure, say Y.
367370 
....@@ -370,7 +373,7 @@
370373 	depends on INET_ESP
371374 	select XFRM_OFFLOAD
372375 	default n
373
-	---help---
376
+	help
374377 	  Support for ESP transformation offload. This makes sense
375378 	  only if this system really does IPsec and want to do it
376379 	  with high throughput. A typical desktop system does not
....@@ -378,15 +381,37 @@
378381 
379382 	  If unsure, say N.
380383 
384
+config 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
+
381396 config INET_IPCOMP
382397 	tristate "IP: IPComp transformation"
383398 	select INET_XFRM_TUNNEL
384399 	select XFRM_IPCOMP
385
-	---help---
400
+	help
386401 	  Support for IP Payload Compression Protocol (IPComp) (RFC3173),
387402 	  typically needed for IPsec.
388403 
389404 	  If unsure, say Y.
405
+
406
+config INET_TABLE_PERTURB_ORDER
407
+	int "INET: Source port perturbation table size (as power of 2)" if EXPERT
408
+	default 16
409
+	help
410
+	  Source port perturbation table size (as power of 2) for
411
+	  RFC 6056 3.3.4.  Algorithm 4: Double-Hash Port Selection Algorithm.
412
+
413
+	  The default is almost always what you want.
414
+	  Only change this if you know what you are doing.
390415 
391416 config INET_XFRM_TUNNEL
392417 	tristate
....@@ -397,37 +422,10 @@
397422 	tristate
398423 	default n
399424 
400
-config INET_XFRM_MODE_TRANSPORT
401
-	tristate "IP: IPsec transport mode"
402
-	default y
403
-	select XFRM
404
-	---help---
405
-	  Support for IPsec transport mode.
406
-
407
-	  If unsure, say Y.
408
-
409
-config INET_XFRM_MODE_TUNNEL
410
-	tristate "IP: IPsec tunnel mode"
411
-	default y
412
-	select XFRM
413
-	---help---
414
-	  Support for IPsec tunnel mode.
415
-
416
-	  If unsure, say Y.
417
-
418
-config INET_XFRM_MODE_BEET
419
-	tristate "IP: IPsec BEET mode"
420
-	default y
421
-	select XFRM
422
-	---help---
423
-	  Support for IPsec BEET mode.
424
-
425
-	  If unsure, say Y.
426
-
427425 config INET_DIAG
428426 	tristate "INET: socket monitoring interface"
429427 	default y
430
-	---help---
428
+	help
431429 	  Support for INET (TCP, DCCP, etc) socket monitoring interface used by
432430 	  native Linux tools such as ss. ss is included in iproute2, currently
433431 	  downloadable at:
....@@ -444,7 +442,7 @@
444442 	tristate "UDP: socket monitoring interface"
445443 	depends on INET_DIAG && (IPV6 || IPV6=n)
446444 	default n
447
-	---help---
445
+	help
448446 	  Support for UDP socket monitoring interface used by the ss tool.
449447 	  If unsure, say Y.
450448 
....@@ -452,7 +450,7 @@
452450 	tristate "RAW: socket monitoring interface"
453451 	depends on INET_DIAG && (IPV6 || IPV6=n)
454452 	default n
455
-	---help---
453
+	help
456454 	  Support for RAW socket monitoring interface used by the ss tool.
457455 	  If unsure, say Y.
458456 
....@@ -460,7 +458,7 @@
460458 	bool "INET: allow privileged process to administratively close sockets"
461459 	depends on INET_DIAG
462460 	default n
463
-	---help---
461
+	help
464462 	  Provides a SOCK_DESTROY operation that allows privileged processes
465463 	  (e.g., a connection manager or a network administration tool such as
466464 	  ss) to close sockets opened by other processes. Closing a socket in
....@@ -471,7 +469,7 @@
471469 
472470 menuconfig TCP_CONG_ADVANCED
473471 	bool "TCP: advanced congestion control"
474
-	---help---
472
+	help
475473 	  Support for selection of various TCP congestion control
476474 	  modules.
477475 
....@@ -485,201 +483,201 @@
485483 config TCP_CONG_BIC
486484 	tristate "Binary Increase Congestion (BIC) control"
487485 	default m
488
-	---help---
489
-	BIC-TCP is a sender-side only change that ensures a linear RTT
490
-	fairness under large windows while offering both scalability and
491
-	bounded TCP-friendliness. The protocol combines two schemes
492
-	called additive increase and binary search increase. When the
493
-	congestion window is large, additive increase with a large
494
-	increment ensures linear RTT fairness as well as good
495
-	scalability. Under small congestion windows, binary search
496
-	increase provides TCP friendliness.
497
-	See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/
486
+	help
487
+	  BIC-TCP is a sender-side only change that ensures a linear RTT
488
+	  fairness under large windows while offering both scalability and
489
+	  bounded TCP-friendliness. The protocol combines two schemes
490
+	  called additive increase and binary search increase. When the
491
+	  congestion window is large, additive increase with a large
492
+	  increment ensures linear RTT fairness as well as good
493
+	  scalability. Under small congestion windows, binary search
494
+	  increase provides TCP friendliness.
495
+	  See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/
498496 
499497 config TCP_CONG_CUBIC
500498 	tristate "CUBIC TCP"
501499 	default y
502
-	---help---
503
-	This is version 2.0 of BIC-TCP which uses a cubic growth function
504
-	among other techniques.
505
-	See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/cubic-paper.pdf
500
+	help
501
+	  This is version 2.0 of BIC-TCP which uses a cubic growth function
502
+	  among other techniques.
503
+	  See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/cubic-paper.pdf
506504 
507505 config TCP_CONG_WESTWOOD
508506 	tristate "TCP Westwood+"
509507 	default m
510
-	---help---
511
-	TCP Westwood+ is a sender-side only modification of the TCP Reno
512
-	protocol stack that optimizes the performance of TCP congestion
513
-	control. It is based on end-to-end bandwidth estimation to set
514
-	congestion window and slow start threshold after a congestion
515
-	episode. Using this estimation, TCP Westwood+ adaptively sets a
516
-	slow start threshold and a congestion window which takes into
517
-	account the bandwidth used  at the time congestion is experienced.
518
-	TCP Westwood+ significantly increases fairness wrt TCP Reno in
519
-	wired networks and throughput over wireless links.
508
+	help
509
+	  TCP Westwood+ is a sender-side only modification of the TCP Reno
510
+	  protocol stack that optimizes the performance of TCP congestion
511
+	  control. It is based on end-to-end bandwidth estimation to set
512
+	  congestion window and slow start threshold after a congestion
513
+	  episode. Using this estimation, TCP Westwood+ adaptively sets a
514
+	  slow start threshold and a congestion window which takes into
515
+	  account the bandwidth used  at the time congestion is experienced.
516
+	  TCP Westwood+ significantly increases fairness wrt TCP Reno in
517
+	  wired networks and throughput over wireless links.
520518 
521519 config TCP_CONG_HTCP
522
-        tristate "H-TCP"
523
-        default m
524
-	---help---
525
-	H-TCP is a send-side only modifications of the TCP Reno
526
-	protocol stack that optimizes the performance of TCP
527
-	congestion control for high speed network links. It uses a
528
-	modeswitch to change the alpha and beta parameters of TCP Reno
529
-	based on network conditions and in a way so as to be fair with
530
-	other Reno and H-TCP flows.
520
+	tristate "H-TCP"
521
+	default m
522
+	help
523
+	  H-TCP is a send-side only modifications of the TCP Reno
524
+	  protocol stack that optimizes the performance of TCP
525
+	  congestion control for high speed network links. It uses a
526
+	  modeswitch to change the alpha and beta parameters of TCP Reno
527
+	  based on network conditions and in a way so as to be fair with
528
+	  other Reno and H-TCP flows.
531529 
532530 config TCP_CONG_HSTCP
533531 	tristate "High Speed TCP"
534532 	default n
535
-	---help---
536
-	Sally Floyd's High Speed TCP (RFC 3649) congestion control.
537
-	A modification to TCP's congestion control mechanism for use
538
-	with large congestion windows. A table indicates how much to
539
-	increase the congestion window by when an ACK is received.
540
- 	For more detail	see http://www.icir.org/floyd/hstcp.html
533
+	help
534
+	  Sally Floyd's High Speed TCP (RFC 3649) congestion control.
535
+	  A modification to TCP's congestion control mechanism for use
536
+	  with large congestion windows. A table indicates how much to
537
+	  increase the congestion window by when an ACK is received.
538
+	  For more detail see https://www.icir.org/floyd/hstcp.html
541539 
542540 config TCP_CONG_HYBLA
543541 	tristate "TCP-Hybla congestion control algorithm"
544542 	default n
545
-	---help---
546
-	TCP-Hybla is a sender-side only change that eliminates penalization of
547
-	long-RTT, large-bandwidth connections, like when satellite legs are
548
-	involved, especially when sharing a common bottleneck with normal
549
-	terrestrial connections.
543
+	help
544
+	  TCP-Hybla is a sender-side only change that eliminates penalization of
545
+	  long-RTT, large-bandwidth connections, like when satellite legs are
546
+	  involved, especially when sharing a common bottleneck with normal
547
+	  terrestrial connections.
550548 
551549 config TCP_CONG_VEGAS
552550 	tristate "TCP Vegas"
553551 	default n
554
-	---help---
555
-	TCP Vegas is a sender-side only change to TCP that anticipates
556
-	the onset of congestion by estimating the bandwidth. TCP Vegas
557
-	adjusts the sending rate by modifying the congestion
558
-	window. TCP Vegas should provide less packet loss, but it is
559
-	not as aggressive as TCP Reno.
552
+	help
553
+	  TCP Vegas is a sender-side only change to TCP that anticipates
554
+	  the onset of congestion by estimating the bandwidth. TCP Vegas
555
+	  adjusts the sending rate by modifying the congestion
556
+	  window. TCP Vegas should provide less packet loss, but it is
557
+	  not as aggressive as TCP Reno.
560558 
561559 config TCP_CONG_NV
562
-       tristate "TCP NV"
563
-       default n
564
-       ---help---
565
-       TCP NV is a follow up to TCP Vegas. It has been modified to deal with
566
-       10G networks, measurement noise introduced by LRO, GRO and interrupt
567
-       coalescence. In addition, it will decrease its cwnd multiplicatively
568
-       instead of linearly.
560
+	tristate "TCP NV"
561
+	default n
562
+	help
563
+	  TCP NV is a follow up to TCP Vegas. It has been modified to deal with
564
+	  10G networks, measurement noise introduced by LRO, GRO and interrupt
565
+	  coalescence. In addition, it will decrease its cwnd multiplicatively
566
+	  instead of linearly.
569567 
570
-       Note that in general congestion avoidance (cwnd decreased when # packets
571
-       queued grows) cannot coexist with congestion control (cwnd decreased only
572
-       when there is packet loss) due to fairness issues. One scenario when they
573
-       can coexist safely is when the CA flows have RTTs << CC flows RTTs.
568
+	  Note that in general congestion avoidance (cwnd decreased when # packets
569
+	  queued grows) cannot coexist with congestion control (cwnd decreased only
570
+	  when there is packet loss) due to fairness issues. One scenario when they
571
+	  can coexist safely is when the CA flows have RTTs << CC flows RTTs.
574572 
575
-       For further details see http://www.brakmo.org/networking/tcp-nv/
573
+	  For further details see http://www.brakmo.org/networking/tcp-nv/
576574 
577575 config TCP_CONG_SCALABLE
578576 	tristate "Scalable TCP"
579577 	default n
580
-	---help---
581
-	Scalable TCP is a sender-side only change to TCP which uses a
582
-	MIMD congestion control algorithm which has some nice scaling
583
-	properties, though is known to have fairness issues.
584
-	See http://www.deneholme.net/tom/scalable/
578
+	help
579
+	  Scalable TCP is a sender-side only change to TCP which uses a
580
+	  MIMD congestion control algorithm which has some nice scaling
581
+	  properties, though is known to have fairness issues.
582
+	  See http://www.deneholme.net/tom/scalable/
585583 
586584 config TCP_CONG_LP
587585 	tristate "TCP Low Priority"
588586 	default n
589
-	---help---
590
-	TCP Low Priority (TCP-LP), a distributed algorithm whose goal is
591
-	to utilize only the excess network bandwidth as compared to the
592
-	``fair share`` of bandwidth as targeted by TCP.
593
-	See http://www-ece.rice.edu/networks/TCP-LP/
587
+	help
588
+	  TCP Low Priority (TCP-LP), a distributed algorithm whose goal is
589
+	  to utilize only the excess network bandwidth as compared to the
590
+	  ``fair share`` of bandwidth as targeted by TCP.
591
+	  See http://www-ece.rice.edu/networks/TCP-LP/
594592 
595593 config TCP_CONG_VENO
596594 	tristate "TCP Veno"
597595 	default n
598
-	---help---
599
-	TCP Veno is a sender-side only enhancement of TCP to obtain better
600
-	throughput over wireless networks. TCP Veno makes use of state
601
-	distinguishing to circumvent the difficult judgment of the packet loss
602
-	type. TCP Veno cuts down less congestion window in response to random
603
-	loss packets.
604
-	See <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1177186>
596
+	help
597
+	  TCP Veno is a sender-side only enhancement of TCP to obtain better
598
+	  throughput over wireless networks. TCP Veno makes use of state
599
+	  distinguishing to circumvent the difficult judgment of the packet loss
600
+	  type. TCP Veno cuts down less congestion window in response to random
601
+	  loss packets.
602
+	  See <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1177186>
605603 
606604 config TCP_CONG_YEAH
607605 	tristate "YeAH TCP"
608606 	select TCP_CONG_VEGAS
609607 	default n
610
-	---help---
611
-	YeAH-TCP is a sender-side high-speed enabled TCP congestion control
612
-	algorithm, which uses a mixed loss/delay approach to compute the
613
-	congestion window. It's design goals target high efficiency,
614
-	internal, RTT and Reno fairness, resilience to link loss while
615
-	keeping network elements load as low as possible.
608
+	help
609
+	  YeAH-TCP is a sender-side high-speed enabled TCP congestion control
610
+	  algorithm, which uses a mixed loss/delay approach to compute the
611
+	  congestion window. It's design goals target high efficiency,
612
+	  internal, RTT and Reno fairness, resilience to link loss while
613
+	  keeping network elements load as low as possible.
616614 
617
-	For further details look here:
618
-	  http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf
615
+	  For further details look here:
616
+	    http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf
619617 
620618 config TCP_CONG_ILLINOIS
621619 	tristate "TCP Illinois"
622620 	default n
623
-	---help---
624
-	TCP-Illinois is a sender-side modification of TCP Reno for
625
-	high speed long delay links. It uses round-trip-time to
626
-	adjust the alpha and beta parameters to achieve a higher average
627
-	throughput and maintain fairness.
621
+	help
622
+	  TCP-Illinois is a sender-side modification of TCP Reno for
623
+	  high speed long delay links. It uses round-trip-time to
624
+	  adjust the alpha and beta parameters to achieve a higher average
625
+	  throughput and maintain fairness.
628626 
629
-	For further details see:
630
-	  http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
627
+	  For further details see:
628
+	    http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
631629 
632630 config TCP_CONG_DCTCP
633631 	tristate "DataCenter TCP (DCTCP)"
634632 	default n
635
-	---help---
636
-	DCTCP leverages Explicit Congestion Notification (ECN) in the network to
637
-	provide multi-bit feedback to the end hosts. It is designed to provide:
633
+	help
634
+	  DCTCP leverages Explicit Congestion Notification (ECN) in the network to
635
+	  provide multi-bit feedback to the end hosts. It is designed to provide:
638636 
639
-	- High burst tolerance (incast due to partition/aggregate),
640
-	- Low latency (short flows, queries),
641
-	- High throughput (continuous data updates, large file transfers) with
642
-	  commodity, shallow-buffered switches.
637
+	  - High burst tolerance (incast due to partition/aggregate),
638
+	  - Low latency (short flows, queries),
639
+	  - High throughput (continuous data updates, large file transfers) with
640
+	    commodity, shallow-buffered switches.
643641 
644
-	All switches in the data center network running DCTCP must support
645
-	ECN marking and be configured for marking when reaching defined switch
646
-	buffer thresholds. The default ECN marking threshold heuristic for
647
-	DCTCP on switches is 20 packets (30KB) at 1Gbps, and 65 packets
648
-	(~100KB) at 10Gbps, but might need further careful tweaking.
642
+	  All switches in the data center network running DCTCP must support
643
+	  ECN marking and be configured for marking when reaching defined switch
644
+	  buffer thresholds. The default ECN marking threshold heuristic for
645
+	  DCTCP on switches is 20 packets (30KB) at 1Gbps, and 65 packets
646
+	  (~100KB) at 10Gbps, but might need further careful tweaking.
649647 
650
-	For further details see:
651
-	  http://simula.stanford.edu/~alizade/Site/DCTCP_files/dctcp-final.pdf
648
+	  For further details see:
649
+	    http://simula.stanford.edu/~alizade/Site/DCTCP_files/dctcp-final.pdf
652650 
653651 config TCP_CONG_CDG
654652 	tristate "CAIA Delay-Gradient (CDG)"
655653 	default n
656
-	---help---
657
-	CAIA Delay-Gradient (CDG) is a TCP congestion control that modifies
658
-	the TCP sender in order to:
654
+	help
655
+	  CAIA Delay-Gradient (CDG) is a TCP congestion control that modifies
656
+	  the TCP sender in order to:
659657 
660658 	  o Use the delay gradient as a congestion signal.
661659 	  o Back off with an average probability that is independent of the RTT.
662660 	  o Coexist with flows that use loss-based congestion control.
663661 	  o Tolerate packet loss unrelated to congestion.
664662 
665
-	For further details see:
666
-	  D.A. Hayes and G. Armitage. "Revisiting TCP congestion control using
667
-	  delay gradients." In Networking 2011. Preprint: http://goo.gl/No3vdg
663
+	  For further details see:
664
+	    D.A. Hayes and G. Armitage. "Revisiting TCP congestion control using
665
+	    delay gradients." In Networking 2011. Preprint: http://goo.gl/No3vdg
668666 
669667 config TCP_CONG_BBR
670668 	tristate "BBR TCP"
671669 	default n
672
-	---help---
670
+	help
673671 
674
-	BBR (Bottleneck Bandwidth and RTT) TCP congestion control aims to
675
-	maximize network utilization and minimize queues. It builds an explicit
676
-	model of the the bottleneck delivery rate and path round-trip
677
-	propagation delay. It tolerates packet loss and delay unrelated to
678
-	congestion. It can operate over LAN, WAN, cellular, wifi, or cable
679
-	modem links. It can coexist with flows that use loss-based congestion
680
-	control, and can operate with shallow buffers, deep buffers,
681
-	bufferbloat, policers, or AQM schemes that do not provide a delay
682
-	signal. It requires the fq ("Fair Queue") pacing packet scheduler.
672
+	  BBR (Bottleneck Bandwidth and RTT) TCP congestion control aims to
673
+	  maximize network utilization and minimize queues. It builds an explicit
674
+	  model of the bottleneck delivery rate and path round-trip propagation
675
+	  delay. It tolerates packet loss and delay unrelated to congestion. It
676
+	  can operate over LAN, WAN, cellular, wifi, or cable modem links. It can
677
+	  coexist with flows that use loss-based congestion control, and can
678
+	  operate with shallow buffers, deep buffers, bufferbloat, policers, or
679
+	  AQM schemes that do not provide a delay signal. It requires the fq
680
+	  ("Fair Queue") pacing packet scheduler.
683681 
684682 choice
685683 	prompt "Default TCP congestion control"
....@@ -748,7 +746,7 @@
748746 	bool "TCP: MD5 Signature Option support (RFC2385)"
749747 	select CRYPTO
750748 	select CRYPTO_MD5
751
-	---help---
749
+	help
752750 	  RFC2385 specifies a method of giving MD5 protection to TCP sessions.
753751 	  Its main (only?) use is to protect BGP sessions between core routers
754752 	  on the Internet.