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

[Christoph Paasch <[e-mail]>]

Hello Ben!

Thanks for your pull-request at https://github.com/network-quality/draft-ietf-ippm-responsiveness/pull/96.


Christoph

> On Dec 18, 2023, at 8:28 AM, Ben Janoff (bjj) <bjj=[e-mail]> wrote:
> 
> 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
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm