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

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

>>> 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.