[Rpm] [ippm] draft-ietf-ippm-responsiveness

[rjmcmahon]

>> Debuggability is not "rocket science" either, all one needs is a
>> three value timestamp format (similar to what NTP uses) and one can,
>> even without synchronized clocks! establish baseline OWDs and then
>> under bi-directional load one can see which of these unloaded OWDs
>> actually increases, so I argue that "it is impossible to
>> differentiate whether the observed latency happens in the uplink or
>> the downlink direction" is simply an incorrect assertion... (and we
>> are actually doing this successfully in the existing internet as
>> part of the cake-autorate project
>> [h++ps://github.com/lynxthecat/cake-autorate/tree/master] already,
>> based on ICMP timestamps). The relevant observation here is that we
>> are not necessarily interested in veridical OWDs under idle
>> conditions, but we want to see which OWD(s) increase during
>> working-conditions, and that works with desynchronized clocks and is
>> also robust against slow clock drift.
>> 
>> Unfortunately, this would require for the server to add timestamps
>> to the HTTP-response, right ?
> 
> [SM] Yes in a sense.... but that could be a a small process that
> simply updates the content of that file every couple of milliseconds,
> so would not strictly need to be the server process...
> 
> Which would kill the in-memory caching the servers do. And some
> webserver implementations actually have the ability to generate
> “random” data on-the-fly without a backing file behind it (like
> “statichit” in ATS
> https://docs.trafficserver.apache.org/en/9.0.x/release-notes/whats-new.en.html).
> 
>>> We opted against this because the “power” of the
>>> responsiveness methodology is that it is extremely lightweight on
>>> the server-side. And with lightweight I mean not only from an
>>> implementation/CPU perspective but also from a deployment
>>> perspective. All one needs to do on the server in order to provide
>>> a responsiveness-measurement-endpoint is to host 2 files (one very
>>> large one and a very small one) and provide an endpoint to
>>> “POST” data to. All of these are standard capabilities in
>>> every webserver that can easily be configured. And we have seen a
>>> rise of endpoints showing up thanks to the simplicity to deploy
>>> it.
>>> 
>>> So, it is IMO a balance between “deployability” and
>>> “debuggability”. The responsiveness test is clearly aiming
>>> towards being deployable and accessible. Thus I think we would
>>> prefer keeping things on the server-side simple.
>>> 
>>> Thoughts ?
>> 
>> [SM] I really really would like some way to get OWDs if only
>> optional, but even more than that I think RPM should get as wide a
>> deployment as possible, ubiquity has its own inherent value for
>> measurement platforms, so if this makes deployment harder it would
>> be a no-go.
>> 
>> Now, I get that this is a long shot, but I fear that if the draft
>> does not mention this at all the chance will be gone forever....
>> Could we maybe add a description of an optional 'time' payload, so
>> clients could expect a single standardised format for that, if a
>> server would optionally support it?
> 
> Well, if we describe the optional ’time’ payload, we also need to
> specify how the clients are gonna use it and expose that information.
> Meaning also, having some kind of implementation experience with it,
> running code, …
> 

I wonder if a solution here is to have a secondary tool that supports 
OWD in more of a diagnostic manner would be an approach that works. RPM 
indications are only the beginning to trigger and affect a full 
diagnostic panel using standard tools that have been statistically 
vetted and can be trusted as accurate? That's what we'll do in WiFi 
automation testing, use RPM as a first level test and use more advanced 
tooling for more complete diagnostics.

Bob