[RFCs/IDs] [Plain Text] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 07 08 09 10 11
12 13 14 15 RFC 4898
Internet-Draft Matt Mathis
John Heffner
Pittsburgh Supercomputing Center
Rajiv Raghunarayan
Cisco Systems
TCP Extended Statistics MIB
draft-ietf-tsvwg-tcp-mib-extension-15.txt
Fri Mar 2 16:25:20 EST 2007
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire July, 2007
Abstract
This draft describes extended performance statistics for TCP. They
are designed to use TCP's ideal vantage point to diagnose performance
problems in both the network and the application. If a network based
application is performing poorly, TCP can determine if the bottleneck
is in the sender, the receiver or the network itself. If the
bottleneck is in the network, TCP can provide specific information
about its nature.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .2
Mathis, et al [Page 1]
Internet-Draft Expires July, 2007 Mar 2, 2007
2. The Internet-Standard Management Framework . . . . . . . . .9
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . .9
4. TCP Extended Statistics MIB . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . 75
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 77
7. Normative References . . . . . . . . . . . . . . . . . . . .77
8. Informative References . . . . . . . . . . . . . . . . . . .79
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . .80
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 81
12. Intellectual Property . . . . . . . . . . . . . . . . . . .81
13. Disclaimer of Validity . . . . . . . . . . . . . . . . . . 82
14. Copyright Statement . . . . . . . . . . . . . . . . . . . .82
1. Introduction
This draft describes extended performance statistics for TCP. They
are designed to use TCP's ideal vantage point to diagnose performance
problems in both the network and the application. If a network based
application is performing poorly, TCP can determine if the bottleneck
is in the sender, the receiver or the network itself. If the
bottleneck is in the network, TCP can provide specific information
about its nature.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
The SNMP objects defined in this draft extend TCP MIB, as specified
in RFC 4022 [RFC4022]. In addition to several new scalars and other
objects, it augments two tables and makes one clarification to RFC
4022. Existing management stations for the TCP MIB are expected to
be fully compatible with these clarifications.
X. Changes
RFC editor, please remove this virtual section. It contains document
history and some information about document version control.
This document is automatically generated from a database of potential
TCP instruments. Beware that the OIDs are still likely to change
with future versions. The current version can be obtained from
<http://www.web100.org/mib/>. Please send all suggestions and
comments to tsvwg@ietf.org so they go to the entire TSV WG.
Changes since draft-ietf-tsvwg-tcp-mib-extension-14.txt (3-Jan-2007):
Mathis, et al [Page 2]
Internet-Draft Expires July, 2007 Mar 2, 2007
Corrected types for tcpEStatsPerfZeroRwinSent,
tcpEStatsPerfZeroRwinRcvd, tcpEStatsPathNonRecovDAEpisodes,
tcpEStatsPathSumOctetsReordered (now all ZeroBasedCounter32).
Changed tcpEStatsStackSndInitial, tcpEStatsStackRecInitial,
tcpEStatsConnTableLatency, tcpEStatsListenerMaxBacklog,
tcpEStatsPathIpTtl and the controls in tcpEStatsTuneTable to be
Unsigned32, to be more consistent with usage conventions.
Changed tcpEStatsPathIpTosIn and tcpEStatsPathIpTosOut to OCTET-
STRING SIZE(1).
Added a range to tcpEStatsConnectIndex and slightly relaxed the
description.
Changed the conformance statements to require read-wite access to
tcpEStatsControlNotify if the notification group is implemented.
Added persistency language to the MIB itself, in addition to the
overview.
Removed tcpEStatsPathQuenchRcvd, since ICMP source quence has been
all but formally deprecated.
Added tcpEStatsTuneLimMSS, to provide a manual mechanism to work
around MTU discovery failures.
Hey, Bill Fenner, can't you read everything just a little bit earlier
in the review cycle?
Changes since draft-ietf-tsvwg-tcp-mib-extension-13.txt (7-Dec-2006):
Updated the copyright dates to 2007. Updated versions for referenced
documents in progress.
Downgrade references to RFCs 2861, 3260, 3522 and 3742 to
informative.
Removed tcpEStatsPathECNNonceRcvd, which instruments the algorithm
described in RFC 3540, an experimental RFC that has recently come
into question. There are no known, widely deployed implementations,
and RFC 3540 conflicts with a recent proposal for a better use of the
remaining IP header bits.
Removed a duplicate incorrect address for Jon Saperia.
Updated TOC.
Mathis, et al [Page 3]
Internet-Draft Expires July, 2007 Mar 2, 2007
Updated copyright language within the MIB (and comments within in the
nroff source) to reflect RFC 4748.
Many automatically detected nits, per Lars Eggert.
Changes since draft-ietf-tsvwg-tcp-mib-extension-12.txt (9-Oct-2006):
These changes reflect comments from the Gen-ART, Last Call Review.
Clarified "this implementation" language in section 3.2.
Corrected cut and paste errors in the descriptions of the table
controls.
Several minor wording nits.
Changes since draft-ietf-tsvwg-tcp-mib-extension-11.txt (3-Aug-2006):
Changed Matt's email address to mathis@psc.edu.
Changes per comments from the transport AD, Lars Eggert: Re-organized
the overview to improve clarity. Moved the security section ahead of
the references. Various nits.
Changes since draft-ietf-tsvwg-tcp-mib-extension-10.txt
(24-May-2006):
These changes reflect comments received during the WGLC.
tcpEStatsConnTableLatency is no longer restricted to be less than 30
seconds.
Added references to the descriptions of Receiver Limited and
Congestion limited objects (tcpEStatsPerfSndLim*).
Reviewed and clarified all ECN related instruments.
Changes since draft-ietf-tsvwg-tcp-mib-extension-09.txt (4-Mar-2006):
Corrected the SYNTAX for PathNonRecovDAEpisodes,
PathSumOctetsReordered and AppSndNxt.
Clarified the relationship between tcpEStatsConnTableLatency and
RFC4022 (TCP-MIB).
Changes since draft-ietf-tsvwg-tcp-mib-extension-08.txt
(23-Oct-2005):
Mathis, et al [Page 4]
Internet-Draft Expires July, 2007 Mar 2, 2007
Changed tcpEStatsConnectIdTable to augment TCP-
MIB::tcpConnectionTable, rather than be a stand alone table. This
requires this draft to clarify vague row latency language in RFC4022
and deleting some text about the removed objects from the overview
and security sections.
Added row latency language to all connection tables.
Added DEFVAL to tcpEStatsConnTableLatency.
Reassigned sane OIDs under tcpEStats.
Careful review and several clarifications of the overview section.
Reviewed and cleaned up all references.
Restructured the tcpEStatsStackTable, by moving all of the objects
that describe the SYN exchange to the front of the table. These
objects are not permitted to change once the connection is
established. This permits polling the latter portion of the table in
a single PDU.
Added the TcpEStatsNegotiated TC and revised the objects that
describe the SYN exchange to better represent the state of the
negotiation without separate objects for both option values and
negotiated states.
Added tcpEStatsPathRcvRTT, which is the receiver's estimate of the
path RTT. Later corrected it to be gauge32.
Changed tcpEStatsListenerCurrConns to tcpEStatsListenerCurConns to
agree with other "current" object names.
Acknowledged the efforts of the MIB Doctor and Operations area
director.
The following changes are per the MIB doctor review:
Minor corrections (form feeds, copyright date, etc) to pass IDnits
and smilint. (Note that the unassigned root OID generates to only
remaining warning.)
Moved this mib from a subtree under experimental to a subtree under
mib-2 and added an IANA considerations section for the root OID.
Added "UNITS" and "REFERENCE" clauses as appropriate.
Clarified the description of tcpEStatsStackInRecovery.
Mathis, et al [Page 5]
Internet-Draft Expires July, 2007 Mar 2, 2007
Updated the description of tcpEStatsStackSoftErrors to mention the
numerical values of the errors.
Updated the Security considerations section with new boiler plate and
better descriptions.
Moved the document revision information to (this) virtual section.
Replaced the TcpEStatsOperation TC with TruthValue TC.
Clarified the description of tcpEStatsListenerCurBacklog. Note that
the text still allows for TCP variants.
Removed references to obsolete SNMP versions from
tcpEStatsConnectIdTable, but did not remove doubled or further
restrict address types.
Added a new subsection to clarify that the relationship to TCP
standards and indicate that the underlying TCP specifications
deliberately encourage diversity.
Updated the description of the tcpEStatsPipeSize to clarify the
permitted diversity in implementation.
Added a normative reference for RFC3517.
Clarified the introduction to the instruments of the window updates
sent by the local receiver.
Added 2 paragraphs to the overview about TCP non-persistence across
reboots, and the non-persistence of all objects in this MIB.
Clarified the description of tcpEStatsPathECNsignals.
Added explicit language about counter deltas, for objects intended to
be used to compute ratios.
Removed text permitting implementers to allocate additional
proprietary codes for tcpEStatsStackSoftErrorReason.
Added language clarifying that SND.NXT, SND.UNA, etc have Counter32
semantics.
Changes since draft-ietf-tsvwg-tcp-mib-extension-07.txt (20-Feb-2005)
Added tcpEStatsStackSpuriousRtoDetected. Renamed AckAfterFR to
tcpEStatsStackSpuriousFrDetected and clarified the description.
Mathis, et al [Page 6]
Internet-Draft Expires July, 2007 Mar 2, 2007
Restructure the tables yet again. The perf, path, and stack tables
now each start out with some required objects, followed by optional
objects. This permits a much more logical grouping of instruments,
lowers the cost for a minimal implementation and encourages
incremental deployment.
Changes since draft-ietf-tsvwg-tcp-mib-extension-06.txt (20-Feb-2005)
Added tcpEStatsPerfPipeSize and tcpEStatsPerfMaxPipeSize to detect
when TCP is unable to open the window as large as permitted.
Added tcpEStatsStackInRecovery to indicate if the connection is
currently in recovery (e.g., has outstanding retransmissions), or
about to enter recovery.
Move tcpEStatsPerfSumRTT, Tcpestatsperfhcsumrtt and
tcpEStatsPerfCountRTT to the path table, tcpEStatsPath.
Added tcpEStatsPathHCGroup.
Move tcpEstatsPathAckAfterFR and tcpEstatsPathSndDupAckEpisodes back
to the performance table, tcpEStatsPerf.
Move tcpEStatsPerfSampleRTT, tcpEStatsPerfSampleRTT and
tcpEStatsPerfSampleRTT to the stack table, tcpEStatsStack.
Clarified the descriptions of tcpEStatsPerfDupAckEpisodes,
tcpEStatsPerfDupAcksOut and tcpEStatsPerfCongSignals
Changes since draft-ietf-tsvwg-tcp-mib-extension-05.txt
(17-July-2004)
Many changes to object descriptions MIB comments and overview to
improve clarity.
Completely restructured the per connection tables. Seven table were
reduced to five. The main per connection table tcpEStatsPerfTable
is now mandatory. Three other new tables are focused on
understanding the details of the behavior of the path, internal TCP
algorithms and the application. In addition, there is a new tuning
table with per-connection writable controls to work around a number
of common problems. Note that due to the table restructuring, most
of the object names listed below have changed.
Restructured the Listen Table (tcpEStatsListenerTable) to better
instrument various SYN flood defenses.
Removed minimal receiver window objects, and replaced them by the
Mathis, et al [Page 7]
Internet-Draft Expires July, 2007 Mar 2, 2007
count of the number of transitions to zero window from non-zero
window.
Replaced tcpEStatsPathIpTos by tcpEStatsPathIpTosOut and added
tcpEStatsPathIpTosIn.
Updated the descriptions of tcpEStatsDataSndNxt, tcpEStatsDataSndMax,
tcpEStatsDataThruOctetsAcked, tcpEStatsDataHCThruBytesAcked,
tcpEStatsDataThruBytesReceived, tcpEStatsDataHCThruBytesReceived,
consistently use RFC793 variables (SND.NXT, etc) or refer to other
TCP-ESTATS-MIB objects.
Changed tcpEStatsSynOptsMSSSent and tcpEStatsSynOptsMSSRcvd from
Gauge32 to Unsigned32
Updated descriptions of tcpEStatsConnectLocalAddress and
tcpEStatsConnectRemAddress to new conventions for InetAddress
Changes since draft-ietf-tsvwg-tcp-mib-extension-04.txt (27-Oct-2003)
Updated ID boiler plate to RFC3668, ID-Guidelines and fixed some
formatting glitches
Added a Table of Contents
Updated the description of tcpEStatsConnectionState to indicate that
the listen state included only for document parallelism and should
not be used.
Explained why it is useful for tcpEStatsConnectIdTable and others to
remain for 30 seconds after a connection closes (so you retrieve the
total statistics for the entire connection).
Added comment about not supporting writing DeleteTcb into the TCP
State.
Explained that SndNxt is not a counter because it is non-monotonic.
Clarified StartTime to be row creation
Clarified row creation to be at the first SYN unless techniques to
defend against SYN floods are in effect, then at connection
establishment.
Added tcpEStatsControlNotify to control the generation of
notifications.
Changed sequence numbers from ZeroBasedCounter32 to Counter32.
Mathis, et al [Page 8]
Internet-Draft Expires July, 2007 Mar 2, 2007
Changes since draft-ietf-tsvwg-tcp-mib-extension-03.txt (2-Mar-2003)
Replaced "queued" with "buffered by TCP"
Changed all counters in the TCP connection tables to be ZeroBased
Remove tcpEStatsHCInSegs, tcpEStatsHCOutSegs, which appear in as
tcpHCInSegs and tcpHCOutSegs in draft-ietf-ipv6-rfc2012-update-03.txt
and later drafts.
Added changes section.
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
3. Overview
The TCP-ESTATS-MIB defined in this memo consists of two groups of
scalars, seven tables and two notifications:
* The first group of scalars contain statistics of the TCP protocol
engine not covered in RFC 4022. This group consists of the single
scalar tcpEStatsListenerTableLastChange which provides management
stations with an easier mechanism to validate their listener
caches.
* The second group of scalars consist of knobs to enable and disable
information collection by the tables containing connection-related
statistics/information. For example, the tcpEStatsControlPath
object controls the activation of the tcpEStatsPathTable. The
tcpEStatsConnTableLatency object determines how long connection
table rows are retained after a TCP connection transitions into the
closed state.
Mathis, et al [Page 9]
Internet-Draft Expires July, 2007 Mar 2, 2007
* The tcpEStatsListenerTable augments tcpListenerTable in TCP-MIB
[RFC4022] to provided additional information on the active TCP
listeners on a device. It supports objects to monitor and diagnose
SYN-flood denial-of-service attacks as described below.
* The tcpEStatsConnectIdTable augments the tcpConnectionTable in TCP-
MIB [RFC4022] to provide a mapping between connection 4-tuples
(which index tcpConnectionTable) and an integer connection index,
tcpEStatsConnectIndex. The connection index is used to index into
the five remaining tables in this MIB module, and is designed to
facilitate rapid polling of multiple objects associated with one
TCP connection.
* The tcpEStatsPerfTable contains objects that are useful for
measuring TCP performance and first check problem diagnosis.
* The tcpEStatsPathTable contains objects that can be used to infer
detailed behavior of the Internet path, such as the extent that
there are segment losses or reordering, etc.
* The tcpEStatsStackTable contains objects that are most useful for
determining how well the TCP control algorithms are coping with
this particular path.
* The tcpEStatsAppTable provides objects that are useful for
determining if the application using TCP is limiting TCP
performance.
* The tcpEStatsTuneTable provides per connection controls that can be
used to work around a number of common problems that plague TCP
over some paths.
* The two notifications defined in this MIB module are
tcpEStatsEstablishNotification, indicating that a new connection
has been accepted (or established, see below), and
tcpEStatsCloseNotification, indicating that an existing connection
has recently closed.
3.1. MIB Initialization and Persistence
Mathis, et al [Page 10]
Internet-Draft Expires July, 2007 Mar 2, 2007
The TCP protocol itself is specifically designed not to preserve any
state whatsoever across system reboots, and enforces this by
requiring randomized Initial Sequence numbers and ephemeral ports
under any conditions where segments from old connections might
corrupt new connections following a reboot.
All of the objects in the MIB MUST have the same persistence
properties as the underlying TCP implementation. On a reboot, all
zero based counters MUST be cleared, all per connection 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.
The ZeroBasedCounter32 and ZeroBasedCounter64 objects in the listener
and connection tables are initialized to zero when the table row is
created.
The tcpEStatsConnTableLatency object determines how long connection
table rows are retained after a TCP connection transitions into the
closed state, to permit reading final connection completion
statistics. In RFC4022 (TCP-MIB), the discussion of
tcpConnectionTable row latency (page 9) the words "soon after" are
understood to mean after tcpEStatsConnTableLatency, such that all
rows of all tables associated with one connection are retained at
least tcpEStatsConnTableLatency after connection close. This
clarification to RFC4022 only applies when TCP-ESTATS-MIB is
implemented. If TCP-ESTATS-MIB is not implemented, RFC4022 permits
an unspecified delay between connection close and row deletion.
3.2. Relationship to TCP standards
There are more than 70 RFCs and other documents that specify various
aspects of the Transmission Control Protocol (TCP) [RFC4614]. While
most protocols are completely specified in one or two documents, this
has not proven to be feasible for TCP. TCP implements a reliable
end-to-end data transport service over a very weakly constrained IP
datagram service. The essential problem that TCP has to solve is
balancing the applications need for fast and reliable data transport
against the need to make fair, efficient and equitable use of network
resources, with only sparse information about the state of the
network or its capabilities.
TCP maintains this balance through the use of many estimators and
heuristics that regulate various aspects of the protocol. For
Mathis, et al [Page 11]
Internet-Draft Expires July, 2007 Mar 2, 2007
example RFC2988 describes how to calculate the retransmission timer,
RTO, from the average and variance of the network round-trip-time as
estimated from the RTT sampled on some data segments. Although these
algorithms are standardized, they are a compromise which is optimal
for only common Internet environments. Other estimators might yield
better results (higher performance or more efficient use of the
network) in some environments, particularly under uncommon
conditions.
It is the consensus of the community that nearly all of the
estimators and heuristics used in TCP might be improved through
further research and development. For this reason nearly all of TCP
documents leave some latitude for future improvements, for example by
the use of "SHOULD" instead of "MUST" [RFC2119]. Even standard
algorithms that are required because they critically effect fairness
or the dynamic stability of Internet congestion control, include some
latitude for evolution. As a consequence there is considerable
diversity in the details of the TCP implementations actually in use
today.
The fact that the underlying algorithms are not uniform makes it
difficult to tightly specify a MIB. We could have chosen the point
of view that the MIB should publish precisely defined metrics of the
network path, even if they are different from the estimators in use
by TCP. This would make the MIB more useful as a measurement tool,
but less useful for understanding how any specific TCP implementation
is interacting with the network path and upper protocol layers. We
chose instead to have the MIB expose the estimators and important
states variables of the algorithms in use, without constraining the
TCP implementation.
As a consequence the MIB objects are defined in terms of fairly
abstract descriptions (e.g., Round-Trip-Time) but are intended to
expose the actual estimators or other state variables as they are
used in TCP implementations, possibly transformed (e.g., scaled or
otherwise adjusted) to match the spirit of the object descriptions in
this document.
This may mean that MIB objects may not be exactly comparable between
two different TCP implementations. A general management station can
only assume the abstract descriptions, which are useful for general
assessment of how TCP is functioning. To a TCP implementer with
detailed knowledge about the TCP implementation on a specific host,
this MIB might be useful for debugging or evaluating the algorithms
in their implementation.
Under no conditions is this MIB intended to constrain TCP to use (or
exclude) any particular estimator, heuristic, algorithm or
Mathis, et al [Page 12]
Internet-Draft Expires July, 2007 Mar 2, 2007
implementation.
3.3. Diagnosing SYN-flood Denial-of-Service attacks
The tcpEStatsListenerTable is specifically designed to provide
information that is useful for diagnosing SYN-flood Denial-of-Service
attacks, where a server is overwhelmed by forged or otherwise
malicious connection attempts. There are several different
techniques that can be used to defend against SYN-flooding but none
are standardized [Edd06]. These different techniques all have the
same basic characteristics which are instrumentable with a common set
of objects even though the techniques differ greatly in the details.
All SYN-flood defenses avoid allocating significant resources (memory
or CPU) to incoming (passive open) connections until the connections
meet some liveness criteria (to defend against forged IP source
addresses) and the server has sufficient resources to process the
incoming request. Note that allocating resources is an
implementation specific event that may not correspond to an
observable protocol event (e.g., segments on the wire). There are
two general concepts that can be applied to all known SYN-flood
defenses. There is generally a well defined event when a connection
is allocated full resources, and a "backlog" - a queue of embryonic
connections that have been allocated only partial resources.
In many implementations incoming TCP connections are allocated
resources as a side effect of the POSIX [POSIX] accept() call. For
this reason we use the terminology "accepting a connection" to refer
to this event: committing sufficient network resources to process the
incoming request. Accepting a connection typically entails
allocating memory for the protocol control block [RFC793], the per
connection table rows described in this MIB and CPU resources, such
as process table entries or threads.
Note that it is not useful to accept connections before they are
ESTABLISHED, because this would create an easy opportunity for
Denial-of-Service attacks, using forged source IP addresses.
The backlog consists of connections that are in SYN-RCVD or
ESTABLISHED states, that have not been accepted. For purposes of
this MIB we assume that these connections have been allocated some
resources (e.g., an embryonic protocol control block) but not full
resources (e.g., do not yet have MIB table rows).
Note that some SYN-Flood defenses dispense with explicit SYN-RCVD
state by cryptographically encoding the state in the ISS of the SYN-
ACK (sometimes called a syn-cookie), and then using the sequence
number of the first ACK to reconstruct the SYN-RCVD state before
Mathis, et al [Page 13]
Internet-Draft Expires July, 2007 Mar 2, 2007
transitioning to the ESTABLISHED state. For these implementations
there is no explicit representation of the SYN-RCVD state and the
backlog only consists of connections that are ESTABLISHED and are
waiting to be ACCEPTED.
Furthermore, most SYN-flood defenses have some mechanism to throttle
connections that might otherwise overwhelm this endpoint. They
generally use some combination of discarding incoming SYNs and
discarding connections already in the backlog. This does not cause
all connections from legitimate clients to fail, as long as the
clients retransmit the SYN or first ACK as specified in RFC793. Most
diversity in SYN flood defenses arise from variations in these
algorithms to limit load, and therefore cannot be instrumented with a
common standard MIB.
The Listen Table instruments all passively opened TCP connections in
terms of observable protocol events (e.g., sent and received
segments) and resource allocation events (entering the backlog and
being accepted). This approach eases generalization to SYN-flood
mechanisms that use alternate TCP state transition diagrams and
implicit mechanisms to encode some states.
4. TCP Extended Statistics MIB
TCP-ESTATS-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, Counter32, Integer32, Unsigned32,
Gauge32, OBJECT-TYPE, mib-2,
NOTIFICATION-TYPE
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
ZeroBasedCounter32
FROM RMON2-MIB -- [RFC2021]
ZeroBasedCounter64
FROM HCNUM-TC -- [RFC2856]
TEXTUAL-CONVENTION,
DateAndTime, TruthValue, TimeStamp
FROM SNMPv2-TC -- [RFC2579]
tcpListenerEntry, tcpConnectionEntry
FROM TCP-MIB; -- [RFC4022]
tcpEStatsMIB MODULE-IDENTITY
LAST-UPDATED "200703021625Z" -- Mar 2, 2007
ORGANIZATION "IETF TSV Working Group"
CONTACT-INFO
Mathis, et al [Page 14]
Internet-Draft Expires July, 2007 Mar 2, 2007
"Matt Mathis
John Heffner
Web100 Project
Pittsburgh Supercomputing Center
4400 Fifth Ave
Pittsburgh, PA 15213
Email: mathis@psc.edu, jheffner@psc.edu
Rajiv Raghunarayan
Cisco Systems Inc.
San Jose, CA 95134
Phone: 408 853 9612
Email: raraghun@cisco.com
Jon Saperia
84 Kettell Plain Road
Stow, MA 01775
Phone: 617-201-2655
Email: saperia@jdscons.com "
DESCRIPTION
"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
per 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 xxx1; see the RFC
itself for full legal notices."
-- RFC Editor: replace xxx1 with actual RFC number & remove note
REVISION "200703021625Z" -- Mar 2, 2007
DESCRIPTION
"Initial version, published as RFC xxx1."
-- RFC Editor assigns RFC xxx1
::= { mib-2 xxx2 }
-- RFC Editor: IANA assigns base OID xxx2
Mathis, et al [Page 15]
Internet-Draft Expires July, 2007 Mar 2, 2007
tcpEStatsNotifications OBJECT IDENTIFIER ::= { tcpEStatsMIB 0 }
tcpEStatsMIBObjects OBJECT IDENTIFIER ::= { tcpEStatsMIB 1 }
tcpEStatsConformance OBJECT IDENTIFIER ::= { tcpEStatsMIB 2 }
tcpEStats OBJECT IDENTIFIER ::= { tcpEStatsMIBObjects 1 }
tcpEStatsControl OBJECT IDENTIFIER ::= { tcpEStatsMIBObjects 2 }
tcpEStatsScalar OBJECT IDENTIFIER ::= { tcpEStatsMIBObjects 3 }
--
-- Textual Conventions
--
TcpEStatsNegotiated ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Indicates if some optional TCP feature was negotiated.
Enabled(1) indicates that the feature was successfully
negotiated on, which generally requires both host to agree
to use the feature.
selfDisabled(2) indicates that the local host refused the
feature because it is not implemented, configured off or
refused for some other reason, such as the lack of
resources.
peerDisabled(3) indicates that the local host was willing
to negotiate the feature, but the remote host did not
do so."
SYNTAX INTEGER {
enabled(1),
selfDisabled(2),
peerDisabled(3)
}
--
-- TCP Extended statistics scalars
--
tcpEStatsListenerTableLastChange OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
Mathis, et al [Page 16]
Internet-Draft Expires July, 2007 Mar 2, 2007
::= { tcpEStatsScalar 3 }
-- ================================================================
--
-- The tcpEStatsControl Group
--
-- The scalar objects in this group are used to control the
-- activation and deactivation of the TCP Extended Statistics
-- tables and notifications in this module.
--
tcpEStatsControlPath OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"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."
DEFVAL { false }
::= { tcpEStatsControl 1 }
tcpEStatsControlStack OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"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."
DEFVAL { false }
::= { tcpEStatsControl 2 }
tcpEStatsControlApp OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Controls the activation of the TCP Application
Statistics table.
Mathis, et al [Page 17]
Internet-Draft Expires July, 2007 Mar 2, 2007
A value 'true' indicates that the TCP Application
Statistics table is active, while 'false' indicates
that the table is inactive."
DEFVAL { false }
::= { tcpEStatsControl 3 }
tcpEStatsControlTune OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"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."
DEFVAL { false }
::= { tcpEStatsControl 4 }
tcpEStatsControlNotify OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"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."
DEFVAL { false }
::= { tcpEStatsControl 5 }
tcpEStatsConnTableLatency OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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
Mathis, et al [Page 18]
Internet-Draft Expires July, 2007 Mar 2, 2007
tcpEStatsPerfTable
tcpEStatsPathTable
tcpEStatsStackTable
tcpEStatsAppTable
tcpEStatsTuneTable"
DEFVAL { 0 }
::= { tcpEStatsControl 6 }
-- ================================================================
--
-- Listener Table
--
tcpEStatsListenerTable OBJECT-TYPE
SYNTAX SEQUENCE OF TcpEStatsListenerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains information about TCP Listeners,
in addition to the information maintained by the
tcpListenerTable RFC4022."
::= { tcpEStats 1 }
tcpEStatsListenerEntry OBJECT-TYPE
SYNTAX TcpEStatsListenerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry in the table contains information about
a specific TCP Listener."
AUGMENTS { tcpListenerEntry }
::= { tcpEStatsListenerTable 1 }
TcpEStatsListenerEntry ::= SEQUENCE {
tcpEStatsListenerStartTime TimeStamp,
tcpEStatsListenerSynRcvd ZeroBasedCounter32,
tcpEStatsListenerInitial ZeroBasedCounter32,
tcpEStatsListenerEstablished ZeroBasedCounter32,
tcpEStatsListenerAccepted ZeroBasedCounter32,
tcpEStatsListenerExceedBacklog ZeroBasedCounter32,
tcpEStatsListenerHCSynRcvd ZeroBasedCounter64,
tcpEStatsListenerHCInitial ZeroBasedCounter64,
tcpEStatsListenerHCEstablished ZeroBasedCounter64,
tcpEStatsListenerHCAccepted ZeroBasedCounter64,
tcpEStatsListenerHCExceedBacklog ZeroBasedCounter64,
tcpEStatsListenerCurConns Gauge32,
tcpEStatsListenerMaxBacklog Unsigned32,
tcpEStatsListenerCurBacklog Gauge32,
Mathis, et al [Page 19]
Internet-Draft Expires July, 2007 Mar 2, 2007
tcpEStatsListenerCurEstabBacklog Gauge32
}
tcpEStatsListenerStartTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsListenerEntry 1 }
tcpEStatsListenerSynRcvd OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsListenerEntry 2 }
tcpEStatsListenerInitial OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of connections for which the Listener
has allocated initial state and placed the
connection in the backlog. The may happen in the
SYN-RCVD or ESTABLISHED states, depending on the
implementation."
::= { tcpEStatsListenerEntry 3 }
tcpEStatsListenerEstablished OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of connections which have been established to
this endpoint. (e.g., The number of first ACKs which have
been received for this listener)."
::= { tcpEStatsListenerEntry 4 }
Mathis, et al [Page 20]
Internet-Draft Expires July, 2007 Mar 2, 2007
tcpEStatsListenerAccepted OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of connections for which the Listener
has successfully issued an accept, removing the connection
from the backlog."
::= { tcpEStatsListenerEntry 5 }
tcpEStatsListenerExceedBacklog OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsListenerEntry 6 }
tcpEStatsListenerHCSynRcvd OBJECT-TYPE
SYNTAX ZeroBasedCounter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of SYNs which have been received for this
listener on systems that can process (or reject) more
than 1 million connections per second. See
tcpEStatsListenerSynRcvd."
::= { tcpEStatsListenerEntry 7 }
tcpEStatsListenerHCInitial OBJECT-TYPE
SYNTAX ZeroBasedCounter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsListenerEntry 8 }
tcpEStatsListenerHCEstablished OBJECT-TYPE
SYNTAX ZeroBasedCounter64
MAX-ACCESS read-only
STATUS current
Mathis, et al [Page 21]
Internet-Draft Expires July, 2007 Mar 2, 2007
DESCRIPTION
"The number of connections which have been established to
this endpoint on systems that can process (or reject) more
than 1 million connections per second. See
tcpEStatsListenerEstablished."
::= { tcpEStatsListenerEntry 9 }
tcpEStatsListenerHCAccepted OBJECT-TYPE
SYNTAX ZeroBasedCounter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsListenerEntry 10 }
tcpEStatsListenerHCExceedBacklog OBJECT-TYPE
SYNTAX ZeroBasedCounter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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
tcpEStatsListenerHCExceedBacklog."
::= { tcpEStatsListenerEntry 11 }
tcpEStatsListenerCurConns OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsListenerEntry 12 }
tcpEStatsListenerMaxBacklog OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Mathis, et al [Page 22]
Internet-Draft Expires July, 2007 Mar 2, 2007
"The maximum number of connections allowed in
backlog at one time."
::= { tcpEStatsListenerEntry 13 }
tcpEStatsListenerCurBacklog OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current number of connections that are in 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."
::= { tcpEStatsListenerEntry 14 }
tcpEStatsListenerCurEstabBacklog OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current number of connections in backlog that are
in the ESTABLISHED state, but for which the Listener has
not yet issued an accept."
::= { tcpEStatsListenerEntry 15 }
-- ================================================================
--
-- TCP Connection ID Table
--
tcpEStatsConnectIdTable OBJECT-TYPE
SYNTAX SEQUENCE OF TcpEStatsConnectIdEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"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 extention of
tcpConnectionTable in RFC4022.
Entries are retained in this table for the number of
Mathis, et al [Page 23]
Internet-Draft Expires July, 2007 Mar 2, 2007
seconds indicated by the tcpEStatsConnTableLatency
object, after the TCP connection first enters the closed
state."
::= { tcpEStats 2 }
tcpEStatsConnectIdEntry OBJECT-TYPE
SYNTAX TcpEStatsConnectIdEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry in this table maps a TCP connection
4-tuple to a connection index."
AUGMENTS { tcpConnectionEntry }
::= { tcpEStatsConnectIdTable 1 }
TcpEStatsConnectIdEntry ::= SEQUENCE {
tcpEStatsConnectIndex Unsigned32
}
tcpEStatsConnectIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsConnectIdEntry 1 }
-- ================================================================
--
-- Basic TCP Performance Statistics
--
tcpEStatsPerfTable OBJECT-TYPE
SYNTAX SEQUENCE OF TcpEStatsPerfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"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
Mathis, et al [Page 24]
Internet-Draft Expires July, 2007 Mar 2, 2007
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."
::= { tcpEStats 3 }
tcpEStatsPerfEntry OBJECT-TYPE
SYNTAX TcpEStatsPerfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry in this table has information about the
characteristics of each active and recently closed tcp
connection."
INDEX { tcpEStatsConnectIndex }
::= { tcpEStatsPerfTable 1 }
TcpEStatsPerfEntry ::= SEQUENCE {
tcpEStatsPerfSegsOut ZeroBasedCounter32,
tcpEStatsPerfDataSegsOut ZeroBasedCounter32,
tcpEStatsPerfDataOctetsOut ZeroBasedCounter32,
tcpEStatsPerfHCDataOctetsOut ZeroBasedCounter64,
tcpEStatsPerfSegsRetrans ZeroBasedCounter32,
tcpEStatsPerfOctetsRetrans ZeroBasedCounter32,
tcpEStatsPerfSegsIn ZeroBasedCounter32,
tcpEStatsPerfDataSegsIn ZeroBasedCounter32,
tcpEStatsPerfDataOctetsIn ZeroBasedCounter32,
tcpEStatsPerfHCDataOctetsIn ZeroBasedCounter64,
tcpEStatsPerfElapsedSecs ZeroBasedCounter32,
tcpEStatsPerfElapsedMicroSecs ZeroBasedCounter32,
tcpEStatsPerfStartTimeStamp DateAndTime,
tcpEStatsPerfCurMSS Gauge32,
tcpEStatsPerfPipeSize Gauge32,
tcpEStatsPerfMaxPipeSize Gauge32,
tcpEStatsPerfSmoothedRTT Gauge32,
tcpEStatsPerfCurRTO Gauge32,
tcpEStatsPerfCongSignals ZeroBasedCounter32,
tcpEStatsPerfCurCwnd Gauge32,
tcpEStatsPerfCurSsthresh Gauge32,
tcpEStatsPerfTimeouts ZeroBasedCounter32,
tcpEStatsPerfCurRwinSent Gauge32,
tcpEStatsPerfMaxRwinSent Gauge32,
tcpEStatsPerfZeroRwinSent ZeroBasedCounter32,
tcpEStatsPerfCurRwinRcvd Gauge32,
tcpEStatsPerfMaxRwinRcvd Gauge32,
Mathis, et al [Page 25]
Internet-Draft Expires July, 2007 Mar 2, 2007
tcpEStatsPerfZeroRwinRcvd ZeroBasedCounter32,
tcpEStatsPerfSndLimTransRwin ZeroBasedCounter32,
tcpEStatsPerfSndLimTransCwnd ZeroBasedCounter32,
tcpEStatsPerfSndLimTransSnd ZeroBasedCounter32,
tcpEStatsPerfSndLimTimeRwin ZeroBasedCounter32,
tcpEStatsPerfSndLimTimeCwnd ZeroBasedCounter32,
tcpEStatsPerfSndLimTimeSnd ZeroBasedCounter32
}
--
-- The following objects provide statistics on aggregate
-- segments and data sent on a connection. These provide a
-- direct measure of the Internet capacity consumed by a
-- connection.
--
tcpEStatsPerfSegsOut OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of segments sent."
::= { tcpEStatsPerfEntry 1 }
tcpEStatsPerfDataSegsOut OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of segments sent containing a positive length
data segment."
::= { tcpEStatsPerfEntry 2 }
tcpEStatsPerfDataOctetsOut OBJECT-TYPE
SYNTAX ZeroBasedCounter32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets of data contained in transmitted
segments, including retransmitted data. Note that this does
not include TCP headers."
::= { tcpEStatsPerfEntry 3 }
tcpEStatsPerfHCDataOctetsOut OBJECT-TYPE
SYNTAX ZeroBasedCounter64
UNITS "octets"
MAX-ACCESS read-only
Mathis, et al [Page 26]
Internet-Draft Expires July, 2007 Mar 2, 2007
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsPerfEntry 4 }
tcpEStatsPerfSegsRetrans OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of segments transmitted containing at least some
retransmitted data."
REFERENCE
"RFC793, Transmission Control Protocol"
::= { tcpEStatsPerfEntry 5 }
tcpEStatsPerfOctetsRetrans OBJECT-TYPE
SYNTAX ZeroBasedCounter32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets retransmitted."
REFERENCE
"RFC793, Transmission Control Protocol"
::= { tcpEStatsPerfEntry 6 }
tcpEStatsPerfSegsIn OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of segments received."
::= { tcpEStatsPerfEntry 7 }
tcpEStatsPerfDataSegsIn OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of segments received containing a positive
length data segment."
::= { tcpEStatsPerfEntry 8 }
tcpEStatsPerfDataOctetsIn OBJECT-TYPE
Mathis, et al [Page 27]
Internet-Draft Expires July, 2007 Mar 2, 2007
SYNTAX ZeroBasedCounter32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets contained in received data segments,
including retransmitted data. Note that this does not
include TCP headers."
::= { tcpEStatsPerfEntry 9 }
tcpEStatsPerfHCDataOctetsIn OBJECT-TYPE
SYNTAX ZeroBasedCounter64
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsPerfEntry 10 }
tcpEStatsPerfElapsedSecs OBJECT-TYPE
SYNTAX ZeroBasedCounter32
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The seconds part of the time elapsed between
tcpEStatsPerfStartTimeStamp and the most recent protocol
event (segment sent or received)."
::= { tcpEStatsPerfEntry 11 }
tcpEStatsPerfElapsedMicroSecs OBJECT-TYPE
SYNTAX ZeroBasedCounter32
UNITS "microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsPerfEntry 12 }
tcpEStatsPerfStartTimeStamp OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
Mathis, et al [Page 28]
Internet-Draft Expires July, 2007 Mar 2, 2007
STATUS current
DESCRIPTION
"Time at which this row was created and all
ZeroBasedCounters in the row were initialized to zero."
::= { tcpEStatsPerfEntry 13 }
--
-- The following objects can be used to fit minimal
-- performance models to the TCP data rate.
--
tcpEStatsPerfCurMSS OBJECT-TYPE
SYNTAX Gauge32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current maximum segment size (MSS), in octets."
REFERENCE
"RFC1122, Requirements for Internet Hosts - Communication
Layers"
::= { tcpEStatsPerfEntry 14 }
tcpEStatsPerfPipeSize OBJECT-TYPE
SYNTAX Gauge32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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 RFC2581, 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.
RFC3517 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 RFC3517 if it is
Mathis, et al [Page 29]
Internet-Draft Expires July, 2007 Mar 2, 2007
implemented. (Note that while not in recovery the pipe
algorithm yields the same values as flight size).
If RFC3517 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.
I.e., PipeSize=SND.NXT-SND.UNA+(retransmits-dupacks)*CurMSS"
REFERENCE
"RFC793, RFC2581, RFC3517"
::= { tcpEStatsPerfEntry 15 }
tcpEStatsPerfMaxPipeSize OBJECT-TYPE
SYNTAX Gauge32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum value of tcpEStatsPerfPipeSize, for this
connection."
REFERENCE
"RFC793, RFC2581, RFC3517"
::= { tcpEStatsPerfEntry 16 }
tcpEStatsPerfSmoothedRTT OBJECT-TYPE
SYNTAX Gauge32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The smoothed round trip time used in calculation of the
RTO. See SRTT in [RFC2988]."
REFERENCE
"RFC2988, Computing TCP's Retransmission Timer"
::= { tcpEStatsPerfEntry 17 }
tcpEStatsPerfCurRTO OBJECT-TYPE
SYNTAX Gauge32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current value of the retransmit timer RTO."
REFERENCE
"RFC2988, Computing TCP's Retransmission Timer"
::= { tcpEStatsPerfEntry 18 }
Mathis, et al [Page 30]
Internet-Draft Expires July, 2007 Mar 2, 2007
tcpEStatsPerfCongSignals OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of multiplicative downward congestion window
adjustments due to all forms of congestion signals,
including Fast Retransmit, ECN and timeouts. This object
summarizes all events that invoke the MD portion of AIMD
congestion control, and as such is the best indicator of
how 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."
REFERENCE
"RFC2581, TCP Congestion Control"
::= { tcpEStatsPerfEntry 19 }
tcpEStatsPerfCurCwnd OBJECT-TYPE
SYNTAX Gauge32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current congestion window, in octets."
REFERENCE
"RFC2581, TCP Congestion Control"
::= { tcpEStatsPerfEntry 20 }
tcpEStatsPerfCurSsthresh OBJECT-TYPE
SYNTAX Gauge32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current slow start threshold in octets."
REFERENCE
"RFC2581, TCP Congestion Control"
::= { tcpEStatsPerfEntry 21 }
tcpEStatsPerfTimeouts OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
Mathis, et al [Page 31]
Internet-Draft Expires July, 2007 Mar 2, 2007
DESCRIPTION
"The number of times the retransmit timeout has expired when
the RTO backoff multiplier is equal to one."
REFERENCE
"RFC2988, Computing TCP's Retransmission Timer"
::= { tcpEStatsPerfEntry 22 }
--
-- The following objects instrument receiver window updates
-- sent by the local receiver to the remote sender. These can
-- be used to determine if the local receiver is exerting flow
-- control back pressure on the remote sender.
--
tcpEStatsPerfCurRwinSent OBJECT-TYPE
SYNTAX Gauge32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The most recent window advertisement sent, in octets."
REFERENCE
"RFC793, Transmission Control Protocol"
::= { tcpEStatsPerfEntry 23 }
tcpEStatsPerfMaxRwinSent OBJECT-TYPE
SYNTAX Gauge32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum window advertisement sent, in octets."
REFERENCE
"RFC793, Transmission Control Protocol"
::= { tcpEStatsPerfEntry 24 }
tcpEStatsPerfZeroRwinSent OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of acknowledgments sent announcing a zero
receive window, when the previously announced window was
not zero."
REFERENCE
"RFC793, Transmission Control Protocol"
::= { tcpEStatsPerfEntry 25 }
Mathis, et al [Page 32]
Internet-Draft Expires July, 2007 Mar 2, 2007
--
-- The following objects instrument receiver window updates
-- from the far end-system to determine if the remote receiver
-- has sufficient buffer space or is exerting flow-control
-- back pressure on the local sender.
--
tcpEStatsPerfCurRwinRcvd OBJECT-TYPE
SYNTAX Gauge32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The most recent window advertisement received, in octets."
REFERENCE
"RFC793, Transmission Control Protocol"
::= { tcpEStatsPerfEntry 26 }
tcpEStatsPerfMaxRwinRcvd OBJECT-TYPE
SYNTAX Gauge32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum window advertisement received, in octets."
REFERENCE
"RFC793, Transmission Control Protocol"
::= { tcpEStatsPerfEntry 27 }
tcpEStatsPerfZeroRwinRcvd OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of acknowledgments received announcing a zero
receive window, when the previously announced window was
not zero."
REFERENCE
"RFC793, Transmission Control Protocol"
::= { tcpEStatsPerfEntry 28 }
--
-- The following optional objects can be used to quickly
-- identify which subsystems are limiting TCP performance.
-- There are three parallel pairs of instruments that measure
-- the extent to which TCP performance is limited by the
-- announced receiver window (indicating a receiver
-- bottleneck), the current congestion window or
Mathis, et al [Page 33]
Internet-Draft Expires July, 2007 Mar 2, 2007
-- retransmission timeout (indicating a path bottleneck) and
-- all others events (indicating a sender bottleneck).
--
-- These instruments SHOULD be updated every time the TCP
-- output routine stops sending data. The elapsed time since
-- the previous stop is accumulated into the appropriate
-- object as determined by the previous stop reason (e.g.,
-- stop state). The current stop reason determines which timer
-- will be updated the next time TCP output stops.
--
-- Since there is no explicit stop at the beginning of a
-- timeout, it is necessary to retroactively reclassify the
-- previous stop as 'Congestion Limited'.
--
tcpEStatsPerfSndLimTransRwin OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC793, Transmission Control Protocol"
::= { tcpEStatsPerfEntry 31 }
tcpEStatsPerfSndLimTransCwnd OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC2581, TCP Congestion Control"
::= { tcpEStatsPerfEntry 32 }
tcpEStatsPerfSndLimTransSnd OBJECT-TYPE
Mathis, et al [Page 34]
Internet-Draft Expires July, 2007 Mar 2, 2007
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsPerfEntry 33 }
tcpEStatsPerfSndLimTimeRwin OBJECT-TYPE
SYNTAX ZeroBasedCounter32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The cumulative time spent in the 'Receiver Limited' state.
See tcpEStatsPerfSndLimTransRwin."
::= { tcpEStatsPerfEntry 34 }
tcpEStatsPerfSndLimTimeCwnd OBJECT-TYPE
SYNTAX ZeroBasedCounter32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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.)"
::= { tcpEStatsPerfEntry 35 }
tcpEStatsPerfSndLimTimeSnd OBJECT-TYPE
SYNTAX ZeroBasedCounter32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The cumulative time spent in the 'Sender Limited' state.
See tcpEStatsPerfSndLimTransSnd."
::= { tcpEStatsPerfEntry 36 }
-- ================================================================
Mathis, et al [Page 35]
Internet-Draft Expires July, 2007 Mar 2, 2007
--
-- Statistics for diagnosing path problems
--
tcpEStatsPathTable OBJECT-TYPE
SYNTAX SEQUENCE OF TcpEStatsPathEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"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."
::= { tcpEStats 4 }
tcpEStatsPathEntry OBJECT-TYPE
SYNTAX TcpEStatsPathEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry in this table has information about the
characteristics of each active and recently closed tcp
connection."
INDEX { tcpEStatsConnectIndex }
::= { tcpEStatsPathTable 1 }
TcpEStatsPathEntry ::= SEQUENCE {
tcpEStatsPathRetranThresh Gauge32,
tcpEStatsPathNonRecovDAEpisodes ZeroBasedCounter32,
tcpEStatsPathSumOctetsReordered ZeroBasedCounter32,
tcpEStatsPathNonRecovDA ZeroBasedCounter32,
tcpEStatsPathSampleRTT Gauge32,
tcpEStatsPathRTTVar Gauge32,
tcpEStatsPathMaxRTT Gauge32,
tcpEStatsPathMinRTT Gauge32,
tcpEStatsPathSumRTT ZeroBasedCounter32,
tcpEStatsPathHCSumRTT ZeroBasedCounter64,
tcpEStatsPathCountRTT ZeroBasedCounter32,
tcpEStatsPathMaxRTO Gauge32,
tcpEStatsPathMinRTO Gauge32,
tcpEStatsPathIpTtl Unsigned32,
tcpEStatsPathIpTosIn OCTET STRING,
Mathis, et al [Page 36]
Internet-Draft Expires July, 2007 Mar 2, 2007
tcpEStatsPathIpTosOut OCTET STRING,
tcpEStatsPathPreCongSumCwnd ZeroBasedCounter32,
tcpEStatsPathPreCongSumRTT ZeroBasedCounter32,
tcpEStatsPathPostCongSumRTT ZeroBasedCounter32,
tcpEStatsPathPostCongCountRTT ZeroBasedCounter32,
tcpEStatsPathECNsignals ZeroBasedCounter32,
tcpEStatsPathDupAckEpisodes ZeroBasedCounter32,
tcpEStatsPathRcvRTT Gauge32,
tcpEStatsPathDupAcksOut ZeroBasedCounter32,
tcpEStatsPathCERcvd ZeroBasedCounter32,
tcpEStatsPathECESent ZeroBasedCounter32
}
--
-- The following optional objects can be used to infer segment
-- reordering on the path from the local sender to the remote
-- receiver.
--
tcpEStatsPathRetranThresh OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC2581, TCP Congestion Control"
::= { tcpEStatsPathEntry 1 }
tcpEStatsPathNonRecovDAEpisodes OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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
Mathis, et al [Page 37]
Internet-Draft Expires July, 2007 Mar 2, 2007
estimate of the frequency of data reordering on the forward
path over some interval."
REFERENCE
"RFC2581, TCP Congestion Control"
::= { tcpEStatsPathEntry 2 }
tcpEStatsPathSumOctetsReordered OBJECT-TYPE
SYNTAX ZeroBasedCounter32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsPathEntry 3 }
tcpEStatsPathNonRecovDA OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC2581, TCP Congestion Control"
::= { tcpEStatsPathEntry 4 }
--
-- The following optional objects instrument the round trip
-- time estimator and the retransmission timeout timer.
--
Mathis, et al [Page 38]
Internet-Draft Expires July, 2007 Mar 2, 2007
tcpEStatsPathSampleRTT OBJECT-TYPE
SYNTAX Gauge32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The most recent raw round trip time measurement used in
calculation of the RTO."
REFERENCE
"RFC2988, Computing TCP's Retransmission Timer"
::= { tcpEStatsPathEntry 11 }
tcpEStatsPathRTTVar OBJECT-TYPE
SYNTAX Gauge32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The round trip time variation used in calculation of the
RTO. See RTTVAR in [RFC2988]."
REFERENCE
"RFC2988, Computing TCP's Retransmission Timer"
::= { tcpEStatsPathEntry 12 }
tcpEStatsPathMaxRTT OBJECT-TYPE
SYNTAX Gauge32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum sampled round trip time."
REFERENCE
"RFC2988, Computing TCP's Retransmission Timer"
::= { tcpEStatsPathEntry 13 }
tcpEStatsPathMinRTT OBJECT-TYPE
SYNTAX Gauge32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum sampled round trip time."
REFERENCE
"RFC2988, Computing TCP's Retransmission Timer"
::= { tcpEStatsPathEntry 14 }
tcpEStatsPathSumRTT OBJECT-TYPE
SYNTAX ZeroBasedCounter32
Mathis, et al [Page 39]
Internet-Draft Expires July, 2007 Mar 2, 2007
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC2988, Computing TCP's Retransmission Timer"
::= { tcpEStatsPathEntry 15 }
tcpEStatsPathHCSumRTT OBJECT-TYPE
SYNTAX ZeroBasedCounter64
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC2988, Computing TCP's Retransmission Timer"
::= { tcpEStatsPathEntry 16 }
tcpEStatsPathCountRTT OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of round trip time samples included in
tcpEStatsPathSumRTT and tcpEStatsPathHCSumRTT."
REFERENCE
"RFC2988, Computing TCP's Retransmission Timer"
::= { tcpEStatsPathEntry 17 }
tcpEStatsPathMaxRTO OBJECT-TYPE
SYNTAX Gauge32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum value of the retransmit timer RTO."
REFERENCE
Mathis, et al [Page 40]
Internet-Draft Expires July, 2007 Mar 2, 2007
"RFC2988, Computing TCP's Retransmission Timer"
::= { tcpEStatsPathEntry 18 }
tcpEStatsPathMinRTO OBJECT-TYPE
SYNTAX Gauge32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum value of the retransmit timer RTO."
REFERENCE
"RFC2988, Computing TCP's Retransmission Timer"
::= { tcpEStatsPathEntry 19 }
--
-- The following optional objects provide information about
-- how TCP is using the IP layer.
--
tcpEStatsPathIpTtl OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of the TTL field carried in the most recently
received IP header. This is sometimes useful to detect
changing or unstable routes."
REFERENCE
"RFC791, Internet Protocol"
::= { tcpEStatsPathEntry 20 }
tcpEStatsPathIpTosIn OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC3260, New Terminology and Clarifications for Diffserv"
::= { tcpEStatsPathEntry 21 }
tcpEStatsPathIpTosOut OBJECT-TYPE
Mathis, et al [Page 41]
Internet-Draft Expires July, 2007 Mar 2, 2007
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC3260, New Terminology and Clarifications for Diffserv"
::= { tcpEStatsPathEntry 22 }
--
-- The following optional objects characterize the congestion
-- feedback signals by collecting statistics on how the
-- congestion events are correlated to losses, changes in RTT
-- and other protocol events.
--
tcpEStatsPathPreCongSumCwnd OBJECT-TYPE
SYNTAX ZeroBasedCounter32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsPathEntry 23 }
tcpEStatsPathPreCongSumRTT OBJECT-TYPE
SYNTAX ZeroBasedCounter32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Sum of the last sample of the RTT (tcpEStatsPathSampleRTT)
prior to 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
Mathis, et al [Page 42]
Internet-Draft Expires July, 2007 Mar 2, 2007
(over some interval) just prior to a congestion signal."
::= { tcpEStatsPathEntry 24 }
tcpEStatsPathPostCongSumRTT OBJECT-TYPE
SYNTAX ZeroBasedCounter32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsPathEntry 25 }
tcpEStatsPathPostCongCountRTT OBJECT-TYPE
SYNTAX ZeroBasedCounter32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsPathEntry 26 }
--
-- The following optional objects can be used to detect other
-- types of non-loss congestion signals such as source quench
-- or ECN.
--
tcpEStatsPathECNsignals OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of congestion signals delivered to the TCP
sender via explicit congestion notification (ECN). This is
typically the number of segments bearing ECE bits but
should also include segments failing the ECN nonce check or
other explicit congestion signals."
REFERENCE
"RFC3168, The Addition of Explicit Congestion Notification
(ECN) to IP"
Mathis, et al [Page 43]
Internet-Draft Expires July, 2007 Mar 2, 2007
::= { tcpEStatsPathEntry 27 }
--
-- The following optional objects are receiver side
-- instruments of the path from the sender to the receiver. In
-- general the receiver has less information about the state
-- of the path, because the receiver does not have a robust
-- mechanism to infer the sender's actions.
--
tcpEStatsPathDupAckEpisodes OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC2581, TCP Congestion Control"
::= { tcpEStatsPathEntry 28 }
tcpEStatsPathRcvRTT OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
::= { tcpEStatsPathEntry 29 }
tcpEStatsPathDupAcksOut OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC2581, TCP Congestion Control"
Mathis, et al [Page 44]
Internet-Draft Expires July, 2007 Mar 2, 2007
::= { tcpEStatsPathEntry 30 }
tcpEStatsPathCERcvd OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of segments received with IP headers bearing
Congestion Experienced (CE) markings."
REFERENCE
"RFC3168, The Addition of Explicit Congestion Notification
(ECN) to IP"
::= { tcpEStatsPathEntry 31 }
tcpEStatsPathECESent OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC3168, The Addition of Explicit Congestion Notification
(ECN) to IP"
::= { tcpEStatsPathEntry 32 }
-- ================================================================
--
-- Statistics for diagnosing stack algorithms
--
tcpEStatsStackTable OBJECT-TYPE
SYNTAX SEQUENCE OF TcpEStatsStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"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."
Mathis, et al [Page 45]
Internet-Draft Expires July, 2007 Mar 2, 2007
::= { tcpEStats 5 }
tcpEStatsStackEntry OBJECT-TYPE
SYNTAX TcpEStatsStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry in this table has information about the
characteristics of each active and recently closed tcp
connection."
INDEX { tcpEStatsConnectIndex }
::= { tcpEStatsStackTable 1 }
TcpEStatsStackEntry ::= SEQUENCE {
tcpEStatsStackActiveOpen TruthValue,
tcpEStatsStackMSSSent Unsigned32,
tcpEStatsStackMSSRcvd Unsigned32,
tcpEStatsStackWinScaleSent Integer32,
tcpEStatsStackWinScaleRcvd Integer32,
tcpEStatsStackTimeStamps TcpEStatsNegotiated,
tcpEStatsStackECN TcpEStatsNegotiated,
tcpEStatsStackWillSendSACK TcpEStatsNegotiated,
tcpEStatsStackWillUseSACK TcpEStatsNegotiated,
tcpEStatsStackState INTEGER,
tcpEStatsStackNagle TruthValue,
tcpEStatsStackMaxSsCwnd Gauge32,
tcpEStatsStackMaxCaCwnd Gauge32,
tcpEStatsStackMaxSsthresh Gauge32,
tcpEStatsStackMinSsthresh Gauge32,
tcpEStatsStackInRecovery INTEGER,
tcpEStatsStackDupAcksIn ZeroBasedCounter32,
tcpEStatsStackSpuriousFrDetected ZeroBasedCounter32,
tcpEStatsStackSpuriousRtoDetected ZeroBasedCounter32,
tcpEStatsStackSoftErrors ZeroBasedCounter32,
tcpEStatsStackSoftErrorReason INTEGER,
tcpEStatsStackSlowStart ZeroBasedCounter32,
tcpEStatsStackCongAvoid ZeroBasedCounter32,
tcpEStatsStackOtherReductions ZeroBasedCounter32,
tcpEStatsStackCongOverCount ZeroBasedCounter32,
tcpEStatsStackFastRetran ZeroBasedCounter32,
tcpEStatsStackSubsequentTimeouts ZeroBasedCounter32,
tcpEStatsStackCurTimeoutCount Gauge32,
tcpEStatsStackAbruptTimeouts ZeroBasedCounter32,
tcpEStatsStackSACKsRcvd ZeroBasedCounter32,
tcpEStatsStackSACKBlocksRcvd ZeroBasedCounter32,
tcpEStatsStackSendStall ZeroBasedCounter32,
tcpEStatsStackDSACKDups ZeroBasedCounter32,
Mathis, et al [Page 46]
Internet-Draft Expires July, 2007 Mar 2, 2007
tcpEStatsStackMaxMSS Gauge32,
tcpEStatsStackMinMSS Gauge32,
tcpEStatsStackSndInitial Unsigned32,
tcpEStatsStackRecInitial Unsigned32,
tcpEStatsStackCurRetxQueue Gauge32,
tcpEStatsStackMaxRetxQueue Gauge32,
tcpEStatsStackCurReasmQueue Gauge32,
tcpEStatsStackMaxReasmQueue Gauge32
}
--
-- The following objects reflect TCP options carried on the
-- SYN or SYN-ACK. These options are used to provide
-- additional protocol parameters or to enable various
-- optional TCP features or algorithms.
--
-- Except as noted, the TCP protocol does not permit these
-- options to change after the SYN exchange.
--
tcpEStatsStackActiveOpen OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"True(1) if the local connection traversed the SYN-SENT
state, else false(2)."
REFERENCE
"RFC793, Transmission Control Protocol"
::= { tcpEStatsStackEntry 1 }
tcpEStatsStackMSSSent OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value sent in an MSS option, or zero if none."
REFERENCE
"RFC1122, Requirements for Internet Hosts - Communication
Layers"
::= { tcpEStatsStackEntry 2 }
tcpEStatsStackMSSRcvd OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value received in an MSS option, or zero if none."
Mathis, et al [Page 47]
Internet-Draft Expires July, 2007 Mar 2, 2007
REFERENCE
"RFC1122, Requirements for Internet Hosts - Communication
Layers"
::= { tcpEStatsStackEntry 3 }
tcpEStatsStackWinScaleSent OBJECT-TYPE
SYNTAX Integer32 (-1..14)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC1323, TCP Extensions for High Performance"
::= { tcpEStatsStackEntry 4 }
tcpEStatsStackWinScaleRcvd OBJECT-TYPE
SYNTAX Integer32 (-1..14)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC1323, TCP Extensions for High Performance"
::= { tcpEStatsStackEntry 5 }
tcpEStatsStackTimeStamps OBJECT-TYPE
SYNTAX TcpEStatsNegotiated
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
Mathis, et al [Page 48]
Internet-Draft Expires July, 2007 Mar 2, 2007
REFERENCE
"RFC1323, TCP Extensions for High Performance"
::= { tcpEStatsStackEntry 6 }
tcpEStatsStackECN OBJECT-TYPE
SYNTAX TcpEStatsNegotiated
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC3168, The Addition of Explicit Congestion Notification
(ECN) to IP"
::= { tcpEStatsStackEntry 7 }
tcpEStatsStackWillSendSACK OBJECT-TYPE
SYNTAX TcpEStatsNegotiated
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC2018, TCP Selective Acknowledgement Options"
::= { tcpEStatsStackEntry 8 }
tcpEStatsStackWillUseSACK OBJECT-TYPE
SYNTAX TcpEStatsNegotiated
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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
Mathis, et al [Page 49]
Internet-Draft Expires July, 2007 Mar 2, 2007
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."
REFERENCE
"RFC2018, TCP Selective Acknowledgement Options"
::= { tcpEStatsStackEntry 9 }
--
-- The following two objects reflect the current state of the
-- connection.
--
tcpEStatsStackState OBJECT-TYPE
SYNTAX INTEGER {
tcpESStateClosed(1),
tcpESStateListen(2),
tcpESStateSynSent(3),
tcpESStateSynReceived(4),
tcpESStateEstablished(5),
tcpESStateFinWait1(6),
tcpESStateFinWait2(7),
tcpESStateCloseWait(8),
tcpESStateLastAck(9),
tcpESStateClosing(10),
tcpESStateTimeWait(11),
tcpESStateDeleteTcb(12)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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."
REFERENCE
"RFC793, Transmission Control Protocol"
::= { tcpEStatsStackEntry 10 }
tcpEStatsStackNagle OBJECT-TYPE
Mathis, et al [Page 50]
Internet-Draft Expires July, 2007 Mar 2, 2007
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"True(1) if the Nagle algorithm is being used, else
false(2)."
REFERENCE
"RFC1122, Requirements for Internet Hosts - Communication
Layers"
::= { tcpEStatsStackEntry 11 }
--
-- The following objects instrument the overall operation of
-- TCP congestion control and data retransmissions. These
-- instruments are sufficient to fit the actual performance to
-- an updated macroscopic performance model [RFC2581] [Mat97]
-- [Pad98].
--
tcpEStatsStackMaxSsCwnd OBJECT-TYPE
SYNTAX Gauge32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum congestion window used during Slow Start, in
octets."
REFERENCE
"RFC2581, TCP Congestion Control"
::= { tcpEStatsStackEntry 12 }
tcpEStatsStackMaxCaCwnd OBJECT-TYPE
SYNTAX Gauge32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum congestion window used during Congestion
Avoidance, in octets."
REFERENCE
"RFC2581, TCP Congestion Control"
::= { tcpEStatsStackEntry 13 }
tcpEStatsStackMaxSsthresh OBJECT-TYPE
SYNTAX Gauge32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
Mathis, et al [Page 51]
Internet-Draft Expires July, 2007 Mar 2, 2007
DESCRIPTION
"The maximum slow start threshold, excluding the initial
value."
REFERENCE
"RFC2581, TCP Congestion Control"
::= { tcpEStatsStackEntry 14 }
tcpEStatsStackMinSsthresh OBJECT-TYPE
SYNTAX Gauge32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum slow start threshold."
REFERENCE
"RFC2581, TCP Congestion Control"
::= { tcpEStatsStackEntry 15 }
tcpEStatsStackInRecovery OBJECT-TYPE
SYNTAX INTEGER {
tcpESDataContiguous(1),
tcpESDataUnordered(2),
tcpESDataRecovery(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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 which is still
unacknowledged."
REFERENCE
"RFC2581, TCP Congestion Control"
::= { tcpEStatsStackEntry 16 }
Mathis, et al [Page 52]
Internet-Draft Expires July, 2007 Mar 2, 2007
tcpEStatsStackDupAcksIn OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of duplicate ACKs received."
REFERENCE
"RFC2581, TCP Congestion Control"
::= { tcpEStatsStackEntry 17 }
tcpEStatsStackSpuriousFrDetected OBJECT-TYPE
SYNTAX ZeroBasedCounter32