[Bloat] [aqm] ping loss "considered harmful"

[Kathleen Nichols]

Somewhat apropos of this discussion, Pollere has been working on passive
techniques to measure latency under a DoE SBIR grant. Although these
can be used on an end-host, the goal is to deploy anywhere. But part of the
goal with SBIR grants is to figure out a revenue stream. As Dave has noted,
this is not all that easy to do for "fix the Internet" kind of things.
Similar to
Dave (though not as dire since my spouse decided to work for the big G and
thus give me the ability to tinker with problems I like), I worked on
CoDel "for
free" and the only revenue I got from it was a small contract with
CableLabs.
Now, I didn't set out to make money from it, it was intially a fun
project to
do as an antidote to nine crappy work months and I kind of got into it when
the aforementioned spouse sort of pulled one of those Tom Sawyer painting
the fence moves on me.

However.

Are these kinds of projects just always going to be done as sidelines or
will
anyone want to pay, either by licensing a finished approach or sponsoring
a new one? I'm about to explore the former soon, but I do wonder if this
isn't quixotic.

	Kathie

On 3/2/15 2:54 AM, Jonathan Morton wrote:
> 
>> On 2 Mar, 2015, at 12:17, Mikael Abrahamsson <swmike at swm.pp.se>
>> wrote:
>> 
>> On Mon, 2 Mar 2015, Brian Trammell wrote:
>> 
>>> Gaming protocols do this right - latency measurement is built
>>> into the protocol.
>> 
>> I believe this is the only way to do it properly, and the most
>> likely easiest way to get this deployed would be to use the TCP
>> stack.
>> 
>> We need to give users an easy-to-understand metric on how well
>> their Internet traffic is working. So the problem here is that the
>> users can't tell how well it's working without resorting to ICMP
>> PING to try to figure out what's going on.
>> 
>> For instance, if their web browser had insight into what the TCP
>> stack was doing then it could present information a lot better to
>> the user. Instead of telling the user "time to first byte" (which
>> is L4 information), it could tell the less novice user about packet
>> loss, PDV, reordering, RTT, how well concurrent connections to the
>> same IP address are doing, tell more about *why* some connections
>> are slow instead of just saying "it took 5.3 seconds to load this
>> webpage and here are the connections and how long each took". For
>> the novice user there should be some kind of expert system that
>> collects data that you can send to the ISP that also has an expert
>> system to say "it seems your local connection delays packets",
>> please connect to a wired connection and try again". It would know
>> if the problem was excessive delay, excessive delay that varied a
>> lot, packet loss, reordering, or whatever.
>> 
>> We have a huge amount of information in our TCP stacks that either
>> are locked in there and not used properly to help users figure out
>> what's going on, and there is basically zero information flow
>> between the applications using TCP and the TCP stack itself. Each
>> just tries to do its best on its own layer.
> 
> This seems like an actually good idea.  Several of those statistics,
> at least, could be exposed to userspace without incurring any
> additional overhead in the stack (except for the queries themselves),
> which is important for high-performance server users.  TCP stacks
> already track RTT, and sometimes MinRTT - the difference between
> these values is a reasonable lower-bound estimate of induced
> latency.
> 
> For stacks which don’t already track all the desirable data, a socket
> option could be used to turn that on, allocating extra space to do
> so.  To maximise portability, therefore, it might be necessary to
> require that option before statistics requests will be valid, even on
> stacks which do collect it all anyway.
> 
> Recent versions of Windows, even, have a semi-magic system which
> gives a little indicator of whether your connection has functioning
> Internet connectivity or not.  This could be extended, if Microsoft
> saw fit, to interpret these statistics and notify the user that their
> connection was behaving badly in the ways we now find interesting.
> Whether Microsoft will do such a thing (which would undoubtedly piss
> off every major ISP on the planet) is another matter, but it’s a
> concept that can be used by Linux desktops as well, and with less
> political fallout.
> 
> Now, who’s going to knuckle down and implement it?
> 
> - Jonathan Morton
> 
> _______________________________________________ aqm mailing list 
> aqm at ietf.org https://www.ietf.org/mailman/listinfo/aqm
>