Subject: RE: [Tsvwg] RE: TCP ESTATS PipeSize vague

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 16 Feb 2006 21:09:42 +0200

Yes, this is better, but I have two questions:

- in the fourth paragraph, do we need to capitalize SHOULD? 
- in the fifth paragraph can we change 'can be estimated' in 'SHOULD be
estimated'? 

Thanks and Regards,

Dan

> -----Original Message-----
> From: Matt Mathis [mailto:[email-masked]] 
> Sent: Thursday, February 16, 2006 7:46 PM
> To: Romascanu, Dan (Dan)
> Cc: Transport WG; Wijnen, Bert (Bert); TCP ESTATS MIB team
> Subject: Re: [Tsvwg] RE: TCP ESTATS PipeSize vague
> 
> 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
> -------------------------------------------
> 
> On Tue, 14 Feb 2006, Romascanu, Dan (Dan) wrote:
> 
> > 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
> 
> <snip>
> 

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

---

From: Matt Mathis <[email-masked]>
Date: Thu, 16 Feb 2006 16:46:36 -0500 (EST)

Done!  Thanks,
--MM--

---

From: Matt Mathis <[email-masked]>
Date: Thu, 23 Feb 2006 14:48:13 -0500 (EST)

As a result of the discussion about "ESTATS PipeSize vague", I decided to add a
section (pasted below) to clarify the relationship between this MIB and the
relatively vague TCP standards.

Dan and Bert, Is this acceptable from MIB Dr perspective?

Does this text bother anyone?

Thanks,
--MM--
   3.1. Relationship to TCP standards

   There are more than 70 RFCs and other documents that specify various
   aspects of the Transmission Control Protocol (TCP) [roadmap].  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 is solved by TCP is
   balancing the upper protocol layer's need for a fast and reliable
   data transport service 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
   example RFC2988 describes how to calculate the retransmission timer,
   RTO, from the 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 fundamentally 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" [RFC2026].  Even standard
   algorithms that are required because they critically effect fairness
   or the dynamic stability of the Internet congestion control, include
   some latitude for evolution.  As a consequence there is considerable
   diversity in the details of the TCP implementation actually in use
   today.

   Since the underlying algorithms are not uniform, it 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 than the estimators in use
   by TCP.  This would make the MIB more useful as a measurement tool,
   but less useful for understanding how this specific TCP
   implementation is interacting with the network path and upper
   protocol layers.  We chose instead to have the MIB expose the actual
   estimators and important states variables of all 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 this TCP implementation, 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.  To a general management station
   it can only assume the the abstract descriptions, which are useful
   for general assessment of how TCP is functioning. To a TCP
   implementer with detailed knowledge about a specific TCP
   implementation this MIB might be useful for debugging or evaluating
   the specific algorithms in this implementation.

   Under no conditions is this MIB intended to constrain TCP to use (or
   exclude) any particular estimator, heuristic, algorithm or
   implementation.