Subject: [Tsvwg] TCP ESTATS PipeSize vague

From: Matt Mathis <[email-masked]>
Date: Thu, 9 Feb 2006 10:48:05 -0500 (EST)

I have been applying the MIB doctor's comments to the TCP ESTATS MIB.  Many of
the "easy" fixes have already been posted to the web draft which can be
obtained from: <http://www.web100.org/mib/>.

Some of the other comments need more clarification or discussion.

>From the MIB doctor review:

15. I am confused about how tcpEStatsPerfPipeSize is to be
implemented. What determines if RFC 3517 is in effect, and how does
a management application know this? Is there a MIB object that
provides this information, if not should there be one?

The object in question:

tcpEStatsPerfPipeSize  OBJECT-TYPE
    SYNTAX          Gauge32
    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, this is the same as ``Flight Size''
        as defined in RFC2581.

        While in recovery, this is the same as ``pipe'' as defined
        in RFC3517.

        If RFC3517 is not in effect, the data octets in flight can
        be estimated as SND.NXT minus SND.UNA plus any
        retransmitted data, minus some measure of the data that has
        left the network. 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"
    ::= { tcpEStatsPerfEntry 15 }

Although the general concept of "pipe" (or "flight size") is well known and in
fairly common use in the tsvwg/tcpm community, there are several different
algorithms that might be used to compute it.  The goal of the algorithm is to
estimate the amount of undelivered data still in the network based on imperfect
knowledge about the state of the network (in particular in advance of any
information needed to distinguish between missing and late (reordered)
segments). RFC3517 describes one specific very conservative algorithm in
standards language.  However 3517 is NOT required, nor does it claim to be
optimal.  It is understood in the tsvwg/tcpm communities that "improvements" to
3517 are permitted, as are entirely different algorithms as long as they
"follow the spirit of TCP's congestion control algorithms [RFC2581, RFC2914]."
(quote from 3517)

About signaling which algorithms are present: there is infinite possible
variation on these algorithms.  I can't imagine a useful way to represent all
of the possible algorithms.

So where does this leave the MIB?  I choose to include all of:
1) Abstract definition w/o reference to implementation
2) Normative reference to a non-required specification
3) A method to estimate it from typical state variables in common older TCP
	implementations (in this case the majority of deployed TCP's).

This leaves the management station in the following position: If it has no
specific knowledge about the TCP implementation it can only assume #1 above,
the abstract definition.

However, if the management station (or the user) does have specific information
about the implementation, it is possible to do deeper inferences into the TCP
state.   E.g. estimating 'dupacks' from PipeSize, SndNxt and SndUna in an older
TCP.

This theme is repeated in several places in the ESTATS MIB, most of which
elicited MIB doctor comments.   How should it be handled?   Do I need more
clarifying language?

One TCP technical issue: many older TCP's do not explicitly track retransmits.
Is even including this term too "avant-garde"?

As always, feedback is appreciated.

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by people who think they know
"The Truth" and use force to apply it to others.

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 10 Feb 2006 00:28:09 +0100

I believe Dan is out-of-office today, so he'll probably
respond later.

I think Dan explained why it is unclear what exactly is being
reported in the object. I think you explained why it is
difficult to report which algorithm is being used. 
If people in tsvwg think that such is OK, then I guess
that is it. But it will make mgmt applications life 
more trouble some.

One way to solve it (possibly) is to add an object that gets
a textual convention as a SYNTAX, and that TC gets registered
and maintained by IANA, so that new algorithms can be easily
be defined/added. Just thinking aloud here.

Bert

> -----Original Message-----
> From: Matt Mathis [mailto:[email-masked]]
> Sent: Thursday, February 09, 2006 16:48
> To: Dan Romascanu; Transport WG
> Cc: Wijnen, Bert (Bert); TCP ESTATS MIB team
> Subject: TCP ESTATS PipeSize vague
> 
>