Subject: [Tsvwg] RE: TCP ESTATS PipeSize vague

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 14 Feb 2006 16:07:11 +0200

I apologize for getting to this rather late, but I was away for a long
weekend and a stack of issues accumulated on my virtual desk. 

It seems to me from what you explain that the common practice described
in RFC 3517 represents the default method based on a 'conservative
algorithm'. It looks that if there are considerable differences between
the results provided by different algorithms an object indicating what
algorithm is used, or at least that the TCP implementation supports RFC
3517 would be useful for interoperability. However, I will not resist
violently of the WG reaches consensus that the current level of
ambiguity of the estimation is 'well-enough'.

Regards,

Dan

> -----Original Message-----
> From: Matt Mathis [mailto:[email-masked]] 
> Sent: Thursday, February 09, 2006 5:48 PM
> To: Romascanu, Dan (Dan); Transport WG
> Cc: Wijnen, Bert (Bert); TCP ESTATS MIB team
> Subject: TCP ESTATS PipeSize vague
> 
> 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: Matt Mathis <[email-masked]>
Date: Thu, 16 Feb 2006 12:45:31 -0500 (EST)

While in recovery (e.g. following lost data) pipesize is an estimator: it is
using incomplete information to guess the state of the network.  There is an
uncountable number of algorithms that might be work.  Furthermore the
tsvwg/tcpm community generally views tinkering with estimators to be a good
thing, because improving the estimators improve TCP operation some part of the
Internet.  Note that, in most common environments theses estimators yield
nearly the same results.

The intent of the MIB object is to precisely expose whatever estimator this TCP
is using, without constraining the TCP implementation.  This has two audiences:
to a general management station, unreasonable values might indicate that some
network or protocol event confused the estimator.  To a TCP implementer (with
specific knowledge about this specific implementation) this is useful for
debugging/evaluating the estimator.

The document does not make this case well enough.  I propose to add some
discussion about estimators in the overview, plus change the description of
PipeSise to:
          "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 bytes 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 the same as ``pipe'' as defined in in RFC3517 if it
           is 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
           can 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"

Does this make the level of ambiguity more palatable?

Thanks,
--MM--
The latest update to draft-ietf-tsvwg-tcp-mib-extension-08.txt
can be obtained from http://www.web100.org/mib
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------

> ambiguity of the estimation is 'well-enough'.

<snip>