TCP-ESTATS-MIB: View SNMP OID List / Download MIB

Documentation of TCP Extended Performance Instrumentation variables from the Web100 project. [Web100] All of the objects in this MIB MUST have the same persistence properties as the underlying TCP implementation. On a reboot, all zero-based counters MUST be cleared, all dynamically created table rows MUST be deleted, and all read-write objects MUST be restored to their default values. It is assumed that all TCP implementation have some initialization code (if nothing else to set IP addresses) that has the opportunity to adjust tcpEStatsConnTableLatency and other read-write scalars controlling the creation of the various tables, before establishing the first TCP connection. Implementations MAY also choose to make these control scalars persist across reboots. Copyright (C) The IETF Trust (2007). This version of this MIB module is a part of RFC 4898; see the RFC itself for full legal notices.

The indicated connection has been accepted (or alternatively entered the established state).

The indicated connection has left the established state

This table contains information about TCP Listeners, in addition to the information maintained by the tcpListenerTable RFC 4022.

Each entry in the table contains information about a specific TCP Listener.

The value of sysUpTime at the time this listener was established. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value.

The number of SYNs which have been received for this listener. The total number of failed connections for all reasons can be estimated to be tcpEStatsListenerSynRcvd minus tcpEStatsListenerAccepted and tcpEStatsListenerCurBacklog.

The total number of connections for which the Listener has allocated initial state and placed the connection in the backlog. This may happen in the SYN-RCVD or ESTABLISHED states, depending on the implementation.

The number of connections that have been established to this endpoint (e.g., the number of first ACKs that have been received for this listener).

The total number of connections for which the Listener has successfully issued an accept, removing the connection from the backlog.

The total number of connections dropped from the backlog by this listener due to all reasons. This includes all connections that are allocated initial resources, but are not accepted for some reason.

The number of SYNs that have been received for this listener on systems that can process (or reject) more than 1 million connections per second. See tcpEStatsListenerSynRcvd.

The total number of connections for which the Listener has allocated initial state and placed the connection in the backlog on systems that can process (or reject) more than 1 million connections per second. See tcpEStatsListenerInitial.

The number of connections that have been established to this endpoint on systems that can process (or reject) more than 1 million connections per second. See tcpEStatsListenerEstablished.

The total number of connections for which the Listener has successfully issued an accept, removing the connection from the backlog on systems that can process (or reject) more than 1 million connections per second. See tcpEStatsListenerAccepted.

The total number of connections dropped from the backlog by this listener due to all reasons on systems that can process (or reject) more than 1 million connections per second. See tcpEStatsListenerExceedBacklog.

The current number of connections in the ESTABLISHED state, which have also been accepted. It excludes connections that have been established but not accepted because they are still subject to being discarded to shed load without explicit action by either endpoint.

The maximum number of connections allowed in the backlog at one time.

The current number of connections that are in the backlog. This gauge includes connections in ESTABLISHED or SYN-RECEIVED states for which the Listener has not yet issued an accept. If this listener is using some technique to implicitly represent the SYN-RECEIVED states (e.g., by cryptographically encoding the state information in the initial sequence number, ISS), it MAY elect to exclude connections in the SYN-RECEIVED state from the backlog.

The current number of connections in the backlog that are in the ESTABLISHED state, but for which the Listener has not yet issued an accept.

This table maps information that uniquely identifies each active TCP connection to the connection ID used by other tables in this MIB Module. It is an extension of tcpConnectionTable in RFC 4022. Entries are retained in this table for the number of seconds indicated by the tcpEStatsConnTableLatency object, after the TCP connection first enters the closed state.

Each entry in this table maps a TCP connection 4-tuple to a connection index.

A unique integer value assigned to each TCP Connection entry. The RECOMMENDED algorithm is to begin at 1 and increase to some implementation-specific maximum value and then start again at 1 skipping values already in use.

This table contains objects that are useful for measuring TCP performance and first line problem diagnosis. Most objects in this table directly expose some TCP state variable or are easily implemented as simple functions (e.g., the maximum value) of TCP state variables. Entries are retained in this table for the number of seconds indicated by the tcpEStatsConnTableLatency object, after the TCP connection first enters the closed state.

Each entry in this table has information about the characteristics of each active and recently closed TCP connection.

The total number of segments sent.

The number of segments sent containing a positive length data segment.

The number of octets of data contained in transmitted segments, including retransmitted data. Note that this does not include TCP headers.

The number of octets of data contained in transmitted segments, including retransmitted data, on systems that can transmit more than 10 million bits per second. Note that this does not include TCP headers.

The number of segments transmitted containing at least some retransmitted data.

The number of octets retransmitted.

The total number of segments received.

The number of segments received containing a positive length data segment.

The number of octets contained in received data segments, including retransmitted data. Note that this does not include TCP headers.

The number of octets contained in received data segments, including retransmitted data, on systems that can receive more than 10 million bits per second. Note that this does not include TCP headers.

The seconds part of the time elapsed between tcpEStatsPerfStartTimeStamp and the most recent protocol event (segment sent or received).

The micro-second part of time elapsed between tcpEStatsPerfStartTimeStamp to the most recent protocol event (segment sent or received). This may be updated in whatever time granularity is the system supports.

Time at which this row was created and all ZeroBasedCounters in the row were initialized to zero.

The current maximum segment size (MSS), in octets.

The TCP senders current estimate of the number of unacknowledged data octets in the network. While not in recovery (e.g., while the receiver is not reporting missing data to the sender), this is precisely the same as 'Flight size' as defined in RFC 2581, which can be computed as SND.NXT minus SND.UNA. [RFC793] During recovery, the TCP sender has incomplete information about the state of the network (e.g., which segments are lost vs reordered, especially if the return path is also dropping TCP acknowledgments). Current TCP standards do not mandate any specific algorithm for estimating the number of unacknowledged data octets in the network. RFC 3517 describes a conservative algorithm to use SACK information to estimate the number of unacknowledged data octets in the network. tcpEStatsPerfPipeSize object SHOULD be the same as 'pipe' as defined in RFC 3517 if it is implemented. (Note that while not in recovery the pipe algorithm yields the same values as flight size). If RFC 3517 is not implemented, the data octets in flight SHOULD be estimated as SND.NXT minus SND.UNA adjusted by some measure of the data that has left the network and retransmitted data. For example, with Reno or NewReno style TCP, the number of duplicate acknowledgment is used to count the number of segments that have left the network. That is, PipeSize=SND.NXT-SND.UNA+(retransmits-dupacks)*CurMSS

The maximum value of tcpEStatsPerfPipeSize, for this connection.

The smoothed round trip time used in calculation of the RTO. See SRTT in [RFC2988].

The current value of the retransmit timer RTO.

The number of multiplicative downward congestion window adjustments due to all forms of congestion signals, including Fast Retransmit, Explicit Congestion Notification (ECN), and timeouts. This object summarizes all events that invoke the MD portion of Additive Increase Multiplicative Decrease (AIMD) congestion control, and as such is the best indicator of how a cwnd is being affected by congestion. Note that retransmission timeouts multiplicatively reduce the window implicitly by setting ssthresh, and SHOULD be included in tcpEStatsPerfCongSignals. In order to minimize spurious congestion indications due to out-of-order segments, tcpEStatsPerfCongSignals SHOULD be incremented in association with the Fast Retransmit algorithm.

The current congestion window, in octets.

The current slow start threshold in octets.

The number of times the retransmit timeout has expired when the RTO backoff multiplier is equal to one.

The most recent window advertisement sent, in octets.

The maximum window advertisement sent, in octets.

The number of acknowledgments sent announcing a zero receive window, when the previously announced window was not zero.

The most recent window advertisement received, in octets.

The maximum window advertisement received, in octets.

The number of acknowledgments received announcing a zero receive window, when the previously announced window was not zero.

The number of transitions into the 'Receiver Limited' state from either the 'Congestion Limited' or 'Sender Limited' states. This state is entered whenever TCP transmission stops because the sender has filled the announced receiver window, i.e., when SND.NXT has advanced to SND.UNA + SND.WND - 1 as described in RFC 793.

The number of transitions into the 'Congestion Limited' state from either the 'Receiver Limited' or 'Sender Limited' states. This state is entered whenever TCP transmission stops because the sender has reached some limit defined by congestion control (e.g., cwnd) or other algorithms (retransmission timeouts) designed to control network traffic. See the definition of 'CONGESTION WINDOW' in RFC 2581.

The number of transitions into the 'Sender Limited' state from either the 'Receiver Limited' or 'Congestion Limited' states. This state is entered whenever TCP transmission stops due to some sender limit such as running out of application data or other resources and the Karn algorithm. When TCP stops sending data for any reason, which cannot be classified as Receiver Limited or Congestion Limited, it MUST be treated as Sender Limited.

The cumulative time spent in the 'Receiver Limited' state. See tcpEStatsPerfSndLimTransRwin.

The cumulative time spent in the 'Congestion Limited' state. See tcpEStatsPerfSndLimTransCwnd. When there is a retransmission timeout, it SHOULD be counted in tcpEStatsPerfSndLimTimeCwnd (and not the cumulative time for some other state.)

The cumulative time spent in the 'Sender Limited' state. See tcpEStatsPerfSndLimTransSnd.

This table contains objects that can be used to infer detailed behavior of the Internet path, such as the extent that there is reordering, ECN bits, and if RTT fluctuations are correlated to losses. Entries are retained in this table for the number of seconds indicated by the tcpEStatsConnTableLatency object, after the TCP connection first enters the closed state.

Each entry in this table has information about the characteristics of each active and recently closed TCP connection.

The number of duplicate acknowledgments required to trigger Fast Retransmit. Note that although this is constant in traditional Reno TCP implementations, it is adaptive in many newer TCPs.

The number of duplicate acknowledgment episodes that did not trigger a Fast Retransmit because ACK advanced prior to the number of duplicate acknowledgments reaching RetranThresh. In many implementations this is the number of times the 'dupacks' counter is set to zero when it is non-zero but less than RetranThresh. Note that the change in tcpEStatsPathNonRecovDAEpisodes divided by the change in tcpEStatsPerfDataSegsOut is an estimate of the frequency of data reordering on the forward path over some interval.

The sum of the amounts SND.UNA advances on the acknowledgment which ends a dup-ack episode without a retransmission. Note the change in tcpEStatsPathSumOctetsReordered divided by the change in tcpEStatsPathNonRecovDAEpisodes is an estimates of the average reordering distance, over some interval.

Duplicate acks (or SACKS) that did not trigger a Fast Retransmit because ACK advanced prior to the number of duplicate acknowledgments reaching RetranThresh. In many implementations, this is the sum of the 'dupacks' counter, just before it is set to zero because ACK advanced without a Fast Retransmit. Note that the change in tcpEStatsPathNonRecovDA divided by the change in tcpEStatsPathNonRecovDAEpisodes is an estimate of the average reordering distance in segments over some interval.

The most recent raw round trip time measurement used in calculation of the RTO.

The round trip time variation used in calculation of the RTO. See RTTVAR in [RFC2988].

The maximum sampled round trip time.

The minimum sampled round trip time.

The sum of all sampled round trip times. Note that the change in tcpEStatsPathSumRTT divided by the change in tcpEStatsPathCountRTT is the mean RTT, uniformly averaged over an enter interval.

The sum of all sampled round trip times, on all systems that implement multiple concurrent RTT measurements. Note that the change in tcpEStatsPathHCSumRTT divided by the change in tcpEStatsPathCountRTT is the mean RTT, uniformly averaged over an enter interval.

The number of round trip time samples included in tcpEStatsPathSumRTT and tcpEStatsPathHCSumRTT.

The maximum value of the retransmit timer RTO.

The minimum value of the retransmit timer RTO.

The value of the TTL field carried in the most recently received IP header. This is sometimes useful to detect changing or unstable routes.

The value of the IPv4 Type of Service octet, or the IPv6 traffic class octet, carried in the most recently received IP header. This is useful to diagnose interactions between TCP and any IP layer packet scheduling and delivery policy, which might be in effect to implement Diffserv.

The value of the IPv4 Type Of Service octet, or the IPv6 traffic class octet, carried in the most recently transmitted IP header. This is useful to diagnose interactions between TCP and any IP layer packet scheduling and delivery policy, which might be in effect to implement Diffserv.

The sum of the values of the congestion window, in octets, captured each time a congestion signal is received. This MUST be updated each time tcpEStatsPerfCongSignals is incremented, such that the change in tcpEStatsPathPreCongSumCwnd divided by the change in tcpEStatsPerfCongSignals is the average window (over some interval) just prior to a congestion signal.

Sum of the last sample of the RTT (tcpEStatsPathSampleRTT) prior to the received congestion signals. This MUST be updated each time tcpEStatsPerfCongSignals is incremented, such that the change in tcpEStatsPathPreCongSumRTT divided by the change in tcpEStatsPerfCongSignals is the average RTT (over some interval) just prior to a congestion signal.

Sum of the first sample of the RTT (tcpEStatsPathSampleRTT) following each congestion signal. Such that the change in tcpEStatsPathPostCongSumRTT divided by the change in tcpEStatsPathPostCongCountRTT is the average RTT (over some interval) just after a congestion signal.

The number of RTT samples included in tcpEStatsPathPostCongSumRTT such that the change in tcpEStatsPathPostCongSumRTT divided by the change in tcpEStatsPathPostCongCountRTT is the average RTT (over some interval) just after a congestion signal.

The number of congestion signals delivered to the TCP sender via explicit congestion notification (ECN). This is typically the number of segments bearing Echo Congestion Experienced (ECE) bits, but should also include segments failing the ECN nonce check or other explicit congestion signals.

The number of Duplicate Acks Sent when prior Ack was not duplicate. This is the number of times that a contiguous series of duplicate acknowledgments have been sent. This is an indication of the number of data segments lost or reordered on the path from the remote TCP endpoint to the near TCP endpoint.

The receiver's estimate of the Path RTT. Adaptive receiver window algorithms depend on the receiver to having a good estimate of the path RTT.

The number of duplicate ACKs sent. The ratio of the change in tcpEStatsPathDupAcksOut to the change in tcpEStatsPathDupAckEpisodes is an indication of reorder or recovery distance over some interval.

The number of segments received with IP headers bearing Congestion Experienced (CE) markings.

Number of times the Echo Congestion Experienced (ECE) bit in the TCP header has been set (transitioned from 0 to 1), due to a Congestion Experienced (CE) marking on an IP header. Note that ECE can be set and reset only once per RTT, while CE can be set on many segments per RTT.

This table contains objects that are most useful for determining how well some of the TCP control algorithms are coping with this particular path. Entries are retained in this table for the number of seconds indicated by the tcpEStatsConnTableLatency object, after the TCP connection first enters the closed state.

Each entry in this table has information about the characteristics of each active and recently closed TCP connection.

True(1) if the local connection traversed the SYN-SENT state, else false(2).

The value sent in an MSS option, or zero if none.

The value received in an MSS option, or zero if none.

The value of the transmitted window scale option if one was sent; otherwise, a value of -1. Note that if both tcpEStatsStackWinScaleSent and tcpEStatsStackWinScaleRcvd are not -1, then Rcv.Wind.Scale will be the same as this value and used to scale receiver window announcements from the local host to the remote host.

The value of the received window scale option if one was received; otherwise, a value of -1. Note that if both tcpEStatsStackWinScaleSent and tcpEStatsStackWinScaleRcvd are not -1, then Snd.Wind.Scale will be the same as this value and used to scale receiver window announcements from the remote host to the local host.

Enabled(1) if TCP timestamps have been negotiated on, selfDisabled(2) if they are disabled or not implemented on the local host, or peerDisabled(3) if not negotiated by the remote hosts.

Enabled(1) if Explicit Congestion Notification (ECN) has been negotiated on, selfDisabled(2) if it is disabled or not implemented on the local host, or peerDisabled(3) if not negotiated by the remote hosts.

Enabled(1) if the local host will send SACK options, selfDisabled(2) if SACK is disabled or not implemented on the local host, or peerDisabled(3) if the remote host did not send the SACK-permitted option. Note that SACK negotiation is not symmetrical. SACK can enabled on one side of the connection and not the other.

Enabled(1) if the local host will process SACK options, selfDisabled(2) if SACK is disabled or not implemented on the local host, or peerDisabled(3) if the remote host sends duplicate ACKs without SACK options, or the local host otherwise decides not to process received SACK options. Unlike other TCP options, the remote data receiver cannot explicitly indicate if it is able to generate SACK options. When sending data, the local host has to deduce if the remote receiver is sending SACK options. This object can transition from Enabled(1) to peerDisabled(3) after the SYN exchange. Note that SACK negotiation is not symmetrical. SACK can enabled on one side of the connection and not the other.

An integer value representing the connection state from the TCP State Transition Diagram. The value listen(2) is included only for parallelism to the old tcpConnTable, and SHOULD NOT be used because the listen state in managed by the tcpListenerTable. The value DeleteTcb(12) is included only for parallelism to the tcpConnTable mechanism for terminating connections, although this table does not permit writing. Enumeration: 'tcpESStateCloseWait': 8, 'tcpESStateFinWait2': 7, 'tcpESStateLastAck': 9, 'tcpESStateFinWait1': 6, 'tcpESStateSynReceived': 4, 'tcpESStateEstablished': 5, 'tcpESStateClosed': 1, 'tcpESStateTimeWait': 11, 'tcpESStateSynSent': 3, 'tcpESStateListen': 2, 'tcpESStateDeleteTcb': 12, 'tcpESStateClosing': 10.

True(1) if the Nagle algorithm is being used, else false(2).

The maximum congestion window used during Slow Start, in octets.

The maximum congestion window used during Congestion Avoidance, in octets.

The maximum slow start threshold, excluding the initial value.

The minimum slow start threshold.

An integer value representing the state of the loss recovery for this connection. tcpESDataContiguous(1) indicates that the remote receiver is reporting contiguous data (no duplicate acknowledgments or SACK options) and that there are no unacknowledged retransmissions. tcpESDataUnordered(2) indicates that the remote receiver is reporting missing or out-of-order data (e.g., sending duplicate acknowledgments or SACK options) and that there are no unacknowledged retransmissions (because the missing data has not yet been retransmitted). tcpESDataRecovery(3) indicates that the sender has outstanding retransmitted data that is still unacknowledged. Enumeration: 'tcpESDataUnordered': 2, 'tcpESDataRecovery': 3, 'tcpESDataContiguous': 1.

The number of duplicate ACKs received.

The number of acknowledgments reporting out-of-order segments after the Fast Retransmit algorithm has already retransmitted the segments. (For example as detected by the Eifel algorithm).'

The number of acknowledgments reporting segments that have already been retransmitted due to a Retransmission Timeout.

The number of segments that fail various consistency tests during TCP input processing. Soft errors might cause the segment to be discarded but some do not. Some of these soft errors cause the generation of a TCP acknowledgment, while others are silently discarded.

This object identifies which consistency test most recently failed during TCP input processing. This object SHOULD be set every time tcpEStatsStackSoftErrors is incremented. The codes are as follows: belowDataWindow(1) - All data in the segment is below SND.UNA. (Normal for keep-alives and zero window probes). aboveDataWindow(2) - Some data in the segment is above SND.WND. (Indicates an implementation bug or possible attack). belowAckWindow(3) - ACK below SND.UNA. (Indicates that the return path is reordering ACKs) aboveAckWindow(4) - An ACK for data that we have not sent. (Indicates an implementation bug or possible attack). belowTSWindow(5) - TSecr on the segment is older than the current TS.Recent (Normal for the rare case where PAWS detects data reordered by the network). aboveTSWindow(6) - TSecr on the segment is newer than the current TS.Recent. (Indicates an implementation bug or possible attack). dataCheckSum(7) - Incorrect checksum. Note that this value is intrinsically fragile, because the header fields used to identify the connection may have been corrupted. otherSoftError(8) - All other soft errors not listed above. Enumeration: 'belowAckWindow': 3, 'dataCheckSum': 7, 'aboveTSWindow': 6, 'otherSoftError': 8, 'belowDataWindow': 1, 'aboveAckWindow': 4, 'belowTSWindow': 5, 'aboveDataWindow': 2.

The number of times the congestion window has been increased by the Slow Start algorithm.

The number of times the congestion window has been increased by the Congestion Avoidance algorithm.

The number of congestion window reductions made as a result of anything other than AIMD congestion control algorithms. Examples of non-multiplicative window reductions include Congestion Window Validation [RFC2861] and experimental algorithms such as Vegas [Bra94]. All window reductions MUST be counted as either tcpEStatsPerfCongSignals or tcpEStatsStackOtherReductions.

The number of congestion events that were 'backed out' of the congestion control state machine such that the congestion window was restored to a prior value. This can happen due to the Eifel algorithm [RFC3522] or other algorithms that can be used to detect and cancel spurious invocations of the Fast Retransmit Algorithm. Although it may be feasible to undo the effects of spurious invocation of the Fast Retransmit congestion events cannot easily be backed out of tcpEStatsPerfCongSignals and tcpEStatsPathPreCongSumCwnd, etc.

The number of invocations of the Fast Retransmit algorithm.

The number of times the retransmit timeout has expired after the RTO has been doubled. See Section 5.5 of RFC 2988.

The current number of times the retransmit timeout has expired without receiving an acknowledgment for new data. tcpEStatsStackCurTimeoutCount is reset to zero when new data is acknowledged and incremented for each invocation of Section 5.5 of RFC 2988.

The number of timeouts that occurred without any immediately preceding duplicate acknowledgments or other indications of congestion. Abrupt Timeouts indicate that the path lost an entire window of data or acknowledgments. Timeouts that are preceded by duplicate acknowledgments or other congestion signals (e.g., ECN) are not counted as abrupt, and might have been avoided by a more sophisticated Fast Retransmit algorithm.

The number of SACK options received.

The number of SACK blocks received (within SACK options).

The number of interface stalls or other sender local resource limitations that are treated as congestion signals.

The number of duplicate segments reported to the local host by D-SACK blocks.

The maximum MSS, in octets.

The minimum MSS, in octets.

Initial send sequence number. Note that by definition tcpEStatsStackSndInitial never changes for a given connection.

Initial receive sequence number. Note that by definition tcpEStatsStackRecInitial never changes for a given connection.

The current number of octets of data occupying the retransmit queue.

The maximum number of octets of data occupying the retransmit queue.

The current number of octets of sequence space spanned by the reassembly queue. This is generally the difference between rcv.nxt and the sequence number of the right most edge of the reassembly queue.

The maximum value of tcpEStatsStackCurReasmQueue

This table contains objects that are useful for determining if the application using TCP is limiting TCP performance. Entries are retained in this table for the number of seconds indicated by the tcpEStatsConnTableLatency object, after the TCP connection first enters the closed state.

Each entry in this table has information about the characteristics of each active and recently closed TCP connection.

The value of SND.UNA, the oldest unacknowledged sequence number. Note that SND.UNA is a TCP state variable that is congruent to Counter32 semantics.

The value of SND.NXT, the next sequence number to be sent. Note that tcpEStatsAppSndNxt is not monotonic (and thus not a counter) because TCP sometimes retransmits lost data by pulling tcpEStatsAppSndNxt back to the missing data.

The farthest forward (right most or largest) SND.NXT value. Note that this will be equal to tcpEStatsAppSndNxt except when tcpEStatsAppSndNxt is pulled back during recovery.

The number of octets for which cumulative acknowledgments have been received. Note that this will be the sum of changes to tcpEStatsAppSndUna.

The number of octets for which cumulative acknowledgments have been received, on systems that can receive more than 10 million bits per second. Note that this will be the sum of changes in tcpEStatsAppSndUna.

The value of RCV.NXT. The next sequence number expected on an incoming segment, and the left or lower edge of the receive window. Note that RCV.NXT is a TCP state variable that is congruent to Counter32 semantics.

The number of octets for which cumulative acknowledgments have been sent. Note that this will be the sum of changes to tcpEStatsAppRcvNxt.

The number of octets for which cumulative acknowledgments have been sent, on systems that can transmit more than 10 million bits per second. Note that this will be the sum of changes in tcpEStatsAppRcvNxt.

The current number of octets of application data buffered by TCP, pending first transmission, i.e., to the left of SND.NXT or SndMax. This data will generally be transmitted (and SND.NXT advanced to the left) as soon as there is an available congestion window (cwnd) or receiver window (rwin). This is the amount of data readily available for transmission, without scheduling the application. TCP performance may suffer if there is insufficient queued write data.

The maximum number of octets of application data buffered by TCP, pending first transmission. This is the maximum value of tcpEStatsAppCurAppWQueue. This pair of objects can be used to determine if insufficient queued data is steady state (suggesting insufficient queue space) or transient (suggesting insufficient application performance or excessive CPU load or scheduler latency).

The current number of octets of application data that has been acknowledged by TCP but not yet delivered to the application.

The maximum number of octets of application data that has been acknowledged by TCP but not yet delivered to the application.

This table contains per-connection controls that can be used to work around a number of common problems that plague TCP over some paths. All can be characterized as limiting the growth of the congestion window so as to prevent TCP from overwhelming some component in the path. Entries are retained in this table for the number of seconds indicated by the tcpEStatsConnTableLatency object, after the TCP connection first enters the closed state.

Each entry in this table is a control that can be used to place limits on each active TCP connection.

A control to set the maximum congestion window that may be used, in octets.

A control to limit the maximum queue space (in octets) that this TCP connection is likely to occupy during slowstart. It can be implemented with the algorithm described in RFC 3742 by setting the max_ssthresh parameter to twice tcpEStatsTuneLimSsthresh. This algorithm can be used to overcome some TCP performance problems over network paths that do not have sufficient buffering to withstand the bursts normally present during slowstart.

A control to set the maximum window advertisement that may be sent, in octets.

A control to limit the maximum segment size in octets, that this TCP connection can use.

Controls the activation of the TCP Path Statistics table. A value 'true' indicates that the TCP Path Statistics table is active, while 'false' indicates that the table is inactive.

Controls the activation of the TCP Stack Statistics table. A value 'true' indicates that the TCP Stack Statistics table is active, while 'false' indicates that the table is inactive.

Controls the activation of the TCP Application Statistics table. A value 'true' indicates that the TCP Application Statistics table is active, while 'false' indicates that the table is inactive.

Controls the activation of the TCP Tuning table. A value 'true' indicates that the TCP Tuning table is active, while 'false' indicates that the table is inactive.

Controls the generation of all notifications defined in this MIB. A value 'true' indicates that the notifications are active, while 'false' indicates that the notifications are inactive.

Specifies the number of seconds that the entity will retain entries in the TCP connection tables, after the connection first enters the closed state. The entity SHOULD provide a configuration option to enable customization of this value. A value of 0 results in entries being removed from the tables as soon as the connection enters the closed state. The value of this object pertains to the following tables: tcpEStatsConnectIdTable tcpEStatsPerfTable tcpEStatsPathTable tcpEStatsStackTable tcpEStatsAppTable tcpEStatsTuneTable

The value of sysUpTime at the time of the last creation or deletion of an entry in the tcpListenerTable. If the number of entries has been unchanged since the last re-initialization of the local network management subsystem, then this object contains a zero value.

Compliance statement for all systems that implement TCP extended statistics.

The tcpEStatsListener group includes objects that provide valuable statistics and debugging information for TCP Listeners.

The tcpEStatsListenerHC group includes 64-bit counters in tcpEStatsListenerTable.

The tcpEStatsConnectId group includes objects that identify TCP connections and control how long TCP connection entries are retained in the tables.

The tcpEStatsPerf group includes those objects that provide basic performance data for a TCP connection.

The tcpEStatsPerf group includes those objects that provide basic performance data for a TCP connection.

The tcpEStatsPerfHC group includes 64-bit counters in the tcpEStatsPerfTable.

The tcpEStatsPath group includes objects that control the creation of the tcpEStatsPathTable, and provide information about the path for each TCP connection.

The tcpEStatsPath group includes objects that provide additional information about the path for each TCP connection.

The tcpEStatsPathHC group includes 64-bit counters in the tcpEStatsPathTable.

The tcpEStatsConnState group includes objects that control the creation of the tcpEStatsStackTable, and provide information about the operation of algorithms used within TCP.

The tcpEStatsConnState group includes objects that provide additional information about the operation of algorithms used within TCP.

The tcpEStatsConnState group includes objects that control the creation of the tcpEStatsAppTable, and provide information about the operation of algorithms used within TCP.

The tcpEStatsStackHC group includes 64-bit counters in the tcpEStatsStackTable.

The tcpEStatsConnState group includes objects that provide additional information about how applications are interacting with each TCP connection.

The tcpEStatsConnState group includes objects that control the creation of the tcpEStatsConnectionTable, which can be used to set tuning parameters for each TCP connection.

Notifications sent by a TCP extended statistics agent.

The tcpEStatsNotificationsCtl group includes the object that controls the creation of the events in the tcpEStatsNotificationsGroup.