Re: [ippm] WGLC for draft-ietf-ippm-responsiveness

["Ben Janoff (bjj)" <[e-mail]>]

Hi all,

We have been working on an implementation of this test based on draft 02
which used plain HTTP instead of HTTPS due to resource constraints. The
draft 03 does include the possiblity of HTTP in the URLs for server
discovery but the formula for aggregated responsiveness doesn't specify
what should be computed in the plaintext case.

I've written a suggested addition to the draft to specify the
computation that resource constrained implementations can use, to ensure
that any future plain HTTP implementations have a compatible definition
of aggregated responsiveness.

My suggested edits are below.

In 4.1.  Working Conditions, add the following section:
---
4.1.4.  Avoiding Test Hardware Bottlenecks

   The Responsiveness Test could be run from various devices which are
   either consumer devices or internet infrastructure such as routers.
   Many routers are cost-sensitive embedded devices optimised for
   switching packets rather than terminating TLS connections at line
   rate.  As a result, they may not have sufficient processing power or
   memory bandwidth to saturate a bottleneck link in order to be a
   useful test client for the responsiveness test.

   In order to measure responsiveness from these devices, the test can
   be conducted without TLS over plain HTTP.  Whenever possible, it is
   preferred to test using TLS to resemble typical internet traffic to
   the maximum extent.
---


In 4.3. Measuring Responsiveness, edit the following paragraphs:
---

   Foreign probes will provide three (3) sets of data-points: First, the
   duration of the TCP-handshake (noted hereafter as tcp_f).  Second,
   the TLS round-trip-time (noted tls_f).  For this, it is important to
   note that different TLS versions have a different number of round-
   trips.  Thus, the TLS establishment time needs to be normalized to
   the number of round-trips the TLS handshake takes until the
   connection is ready to transmit data.  In the case that TLS is not
   being used, it is undefined.  And third, the HTTP elapsed time
   between issuing the GET request for a 1-byte object and receiving the
   entire response (noted http_f).

   Self probes will provide a single data-point that measures the
   duration of time between when the HTTP GET request for the 1-byte
   object is issued on the load-generating connection and when the full
   HTTP response has been received (noted http_s).  For cases where
   multiplexing GET requests into the load generation connections is not
   possible (e.g. due to only HTTP/1.1 being available), the TCP stack
   estimated round-trip-time can be used as a proxy or substitute value.
---


In 4.3.1. Aggregating the Measurements, modify the paragraph level and
insert the additional section:
---
4.3.1.1.  For the TLS-Enabled Case

   The algorithm produces sets of 4 times for each probe, namely: tcp_f,
   tls_f, http_f, http_l (from the previous section).  The
   responsiveness of the network connection being tested evolves over
   time as buffers gradually reach saturation.  Once the buffers are
   saturated, responsiveness will stabilize.  Thus, the final
   calculation of network responsiveness considers the last MAD (Moving
   Average Distance - default to 4) intervals worth of completed
   responsiveness probes.

   Over that period of time, a large number of samples will have been
   collected.  These may be affected by noise in the measurements, and
   outliers.  Thus, to aggregate these we suggest using a trimmed mean
   at the TMP (Trimmed Mean Percentage - default to 95%) percentile,
   thus providing the following numbers: TM(tcp_f), TM(tls_f),
   TM(http_f), TM(http_l).

   The responsiveness is then calculated as the weighted mean:

   Responsiveness = 60000 /
   (1/6*(TM(tcp_f) + TM(tls_f) + TM(http_f)) + 1/2*TM(http_s))

   This responsiveness value presents round-trips per minute (RPM).

4.3.1.2.  For the TCP-Only Case

   If there are no TLS connections being used, then the notion of a
   normalised round-trip time for the TLS handshake does not apply.
   Zeroes cannot be substituted for tls_f, as that will result in an
   artificially low responsiveness value.  Instead, the same principle
   of weighing each contribution to the foreign RTT equally (and then
   weighting the foreign and self RTTs equally) is applied.

   The TCP-only responsiveness is therefore calculated as the weighted
   mean:

   Responsiveness = 60000 /
   (1/4*(TM(tcp_f) + TM(http_f)) + 1/2*TM(http_s))
---

Best regards
        Ben