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

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 23 Feb 2006 23:57:54 +0200

This text looks OK to me. Just an editorial question. Is [roadmap] in
the first sentence supposed to point to some reference? Which one? 

Thanks and Regards,

Dan

> -----Original Message-----
> From: Matt Mathis [mailto:[email-masked]] 
> Sent: Thursday, February 23, 2006 9:48 PM
> To: Romascanu, Dan (Dan)
> Cc: Wijnen, Bert (Bert); TCP ESTATS MIB team; Transport WG
> Subject: TCP ESTATS: TCP standards vague
> 
> 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--
> 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
> -------------------------------------------
>    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.
> 
> 

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

---

From: Matt Mathis <[email-masked]>
Date: Thu, 23 Feb 2006 17:09:47 -0500 (EST)

Sorry, [ROADMAP] is draft-ietf-tcpm-tcp-roadmap-05.txt

Thanks,
--MM--