Re: [ippm] Testing TCP Throughput Capacity in Operator Networks

[Matt Mathis <matt.mathis at gmail.com>]

Opps I forgot to paste in the references:

[NPAD] M. Mathis, J. Heffner, P. O'Neil, P. Siemsen, "Pathdiag:
Automated TCP Diagnosis", PAM 2008.  See also:
http://www.psc.edu/networking/projects/pathdiag/

[CAP] M. Allman "Measuring End-to-End Bulk Transport Capacity" ACM
SIGCOMM Internet Measurement Workshop 2001.

[RFC3148] M. Mathis, M. Allman, "A Framework for Defining Empirical
Bulk Transfer Capacity Metrics", RFC3148, July 2001.

[RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Framework for
IP Performance Metrics", RFC2330, May 1998.

[MODEL] M. Mathis, J. Semke, J. Mahdavi, T. Ott, "The Macroscopic
Behavior of the TCP Congestion Avoidance Agorithm", Computer
ommunication Review, volume 27, number 3, July 1997.

[TReno] M. Mathis, "Diagnosing Internet Congestion with a Transport
Layer Performance Tool", Proceedings of INET'96, June, 1996, Montreal,
Quebec.

Thanks,
--MM--

On Thu, Oct 15, 2009 at 2:52 PM, Matt Mathis <matt.mathis at gmail.com> wrote:
>>>> My thoughts are similar to Henk's.  IPPM has always been interested in
>>>> the area (see the bulk transport capacity work), so I'd claim the area
>>>> is in-scope, but doing work would require AD discussion.
>>>
>>> I think it wouldn't be unreasonable for IPPM to take this on, if we more
>>> clearly nail down what "this" is.
>
> You might want to consider finishing the work started in RFCs 2330 and
> 3148 as a sufficient definition of "this".
>
> Developing a Bulk Transport Metric has been sort of a holy grail of
> IPPM from the very beginning.    It was my primary agenda when I
> co-chaired the BOF at the Danvers IETF, April 1995).    After
> publishing a tool [TReno] and making some important progress [RFC2330,
> RFC3148, and Marl Alman's[CAP] the effort was abandoned essentially
> because the results were not sufficiently robust to be useful to
> support SLAs.  [NPAD] was my latest chapter of my efforts in this
> area.
>
> Although there are many difficulties with using TCP (notably
> differences in implementations as noted in other messages) the real
> killer is this:
>
> TCP congestion control is an equilibrium process.  Correctly
> functioning TCP with sufficient data ALWAYS causes congestion
> somewhere in the network.  This congestion manifests itself by raising
> the RTT and/or the packet loss until the data rate is consistent with
> the the model[MODEL]:
> date_rate=(MSS/RTT)*(0.7/squrt(loss_probability))   The problem is you
> can't tell how much of the congestion was caused by your measurement,
> and how much was already present in the network.   This causes sort of
> a double Heisenberg problem where you can't even tell if you are
> measuring bowling balls with pingpong balls or vice versa.  This is
> because the "stiffness" of a TCP flow (think "first derivative of the
> model") depends on the RTT, so when there are multiple flows sharing a
> bottleneck, each flow yields a different amount, depending on their
> relative RTTs.   If the measurement flow has a very short RTT, it will
> push nearly all other traffic out of the bottleneck, if the cross
> traffic has a short RTT, it will greatly depress the data rate of the
> measured folw.  As a consequence a simple measurement with a single
> TCP flow is useless for predicting performance of another flow through
> the same bottleneck.   Note that a non-predictive measurement is
> useless to the point where it can't really be called a metric.
>
> THIS IS REALLY IMPORTANT: even with an ideal TCP implementation and
> network, equilibrium TCP performance is useless as a metric.
>
> The trick (used by NPAD) is the throttle TCP with a controlled
> bottleneck, such that it does not cause congestion....
>
> This can be done using an RFC 4898 instrumented stack under real
> applications.   I will describe it in email in a bit, and a
> presentation at IPPM, if people are interested.    No I do not have
> enough cycles to generate an ID in time for the submission deadline.
>
> Thanks,
> --MM--
> -------------------------------------------
> Matt Mathis      http://staff.psc.edu/mathis
> Work:412.268.3319   Home/Cell:412.654.7529
> -------------------------------------------
> Evil is defined by mortals who think they know
> "The Truth" and use force to apply it to others.
>