@@ -180,8 +180,8 @@ config NET_IPIP
180
180
config NET_IPGRE_DEMUX
181
181
tristate "IP: GRE demultiplexer"
182
182
help
183
- This is helper module to demultiplex GRE packets on GRE version field criteria.
184
- 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.
185
185
186
186
config NET_IP_TUNNEL
187
187
tristate
@@ -459,200 +459,200 @@ config TCP_CONG_BIC
459
459
tristate "Binary Increase Congestion (BIC) control"
460
460
default m
461
461
---help---
462
- BIC-TCP is a sender-side only change that ensures a linear RTT
463
- fairness under large windows while offering both scalability and
464
- bounded TCP-friendliness. The protocol combines two schemes
465
- called additive increase and binary search increase. When the
466
- congestion window is large, additive increase with a large
467
- increment ensures linear RTT fairness as well as good
468
- scalability. Under small congestion windows, binary search
469
- increase provides TCP friendliness.
470
- See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/
462
+ BIC-TCP is a sender-side only change that ensures a linear RTT
463
+ fairness under large windows while offering both scalability and
464
+ bounded TCP-friendliness. The protocol combines two schemes
465
+ called additive increase and binary search increase. When the
466
+ congestion window is large, additive increase with a large
467
+ increment ensures linear RTT fairness as well as good
468
+ scalability. Under small congestion windows, binary search
469
+ increase provides TCP friendliness.
470
+ See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/
471
471
472
472
config TCP_CONG_CUBIC
473
473
tristate "CUBIC TCP"
474
474
default y
475
475
---help---
476
- This is version 2.0 of BIC-TCP which uses a cubic growth function
477
- among other techniques.
478
- See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/cubic-paper.pdf
476
+ This is version 2.0 of BIC-TCP which uses a cubic growth function
477
+ among other techniques.
478
+ See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/cubic-paper.pdf
479
479
480
480
config TCP_CONG_WESTWOOD
481
481
tristate "TCP Westwood+"
482
482
default m
483
483
---help---
484
- TCP Westwood+ is a sender-side only modification of the TCP Reno
485
- protocol stack that optimizes the performance of TCP congestion
486
- control. It is based on end-to-end bandwidth estimation to set
487
- congestion window and slow start threshold after a congestion
488
- episode. Using this estimation, TCP Westwood+ adaptively sets a
489
- slow start threshold and a congestion window which takes into
490
- account the bandwidth used at the time congestion is experienced.
491
- TCP Westwood+ significantly increases fairness wrt TCP Reno in
492
- wired networks and throughput over wireless links.
484
+ TCP Westwood+ is a sender-side only modification of the TCP Reno
485
+ protocol stack that optimizes the performance of TCP congestion
486
+ control. It is based on end-to-end bandwidth estimation to set
487
+ congestion window and slow start threshold after a congestion
488
+ episode. Using this estimation, TCP Westwood+ adaptively sets a
489
+ slow start threshold and a congestion window which takes into
490
+ account the bandwidth used at the time congestion is experienced.
491
+ TCP Westwood+ significantly increases fairness wrt TCP Reno in
492
+ wired networks and throughput over wireless links.
493
493
494
494
config TCP_CONG_HTCP
495
495
tristate "H-TCP"
496
496
default m
497
497
---help---
498
- H-TCP is a send-side only modifications of the TCP Reno
499
- protocol stack that optimizes the performance of TCP
500
- congestion control for high speed network links. It uses a
501
- modeswitch to change the alpha and beta parameters of TCP Reno
502
- based on network conditions and in a way so as to be fair with
503
- other Reno and H-TCP flows.
498
+ H-TCP is a send-side only modifications of the TCP Reno
499
+ protocol stack that optimizes the performance of TCP
500
+ congestion control for high speed network links. It uses a
501
+ modeswitch to change the alpha and beta parameters of TCP Reno
502
+ based on network conditions and in a way so as to be fair with
503
+ other Reno and H-TCP flows.
504
504
505
505
config TCP_CONG_HSTCP
506
506
tristate "High Speed TCP"
507
507
default n
508
508
---help---
509
- Sally Floyd's High Speed TCP (RFC 3649) congestion control.
510
- A modification to TCP's congestion control mechanism for use
511
- with large congestion windows. A table indicates how much to
512
- increase the congestion window by when an ACK is received.
513
- For more detail see http://www.icir.org/floyd/hstcp.html
509
+ Sally Floyd's High Speed TCP (RFC 3649) congestion control.
510
+ A modification to TCP's congestion control mechanism for use
511
+ with large congestion windows. A table indicates how much to
512
+ increase the congestion window by when an ACK is received.
513
+ For more detail see http://www.icir.org/floyd/hstcp.html
514
514
515
515
config TCP_CONG_HYBLA
516
516
tristate "TCP-Hybla congestion control algorithm"
517
517
default n
518
518
---help---
519
- TCP-Hybla is a sender-side only change that eliminates penalization of
520
- long-RTT, large-bandwidth connections, like when satellite legs are
521
- involved, especially when sharing a common bottleneck with normal
522
- terrestrial connections.
519
+ TCP-Hybla is a sender-side only change that eliminates penalization of
520
+ long-RTT, large-bandwidth connections, like when satellite legs are
521
+ involved, especially when sharing a common bottleneck with normal
522
+ terrestrial connections.
523
523
524
524
config TCP_CONG_VEGAS
525
525
tristate "TCP Vegas"
526
526
default n
527
527
---help---
528
- TCP Vegas is a sender-side only change to TCP that anticipates
529
- the onset of congestion by estimating the bandwidth. TCP Vegas
530
- adjusts the sending rate by modifying the congestion
531
- window. TCP Vegas should provide less packet loss, but it is
532
- not as aggressive as TCP Reno.
528
+ TCP Vegas is a sender-side only change to TCP that anticipates
529
+ the onset of congestion by estimating the bandwidth. TCP Vegas
530
+ adjusts the sending rate by modifying the congestion
531
+ window. TCP Vegas should provide less packet loss, but it is
532
+ not as aggressive as TCP Reno.
533
533
534
534
config TCP_CONG_NV
535
- tristate "TCP NV"
536
- default n
537
- ---help---
538
- TCP NV is a follow up to TCP Vegas. It has been modified to deal with
539
- 10G networks, measurement noise introduced by LRO, GRO and interrupt
540
- coalescence. In addition, it will decrease its cwnd multiplicatively
541
- instead of linearly.
535
+ tristate "TCP NV"
536
+ default n
537
+ ---help---
538
+ TCP NV is a follow up to TCP Vegas. It has been modified to deal with
539
+ 10G networks, measurement noise introduced by LRO, GRO and interrupt
540
+ coalescence. In addition, it will decrease its cwnd multiplicatively
541
+ instead of linearly.
542
542
543
- Note that in general congestion avoidance (cwnd decreased when # packets
544
- queued grows) cannot coexist with congestion control (cwnd decreased only
545
- when there is packet loss) due to fairness issues. One scenario when they
546
- can coexist safely is when the CA flows have RTTs << CC flows RTTs.
543
+ Note that in general congestion avoidance (cwnd decreased when # packets
544
+ queued grows) cannot coexist with congestion control (cwnd decreased only
545
+ when there is packet loss) due to fairness issues. One scenario when they
546
+ can coexist safely is when the CA flows have RTTs << CC flows RTTs.
547
547
548
- For further details see http://www.brakmo.org/networking/tcp-nv/
548
+ For further details see http://www.brakmo.org/networking/tcp-nv/
549
549
550
550
config TCP_CONG_SCALABLE
551
551
tristate "Scalable TCP"
552
552
default n
553
553
---help---
554
- Scalable TCP is a sender-side only change to TCP which uses a
555
- MIMD congestion control algorithm which has some nice scaling
556
- properties, though is known to have fairness issues.
557
- See http://www.deneholme.net/tom/scalable/
554
+ Scalable TCP is a sender-side only change to TCP which uses a
555
+ MIMD congestion control algorithm which has some nice scaling
556
+ properties, though is known to have fairness issues.
557
+ See http://www.deneholme.net/tom/scalable/
558
558
559
559
config TCP_CONG_LP
560
560
tristate "TCP Low Priority"
561
561
default n
562
562
---help---
563
- TCP Low Priority (TCP-LP), a distributed algorithm whose goal is
564
- to utilize only the excess network bandwidth as compared to the
565
- ``fair share`` of bandwidth as targeted by TCP.
566
- See http://www-ece.rice.edu/networks/TCP-LP/
563
+ TCP Low Priority (TCP-LP), a distributed algorithm whose goal is
564
+ to utilize only the excess network bandwidth as compared to the
565
+ ``fair share`` of bandwidth as targeted by TCP.
566
+ See http://www-ece.rice.edu/networks/TCP-LP/
567
567
568
568
config TCP_CONG_VENO
569
569
tristate "TCP Veno"
570
570
default n
571
571
---help---
572
- TCP Veno is a sender-side only enhancement of TCP to obtain better
573
- throughput over wireless networks. TCP Veno makes use of state
574
- distinguishing to circumvent the difficult judgment of the packet loss
575
- type. TCP Veno cuts down less congestion window in response to random
576
- loss packets.
577
- See <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1177186>
572
+ TCP Veno is a sender-side only enhancement of TCP to obtain better
573
+ throughput over wireless networks. TCP Veno makes use of state
574
+ distinguishing to circumvent the difficult judgment of the packet loss
575
+ type. TCP Veno cuts down less congestion window in response to random
576
+ loss packets.
577
+ See <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1177186>
578
578
579
579
config TCP_CONG_YEAH
580
580
tristate "YeAH TCP"
581
581
select TCP_CONG_VEGAS
582
582
default n
583
583
---help---
584
- YeAH-TCP is a sender-side high-speed enabled TCP congestion control
585
- algorithm, which uses a mixed loss/delay approach to compute the
586
- congestion window. It's design goals target high efficiency,
587
- internal, RTT and Reno fairness, resilience to link loss while
588
- keeping network elements load as low as possible.
584
+ YeAH-TCP is a sender-side high-speed enabled TCP congestion control
585
+ algorithm, which uses a mixed loss/delay approach to compute the
586
+ congestion window. It's design goals target high efficiency,
587
+ internal, RTT and Reno fairness, resilience to link loss while
588
+ keeping network elements load as low as possible.
589
589
590
- For further details look here:
591
- http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf
590
+ For further details look here:
591
+ http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf
592
592
593
593
config TCP_CONG_ILLINOIS
594
594
tristate "TCP Illinois"
595
595
default n
596
596
---help---
597
- TCP-Illinois is a sender-side modification of TCP Reno for
598
- high speed long delay links. It uses round-trip-time to
599
- adjust the alpha and beta parameters to achieve a higher average
600
- throughput and maintain fairness.
597
+ TCP-Illinois is a sender-side modification of TCP Reno for
598
+ high speed long delay links. It uses round-trip-time to
599
+ adjust the alpha and beta parameters to achieve a higher average
600
+ throughput and maintain fairness.
601
601
602
- For further details see:
603
- http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
602
+ For further details see:
603
+ http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
604
604
605
605
config TCP_CONG_DCTCP
606
606
tristate "DataCenter TCP (DCTCP)"
607
607
default n
608
608
---help---
609
- DCTCP leverages Explicit Congestion Notification (ECN) in the network to
610
- provide multi-bit feedback to the end hosts. It is designed to provide:
609
+ DCTCP leverages Explicit Congestion Notification (ECN) in the network to
610
+ provide multi-bit feedback to the end hosts. It is designed to provide:
611
611
612
- - High burst tolerance (incast due to partition/aggregate),
613
- - Low latency (short flows, queries),
614
- - High throughput (continuous data updates, large file transfers) with
615
- commodity, shallow-buffered switches.
612
+ - High burst tolerance (incast due to partition/aggregate),
613
+ - Low latency (short flows, queries),
614
+ - High throughput (continuous data updates, large file transfers) with
615
+ commodity, shallow-buffered switches.
616
616
617
- All switches in the data center network running DCTCP must support
618
- ECN marking and be configured for marking when reaching defined switch
619
- buffer thresholds. The default ECN marking threshold heuristic for
620
- DCTCP on switches is 20 packets (30KB) at 1Gbps, and 65 packets
621
- (~100KB) at 10Gbps, but might need further careful tweaking.
617
+ All switches in the data center network running DCTCP must support
618
+ ECN marking and be configured for marking when reaching defined switch
619
+ buffer thresholds. The default ECN marking threshold heuristic for
620
+ DCTCP on switches is 20 packets (30KB) at 1Gbps, and 65 packets
621
+ (~100KB) at 10Gbps, but might need further careful tweaking.
622
622
623
- For further details see:
624
- http://simula.stanford.edu/~alizade/Site/DCTCP_files/dctcp-final.pdf
623
+ For further details see:
624
+ http://simula.stanford.edu/~alizade/Site/DCTCP_files/dctcp-final.pdf
625
625
626
626
config TCP_CONG_CDG
627
627
tristate "CAIA Delay-Gradient (CDG)"
628
628
default n
629
629
---help---
630
- CAIA Delay-Gradient (CDG) is a TCP congestion control that modifies
631
- the TCP sender in order to:
630
+ CAIA Delay-Gradient (CDG) is a TCP congestion control that modifies
631
+ the TCP sender in order to:
632
632
633
633
o Use the delay gradient as a congestion signal.
634
634
o Back off with an average probability that is independent of the RTT.
635
635
o Coexist with flows that use loss-based congestion control.
636
636
o Tolerate packet loss unrelated to congestion.
637
637
638
- For further details see:
639
- D.A. Hayes and G. Armitage. "Revisiting TCP congestion control using
640
- delay gradients." In Networking 2011. Preprint: http://goo.gl/No3vdg
638
+ For further details see:
639
+ D.A. Hayes and G. Armitage. "Revisiting TCP congestion control using
640
+ delay gradients." In Networking 2011. Preprint: http://goo.gl/No3vdg
641
641
642
642
config TCP_CONG_BBR
643
643
tristate "BBR TCP"
644
644
default n
645
645
---help---
646
646
647
- BBR (Bottleneck Bandwidth and RTT) TCP congestion control aims to
648
- maximize network utilization and minimize queues. It builds an explicit
649
- model of the the bottleneck delivery rate and path round-trip
650
- propagation delay. It tolerates packet loss and delay unrelated to
651
- congestion. It can operate over LAN, WAN, cellular, wifi, or cable
652
- modem links. It can coexist with flows that use loss-based congestion
653
- control, and can operate with shallow buffers, deep buffers,
654
- bufferbloat, policers, or AQM schemes that do not provide a delay
655
- signal. It requires the fq ("Fair Queue") pacing packet scheduler.
647
+ BBR (Bottleneck Bandwidth and RTT) TCP congestion control aims to
648
+ maximize network utilization and minimize queues. It builds an explicit
649
+ model of the the bottleneck delivery rate and path round-trip
650
+ propagation delay. It tolerates packet loss and delay unrelated to
651
+ congestion. It can operate over LAN, WAN, cellular, wifi, or cable
652
+ modem links. It can coexist with flows that use loss-based congestion
653
+ control, and can operate with shallow buffers, deep buffers,
654
+ bufferbloat, policers, or AQM schemes that do not provide a delay
655
+ signal. It requires the fq ("Fair Queue") pacing packet scheduler.
656
656
657
657
choice
658
658
prompt "Default TCP congestion control"
0 commit comments