Tuning settings for Microsoft Windows. Windows 8/10. The 'PowerShell' is the mechanism that. Specifies whether to enable ECN capability. May 14, 2014 Enable CTCP and ECN In Windows may reduce latency in some online applications. ECN Capability -'Enabled'. ECN (Explicit Congestion Notification, RFC 3168) is a mechanism that provides routers with an alternate method of communicating network congestion.
Internet protocol suite |
---|
Application layer |
Transport layer |
Internet layer |
|
Link layer |
|
Explicit Congestion Notification (ECN) is an extension to the Internet Protocol and to the Transmission Control Protocol and is defined in RFC 3168 (2001). ECN allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that may be used between two ECN-enabled endpoints when the underlying network infrastructure also supports it.
Conventionally, TCP/IP networks signal congestion by dropping packets. When ECN is successfully negotiated, an ECN-aware router may set a mark in the IP header instead of dropping a packet in order to signal impending congestion. The receiver of the packet echoes the congestion indication to the sender, which reduces its transmission rate as if it detected a dropped packet.
Rather than responding properly or ignoring the bits, some outdated or faulty network equipment has historically dropped or mangled packets that have ECN bits set.[1][2][3] As of 2015, measurements suggested that the fraction of web servers on the public Internet for which setting ECN prevents network connections had been reduced to less than 1%.[4]
Passive support has existed in Ubuntu Linux since 12.04 and in Windows Server since 2012.[5] Passive support in the most popular websites has increased from 8.5% in 2012 to over 70% in May 2017.[5] Adoption across the Internet now requires clients to actively request ECN. In June 2015, Apple announced that ECN will be enabled by default on its supported and future products, to help drive the adoption of ECN signaling industry-wide.[6]
- 1Operation
- 1.2Operation of ECN with TCP
- 3Implementations
- 3.1ECN support in TCP by hosts
Operation[edit]
ECN requires specific support at both the Internet layer and the transport layer for the following reasons:
- In TCP/IP, routers operate within the Internet layer, while the transmission rate is handled by the endpoints at the transport layer.
- Congestion may be handled only by the transmitter, but since it is known to have happened only after a packet was sent, there must be an echo of the congestion indication by the receiver to the transmitter.
Without ECN, congestion indication echo is achieved indirectly by the detection of lost packets. With ECN, the congestion is indicated by setting the ECN field within an IP packet to CE and is echoed back by the receiver to the transmitter by setting proper bits in the header of the transport protocol. For example, when using TCP, the congestion indication is echoed back by setting the ECE bit.
Operation of ECN with IP[edit]
ECN uses the two least significant (right-most) bits of the DiffServ field in the IPv4 or IPv6 header to encode four different code points:
00
– Non ECN-Capable Transport, Non-ECT10
– ECN Capable Transport, ECT(0)01
– ECN Capable Transport, ECT(1)11
– Congestion Encountered, CE.
When both endpoints support ECN they mark their packets with ECT(0) or ECT(1). If the packet traverses an active queue management (AQM) queue (e.g., a queue that uses random early detection (RED)) that is experiencing congestion and the corresponding router supports ECN, it may change the code point to
CE
instead of dropping the packet. This act is referred to as “marking” and its purpose is to inform the receiving endpoint of impending congestion. At the receiving endpoint, this congestion indication is handled by the upper layer protocol (transport layer protocol) and needs to be echoed back to the transmitting node in order to signal it to reduce its transmission rate.Because the CE indication can only be handled effectively by an upper layer protocol that supports it, ECN is only used in conjunction with upper layer protocols, such as TCP, that support congestion control and have a method for echoing the CE indication to the transmitting endpoint.
Operation of ECN with TCP[edit]
TCP supports ECN using two flags in the TCP header. The first, ECN-Echo (ECE) is used to echo back the congestion indication (i.e. signal the sender to reduce the amount of information it sends). The second, Congestion Window Reduced (CWR), to acknowledge that the congestion-indication echoing was received. Use of ECN on a TCP connection is optional; for ECN to be used, it must be negotiated at connection establishment by including suitable options in the SYN and SYN-ACK segments.
When ECN has been negotiated on a TCP connection, the sender indicates that IP packets that carry TCP segments of that connection are carrying traffic from an ECN Capable Transport by marking them with an ECT code point. This allows intermediate routers that support ECN to mark those IP packets with the CE code point instead of dropping them in order to signal impending congestion.
Upon receiving an IP packet with the Congestion Experienced code point, the TCP receiver echoes back this congestion indication using the ECE flag in the TCP header. When an endpoint receives a TCP segment with the ECE bit it reduces its congestion window as for a packet drop. It then acknowledges the congestion indication by sending a segment with the CWR bit set.
A node keeps transmitting TCP segments with the ECE bit set until it receives a segment with the CWR bit set.
To see affected packets with tcpdump, use the filter predicate
(tcp[13] & 0xc0 != 0)
.ECN and TCP control packets[edit]
Since the Transmission Control Protocol (TCP) does not perform congestion control on control packets (pure ACKs, SYN, FIN segments), control packets are usually not marked as ECN-capable.
A 2009 proposal[7] suggests marking SYN-ACK packets as ECN-capable. This improvement, known as ECN+, has been shown to provide dramatic improvements to performance of short-lived TCP connections.[8]
Operation of ECN with other transport protocols[edit]
ECN is also defined for other transport layer protocols that perform congestion control, notably DCCP and Stream Control Transmission Protocol (SCTP). The general principle is similar to TCP, although the details of the on-the-wire encoding differ.
It should in principle be possible to use ECN with protocols layered above UDP. However, UDP requires that congestion control be performed by the application, and current networking APIs do not give access to the ECN bits[citation needed].
Effects on performance[edit]
Since ECN is only effective in combination with an Active Queue Management (AQM) policy, the benefits of ECN depend on the precise AQM being used. A few observations, however, appear to hold across different AQMs.
As expected, ECN reduces the number of packets dropped by a TCP connection, which, by avoiding a retransmission, reduces latency and especially jitter. This effect is most drastic when the TCP connection has a single outstanding segment,[9] when it is able to avoid an RTO timeout; this is often the case for interactive connections, such as remote logins, and transactional protocols, such as HTTP requests, the conversational phase of SMTP, or SQL requests.
Effects of ECN on bulk throughput are less clear[10] because modern TCP implementations are fairly good at resending dropped segments in a timely manner when the sender's window is large.
Use of ECN has been found to be detrimental to performance on highly congested networks when using AQM algorithms that never drop packets.[8] Modern AQM implementations avoid this pitfall by dropping rather than marking packets at very high load.
Implementations[edit]
Many modern implementations of the TCP/IP protocol suite have some support for ECN; however, they usually ship with ECN disabled.
ECN support in TCP by hosts[edit]
Microsoft Windows[edit]
Windows versions since Windows Server 2008 and Windows Vista support ECN for TCP.[11] Since Windows Server 2012, it is enabled by default in Windows Server versions, because Data Center Transmission Control Protocol (DCTCP) is used.[12] In previous Windows versions and non-server versions it is disabled by default.
ECN support can be enabled using a shell command such as netsh interface tcp set global ecncapability=enabled.
BSD[edit]
FreeBSD 8.0 and NetBSD 4.0 implement ECN support for TCP; it can be activated through the sysctl interface by setting 1 as value for the sysctl net.inet.tcp.ecn.enable parameter. Likewise, the sysctl net.inet.tcp.ecn can be used in OpenBSD.[13][14]
Linux[edit]
Since version 2.4.20 of the Linux kernel, released in November 2002,[15] Linux supports three working modes of the ECN for TCP, as configured through the sysctl interface by setting parameter /proc/sys/net/ipv4/tcp_ecn to one of the following values:[16]
- 0 – disable ECN and neither initiate nor accept it
- 1 – enable ECN when requested by incoming connections, and also request ECN on outgoing connection attempts
- 2 – (default) enable ECN when requested by incoming connections, but do not request ECN on outgoing connections
Beginning with version 4.1 of the Linux kernel, released in June 2015, the tcp_ecn_fallback mechanism, as specified in RFC 3168 section 6.1.1.1,[17] is enabled by default[18] when ECN is enabled (the value of 1). The fallback mechanism attempts ECN connectivity in the initial setup of outgoing connections, with a graceful fallback for transmissions without ECN capability, mitigating issues with ECN-intolerant hosts or firewalls.
Mac OS X[edit]
Mac OS X 10.5 and 10.6 implement ECN support for TCP. It is controlled using the boolean sysctl variables net.inet.tcp.ecn_negotiate_in and net.inet.tcp.ecn_initiate_out.[19] The first variable enables ECN on incoming connections that already have ECN flags set; the second one tries to initiate outgoing connections with ECN enabled. Both variables default to 0, but can be set to 1 to enable the respective behavior.
In June 2015, Apple Inc. announced that OS X 10.11 would have ECN turned on by default.[6] That never happened, in macOS Sierra, ECN is enabled for 50 percent of TCP sessions [20]
iOS[edit]
In June 2015, Apple Inc. announced that iOS 9, its next version of iOS, would support ECN and have it turned on by default.[6] TCP ECN negotiation is enabled on 5% of randomly selected connections over Wi-Fi / Ethernet in iOS 9 and 50% of randomly selected connections over Wi-Fi / Ethernet and a few cellular carriers in iOS 10[21][22] and 100% for iOS 11[23]
Solaris[edit]
The Solaris kernel supports three states of ECN for TCP:[citation needed]
- never – no ECN
- active – use ECN
- passive – only advertise ECN support when asked for.
The default behavior is passive. As of Solaris 11, full ECN usage can be activated via ipadm set-prop -p ecn=active tcp.[citation needed]
ECN support in IP by routers[edit]
Since ECN marking in routers is dependent on some form of active queue management, routers must be configured with a suitable queue discipline in order to perform ECN marking.
Cisco IOS routers perform ECN marking if configured with the WRED queuing discipline since version 12.2(8)T.
Linux routers perform ECN marking if configured with one of the RED or GRED queue disciplines with an explicit ecn parameter, by using the sfb discipline, by using the CoDel Fair Queuing (fq_codel) discipline, or the CAKE[24] queuing discipline.
Modern BSD implementations, such as FreeBSD, NetBSD and OpenBSD, have support for ECN marking in the ALTQ queueing implementation for a number of queuing disciplines, notably RED and Blue. FreeBSD 11 included CoDel, PIE, FQ-CoDel and FQ-PIE queuing disciplines implementation in ipfw/dummynet framework with ECN marking capability.[25]
Data Center TCP[edit]
Data Center Transmission Control Protocol (Data Center TCP or DCTCP) utilizes ECN to enhance the Transmission Control Protocol congestion control algorithm. It is used in data center networks. Whereas the standard TCP congestion control algorithm is only able to detect the presence of congestion, DCTCP, using ECN, is able to gauge the extent of congestion.[26]
DCTCP modifies the TCP receiver to always relay the exact ECN marking of incoming packets at the cost of ignoring a function that is meant to preserve signalling reliability. This makes a DCTCP sender vulnerable to loss of ACKs from the receiver, which it has no mechanism to detect or cope with.[27] As of July 2014, algorithms that provide equivalent or better receiver feedback in a more reliable approach are an active research topic.[28]
See also[edit]
- Backward ECN (BECN)
- Type of service (ToS)
References[edit]
- ^Steven Bauer; Robert Beverly; Arthur Berger (2011). 'Measuring the State of ECN Readiness in Servers, Clients, and Routers'(PDF). Internet Measurement Conference 2011. Archived(PDF) from the original on 2014-03-22.
- ^Alberto Medina; Mark Allman; Sally Floyd. 'Measuring Interactions Between Transport Protocols and Middleboxes'(PDF). Internet Measurement Conference 2004. Archived(PDF) from the original on 2016-03-04.
- ^'TBIT, the TCP Behavior Inference Tool: ECN'. Icir.org. Archived from the original on 2013-03-11. Retrieved 2014-03-22.
- ^Brian Trammell; Mirja Kühlewind; Damiano Boppart; Iain Learmonth; Gorry Fairhurst; Richard Scheffenegger (2015). 'Enabling Internet-Wide Deployment of Explicit Congestion Notification'(PDF). Proceedings of the Passive and Active Measurement Conference 2015. Archived from the original(PDF) on 15 June 2015. Retrieved 14 June 2015.
- ^ abDavid Murray; Terry Koziniec; Sebastian Zander; Michael Dixon; Polychronis Koutsakis (2017). 'An Analysis of Changing Enterprise Network Traffic Characteristics'(PDF). The 23rd Asia-Pacific Conference on Communications (APCC 2017). Archived(PDF) from the original on 3 October 2017. Retrieved 3 October 2017.
- ^ abc'Your App and Next Generation Networks'. Apple Inc. 2015. Archived from the original on 2015-06-15.
- ^RFC 5562 - Adding Explicit Congestion Notification Capability to TCP's SYN/ACK Packets.Archived 2010-09-02 at the Wayback Machine A. Kuzmanovic, A. Mondal, S. Floyd, K. Ramakrishnan
- ^ abAleksandar Kuzmanovic. The power of explicit congestion notification. In Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications. 2005.
- ^Jamal Hadi Salim and Uvaiz Ahmed. Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks. RFC 2884. July 2000
- ^Marek Malowidzki, Simulation-based Study of ECN Performance in RED Networks, In Proc. SPECTS'03. 2003.
- ^'New Networking Features in Windows Server 2008 and Windows Vista'. Archived from the original on 2010-01-15.
- ^'Data Center Transmission Control Protocol (DCTCP) (Windows Server 2012)'. Archived from the original on 2017-08-26.
- ^Michael Lucas. Absolute OpenBSD: UNIX for the Practical Paranoid. Books.google.com. Retrieved 2014-03-22.
- ^'Announcing NetBSD 4.0'. 2007-12-19. Archived from the original on 2014-10-31. Retrieved 2014-10-13.
- ^'A Map of the Networking Code in Linux Kernel 2.4.20, Technical Report DataTAG-2004-1, FP5/IST DataTAG Project'(PDF). datatag.web.cern.ch. March 2004. Archived(PDF) from the original on 27 October 2015. Retrieved 1 September 2015.
- ^'Documentation/networking/ip-sysctl.txt: /proc/sys/net/ipv4/* Variables'. kernel.org. Archived from the original on 2016-03-05. Retrieved 2016-02-15.
- ^'RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP'. ietf.org. September 2001. Archived from the original on 2016-02-05. Retrieved 2016-02-15.
- ^'Linux man pages'. man7.org. 2015-12-05. Archived from the original on 2016-02-16. Retrieved 2016-02-15.
- ^'ECN (Explicit Congestion Notification) in TCP/IP'. Archived from the original on 2012-06-19.
- ^'macOS 10.12 Sierra: The Ars Technica review'. Ars Technica. Archived from the original on 26 April 2018. Retrieved 25 April 2018.
- ^Inc., Apple. 'Networking for the Modern Internet - WWDC 2016 - Videos - Apple Developer'. Apple Developer. Archived from the original on 18 April 2018. Retrieved 18 April 2018.
- ^'Archived copy'(PDF). Archived(PDF) from the original on 2018-05-09. Retrieved 2017-05-03.CS1 maint: archived copy as title (link)
- ^Inc., Apple. 'Advances in Networking, Part 1 - WWDC 2017 - Videos - Apple Developer'. Apple Developer. Archived from the original on 31 January 2018. Retrieved 18 April 2018.
- ^Høiland-Jørgensen, Toke; Täht, Dave; Morton, Jonathan. 'Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways'.
- ^'Import Dummynet AQM version 0.2.1 (CoDel, FQ-CoDel, PIE and FQ-PIE) to FreeBSD 11'. The FreeBSD Project, FreeBSD r300779. Retrieved 5 August 2016.
- ^'Data Center TCP'. Archived from the original on 2016-12-23. Retrieved 2016-12-21.
- ^'Requirements for a More Accurate ECN Feedback'. tools.ietf.org. IETF. March 9, 2015. Archived from the original on November 19, 2015. Retrieved May 2, 2015.
- ^'RFC 7560: Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback'. tools.ietf.org. IETF. August 26, 2015. Archived from the original on April 29, 2016. Retrieved May 12, 2016.
External links[edit]
- RFC 4774 (BCP), Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field, S. Floyd, (November 2006)
- Linux kernel support for defining a per-route/destination congestion control algorithm (merged in Linux kernel 4.0)
Retrieved from 'https://en.wikipedia.org/w/index.php?title=Explicit_Congestion_Notification&oldid=916708156'
-->Syntax
Description
The Set-NetTCPSetting cmdlet modifies a TCP setting.TCP settings are optimized for different network conditions including latency and congestion.To apply a TCP setting to a port number or destination IP address range, create a transport filter by using the New-NetTransportFilter cmdlet.
Note
- You can modify Custom and Non-Custom settings on windows server 2016 and 2019.
- You can modify only Custom settings, Internet and Datacenter settings Cannot be modified on windows 2012 or earlier versions.
- You cannot modify the NetTCPsetting on Client Operating systems(Windows 7, 8.1 and 10) as they are Read-Only.
Examples
Example 1: Change the custom TCP setting
This command changes the custom TCP setting to have a value of 6 for the initial congestion window and use compound TCP.
Parameters
Runs the cmdlet as a background job. Use this parameter to run commands that take a long time to complete.
Type: | SwitchParameter |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies the number of ports for the auto-reuse port range, which is a port range used for local ephemeral port selection by outbound TCP connections for which either SO_REUSE_UNICASTPORT has been set on the socket, or for which connect() has been called without calling bind() on the socket.
![Ecn Capability Windows 10 Ecn Capability Windows 10](/uploads/1/2/6/2/126248434/974823814.png)
If you specify 0, the auto-reuse feature is disabled and ephemeral ports are drawn instead from the dynamic port range as specified by DynamicPortRangeStartPort and DynamicPortRangeNumberOfPorts, even if SO_REUSE_UNICASTPORT is set on a socket.
Type: | UInt16 |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies the number of ports for the auto-reuse port range, which is a port range used for local ephemeral port selection by outbound TCP connections for which either SO_REUSE_UNICASTPORT has been set on the socket, or for which connect() has been called without calling bind() on the socket.
If you specify 0, the auto-reuse feature is disabled and ephemeral ports are drawn instead from the dynamic port range as specified by DynamicPortRangeStartPort and DynamicPortRangeNumberOfPorts, even if SO_REUSE_UNICASTPORT is set on a socket.
Type: | UInt16 |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies a TCP auto-tuning level for the host computer.TCP auto-tuning can improve throughput on high throughput, high latency networks.The acceptable values for this parameter are:
- Disabled.Sets the TCP receive window to the default value.
- HighlyRestricted.Sets the TCP receive window to grow beyond the default value, but very conservatively.
- Restricted.Sets the TCP receive window to grow beyond the default value, but less conservatively than HighlyRestricted.
- Normal.Sets the TCP receive window to grow to accommodate almost all scenarios.
- Experimental.Sets the TCP receive window to grow to accommodate extreme scenarios.
Type: | AutoTuningLevelLocal |
Accepted values: | Disabled, HighlyRestricted, Restricted, Normal, Experimental |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies whether the automatic profile assigns a custom template, either Datacenter Custom or Internet Custom, to a connection.The acceptable values for this parameter are:
- True
- False
Type: | AutomaticUseCustom |
Accepted values: | Disabled, Enabled |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Runs the cmdlet in a remote session or on a remote computer.Enter a computer name or a session object, such as the output of a New-CimSession or Get-CimSession cmdlet.The default is the current session on the local computer.
Type: | CimSession[] |
Aliases: | Session |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Prompts you for confirmation before running the cmdlet.
Type: | SwitchParameter |
Aliases: | cf |
Position: | Named |
Default value: | False |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies the congestion provider property that TCP uses.The acceptable values for this parameter are:
- CTCP.Compound TCP increases the receive window and amount of data sent.CTCP can improve throughput on higher latency connections.
- DCTCP.Data Center TCP adjusts the TCP window based on network congestion feedback based on Explicit Congestion Notification (ECN) signaling.DCTCP may improve throughput on low latency links.
- Default.Servers use DCTCP by default.Client computers use NewReno.For information about NewReno, see RFC 3782.
Type: | CongestionProvider |
Accepted values: | Default, CTCP, DCTCP |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies whether to enable congestion window restart.Congestion window restart can avoid slow start to optimize throughput on low latency networks.For more information about congestion window restart, see RFC 2581.The acceptable values for this parameter are:
- True.TCP uses congestion window restart.
- False.TCP uses the default setting of the connection.
Type: | CwndRestart |
Accepted values: | False, True |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies the number of acknowledgments (ACKs) received before the computer sends a response.
Type: | Byte |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies the time to wait, in milliseconds, before the computer sends an ACK if the computer receives fewer than delayed acknowledgment frequency of packets.Use the DelayedAckFrequency parameter to specify the delayed ACK frequency value.Reducing the time to wait can increase throughput on low latency networks by accelerating growth in TCP window size.The acceptable values for this parameter are: increments of 10, from 10 through 600.
Type: | UInt32 |
Aliases: | DelayedAckTimeout |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies the number of ports for the dynamic port range that starts from the port that you specify for the DynamicPortRangeStartPort parameter.
Type: | UInt16 |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies the starting port for the dynamic port range.This parameter sets the starting port to send and receive TCP traffic.The acceptable values for this parameter are: 1 through 65535.
Type: | UInt16 |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies whether to enable ECN capability.The acceptable values for this parameter are:
- Enabled.Uses ECN capability.
- Disabled.Does not use ECN capability.
If you specify a value of Disabled, UseECT0, or UseEct1 for the EcnMarking parameter of the Set-NetIPInterface cmdlet, the current parameter has no effect.
Type: | EcnCapability |
Accepted values: | Disabled, Enabled |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies whether to force window scaling for retransmission.The acceptable values for this parameter are:
- Enabled.Requires window scaling for retransmission.
- Disabled.Does not require window scaling for retransmission.
The default value is Disabled.
Type: | ForceWS |
Accepted values: | Disabled, Enabled |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies the initial size of the congestion window.Provide a value to multiply by the maximum segment size (MSS).The acceptable values for this parameter are: even numbers from 2 through 64.
Type: | UInt32 |
Aliases: | InitialCongestionWindow |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies the period, in milliseconds, before connect, or SYN, retransmit.The acceptable values for this parameter are: increments of 10, from 300 ms through 3000 ms.
Type: | UInt32 |
Aliases: | InitialRto |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
![Capability Capability](http://lifeofageekadmin.com/wp-content/uploads/2016/08/2012defaultglobalmod1.png)
Specifies the input object that is used in a pipeline command.
Type: | CimInstance[] |
Position: | Named |
Default value: | None |
Accept pipeline input: | True (ByValue) |
Accept wildcard characters: | False |
Specifies the maximum number of times the computer sends SYN packets without receiving a response.
Type: | Byte |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies whether to use memory pressure protection.TCP memory pressure protection helps ensure that a computer continues normal operation when low on memory due to denial of service attacks.The acceptable values for this parameter are:
- Enabled.When low on memory, during an attack, close existing TCP connections and drop incoming SYN requests.
- Disabled.Do not use memory pressure protection.
- Default.Use the computer default value for memory pressure protection.
Type: | MemoryPressureProtection |
Accepted values: | Disabled, Enabled, Default |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies a value, in milliseconds, for the TCP retransmission to time out.The acceptable values for this parameter are: increments of 10, from 20 ms through 300 ms.
Type: | UInt32 |
Aliases: | MinRto |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies whether to enable round trip time resiliency for clients that do not support selective acknowledgment.The acceptable values for this parameter are:
- Enabled
- Disabled
Type: | NonSackRttResiliency |
Accepted values: | Disabled, Enabled |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Returns an object representing the item with which you are working.By default, this cmdlet does not generate any output.
Type: | SwitchParameter |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies whether to enable scaling heuristics.The acceptable values for this parameter are:
- Enabled
- Disabled
Type: | ScalingHeuristics |
Accepted values: | Disabled, Enabled |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies an array of setting names.You can specify only Custom for this parameter.
Type: | String[] |
Position: | 0 |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies the maximum number of concurrent operations that can be established to run the cmdlet.If this parameter is omitted or a value of
0
is entered, then Windows PowerShell速 calculates an optimum throttle limit for the cmdlet based on the number of CIM cmdlets that are running on the computer.The throttle limit applies only to the current cmdlet, not to the session or to the computer.Type: | Int32 |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Specifies whether to enable timestamps.Timestamps facilitate round trip measurement, and can help protect against wrapped sequence numbers on high throughput links.For more information about TCP timestamps, see RFC 1323.The acceptable values for this parameter are:
- Enabled
- Disabled
Type: | Timestamps |
Accepted values: | Disabled, Enabled |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Shows what would happen if the cmdlet runs.The cmdlet is not run.
Type: | SwitchParameter |
Aliases: | wi |
Position: | Named |
Default value: | False |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Inputs
Microsoft.Management.Infrastructure.CimInstance#rootStandardCimv2MSFT_NetTCPSetting
The
Microsoft.Management.Infrastructure.CimInstance
object is a wrapper class that displays Windows Management Instrumentation (WMI) objects.The path after the pound sign (#
) provides the namespace and class name for the underlying WMI object.Outputs
None